CatacombGL - source port for the Catacomb 3D games

[SiFi270]

I meant the one before Abyss.

And tab+o doesn't seem to be doing anything in Wolf3D's debug mode. Maybe it's the person who wrote that page who has them mixed up.

[Arno]

Oh wow, thanks! I learn something new every day! I just tried it myself in Catacomb 3D; it works quite well. The whole map can be viewed via the arrow keys and the destructible walls are marked. I also found the related source code in C3_DEBUG.C. It would be nice to have this in all four games.

[taufan99]

Neat! Although I think the binary markers could be more indicative of what they represent. Perhaps convert them into small icons?

[NY00123]

Going to reply on Tab+O as used in Wolf3D, but this might be the chance to finally write a bit about Catacomb 3-D ports in general.

 

So, with regards to CatacombGL itself, very good job! Nice to see that less commonly played games like these get the attention, and not just from me.

 

Personally, I wasn't very familiar with the Catacombs when I started. I probably saw just a few bits of Catacomb 3-D beforehand. I got exposed to Dangerous Dave very long ago, though, so it was obviously not done via the Gamer's Edge Sampler Disk, at least not in a way which lets you select Catacomb. I also got familiarity with the Keens, again quite a while ago.

 

After the Catacombs were open-sourced, I had small work on files from the id Engine, in case it may become useful for some Keen game.

Eventually, they only got used for an actual released project of mine after Keen Dreams was open sourced. I started with the CGA graphics for Keen Dreams, with support for EGA versions being added afterwards. My port was initially titled "Chocolate Keen Dreams". Later on, I (eventually) ported all 3D Catacombs, beginning from Catacomb Abyss. I also gave up "Chocolate" for "Reflection" after adding Catacomb Abyss support. Thus, we now have "Reflection Keen".

 

Someone identified as NotStiller was also experimenting with a Catacomb 3-D port. The initial commit was done about 2 weeks before Keen Dreams was open-sourced: https://github.com/NotStiller/Catacomb3D/

 

Either way, good job again. While it's obvious that users of ports prefer them to run natively, version 0.4.3 is already working well for me under Ubuntu, using Wine.

 

On 5/12/2020 at 11:38 PM, SiFi270 said:

And tab+o doesn't seem to be doing anything in Wolf3D's debug mode. Maybe it's the person who wrote that page who has them mixed up.

 

I've checked this. The overhead map is accessible in Wolf3D shareware v1.0 with Tab+O, although the data is missing 16x16 tiles required for proper map display. Enabling cheats in v1.0 is just a little bit different than in v1.1+, but it's otherwise the same.

The code was disabled using "#if 0" blocks, but is still present in the sources as originally released, within WL_DEBUG.C.

 

The earlier alpha build from March 1992 also supports this, and has the 16x16 tiles in the VGAGRAPH data. F10 is used in this prototype instead of Tab; Just like Keen Dreams and Keen 4-6, and also like Catacomb 3-D and Catacomb Abyss.

 

A few side-notes:

1. Catacomb Armageddon & Apocalypse changed to using Backspace for the debug keys instead of F10. The same thing was done for Blake Stone. I have a feeling that this is not a coincidence.

2. On the other hand, Catacomb Armageddon & Apocalypse both had the "statetype" structs moved to far memory, something which was also done during the development of Bio Menace. Unlike the debug keys example, this does look like a coincidence to me.

 

Edited June 19, 2020 by NY00123

[Arno]

Thanks for your detailed post, @NY00123.

Reflection Keen is well known among Catacomb players and it helped me save a lot of time when developing CatacombGL. Thanks to the source code of Reflection Keen, it was little effort for me to get sound effects and music working in CatacombGL. I especially love the PC speaker emulation. It also helped to see how you translated all the assembly code to C. In that respect, you posting here that you like what I've done so far with CatacombGL means a lot to me. Although it is also fair to point out that this source port would not have been in its current state if it wasn't for all the play testing and bug reporting done by some good folks on this forum and elsewhere.

 

I've played the Catacomb Abyss shareware in the 90's. I think among gamers that's also by far the most well known game in the Catacomb series. I wasn't familiar with the other games until I started development on the source port. Which is a shame, because I think I would have loved to play Armageddon and Apocalypse on my 486 back in the day.

 

