Yes because we are skipping every second frame it's 17.5FPS which is not the most pleasant experience, so would be great to add a no-frameskip setting. Even with full overclock the calculator has in a few areas still trouble to even reach 20 or 25FPS so that automatic frameskip would be great too.

Alright, now about the newly added Save/Load function. It works perfectly but if you try to load in a save file from another WAD it gives me a System ERROR. Inputting a name is a bit slow because it takes some time for the typed character to appear on screen. So would be great if you could make that one a bit faster because if you type too fast it skips characters. Also is there any way to put numbers into the name? I like to name my savefiles starting with the name of the WAD and then the episode (if any). For example: DOOM1 E2 or DOOM2.

One thing which is really annoying is that always after saving the game it kicks you out of it which is bad. I know this has something to do with the WAD mapping not being correct anymore after writing a save file to flash but there has to be a better solution.
First up we have 3MB of RAM. So let's use it. My idea is to store all the savefiles while the game is running to RAM and also load them from there. Savefiles don't have a consistent size because they grow steadily the more you do in a level. So just to be safe I would cut from the end of the 3MB RAM a slice of 500KB off.
Here is how it will work:
Starting the game: look for savefiles in flash and load them into 500KB zone of RAM
Load Game: load the game savefile from 500KB zone of RAM
Save Game: write the game savefile into 500KB zone of RAM
Quit Game: write all the savefiles from RAM on the flash to store them permanently

As you can see with this approach we don't use the flash at all while the game is running which should eliminate that the WAD isn't mapped correctly. The drawback of this method is that it takes up some RAM and it will have to do a lot of writing to flash at the end which might be a bit slow. Maybe you can also add a progressbar to show how long the user has to wait and also only write changed / new savefiles to flash.

I used to think that 17.5 FPS is butter smooth! You're raising the bar to whole new levels here. But I like it, your directions have already helped incredibly.

I've changed the VARS button to cycle between frameskip 0, 1, 2 and 3. This indicates how many frames are skipped after each render. The default setting is 1, the "smooth" and "fast" settings of VARS previously were 1 and 3.

Unfortunately it's really hard to clear the gap between 17.5 FPS and 35 FPS, even with full overclock, so it remains to be seen whether the game can be played at consistent speed (35 tics/s) without frameskip.


I had noticed the slow reaction time. Displaying the FPS counter shows a significant FPS drop whenever the 6 rectangles with save names are shown. The reason for that is that each rectangle is rendered with 24 segments of a short bar section, and the lump for that section is accessed by name 24 times in a row, for all 6 rectangles. You can see the function in action here.

