Yeah, a thread bump. I should've probably linked to a download link for a shareware release of The Catacomb Abyss (it's probably better to try v1.13, just for the sake of consistency): http://www.classicdosgames.com/game/The_Catacomb_Abyss.html

And before anyone's asking, sure, if I had access to "real hardware" then I'd check this too. It would really be nice have the chance, but I'm afraid this is not the case.

Yeah, after all the discussions we had on this on IRC, it would be nice to see the behaviour on real hardware.

The cursor has a bit of "noise" in it on a real P2 400 but the rest of the game doesn't flicker afaik. I've been playing this game for years on various P1 and P2 configurations and never noticed anything funny.

There is also the possibility of loading the game with COMP sent as a parameter for the SVGA compatibility mode. Not sure if it well help anything though, it used to help a lot with some older id titles that had jerky scrolling.

On a fast Pentium 3 with Voodoo3, this game flickers like crazy.

edit:

Maraakate wrote:

There is also the possibility of loading the game with COMP sent as a parameter for the SVGA compatibility mode. Not sure if it well help anything though, it used to help a lot with some older id titles that had jerky scrolling.

Will have to try this, once I get my DOS PC up and running again.

Thanks for all the reports! They are surely useful. It's probably a good idea to add a reason for having an interest in these (Note: It's just Keen Dreams and a couple of 3D Catacomb titles now, not anything else): https://github.com/NY00123/refkeen

Considering the /COMP argument...

It looks like it is, in fact, useless. Yeah, it is mentioned by typing "CAT3D /?" in a DOS prompt as of v1.22, but this is still the case.

To see why, it's a good idea to compare to Commander Keen 4-6, sharing a lot of code. A little portion of it is the control panel with the "Configure" menu, which in turn has the "Options" submenu with the "SVGA COMPATIBILITY" option responsible for the functionality of the /COMP argument.

To compare, the "Options" submenu is absent from Catacomb 3-D, which is already a good hint this option is not really doing anything.

