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:
% cat CGDoom.cfg
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!
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.
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!
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.
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!).
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.
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!