It's nice to see how the overhead map functionality of Catacomb 3D was reused in Wolfenstein 3D. Luckily, the Catacomb adventure series also have the 16x16 tiles in their EGAGRAPH data, so I should be able to get the overhead map working in those games.

[NY00123]

@Arno I was surprised (at least a bit) when I discovered the existence of the Catacomb Wiki, obviously due to my assumption that there's a significantly lower interest in the Catacombs than in, say, Commander Keen. I guess that eventually, one individual is sufficient for launching a new Wiki.

 

I know that there was at least one attempt to mod any of the 3D Catacombs, but I don't know if anything using Catacombs code was released.

 

I saw that you re-used Reflection Keen for the sound code. I didn't think about the notion of inspecting the C translation of assembly code, although in a retrospect, this actually makes sense. Nice to see my work for the Catacombs being useful in this manner, given what I presumed to be low interest in the series again.

Another example of work which I'm aware of is an Amiga port of Reflection Keen, done by someone identified as "BSzili": https://github.com/BSzili/refkeen/tree/amiga

 

One thing about CatacombGL which I did notice a while ago is that, while it was clear to me that you used the original sources as a reference, CatacombGL is mostly looking like new code, implementing various features somewhat differently. It's possible that I may get differing impressions based on the filenames. Consider ECWolf for one example. While it's obvious that it has differences from the DOS versions, say, due to support of DECORATE for modding and the differing video output code, it still has enough code which clearly comes from Wolfenstein 3D.

 

I thought that Catacomb 3-D was maybe a bit more well-known than Abyss, due to being the first, and also since I think that it was (probably mistakenly) included in at least one BBS and two CDs of game collections; At least one of these CDs is identified as a collection of shareware games.

 

A couple of more points about CatacombGL development:

- I've wondered how feasible it can be to re-implement Carmack's software renderer. Since Catacomb 3-D's renderer can be seen as an early prototype of Wolfenstein 3D's renderer, though, maybe it's better to use the one from Wolf3D as a base (unless you do want Cat3D's one).

- I see that you actually considered making CatacombGL compatible with saved games from the original DOS versions. I assume that this covers just saved game loading, due to CatacombGL working in other ways internally? You maybe further saw that there might be a problem with even defining such compatibility for Armageddon/Apocalypse.

 

For the ones who don't know, this is related to my previously mentioned example of "statetype" structs being moved to far memory for these games. Basically, pointers to such states are written to saved games. In Cat3D and Abyss, and also in KDreams, Keen 4-6 and Wolf3D, these are 16-bit near pointers, consisting of 16-bit offsets. These offsets depend just on the layout of a specific EXE for DOS. With the structs moved to far memory, though, each such pointer is a 32-bit value consisting of a 16-bit segment and a 16-bit offset. In theory, the segment should also depend just on the EXE. In practice, though, the exact location of the first loaded segment depends on the environment (e.g., available memory), and this also impacts the locations of all following segments.

 

Catacomb Armageddon and Apocalyse (the original DOS versions) still write and read saved games as usual, but there's no guarantee with regards to the stability of the segment values. In particular, if you start the game from DOSBox, save a game, then restart it with LOADFIX and then load the game, there are great chances that you'll get the game to a seemingly undefined corrupted state.

 

The situation is different in the case of Bio Menace, for which the "statetype" structs were also moved to far memory. This was actually the reason for changing the game to bring you back to the beginning of the corresponding level after loading a saved game. In the Bio Hazard prototype, which still has the states in near memory, you can load a saved game and find yourself in the middle of a level, albeit it's not without issues.

[Arno]

@NY00123 Indeed, CatacombGL consists mostly of new code. My goal was to write a basic game engine from scratch as a learning experience. The renderer is based on OpenGL. The movement is handled in floating point and runs with 1 ms clock ticks to allow for an uncapped framerate. The original games are capped at 70 Hz. Mouse/keyboard input is handled via SDL2. The sound and music code is obtained from Reflection Keen. On top of that I applied the gameplay mechanics as seen in the original Catacomb source code. The end result doesn't have that much similarities with the original engine from Carmack, but I think it reasonably resembles the look and feel of the original games. So conceptually it's developed in a similar fashion as the RAD source port from jval. Or like Daggerfall Unity, but on a much smaller scale.

 