Furthermore, looking at the released source code for Catacomb 3-D (from which it's possible to reconstruct the original v1.22 EXE), the /COMP argument (or the unused SVGA COMPATIBILITY menu option) toggles a boolean variable named "compatability". It looks like it can have an effect on rendering only from ID_RF.C, the refresh manager used for smooth scrolling in Keen 4-6. This file is not even compiled for Catacomb 3-D. So yeah, I guess that sums it up for /COMP.

Finally had enough time to do some test runs. I have no CRT monitor on hand so all tests were done using my Acer S202HL 20-inch widescreen LED monitor.

Pentium 166MMX, Asus TX97-XE (Socket 7, Intel 430TX), 64mb EDO ram

Matrox Millennium II 4mb: Red-tinted game screens, constant flickering, horizontal scrolling stutters. Screens have normal color when both caches are disabled, but flickering and stutters remain.

S3 Virge 4mb: Some slight stuttering.

NVIDIA Riva TNT 16mb: Some slight flickering and stuttering at start of levels.

Pentium 4 2.4GHz Northwood, Soyo P4I-845PE (Socket 478, Intel 845PE), 512mb DDR-333 ram

NVIDIA GeForce 4 Ti 4200 128mb AGP: Constant flickering.

NVIDIA GeForce FX5500 256mb AGP: Constant flickering and stuttering.

And just out of idle curiosity, I also tested my main PC.

Intel Core i5 3350P, MSI Z77A-G43 (LGA 1155, Ivy Bridge), 8gb DD3-800 ram, NVIDIA GeForce GT 640 2gb PCI-E

No flickering or stuttering, instead game font corruption and a light green screen tint is present:

Disabling all caches doesn't resolve the issues.

Incidentally, all 3D Catacomb games have the Turbo/Borland Pascal 7.0 run time 200 bug, so I used a TSR that patches this error in system memory without modifying any game files. Works like a charm 😀 . And the /COMP command line parameter doesn't help at all.

You can manually patch the catacombs files by using unlzexe and then using tppatch.exe. UNP may work as well to unpack it but I have not tested this.

I am surprised at the flickering issue for a lot of people. The P2 400 runs totally fine with CAT3D (all games in the series) and this is with a Voodoo 5 5500. No special patches or anything. I also have a P1 200mhz with a Trident (forget the model number) card and a few Gateway Solo 9100 series laptops that are P2 300s with a Trident card as well. All these systems run the game just fine. Maybe I got lucky and never used something fast enough to exhibit this bug.

Thanks for all of the reports!

I know the GTX 460 I've gotten here has at least some behaviors shared with the GT 640, JayCeeBee64, from some earlier tests (basically the green screen tint in at least specific CGA and EGA modes, and the overscan borders). Keen 4 v1.0 and Catacomb 3D/Abyss don't seem to run in DOSEMU (for Linux) for me here, but Keen 4 v1.4 is OK (there's a way to make DOSEMU use direct hardware access with VGA-compatible modes, obviously requiring root privileges).

That runtime error 200 bug is also interesting, considering the fact we're talking about C (and ASM) code, not Pascal. It does, however, look like Turbo/Borland Pascal and C++ share code. Maybe it comes from the usage of the "delay" function in the INTRO and LOADSCN programs as bundled with Catacomb Abyss v1.13, or any other functionality from a library that contains the implementation of delay.

Given the reports above, I think that I know what I'll do regarding the ports of the games. Thanks again for these reports.

There's one more point I've wondered about, though, if it helps at all. I've gotten a saved game for Catacomb 3-D: The Descent v1.22 in map no. 16 (counting from 1), where the player is positioned at a glitchy location. While rotating the player's view, some flickering is seen in DOSBox with cycles=5000, but not cycles=3000. It's also not seen in the source port (although there's another minor difference I'm not sure where does it come from).

If anybody has a copy of this version of the game, some early hardware, and doesn't mind, can you check what do you see once you load this saved game and rotate the player? There's a video I've recorded with DOSBox v0.74 (cycles=5000) for reference. Thanks!

Does PCem show same behavior as dosbox?

truth5678 wrote:

Does PCem show same behavior as dosbox?

I think I've considered checking this on my own, although I haven't really tried to get PCem to run. Or actually, while v0.6 is running for me, later versions don't seem to, but that may be the case since I'm not using Windows here. (v0.9 adds preliminary Linux support, but it's not yet ready.)

With a hacked-up setup for v0.6 (AMI 486 clone with Trident SVGA and 480SX/20), Catacomb 3-D and Abyss can be run. However, it looks like the EGA "split screen" feature (Line Compare) isn't properly implemented in PCem v0.6. A little of the in-game view can still be seen in Cat3D, though, and it looks like there are flickers, but then the game is also a bit slow in terms of framerate.

It's probably better to check this with PCem v0.9 anyway.

DOSBox-X does not have the (constant) video flickering where machine=ega and cycles=max.

Edit #1: I believe that Codeholio's clock/timer additions in February 2014 are the reason for the above positive result. However, it requires testing because a slowdown could occur from another cause, which then mimics a low cycle count, leading to a positive result of no flickering.

Edit #2: I also noted assembly functions in the source code for 3D Catacomb, particularly in writing from screen to memory and memory to screen. I haven't tested it, but I wonder if adding a delay in one or more of these functions would lessen the flickering.

Which version of DOSBox-X is it? I've tried the most recent revision (Dec 7) from this git repository, as well as a couple of older builds, and have seen the flickering with machine=ega and high cycles amount, unless I've done something wrong: https://github.com/joncampbell123/dosbox-x/commits/master

Considering the source codes: It's probably a good idea to compare C3_DRAW.C:ThreeDRefresh to ID_RF.C:RF_Refresh.

ID_RF (refresh manager for smooth scrolling) is totally unused in Catacomb 3-D, but it seems to be a part of Keen 4-6, and an earlier version of ID_RF can be found in the Keen Dreams codebase. RF_Refresh calls VW_SetScreen, which sets the CRTC start address and pel panning register values. VW_SetScreen ensures each of these is done when apporpiate, e.g., there's a wait for vertical retrace before setting the horizontal panning.

On the other hand, ThreeDRefresh sets the CRTC start address register only, and it's done immediately. There's no wait for e.g., vertical retrace. By replacing this code with a call to VW_SetScreen (panning is chosen to be 0) the flickering can be remedied.

It can surely make one wonder why wasn't this originally done. Maybe it's the case since the game was designed for older hardware, probably with a framerate much lower than the refresh rate of ~70Hz, and the flickering wasn't noticeable or present. Catacomb 3-D was also one of multiple titles made for Softdisk under a contractual obligation, so it must have had a somewhat lower priority than id's own titles.

I'm glad to hear you are far along to solving the problem (or is it solved already?). I only got as far as compiling versions of Catacomb 3D and Catacomb Abyss, which was a feat in itself since the former is not compatible with my version of the data files. There is a discussion on a Doomworld forum that suggests the ID Anthology version is required for compatibility. Partly confirming this is your work with the Catacomb source codes and making them compatible with older versions of the data files. I also tried your patches.

I had somewhat better luck testing Catacomb Abyss, although after verifying it was likely a good build, it would error on insufficient memory (and I verified that the binary doesn't work if the error is bypassed). I had to assume that the game/data version is not a match to the binary version. If I was successful, I thought to place delays in the memory writes so that I could mimic the effect of a low cycle count in dosbox. Also, dosbox-x has some effect on the flickering in my case (only), but mainly away from in-game walls or where there are a lot of objects on screen; however, my computer system is slower, and apparently the ISA clock timing is not a fix. 😀

Your work on this is very interesting (I'd have to learn more to appreciate your description of the video emulation). If it is possible to make current binaries which are compatible with older data files, then that would be convenient. Otherwise, it's an important finding that Catacomb inherently is dependent on the speed of the computer system and dosbox doesn't need modification.

I have wondered whether the Catacomb source code releases is to complement the gog.com release of these games only. It's already generous that John releases the code, although I wish older versions of the engines were available for testing (and perhaps even the vQuake source code!).

I was mostly interested in figuring out if the flickering is reproduced with any of the original executables, rather than an EXE based on modified source codes (e.g., the usage of VW_SetScreen). Well, ok, I agree that knowing exactly why there are flickers is a nice bonus, and I'm not yet sure that's entirely resolved.

The released source codes should be compatible with the data from GOG.com, including Catacomb 3-D: The Descent v1.22 and The Catacomb Abyss v1.24. I'm not sure you've referred to this in your last reply, but I've also had attempts to reproduce a few other (but not that many) DOS EXEs revisions, found here (note that not only source codes were modified, but also some static data to be linked, like EGA headers): https://bitbucket.org/NY00123/gamesrc-ver-recreation

You may need to use the exact tools mentioned for the relevant game/revision to build, e.g., a specific version of Borland C++ (LZEXE and co. are probably unnecessary).

Interestingly, the Catacombs and Hovertank 3D were made for Softdisk, and from what I got to hear Flat Rock Software acquired the publishing rights (and possibly more) for the whole Softdisk catalog, including these. Alright, things have changed since July regarding that, so let's think of June 2014 or earlier. The release of the source codes for these titles came from Richard Mandel of Flat Rock Software, after being convinced by Blzut3 (ZDoom and ECWolf dev). John Carmack didn't even know any of this is going to occur until Blzut3 notified him: https://twitter.com/Blzut3/status/474607937021693952

Thanks for your interest so far!

The data versions for the source all require the latest versions that you can purchase from softdisk. I ended up having to spend the $5 to get my compiles working.

I appreciate the hints on compiling for the older Catacomb versions, and for the detailed information on what was involved to allow for the source code release (thanks to Mr. Mandel and Blzut3). I think I misinterpreted a README file with J. Carmack's notes, I guess those comments must have been from a long time ago! All of this is a monument to a (or the) progenitor of the modern FPS genre. 😀 Thanks!

A little bump, mainly for giving out a little bit of information that someone may be interested in.

Catacomb 3-D: The Descent (and only this game in the series) actually has a way to get rid of the flickering in DOSBox (and possibly also real DOS setups) without modifying the EXE or recompiling modified sources. Simply use the debug keys F10+V and ask to add 1 additional extra VBL to wait for (per PlayLoop iteration). By asking for more, the max. framerate is expected to be lower.

Unfortunately, while the code itself can still be found, it was commented out for the later Catacomb episodes, along with other debug keys. In The Catacomb Abyss, F10+V rather shows the game version in use. In The Catacomb Armageddon+Apocalypse, even this code (which can theoretically be accessible using Backspace+V) is disabled in compilation time, due to the presence of a new macro named DEBUG_KEYS_AVAILABLE, defined to be 0.

This is also a good chance to refer to another kind of behavior that may be sensitive to timing. Usually, when I press on F10+B in Catacomb 3-D, I just get the border color change dialog. After using F10+V to add 1 VBL per PlayLoop, though, F10+B often leads to the in-game action done by pressing merely on 'B', being an attempt to use a bolt. At the moment this is also (I think) always reproduced in the refkeen port mentioned above. It is probably related to the timing of the keyboard interrupt handler INL_KeyService, given that the Keyboard boolean array is the relevant structure.