Since the lump is mentioned by name, lump name resolution occurs 24 times for each of the 6 rectangles, and due to the location in the shareware WAD 800 comparisons of lump names need to be performed to find it (even when it's already loaded). That's right, this simple graphical detail causes more than 100'000 name comparisons per frame. This would occupy a whopping 1500ms in the profiler, which dropped down to 79 ms once I factored everything properly.

I've added the space character (DOT key) as well as digits to save description input. For digits you need to press ALPHA and then press the digit key before releasing ALPHA.

To avoid problems with saves from different WADs conflicting with each other, I've decided to name each save file <WADname>_<number>.dsg. This way, you can't have doom_1.dsg interfere with, for instance, doomu2_1.dsg. And of course you can only load each when playing their respective WADs. You also get 6 save slots per WAD instead of 6 total. This works quite well because the fx-CG 50 filesystem supports file names longer than 8 characters.


The idea of saving everything to RAM and committing to ROM when leaving is pretty reasonable, plus there are less drawbacks than you might expect.

The save data is first generated over the screen buffers (which allows up to ~160 kB). Once the data is generated, we know its exact size and so we can copy it somewhere else. But there's no need to rely on a specific region, we can simply use Z_Malloc to find memory. There are plenty of levels with enough room for it even without the 3 MB extension. If Z_Malloc fails, we can just save immediately and quit as a fallback.

I've implemented that method, and set the "game saved" message to something clearer. The writing to ROM is indeed a bit slow, so I've added another UI screen with a progress bar on exit. Creating the file takes most of the time and I can't access any progress information for that, but I think it looks pretty neat nonetheless.

Not saving immediately adds a little bit of complexity to the menus, since ideally we'd want the Save Game menu to show the name of the (yet unsaved) entry and the Load Game menu to be able to use it. I've programmed both of these so the illusion should be complete (unless the game crashes in which case you lose the save, obviously). It's pretty good!

Super quick bug report:
You move anymore while shooting.
I want to test the zero frameskip option a bit more, so would be great if you can fix that. You're right it's butter smooth.

Saving in game can mess up status bar for some reason.

I'll take a closer look at the improved save/load function tomorrow.

Fixed!


Fixed!

Thank you for your input as usual. Critor just made a really nice post on TI-Planet about CGDoom too, things are looking really good right now. I hope we can wrap up soon with decent performance and maximum compatibility!

I have some good news (and a bad one).
First up, the save/load function works perfectly, is super fast (thanks to the RAM saving) and entering a name works now a lot better. The saving at the end is a bit slow (especially in the creation of a file) but it's not too bad.

Playing Doom is now a completly new experience and is super smooth for the most part!

I also wanted to extend the WAD support a bit with one of my favourite custom WAD: Freedoom Phase 1. Not Phase 2 because this one wouldn't fit on it and there isn't a good way to make it smaller.

Freedoom Phase 1 is way to big with 26MB to fit on the calc. So I did it exacly like the Ultimate Doom WAD E[1-4]. And I got it working with the first episode!! It's a bit slow sometimes but overall not too bad. I didn't find any bugs so perfectly playable. The only thing is once again the wrong level names but this can be fixed later.
The problem is with the other episodes. Episode 2 doesn't want to work and it gives me a System ERROR at the start.

I uploaded all my custom WADs here, so you can also test a bit with them because I have no idea what I'm doing wrong especialy because it worked so good the first time.

Critors post is definitly worth a read although I did notice there were some outdated information.

I'm happy you liked the latest changes!

I just want to mention briefly that I have made more progress in the PC build of CGDoom. It now boots properly, and can load into E1M1. It does not yet simulate the calculator API very realistically but it will do later. This build is not of incredible interest but will help with screen captures, videos wherever performance does not need to be portrayed exactly, and possibly some future debugging. Plus I felt bad about destroying the Windows version that Martin Poupe had set up.

It appears like the focus now is going to be on WAD support (to my delight!). I think I will briefly publish the current version of CGDoom while advertising support for Doom I (possibly Doom II), and then work my way from here - I have put off a release for too long. ^^

I want to check all important WADs to not miss anything. I believe this is the latest state of things:

* Doom I: shareware works, Ultimate Doom works, Ultimate Doom episodes work
* Doom II: now works, if I understand this post correctly?
* The Plutonia Experiment: ? (is it compatible with the base engine?)
* TNT: ? (same question?)

* Heretic (original): ?
* Heretic: Shadow of the Serpent Riders: missing textures, crashes according to this post

* Fallout: ?
* Pinochestein 3D: ?

* Counter-strike (5-level version, 32-level version): ? (playable according to Critor)
* HellRaiser: ?

* Freedoom Phase1: episode 1 works (#295332), episode 2 fails (#295332)

Yes, you're understanding my post correctly, Doom II definitly works with 3MB extra RAM. I also tested every single level just to be sure and no problems with that.

Plutonia and TNT might be just small enough to fit if you remove the audio. I'll test that and also some of the other ones!

If you want to make a first release don't forget to add the run key (a few levels in Doom and Doom II require this)

Edit:
TNT and Plutonia gave me both a System ERROR at startup.
cstrike.WAD: visplane errors at some point
Hellraiser: doesn't start - R_InitTextures: Missing patch in texture DS1/DS2 -> System ERROR afterwards
Pinochestein 3D: seems to be working - still need to the all the levels

Ok, good! I also tested it briefly by loading all the levels, which works even without the extra RAM. I made the "Title Screen" option turn to "Skip" automatically if the starting episode/map is changed to make the process a bit faster. I also renamed the extra RAM option "Use experimental RAM" to avoid any confusion on its exact meaning.

I think we can say now that Doom II is officially supported! \o/

You're right I forgot about the keyboard, I'll go back to it to add the Run and Strife keys, then maybe test the alternate keyboard layout that I wanted to create as an option (with more fingers on the keyboard) before a full release.

I found a bug with saving.
To clarify it further: this one happened in E1M5 in Freedoom which is one of the largest levels and it consumes more than half of the extened RAM.
I managed to fill the entire save buffer with a 228KB save file (how large can they even get?). And then it screwed everything up. The name of the first savefile was gone and slightly moved to the right. After trying a second time to save to the first slot, it created a fifth savefile which shouldn't be there. I then quit the game and it seemed to save the file but after reloading Freedoom and trying to load the savefile it didn't work anymore. :/


Yes, that works but if you get further into specific levels (like level 15) you will eventually get a Z_Malloc error without the extra RAM.

I also noticed some key problems. When I press up-right on the "D-Pad" and x² it pauses the game which should only happen if you press the OPTN key above. A similar thing happens when pressing ALPHA. Then it sometimes seems to press SHIFT for the BFG9000.
I also tried it on another calculator, that isn't too used, and got pretty much the same result, so it may not be a keyboard problem that occurs if you used the calc too much.

I tested a bit more through Freedoom E1 and found this error in E1M2 and at the end of E1M5: R_DrawSpriteRange: bad texturecolumn. This one happens also at a few other places for some reason.

Not sure what the point of the Fallout WAD is. It's just Doom II with a few changed graphics and it takes up more space. No new levels but it seems to be fully working with extended RAM.

In terms of keyboard, I've played around quite a lot and decided to do things "the right way".

First, I did some adjustments to the controls. I reenabled an option called "slow turning" which reduces turn speed in the first few tics of a left/right key press, which is very useful to aim accurately (turns at 320 units/tic instead of 640). I also bumped the standard turning speed from 640 to 720 for slightly easier 180-degree turns. More would be uncomfortable because fast turning at 17.5 FPS is too jaggy. Finally, I enabled running via a toggle key and made sure the turning speed remained the same while running.

I mapped this run key and the strafe keys closer to the main controls; specifically I put "toggle run" on [X,θ,T], "strafe left" on [log] and "strafe right" on [ln]. It's fairly usable, but any feedback is welcome if you see better alternatives.

I also tweaked the layout a little bit further, by which I mean that I moved the Cheat key from [^] to [,] (next to the noclip key). The reason for that is ghosting. In CGDoom 0.3 by MPoupe you could only press a single key at once, but now you can press any number, which gives rise to ghosting issues. The top area of the keyboard is heavily used, so it's easy to encounter ghosting problems. There was one specifically on the [^] key, and I could hardly ever finish E1M1 without accidentally cheating. You probably have accidentally selected the BFG9000 by shooting while moving diagonally at some point; that's also a ghosting effect on [SHIFT] (I didn't fix this one).

After this, I created a new built-in keyboard layout called "full hands" which is played with all fingers over the calculator. It has a directional pad on [OPTN] |ALPHA] [x²] [^], directional keys on [F5] and [F6] (the arrow keys are less ergonomic when you switch from left to right), and the main action keys near thumbs at [DEL] and [×]. It is carefully designed to avoid ghosting effects.

To be 100% honest with you, the full-hands mode is vastly superior to thumbs-only. I can finally feel some of the PC experience of Doom when using it, because strafing is so natural and the WASD-style directional pad benefits from my brain habits from playing other games on PC. I finished a 100% kills, 100% secrets run of E1M1 in 02:38, and I didn't even run (except for that one secret) because it was too jaggy for 17.5 FPS.

I moved some of the more advanced options (specifically the debug ones) into an "Advanced options..." section on the main menu to clean up a bit of space, then added the important piece that is the controls editor. It can not only select between three built-in key maps (the original CGDoom 0.3, the current one, and the full-handed one), but also edit each key individually to try out new combinations.

But then of course you want to keep the same controls from one run to another, so I made the add-in save the settings just before you load a WAD. It takes about a second, it's mostly transparent. Other options are saved too. Here is an example file:

Code:

The file is loaded at startup if it exists; typical stuff. Less typical is the fact that atoi() didn't work on the calc, it took me a while to figure that one out. It was fun generating the file on-calc then loading it on the PC build to debug the parsing, though!

-


That's ghosting. The keyboard has a row/column layout, so basically if you press any 3 keys on 3 corners of a square then the 4th key is read as pressed as well. The two lines and two columns of the square don't need to be adjacent. For instance :

• Press 1, 3, 7 : ghost press on 9.
• Press Up (second row, rightmost key), Right (third row, rightmost key), x² : ghost press on OPTN.
• Same thing happens if you press Down-Left.
• Press either diagonal and ALPHA : ghost press on SHIFT.

You can't do anything about it, it's a hardware problem. PC keyboards have the same problem, but better technology to solve it. Search things like "anti-ghosting" or "NKRO" if you want to learn more. The calculator keyboard, like any key matrix of the kind, is 2KRO.

To avoid this problem you need to decouple lines and columns. If you look closely, in my full-hands layout, I don't use SHIFT or VARS to avoid ghosting from three arrow keys. I don't use the D-Pad to avoid ghosting from two movement keys + one directional key. I use DEL and × for the main actions and cos to run because no other keys are used on that column. Some of auxiliary stuff are on the last column because I assume that you release the left/right key (F5/F6) to use them.

-

I've further reduced the distance between the calculator build and the SDL2 one; some memory layout is now emulated, and the keyboard code that was split before is now shared. I'm thinking if I implement demo recording on the calculator version I could use the PC version to replay the demos and record clean videos to showcase the program. While such videos wouldn't reflect actual performance, it would show control handling as well as supported games. Heck, I could even make a basic control overlay!

-


Wow, how extreme! The original Doom code would not allow save files larger than 192 kB. I can fix that; the basic idea is to detect when the buffer is overrun, then continue generating the save by overwriting the start of the save data, and when it's finished Z_Malloc a new buffer of the required size and redo the save there. There are other methods but it should be enough. I'll test and push that when I get to FreeDoom (sorry I'm not faster!).


Sounds like an error in the WAD, to be honest. There is a chance that it also occurs on PC but either goes unnoticed (just a message in the terminal) or is disabled (there is a RANGECHECK macro guarding the error test). Worst case we can probably just hide the error and ignore the faulty draw operation.

There's much more to do, I'm on it!

Really like the new key editor. I played a bit around with it and changed a bit the Thumbs only preset:
-> 7-BFG9000: 7
-> Pause: AC/ON
These changes should eliminate the ghosting issues. The other preset "Full hands" is also very interesting but it's still a bit hard to play with that because every key is different. But I will test it a bit more.

The Run key works, as well as strafing. I thought you would do not a Run toggle button, but like in the DOS version where you need to have it pressed in order to run. But with the ghosting problems this is probably the right way and you don't have to hold permanently your finger on it.
What is a bit annoying about the placement of the run key is that it's right next to the strafe buttons which you press much more frequently. So would be nice if you can put the run key a bit more to the right and make X,O,T and log the strafe buttons. The run key could be tan.

The main menu is really nice looking cleaned up. Options saving is also very useful and especially that it goes automatically to Skip Title screen when selecting another starting map. This will help a lot for testing!


This sounds very cool! Demo recording on a calculator! This is probably the first time this will ever happen.


Hm, that's bad. The problem is that after it shows the error message you can't continue the game. Can you hide the error and only show it in the messages to see if it still works then?

Here is another little bug I found:
the melting screen effect lags sometimes. This might be because the game loads the background from flash and is sometimes a bit too slow.

One thing I always didn't like was the icon. I mean it's now in fx-CG50 style but it was very s t r e c h e d. For that reason I made pretty much the same icon completly new from scratch. Thanks btw for uploading the templates again. Without them this would have been much harder. This took quite a while to make but I'm pretty happy with the end result. If you still want to change something, I also uploaded the XCF files.

Here is the download link: https://drive.google.com/file/d/1MzxBUhXT76uwCfEmLF0jcnxZlq7jzBXy/view?usp=sharing
This is an improved version, please use this version above! ↑

Thank you very much! I applied your suggestions to the Thumbs-only keymap. I'll try and post a photo of how to place fingers on the keyboard for the full-hand mode at some point, I think it might be unclear.

Yes so I chose to use a Run toggle button because of the chances of ghosting and the fact that we only have a limited number of thumbs to put on keys in the common layout. I'll admit I generally don't run at all since it goes too fast. Then again I could play without frameskip and enjoy slow motion to set some good speedrun scores :]


Well it works now! This way I can show good quality videos of the engine. There is now a main menu option that lets you select a demo slot to record. It records all inputs from when you spawn into the world to when you leave with MENU, even going through intermissions. Each slot corresponds to a file name like doomu_demo18.lmp which contains the WAD name so that it can be replayed easily.

The demo files are completely standard, which means you can inject them into the WAD with SLADE and view it from the title screen. (Barring engine compatibility problems you could also submit them to challenges or speedruns!)

When there are demo files in the storage memory, a new option "Replay demo..." appears, which can be used to replay demos directly from CGDoom (assuming you didn't remove the WAD). For instance here's a demo of me completing 100% kills and 100% secrets on shareware Doom's E1M1 in 2 minutes flat : https://www.planet-casio.com/storage/forums/doom_demo01-184724.zip . In case you're wondering, yes I can replay it on the PC build and make a video capture of it! (You'll notice in the larger room that I am much more precise in real-time with the full-hands keymap, resulting in a pretty clean series of shots)

The demo file size is limited to 64 kiB (kind of small) when experimental RAM is disabled, and 128 kiB (the engine's normal size) when it's enabled. The file is written to ROM when leaving the add-in, just like game saves, so you get to see the file name as well as a progress bar.

I did a lot of internal cleaning and refactoring regarding options and variables floating around, which allowed me to add logic to the main menu so that if you don't change any options the settings aren't re-saved when starting the WAD, as the extra second was still bugging me a little bit.


I've temporarily disabled that error so that you can test. I'll look on the PC eventually to see if the WAD or the code is responsible.


When exactly is that? Before adding the experimental memory I made one last memory optimization which consists in displaying full-screen images (title screen, intermissions, help screens) directly from ROM without loading them. (You might remember that they sometimes failed to load because of fragmentation, causing errors at intermissions.)

The process by which I do that is somewhere between fairly slow and very slow, though, so it might be the cause. I've never seen issues so I haven't tried to optimize it specifically so far.


And of course you spend all this time making a new icon the exact same day that I changed it myself to a different design. In fact I received a notification for your message while making the last adjustments on color. How unlucky is that?! xD

I don't really like the old icon too much either, it doesn't blend very well with the theme of the main menu. I've wanted to make a standard icon for some time, and for that I knew the DOOM logo alone would be better (Doom guy on top is too high). I hope you like it, if not I can try and make a blend of the two designs. You version is very clean especially on the sides, you've done a fantastic job in my opinion. ^^

This is insanely cool! Recording demos and watching them back is so much fun!
I also recorded my own demo of UV 100% kills/secrets in 1:23 with Thumbs only + Running and played on an overclocked calculator with Frameskip 0 (no slow-motion tricks).

Something I noticed is that when you're replaying a demo and open the menu the demo gets completly thrown off and dies.

In Freedoom it sadly crashes with a System ERROR when getting the error.


It's one of the errors that happens sometimes and most of the time not like before with the Z_Malloc errors on the Intermission screen. I'll try to get a video if I manage to get this one again so you can get a better idea what I mean.


Oh no! I guess we both had the same idea when you uploaded the templates again. Your icon also looks very nice and fits better with the other icons. But how would it look if you blend the designs together? Maybe you can place Doomguy on the bottom left corner?
One thing I wanted you to ask for a while is if it's possible to get this version of CGDoom running on the older CG10/20. This version will of course not have the extra RAM and have probably the old save style that quits the game. But I think my icon would work perfectly for this version. I just need to change the selected background.

I finally released a first version of the game!! You can see the topic on Planète Casio.

You're already well aware of all the features and changes so there's no point getting into specifics here. Just note that I renamed the repository so the URL has changed, in the future the G3A can be found here: https://gitea.planet-casio.com/Lephenixnoir/CGDoom


Ok, I see you! I don't mind a little competition right there. I took me ~15 tries but here I am with a 1:08 (demo file here). I had to enable running with frameskip 0 and overlock like you, otherwise I wouldn't be precise enough. The run is fairly clean otherwise, I didn't hit too many walls along the way, except that I threw the ending.

I've opened a small leaderboard on the official topic to try and raise interest into this. Maybe more people will join the fray! :p

Wohoo! First release! ^_^
Your 1:08 run is really good. There is for sure still some improvement possible but I'm bad at full hands so I'm not gonna try it right now.

The SDL2 version already seems to be working very well as I could see it from your video. Would really like to try out this one as well!

I also managed to record a video of the melting screen bug: https://www.youtube.com/watch?v=dJ-RaThBXWg
The bug happens two times in the video: at 1:00 and 2:45

If you want to watch something else I also have a video of an interesting palette glitch (see the video description for more details): https://www.youtube.com/watch?v=Sf1plU2EGPk
This one reminds me of printer Doom.

Two other things:
Can you show the startup messages like R_Init: Init DOOM refresh daemon? I think this could help for testing to see why a WAD crashes at startup.
Another thing that would be very nice is to show the end screen (the ANSI-text in the WAD) because right now the last thing CGDoom shows on screen is just garbage.

Edit:
I found another little bug:
I can't enter any numbers / spaces in the save name anymore.

I also put Doomguy onto your icon. Hope you like it.
https://drive.google.com/file/d/18MozhIJH9_BeUaq3GD2omShEZ9KulSF0/view?usp=sharing

Just a quick message to say I'm still here, but I've resumed full-time research work (theoretical computer science!) this month so that's why I'm very slow. I've still published an article recently and I absolutely do intend to come back for WAD compatibility up to FreeDoom once I clean up my current tasks!

Good too hear! Just take your time. I'm also pretty busy at the moment with developing my first (good) game. Your article is très bien and definitly worth a read like Critor's article on TI-Planet.

[quote="Lephe"] The #1 problem, which fixes almost all add-ins, is using a hardcoded VRAM address. Due to physical reasons the RAM on the fx-CG 50 starts at 0x8c000000, not 0x88000000, and so the VRAM moves as well. Just use the GetVRAMAddress() syscall instead of the VRAM_ADDR macro (not sure how it's usually called), recompile, and most programs will work out of the box, and even on both platforms with the same g3a. Additionally, many programs set some overclock on fx-CG 10/20 for a little added speed. The CPU of the fx-CG 50 natively runs faster than the fx-CG 10/20 (specifically twice as fast), and so this overclock step is no longer needed. It is even detrimental as the configuration it sets is slower than the default. This overclock step can thus be skipped. You can heuristically detect the fx-CG 50 with the stack address (if it's < 0x8c000000 -> fx-CG 10/20, if it's higher -> fx-CG 50).

Is this possible to do with an add in like [PRIZM] cookie clicker? (https://www.cemetech.net/downloads/files/1127/x1127#review-676), I've been trying to get it to work on my CG50 for ages now yet just no graphics run, all it ends up showing is a white screen with no graphics or textures.

I don't see any sources for this add-in... unless the sources are available somewhere, it would take a lot of reverse-engineering work to get this trivial change done.

(For anyone wondering, no the address 0x88000000 doesn't appear verbatim; for some reason, some compilers like to load constants like these with left shifts. 88xx is the opcode for cmp/eq #xx, r0 so there can be confusions, although 8800, should not appear as tst r0, r0 is generally preferred. I don't personally have time to disassemble and investigate.)