About Carmack's software renderer, I've read in the Wolfenstein 3D Game Engine Black Book that in the Catacomb engine the walls are rendered by rasterizing polygons, while in the Wolfenstein 3D engine this is done via raycasting. Carmack recalled that the Catacomb engine did not work as robust as he would have liked to see. Sometimes additional wall segments pop up. Sprites that are too close to the player can disappear. This was one of the reasons that Carmack dropped rasterization in Wolf 3D and went for raycasting.

I can understand that for some players these peculiarities of the original software renderer are a genuine part of the experience when playing the Catacomb games. But I feel that Reflection Keen already has that covered and it doesn't really have my interest to bring the full "chocolate" experience into CatacombGL as well. I do have some interest in replicating the 320x200 screen resolution, but that's about it.

 

Thanks for the detailed explanation of the save game compatibility hurdles. It confirms my suspicion that it will be hard to implement. I indeed only intend to cover the loading of saved games, i.e. allowing players to resume play in CatacombGL from a save point that was made in DosBox or Reflection Keen. The other way around, converting the partially floating point data structs from CatacombGL into a saved game file that the original games can read, seems too much of a hassle.
 

[bnabradi]

I'm using the newest version of catacombGL (40.1) , and after entering the mausoleum,the mouse decided to lag horribly and keeps doing that. it might have to do something with my fps being "1134" and else...even when i turn on Vsync,so it should be 75 max.....

[Arno]

Hi @bnabradi. Thanks for the feedback!

So far I'm not sure what could have caused the mouse to lag. I do know there used to be a major bug with mouse movement in older releases, but I fixed that in version 0.4.1. The latest version is 0.4.3. An fps of 1000+ is pretty common and shouldn't impact the mouse movement.

Does the mouse stutter while looking around, or is it just very slow? Dd you try to adjust the mouse sensitivity in the Controls menu?

[bnabradi]

49 minutes ago, Arno said:

Hi @bnabradi. Thanks for the feedback!

So far I'm not sure what could have caused the mouse to lag. I do know there used to be a major bug with mouse movement in older releases, but I fixed that in version 0.4.1. The latest version is 0.4.3. An fps of 1000+ is pretty common and shouldn't impact the mouse movement.

Does the mouse stutter while looking around, or is it just very slow? Dd you try to adjust the mouse sensitivity in the Controls menu?

I downloaded version 0.4.3 (the x86 version too) and it seems to be fixed. i'll come back if i see anything.

[bnabradi]

22 hours ago, Arno said:

Hi @bnabradi. Thanks for the feedback!

So far I'm not sure what could have caused the mouse to lag. I do know there used to be a major bug with mouse movement in older releases, but I fixed that in version 0.4.1. The latest version is 0.4.3. An fps of 1000+ is pretty common and shouldn't impact the mouse movement.

Does the mouse stutter while looking around, or is it just very slow? Dd you try to adjust the mouse sensitivity in the Controls menu?

