[New GOG.com Versions Of Game Ports More Wrapper Fixes.
Saija Grzegorek
Hi all,
Let me introduce you to the following source ports inspired by Chocolate Doom, now also covering Wolfenstein 3D:
This is a 6 years anniversary release. On September 26 2014, I released a new port of Keen Dreams, initially titled "Chocolate Keen Dreams".
Although Keen Dreams was released earlier in the same month, I actually started some work on it even earlier, after the Catacombs were open-sourced (in June 2014). Reason is that I already knew that a lot of the code was common.
Following Keen Dreams, I added Catacomb Abyss, then Catacomb 3-D, and finally the rest of the Catacomb Adventure Series.
Recently, I've been working on the source ports again. With the assistance of the gamesrc-ver-recreation/wolf3d tree, the last release introduces support for Wolfenstein 3D, Spear of Destiny (excluding the mission packs) and Super 3-D Noah's Ark (DOS version).
For Wolfenstein 3D, this currently covers Apogee shareware versions 1.0, 1.1, 1.2 and 1.4 (the one with cheats), as well as 6-episodes Activision v1.4.
For Spear of Destiny, this covers FormGen demo v1.0 and Activision v1.4.
For Super 3-D Noah's Ark, this covers the one Wisdom Tree DOS version that I'm aware of.
There are still some problems. In particular:
- You can't save games or load saved games in Wolf3D and the games based on it.
- These games have no support for the "modern" game controller scheme. I think that the other games should still have it, though.
- For technical reasons, you can't load the Spear of Destiny mission packs.
- More generally, you can't load TCs made to work with original EXEs from the 90s (as released by id and/or related publishers). I still haven't decided how to approach this.
- In order to detect game data, you also need the original DOS exe (albeit the 2015 edition of Keen Dreams is an exception).
- For Super 3-D Noah's Ark, this exe currently has to be named noah3dos.exe, as this is the way it arrives from Steam right now. Currently, there's no good way to support auto-detection of data with alternative file names.
- The rate of palette updates in Wolfenstein 3D is at least somewhat imprecise.
- VSync is disabled by default for now. There are other potential problems with timing in Wolfenstein 3D, which might partially be related to instances in which the game tries to render more often than the host display's refresh rate.
- Stereo panning remains unimplemented.
- For the Wolfenstein 3D based games, if you try to use a wall right after pushing it, the behaviors are essentially undefined.
Yeah, I got a similar report from someone else about this. It's basically another example of a bug I wasn't aware of, due to the project not being as commonly used, and/or due to not having a good place for bug reports. Basically, the program was inspecting the contents of "C:" instead of "C:\". Here, my understanding is that "C:" refers to the most recently set directory in the C drive.
I've actually just uploaded a hotfix release which should resolve this problem, as well as a stale menu item non-deterministically being reproduced in SOD and the Activision version of Wolf3D, depending on the way the exe is built. The usual "Releases" page on GitHub should have the last release.
Yeah, I got a similar report from someone else about this. It's basically another example of a bug I wasn't aware of, due to the project not being as commonly used, and/or due to not having a good place for bug reports.
I have the GOG Catacombs Pack installed, but it's not automatically detected. That's because at one point in time GOG.com updated the installation package and changed the location in the registry, which means now two registry locations will have to be checked. In be_cross_fs.c you already check for "SOFTWARE\\GOG.COM\\GOGCATACOMBSPACK". The new location is at "SOFTWARE\\GOG.com\\GAMES\\1207659189". The number apparently represents the product ID: . For the same reason my GOG Wolfenstein 3D installation isn't detected either. That one is located at "SOFTWARE\\GOG.com\\GAMES\\1441705046", see .
In Catacomb Abyss I get a crash when trying to travel to map slot 19 with the F10+W cheat. Although the dialog box asks for a number 0-18, it is actually possible to go to map 19 when playing Catacomb Abyss in DosBox. See _Tester_3 .
I can reproduce the problem. At least in this case, there's a map that can be loaded, but I think that with later, non-existent maps, the behaviors are more-or-less undefined. Keen Dreams v1.00 has a similar issue with empty map slots.
In Keen Dreams v1.00, ((mapfiletype id0_seg *)tinf)->headersize[mapnum] was set to 0 for mapnum == 6, meaning that I can detect this case in CA_CacheMap and then possibly report a new (non-vanilla) error. With the original DOS EXE, you might get one possible error out of two, which isn't related to the lack of a map, and/or possibly also a hang. Thus, there's probably no problem with making the port quit with a specific error message in this case.
Here, the levelnames array, located at dseg:1300, is immediately followed by the level name strings themselves. Thus, levelnames[19] technically translates to the first two bytes of the string "The Towne Cemetery", which are 0x6854 (in Little-Endian order).
This implies that it the code in question tries to read a string literal from the grsegs array. Why? Well, NUMCHUNKS is 626, implying that the grsegs array has the size of 1252 i.e., 0x4E4 bytes. This is exactly the difference between the offsets of the following addresses in the EXE:
When leaving level 19 (or possibly even just restarting level 19), CA_CacheMap will not free the memory previously referenced by mapheaderseg[19], because this pointer variable, which is actually textstarts[0], has already been set to 0.
One possible way to handle this in a port is as follows. The mapheaderseg array length can be increased by 1, and then mapheaderseg[19] (i.e., mapheaderseg[NUMMAPS+1]) can be reset to 0 right after being used in SetupGameLevel.
I'm unsure about any later level. I'll first ignore possible issues with levelnames. Just like mapheaderseg[19] refers to textstarts[0], mapheaderseg[20], mapheaderseg[21] and mapheaderseg[22] refer to the following 3 locations in the textstarts array. Main difference is that these offsets are generally nonzero when CA_CacheMap is called. Thus, it'll try to set their purge levels with MM_SetPurge.
An exception to the above is level 21 in v1.13. In that case, I'm not currently sure what exactly occurs, but it looks like a case of buffer overflow. I get a minor screen corruption, followed by a crash of DOSBox.
If it isn't a case of levelnames[21] (which seems to reference one of the values in shapesize) leading to an overflow in a call to US_CPrint, then maybe MM_SetPurge actually finds a matching address, and thus we get some problems.
LATE UPDATE: ok, I think that I've found the cause of the problem. While there's no overflow in the length of levelnames[21], this is how the string looks like as a sequence of bytes: 2F 06 15 07 73 33 00
What happens is that ShiftPropChar from ID_VW_AE.ASM should be called once per char. When it's called with the value of bx == 6, [es:charwidth+bx] (i.e., currfont->width[charnum] in Reflection Catacomb) is 0, so the si register is also set to 0. It remains set to 0 even after a few more manipulations on it. Eventually, an attempt to jump is done as follows:
When I learned about the possibility to warp beyond level 18, combined with the fact that GAMEMAPS.ABS actually contains 23 levels, my first thought was how to get all the hidden levels to load. Because I wanted to see in first person view what kind of levels the developers made for test purposes.
It's nice to see how you approach the very same topic from a different viewpoint. I now fully realise that the "chocolate" philosophy brings its own challenges. It seems certainly not trivial to accurately replicate bugs, when the original memory layout is lost due to the usage of a modern compiler.
Although sounds like not quite so much in this particular case it seems, it's not just using a modern compiler but also the CPU architecture change. x86-16 had interesting memory wrapping properties due to the way memory was addressed. Plus primitive types changing sizes (especially pointers since integer sizes can usually be forced) all means even if things were laid out in the same order things still wouldn't line up correctly once built as x86-32 or x86-64.
I'm actually unsure that I got to visit all warp-only levels in the Catacombs, not to mention the generally inaccessible levels of The Catacomb Abyss. If it weren't for checking in an editor or another source port, I'd probably assume that these were not that far from empty map slots.
The comment about memory wrapping is true. It was especially important while implementing the CGA graphics routines for Keen Dreams, which generally output the graphics to a buffer in system memory instead of video memory. I remember running into problems with this, until I read a comment about memory wrapping from David Gow (developer of Omnispeak and the SDL2 port of Keen Dreams), which was actually related to EGA graphics.
795a8134c1