viti95

Another idea to reduce memory usage, compress better the IWADs. @fraggle has updated wadptr and fixed old issues, this reduces the amount of memory used for certain graphics, and specially the size of the sidedefs.

Really interesting, I really want to see this running natively on a 486/Pentium.

Yep compilers aren't very smart. Under some conditions and ASM coding it's possible to process two 8-bit registers at the same time with a single instruction (like SIMD). I use this trick extensively to convert 256-color backbuffered modes to other video modes in FastDoom. Also having 8-bit variables is better for the 8088 as the data bus is 8-bit wide. Potato mode is easy to implement, and reduces a lot the number of OUT instructions issued per frame. If graphic fidelity is not an issue, it's possible to modify the visplane rendering using flat colors without color dimishing, it's much faster as it doesn't require a conversion from columns to rows (took this idea from @Optimus OptiDoom). The main problem after optimizing graphic routines is to optimize game logic and mantain demo compability at the same time, there are lot's of optimizations that break it quite easily.

With FastDoom I learned that the bigger speedups came from optimizing the rendering code (ASM), so I guess that's the first thing to do after fixing all bugs. Also converting 32-bit variables to 16-bit or 8-bit will help a lot (I think @Frenkel is doing this on Doom8088).

Awesome!!

How do you debug RealDoom? I tried to use the Watcom debugger for FastDoom but it was very prone to crash, so I ended up using the classic log files and realtime second screen MDA/Hercules output.

I think I'm gonna steal this meme for FastDoom 😂😂😂

Doom doesn't run well on any Amiga unless you upgrade your CPU and fast RAM massively. The blitter and other Amiga chips cannot help at all to render Doom, and is even worse as the VRAM layout uses planes, which is totally bad for 3D games (the CD32 has the Akiko chip that helps a bit, but anyway the CD32 cpu is too slow). The conversion from a linear VRAM layout to a plane based takes lot's of CPU time.

That's not based on vanilla Doom source code, so not Doom at all.

I think I'll be sharing ideas here to reduce the memory footprint that I've recently discovered on FastDoom (as this is the most importat part to avoid unnecesary paging). It's possible to unify the STBAR and STARMS lumps, as there will be no multiplayer. This lowers memory usage 1Kb, and makes the code a bit faster since there is no need to update twice the status bar. With some optimizations and downgrades I think fast 286s will be able to run Doom at somewhat playable framerates (similar to 386SX)

True, it's very weird they were modifying/using an older version of this screen in Doom development. Wolf3D memory error screen is really similar to Doom 0.4:

So ID Software reused the Commander Keen 4 error page, and modified it a bit replacing "Commander Keen" for "DOOM, bonepie". That's why it's talking about EMS, when DOOM doesn't use EMS memory at all.

Oh great to hear that, for now I've done these modifications: - Add entry removal method, to cleanup unused multiplayer / sound lumps. This is giving me some headaches since some lumps really get deleted but others don't. - Disable compression of sidedefs associated to type 48 linedefs. This is confirmed that fixes the high speed scrolling textures. - Add compression method for PLAYPAL (removes two unused palettes) - Add compression method for COLORMAP (removes one unused entry) - Add compression method for 320x200 graphics, instead of being stored in columns, now are stored as a single 64000 byte linear raw image - Remove uncompress methods - Made WadPtr a little bit less verbose I have an issue in my GitHub as a roadmap: https://github.com/viti95/FastDoom/issues/155

After some investigation, this looks like an early version of DOOMERR found in Doom 0.4 (April 2, 1993)

*Lump already discovered in Doom 0.4* *Delete please*