So ,it happened again in the aquaducts level,and to a much worse degree......turns out for some reason the port started murdering my processor (it's an i5-7600k),and instead of giving me less fps, it made my mouse lag horribly (this time, it almost froze completely,but i still could move around,only the looking-around part was affected).
I also was recording the footage via Nvidia shadowplay ,but as far as i know, shadow play is optimized for minimal effect on game performance,and the probem did not get better when i stopped the recording.......
I really should buy a better processor. 

[Arno]

44 minutes ago, bnabradi said:

So ,it happened again in the aquaducts level,and to a much worse degree......turns out for some reason the port started murdering my processor (it's an i5-7600k),and instead of giving me less fps, it made my mouse lag horribly (this time, it almost froze completely,but i still could move around,only the looking-around part was affected).
I also was recording the footage via Nvidia shadowplay ,but as far as i know, shadow play is optimized for minimal effect on game performance,and the probem did not get better when i stopped the recording.......
I really should buy a better processor. 

That's strange. I actually use an i5 as well, although not in combination with an Nvidia GPU. I have to use the onboard Intel graphics. When VSync is disabled, by design the game uses the maximum capacity of the GPU and one CPU core to produce as much frames as possible. That's nice for benchmarking, but under normal circumstances it's better to enable VSync. I can imagine that recording software will also have a hard time to read from the frame buffer when it gets flushed a 1000+ times per second. In my case, with VSync enabled (at 60 fps), the game uses about 2% of my CPU and 10% of the GPU. So your processor should be more than sufficient.

I wonder, maybe your Nvidia control panel tries to enfore certain VSync settings on the game?

[bnabradi]

1 hour ago, Arno said:

That's strange. I actually use an i5 as well, although not in combination with an Nvidia GPU. I have to use the onboard Intel graphics. When VSync is disabled, by design the game uses the maximum capacity of the GPU and one CPU core to produce as much frames as possible. That's nice for benchmarking, but under normal circumstances it's better to enable VSync. I can imagine that recording software will also have a hard time to read from the frame buffer when it gets flushed a 1000+ times per second. In my case, with VSync enabled (at 60 fps), the game uses about 2% of my CPU and 10% of the GPU. So your processor should be more than sufficient.

I wonder, maybe your Nvidia control panel tries to enfore certain VSync settings on the game?

Will try,thank you. also, i just finished a session. it's weird,because when i start the game, it's silky smooth, and after a level,or two it steadily becomes more and more laggy.

[bnabradi]

2 hours ago, Arno said:

That's strange. I actually use an i5 as well, although not in combination with an Nvidia GPU. I have to use the onboard Intel graphics. When VSync is disabled, by design the game uses the maximum capacity of the GPU and one CPU core to produce as much frames as possible. That's nice for benchmarking, but under normal circumstances it's better to enable VSync. I can imagine that recording software will also have a hard time to read from the frame buffer when it gets flushed a 1000+ times per second. In my case, with VSync enabled (at 60 fps), the game uses about 2% of my CPU and 10% of the GPU. So your processor should be more than sufficient.

I wonder, maybe your Nvidia control panel tries to enfore certain VSync settings on the game?

I forced vsync and the problem seems to be completely gone. thank you very much.

[Arno]

7 hours ago, bnabradi said:

I forced vsync and the problem seems to be completely gone. thank you very much.

You're welcome. Good to hear that the issue appears to be resolved.

[bnabradi]

12 hours ago, Arno said:

You're welcome. Good to hear that the issue appears to be resolved.

I have another question. Is it possible with the port,to maybe add music (midi or mp3 files) to the levels? just finished armageddon,and i had a lots of "oh this would be great with this and that track".

[Arno]

On 11/23/2020 at 8:44 PM, bnabradi said:

I have another question. Is it possible with the port,to maybe add music (midi or mp3 files) to the levels? just finished armageddon,and i had a lots of "oh this would be great with this and that track".

I have that feature on my todo list, but it might take a while before I get to it. Nevertheless, thanks for the suggestion. It's good to know that multiple people are interested in the ability to play custom music files.

[Arno]

CatacombGL 0.5.0 is released!

Many thanks for all the feedback that has been provided since the last release.

 

Automap

The biggest addition to this release is the automap feature, as suggested by @Master O.
The automap can be opened up via the cheat code F10+O (or Backspace+O in Armageddon and Apocalypse) and shows the whole map. Alternatively, the automap can be bound to a key (default: 'O'), in which case only the locations that were visited by the player are shown.
 Furthermore, the automap can be rendered in four different styles, which can be configured via the Video menu:

• "Original", which replicates the look and feel of the existing automap from Catacomb 3D, as @SiFi270 showed me.
• "Top down": this style is similar to the original look and feel. It respects the 320x200 resolution, but brings some Quality of Life improvements. The hexadecimal characters are replaced by visual 16x16 icons and location names are shown in the map.
• "Top down HD": instead of the 16x16 tiles, the actual textures and sprites from the game are used to render the map.
• "Isometric": shows the map from an isometric point of view.

Mana bar

The mana bar that @Hellbent suggested is in. It can be enabled via the Controls menu. When enabled, you can no longer stun enemies with endless clicking on the primary fire button. I noticed that this works nicely in the levels with a lot of demons. You'll have to rely more on the Zappers and Xterminators to keep the demons at bay. Which means it becomes more important to collect treasure chests.

 

320x200 screen resolution

I've also implemented the suggestions from @Dinoaur, including the simulation of a 320x200 screen resolution. It can be enabled via the Video menu. It also works in combination with other video options, like widescreen or depth shading. One note for @InDOOMnesia: the 320x200 screen resolution is accomplished by rendering off-screen to an OpenGL buffer object, which is strictly speaking OpenGL 3.0 functionality. My intention is that the source port still works on OpenGL 1.4 hardware like yours, except with the 320x200 option disabled. I couldn't verify if this works, as the NVidia OpenGL 2.x card that I have is apparently able to work with OpenGL buffer objects just fine.

 

As always, more feedback is welcome!

 

The automap in isometric style

320x200 screen resolution

Edited December 19, 2020 by Arno

[Master O]

Great work, @Arno!

[taufan99]

So many new things since the last version! I know it was worth the wait. Gotta try this very soon. :)

A side note I forgot to tell you earlier: my latest device has at least OGL 3.3. I don't think I'll ever use OGL 1.x/2.x devices again, but hopefully you'll succeed.

Edited December 20, 2020 by InDOOMnesia

[Arno]

18 hours ago, Master O said:

Great work, @Arno!

Thank you!

18 hours ago, InDOOMnesia said:

So many new things since the last version! I know it was worth the wait. Gotta try this very soon. :)

