viti95

Yes Cirrus Logic cards require LFB to be addressed under 16Mb of RAM due to the 24-bit address limitation (limitation inherited from ISA), anyway VBD is not much faster in those cards. They are limited to 16-bit writes internally, so no 32-bit write optimizations are useful with those cards. Maybe FastDoom optimized R_DrawColumn and R_DrawSpan code can be used in DJDoom, they are about 10% faster due to unrolled code (used in Heretic). Right now I'm building specialized versions for each CPU, so I expect a bit more of juice from each CPU architecture (386/486). Also I'm trying to implement Ken's ideas to the renderer, but ASM code is giving me some headache, it's kind of hard to understand texture mapping code 😅

DEH support was abandoned, I tried to add support but having no debugger makes this kind of development really hard. Right now I'm focused on Ken Silverman's ideas to optimize the R_DrawColumn and R_DrawSpan functions. Again, DJDoom is a much better opportunity for these things, having a better compiler makes a great difference for developers.

Honestly FastDoom is so heavily modified that reverting network changes is near a mission impossible. I see bigger opportunity on DJDoom, with all we have learned from creating FastDoom we can create a much better DOS Doom port from scratch, while also being faster (yep, DJGPP is better than OpenWatcom).

Actually I think there is a way to get an even cooler multi-monitor automap, but requires from a very rare videocard, the Hercules Incolor. This card uses 0xB0000 for VRAM and I/O addresses 0x3B0 to 0x3BF, and works like an MDA card, but with 720x350 16 color support (based on bitplanes like EGA cards). This means it could be used at the same time with CGA, EGA or VGA cards as resources aren't shared. So it should be possible to get a "high definition" 16 color automap while playing the game on another screen 🤯

New release: 0.9.6 * Add executable filename to benchmark (CSV) * Fix wrong fps display if 0XX after decimal point (@RamonUnch #145) * New invisible column renderer: Flat Sega Saturn (@RamonUnch idea) * Small code optimizations * Sound Blaster MIDI support (for Sound Blaster 1.0, 1.5, 2.0, Pro 1.0 and Pro 2.0) https://github.com/viti95/FastDoom/releases/tag/0.9.6

No but it could be done. Don't know if this will work well with low Doom framerates, those kind of effects work fine when the framerate is 60fps (or more).

@Ramon_Demestre I've added your idea to FastDoom, thanks!! Edit: It works very well on non-256 color modes.

Also https://github.com/ozkl/doomgeneric

Pretty good idea, this is the same method as Daytona USA car shadows on Sega Saturn. It should be much faster as no texture mapping is needed.

Any communication via ISA bus is extremely slow, so the less you use it, the better. As you said @zokum, Doom writes directly to VRAM in all cases, first renders the scenario (no overdraw here), and then objects (that includes some walls) in back to front order. This is were major overdraw happens, and there is no possible fix just because everything is stored in VRAM. The other big problem is rendering fuzzy objects (spectres). Due to everything being rendered on VRAM, it requires to read from the VRAM in order to create that fuzzy effect, which is also extremely slow (1 read + 1 write per each pixel). That's why I decided to add the Sega Saturn rendering method, is much faster as only half of the pixels are directly drawn to VRAM.

For FastDoom Vesa modes you need a video card that supports VESA 2.0 and the 320x200 (8 bit, 256 color) video mode. There are two executables: FDOOMVBR.EXE: This modes uses a backbuffer for rendering, and doesn't require LFB support. FDOOMVBD.EXE: This mode renders directly on the video card, and supports triple buffering. It requires LFB support. I've tested those executables succesfully with these video cards, using Scitech Display Doctor 5.3a: - S3 805, Trio32, Trio64, Virge - Trident 9440 - Cirrus Logic GD-5426, GD-5428 - ATI Mach32, Mach64 - Cyrix MediaGX - Rendition Verite 2200 Non-working video cards: - Matrox video cards. I guess it's due to different VRAM layout, the screen is corrupted on those cards.

Yeah it makes a great difference, I hope to create even faster R_Draw* routines with the hints Ken have given. BTW I think DJDoom is a great opportunity to create a great port from scratch. I mean, it builds on GCC fine and is Vanilla 100%, so we can port it to multiple architectures, using ASM code for specific parts like rendering or sound. For example I think the Macintosh 68k platform can benefit a lot (using the Retro68 SDK), since the Macintosh uses a linear VRAM layout, and supports 256 colors (no chunky to planar penalty compared to Amiga or Atari ST).

Maybe it's not required to use GAS at all (yeah I also hate it). It's possible to generate DJGPP compatible objects with NASM, so maybe FastDoom's rendering functions can be used directly on DJDoom.

Is insane to see a 29% performance uplift just from using DJGPP compared to OpenWatcom. Just add optimized ASM code for rendering functions an I'm pretty sure DJDoom will be faster than FastDoom.

86Box is much more accurate for emulation (in every aspect) than DOSBox. There is an easy way to access drive files from that emulator, just set-up a CD-ROM drive on DOS (MSCDEX + any IDE driver), and mount your dev folder directly on that CD drive (no ISO required at all). BTW I tried to build DJDoom on Linux, it builds fine if all referenced files (.h) in the code are converted to lower-case, otherwise compilation fails. Well I tried to optimized the nodes with Zennode and ZokumBSP and the results were clear, there is a performance uplift https://www.doomworld.com/forum/post/2175041 Also WadPtr tool made the timedemos run faster, but in both cases there were issues. WadPtr caused some textures to move much faster (for example in E1M1 the rotating texture below the green armor spinned like crazy), and reordering the nodes caused desync in demos. @Ramon_Demestre DJDoom is slower due to non-optimized rendering routines, it's just non-unrolled C code.