AI is not magic. Any attempt I've made to optimize ASM code in ChatGPT wasn't succesful. But to be fair, there are some small parts of FastDoom that ChatGPT has helped to develop, mostly boring stuff like reading files. It works for *very* basic C stuff.

noshutdown wrote on 2024-08-28, 06:48:

i have a suggestion:
now that fastdoom has undergone several updates with various fancy video modes supported, maybe we need an updated info list of them, and a survey on how each mode performs. also to decide which modes to be preserved or deprecated: a video mode should be at least either fast or nice to be supported, or it would be a waste of work if its both ugly and slow.

I was also thinking of this. There is a wiki entry for supported video modes, but it's a bit outdated https://github.com/viti95/FastDoom/wiki/Suppo … ted-video-modes

Hi all I wrote the hi res and fps interpolation modes feedback is appreciated

in the spirit of "ever faster", what about drawing walls and floors as lines (some kind of wireframe mode) ?
Does it make any sense and would it be easy to implement ?

Creating a wireframe is relatively easy to do, as the MDA mode already uses wireframes for walls. It should be really fast in VGA mode-Y, since it's possible to fill the entire screen with a single color using REP STOSD + 4-plane write mode, and then draw only the necessary lines.

However, I want to fix all the bugs in the FPS interpolation mode first before merging it (which is why we were asking for testers).

Frenkel wrote on 2024-06-12, 20:11:

*cough* Doom8088 *cough*

And I was told right here that a 286 port is nearly impossible due to the lack of flat memory model, hmm.
Anyway, that one is still raw, but very cool as a proof of concept

ujav wrote on 2024-09-08, 22:10:

Frenkel wrote on 2024-06-12, 20:11:

*cough* Doom8088 *cough*

And I was told right here that a 286 port is nearly impossible due to the lack of flat memory model, hmm.
Anyway, that one is still raw, but very cool as a proof of concept

RealDoom is also a project in development for 286’s.

ujav wrote on 2024-09-08, 22:10:

And I was told right here that a 286 port is nearly impossible due to the lack of flat memory model, hmm.
Anyway, that one is still raw, but very cool as a proof of concept

I think that the point of FastDoom is that it's still essentially Doom, but optimized.

There are many projects out there that are essentially complete rewrites of Doom to make a game tailored to play on a specific system. Doom8088 is adapted from a version of Doom written to run on a Gameboy Advanced. It's a totally different ball of wax.

porting doom to 16bit is still an idea too crazy for me to believe.
even though 286 is equally as fast as 386dx in term of 16bit operations, keep in mind that each 32bit opreation has to be divided into several 16bit ones, not to mention that doom is still too slow on a 386dx.

also, while there is gcc-ia16 that generates 8088/286 binaries, can it be made to compile itself?

I've managed to source a camera that can record 60 fps video, here is FastDoom running uncapped on my Pentium II (266MHz) Toshiba laptop

https://www.youtube.com/watch?v=P7IjZE_67gg

BTW both Doom8088 and RealDoom deserve all the respect. Porting the Doom engine to x86 16-bit instructions with 64KB RAM segments and the memory limitations (640KB) is mind-blowing, to say the least. Of course, some compromises had to be made, and both are still in development.

7F20 wrote on 2024-09-08, 23:26:

ujav wrote on 2024-09-08, 22:10:

And I was told right here that a 286 port is nearly impossible due to the lack of flat memory model, hmm.
Anyway, that one is still raw, but very cool as a proof of concept

I think that the point of FastDoom is that it's still essentially Doom, but optimized.

There are many projects out there that are essentially complete rewrites of Doom to make a game tailored to play on a specific system. Doom8088 is adapted from a version of Doom written to run on a Gameboy Advanced. It's a totally different ball of wax.

According to The Doom Wiki the source code lineage of Doom8088 goes Doom8088 -> GBADoom -> PrBoom -> Boom v2.02 -> Final Doom v1.9 & DOSDoom 0.2. Doom8088 is not based on Doom for the Game Boy Advance, whose source code lineage goes Doom for Game Boy Advance -> Jaguar Doom -> Doom v1.2. It's also not based on Doom II for the Game Boy Advance which runs on the custom engine called Southpaw Engine.

Point is: There's vanilla Doom source code in Doom8088. It's graphics and level data is processed vanilla Doom data, not Jaguar Doom data. And it's compatible with demo3.

The lack of a flat memory model on a 286 wasn't really a problem. Luckily a 286 can access all 640 kB of memory without bank switching. The 64 kB segment limitation just enforced the Doom data lumps had to be less than 64 kB in size.

Frenkel wrote on 2024-09-10, 15:53:

According to The Doom Wiki the source code lineage of Doom8088 goes Doom8088 -> GBADoom -> PrBoom -> Boom v2.02 -> Final Doom v1.9 & DOSDoom 0.2. Doom8088 is not based on Doom for the Game Boy Advance, whose source code lineage goes Doom for Game Boy Advance -> Jaguar Doom -> Doom v1.2. It's also not based on Doom II for the Game Boy Advance which runs on the custom engine called Southpaw Engine.

Point is: There's vanilla Doom source code in Doom8088. It's graphics and level data is processed vanilla Doom data, not Jaguar Doom data. And it's compatible with demo3.

I’m not trying to argue, you are the Author but it’s easy to see how someone could get confused. Also even more annoying when you click the Doom8088 wiki link it says “RealDoom” immediately under the header, which I’m pretty sure is a separate but similar unrelated project?

BinaryDemon wrote on 2024-09-10, 17:26:

I’m not trying to argue, you are the Author but it’s easy to see how someone could get confused. Also even more annoying when you click the Doom8088 wiki link it says “RealDoom” immediately under the header, which I’m pretty sure is a separate but similar unrelated project?

I've fixed the DoomWiki entry for Doom8088, that was a small mistake

ViTi95 wrote on 2024-09-10, 11:40:

BTW both Doom8088 and RealDoom deserve all the respect. Porting the Doom engine to x86 16-bit instructions with 64KB RAM segments and the memory limitations (640KB) is mind-blowing, to say the least. Of course, some compromises had to be made, and both are still in development.

yes they do, however i really doubt if they could ever achieve any acceptable performance on even a fast 286-20 machine. remember that doom is still pretty slow on a 386, and to port it to 16bit, each 32bit operation would be converted into several 16bit operations, not to mention the memory limitations.
i would like to see a benchmark of them against fastdoom on a 386 machine, using similar graphics settings, to find out how much the slow down is.

Frenkel wrote on 2024-09-10, 15:53:

According to The Doom Wiki the source code lineage of Doom8088 goes Doom8088 -> GBADoom -> PrBoom -> Boom v2.02 -> Final Doom v1.9 & DOSDoom 0.2. Doom8088 is not based on Doom for the Game Boy Advance, whose source code lineage goes Doom for Game Boy Advance -> Jaguar Doom -> Doom v1.2. It's also not based on Doom II for the Game Boy Advance which runs on the custom engine called Southpaw Engine.

Point is: There's vanilla Doom source code in Doom8088. It's graphics and level data is processed vanilla Doom data, not Jaguar Doom data. And it's compatible with demo3.

The lack of a flat memory model on a 286 wasn't really a problem. Luckily a 286 can access all 640 kB of memory without bank switching. The 64 kB segment limitation just enforced the Doom data lumps had to be less than 64 kB in size.

I was aware that GBA Doom and Game Boy Advanced Doom are 2 different things, but I didn't realize that 8088 came first. What I said was based on what was written on GitHub (which I think you wrote?).

Doom8088 is a port for PCs with a 16-bit processor like an 8088 or a 286, and with VGA or MCGA graphics. It uses 64 kB of EMS memory, if available. And 2366 kB of XMS memory, if available. It's based on GBADoom.

Doom8088 is a source port, correct?

And to be clear, I never said that source ports are somehow inferior, but they are different from a code optimization.

7F20 wrote on 2024-09-11, 04:23:

I was aware that GBA Doom and Game Boy Advanced Doom are 2 different things, but I didn't realize that 8088 came first. What I said was based on what was written on GitHub (which I think you wrote?).

he wrote it in reverse order. actually doom8088 is based on gbadoom, which in turn is based on prboom.

Four years after the first release of FastDoom (0.1), the 1.0 version is finally here. As always, huge thanks to everyone involved in the project.

Changelog:

* Optimized rendering of non-scaled graphics (skybox and player sprite, only on 320x200 modes and screensize >= 10)
* Added player sprite rendering display option (player weapon)
* Fix issue #203. Now savegames are different for each IWAD
* Fix issue on command line parameter "-iwad"
* Faster update rate for the onscreen FPS counter (@tigrouind)
* Reduced memory usage
* Fixed map names for FreeDoom (now map names are stored in the folder "LEVELS")
* New uncapped framerate mode, for fast 486/Pentium machines (@dougvj)
* Fixed VSync code (@dougvj)
* Fixed FDBENCH.EXE utility

https://github.com/viti95/FastDoom/releases/d … tDoom_1.0.0.zip

Thank you for 4 years of effort and support, we really appreciate it.

Congrats on the 1.0 version! Awesome project!

Congrats. Hope there will be 1.666 in the future. 😏

Amazing achievement. I need to get it loaded onto my 486 and give it a spin. Any plans on adding more WAD support? Or maybe Heretic, Hexen or Strife? No shame if you've achieved your purpose and are happy with it, just curious.