A side note I forgot to tell you earlier: my latest device has at least OGL 3.3. I don't think I'll ever use OGL 1.x/2.x devices again, but hopefully you'll succeed.

Heh, it's just that I like the challenge of getting the source port to run on older hardware. I don't care that much whether it runs at 2000 or 3000 fps on modern hardware. I get more fun out of making it run smooth on ancient potato hardware. Nevertheless, it's nice that you got yourself an upgrade. It means more games and mods for you to enjoy. :-)

[NY00123]

Great work as usual! The isometric map view is a nice addition, and it's not even the only possible appearance of the map.

 

I don't know how difficult is it in the technical sense, but since the automap is now at least a bit more accessible,

can it be optionally changed in Catacomb 3-D to not show where are destructible walls present?

 

Additionally, as other non-vanilla changes are acceptable, following are a few additional suggestions (other than mouse navigation in the menus, which was acknowledged):

- Skipping to a menu option by using a letter (mostly like Vanilla Cat3D/Wolf3D/Doom), or alternatively by using Page Up/Down or the mouse wheel.

- Going back to the main menu from a different menu by using the Esc key (or possibly another mouse button). In Vanilla Doom, Esc is reserved for hiding the menu, while Backspace is used for showing the preceding menu, so I guess that's another option.

- Add the overscan border, or at least a short screen flash for specific occasions. While the border can't be seen with a lot of modern DOS setups, including real DOS installations as well as DOSBox-based ones, it can be very useful for indicating when the player loses health. Such a border is drawn in my ports.

 

I'll finish with a few bug reports, which should also be added as GitHub issues by me:

- Using F10+W in Catacomb 3-D, level numbering is mistakenly started from 0 instead of 1.

- Suppose that you press on F10+W in Catacomb 3-D, then press on "Esc" to go to the menu, and finally leave the menu.

In such a case, you get the dialog again. If you then ask it to warp to the current level i.e.,

stay in the current one, you'll then be back to the game, but without music.

- The same occurs if you display the automap, show the menu and then return to the game.

 

Great work again.

[Arno]

Thanks a lot for the helpful, extensive feedback and bug reports, @NY00123!

 

The way Catacomb 3-D reveals destructible walls in the "original" and "top down" automaps could indeed spoil some secrets. Rather than adding an extra option, I think I'm going to hide them in the "top down" automap and keep them in the "original" automap as-is.

 

Coincidentally, I'm planning on improving the menu in the next release. Quite some code duplication sneaked in due to the growing number of options in the menu, so it's time to reorganize in that area. I want to add mouse and game controller support, along with scroll bars and such. I will take your suggestions along.

 

I like your suggestion to make the overscan border visible. I've recently also seen the overscan border used effectively in the Crystal Caves HD remaster. I'll add it to the list.

[Gez]

On samedi 19 décembre 2020 at 10:33 PM, Arno said:

The automap can be opened up via the cheat code F10+O (or Backspace+O in Armageddon and Apocalypse) and shows the whole map. Alternatively, the automap can be bound to a key (default: 'O'), in which case only the locations that were visited by the player are shown.

The key is "O" for Ottomap. :p

 

Sorry for the silliness. But I gotta say that this screenshot of the isometric automap is the first thing I've seen that made me want to actually try playing the Catacomb games.

[NY00123]

3 hours ago, Arno said:

Thanks a lot for the helpful, extensive feedback and bug reports, @NY00123!

 

The way Catacomb 3-D reveals destructible walls in the "original" and "top down" automaps could indeed spoil some secrets. Rather than adding an extra option, I think I'm going to hide them in the "top down" automap and keep them in the "original" automap as-is.

 

Coincidentally, I'm planning on improving the menu in the next release. Quite some code duplication sneaked in due to the growing number of options in the menu, so it's time to reorganize in that area. I want to add mouse and game controller support, along with scroll bars and such. I will take your suggestions along.

 

I like your suggestion to make the overscan border visible. I've recently also seen the overscan border used effectively in the Crystal Caves HD remaster. I'll add it to the list.

 

You're welcome!

 

One thing I forgot to mention, is that in Catacomb 3-D's menus, pressing on Esc brings you back to the preceding menu. So, maybe it's better to follow these behaviors for the rest of the games, not just for consistency with Catacomb 3-D, but also since it seems to be a more common convention than Doom's.

 

I also forgot to attach two screenshots for comparison. It looks like even with the minimal FOV of 25, CatacombGL shows a bit more. Of course, it's not intended to look exactly like the original (and especially not reproduce original glitches), but for the curious ones, I've attached these.

[Arno]

On 12/25/2020 at 2:38 PM, Gez said:

The key is "O" for Ottomap. :p

 

Sorry for the silliness. But I gotta say that this screenshot of the isometric automap is the first thing I've seen that made me want to actually try playing the Catacomb games.

Thanks, I appreciate it.

The Catacomb source code refers to the automap as the "overhead map", hence the "O". But I named it "automap" in the source port, as I think that is a more commonly used term. At least in Doom and ECWolf. But "A" was already bound to "Strafe Left", so I kept the "O".

 

On 12/25/2020 at 5:34 PM, NY00123 said:

I also forgot to attach two screenshots for comparison. It looks like even with the minimal FOV of 25, CatacombGL shows a bit more. Of course, it's not intended to look exactly like the original (and especially not reproduce original glitches), but for the curious ones, I've attached these.

Thanks again, that's interesting!

You're right that it's not intended to be a pixel perfect match with the original, but I was hoping that the minimal FOV would at least closely resemble the original FOV. Looking at your comparison screenshots, I think I can improve on this. I will take a closer look.

Edited December 26, 2020 by Arno

[Master O]

24 minutes ago, Arno said:

Thanks, I appreciate it.

The Catacomb source code refers to the automap as the "overhead map", hence the "O". But I named it "automap" in the source port, as I think that is a more commonly used term. At least in Doom and ECWolf. But "A" was already bound to "Strafe Left", so I kept the "O".

 

 

Most FPS sourceports tend to use Tab as the default key for the automap.

[Arno]

20 hours ago, Master O said:

 

Most FPS sourceports tend to use Tab as the default key for the automap.

To be honest, I hadn't thought about that.

However, currently Tab is by default bound to the Quick Turn action, just like in the original (MS-DOS) Catacomb Adventure series. So I'm going to keep it like that.

[Master O]

2 hours ago, Arno said:

To be honest, I hadn't thought about that.

However, currently Tab is by default bound to the Quick Turn action, just like in the original (MS-DOS) Catacomb Adventure series. So I'm going to keep it like that.

 

That's perfectly valid. I only brought it up as a possible default value for you to use.  The ultimate decision is yours to make, as the source port's creator.

[Arno]

52 minutes ago, Master O said:

 

That's perfectly valid. I only brought it up as a possible default value for you to use.  The ultimate decision is yours to make, as the source port's creator.

I'm glad that you brought it up, because I hadn't thought about it and it's also perfectly valid to argue that having the automap by default under Tab will be more convenient for some players. It's part of the fun to collect the pro's and con's in order to shape the source port. So I appreciate all your feedback.