ViTi95 wrote on 2022-04-26, 16:10:

IBM Monochrome Display Adapter

I wonder how far it would be possible to improve this. Like would attempting to recreate the shape of the level geometry using the MDA's "graphical" characters be feasible?

EDIT : or at least, using the block graphics characters to increase percieved resolution

rasteri wrote on 2022-04-30, 08:50:

ViTi95 wrote on 2022-04-26, 16:10:

IBM Monochrome Display Adapter

I wonder how far it would be possible to improve this. Like would attempting to recreate the shape of the level geometry using the MDA's "graphical" characters be feasible?

EDIT : or at least, using the block graphics characters to increase percieved resolution

from the comments of the video... and from the same guy... https://www.youtube.com/watch?v=ILM0uayHQmA

rasz_pl wrote on 2021-06-02, 08:23:

ViTi95 wrote on 2021-06-01, 17:38:

Some video cards are just faster in VBE2 mode, don't know exactly why.

me neither, but this fascinates me 😮

It finally hit me - chaining. 13h must be fully compatible with original VGA, which was build on top of EGA. 13h is a chain-4 mode. http://www.brackeen.com/vga/unchain.html#4
I was just reading 1992 Cirrus Logic GD5402/AVGA2 datasheet (available here http://www.vgamuseum.info/index.php/cpu/item/ … 02-acumos-avga2) learning about cool stuff this early chip supported:

- ability to ignore Reads relying on motherboard bios configuring A0000 shadow ram caching. Would be perfect for speeding up invisibility readback in Doom 😀 as even 386SX-25 does 10MB/s ram read speed vs 1-3MB/s of ISA VGA read.

- two independent linear sliding access windows.

- not fully documented, but mentioned in passing ability to map 128KB linear window A0000-Bffff to VGA memory.

- Set/Reset and Compare registers extended to full 8 bits and read/write mode 1 extended to 8 bytes at a time 😮 with extra foreground/background masks. If Im calculating correctly this means you can perform internal copies at 12-20MB/s and lines/pattern fills at 24-40MB/s
"D3 Selects the memory read data latches to be eight bytes wide, instead of the normal four bytes.
This bit can be used in Write Mode 1, in order to rewrite 8 latched pixels (64 bits) back into display
memory. This bit should be used in X8 addressing mode only."

- Start Address extended to 17 bits for a 128KB wrap around, enables 4 independent scrollable pages in linear 13h. Also considering Start Address is automatically latched on Vsync this should allow for perfect Vsync in linear 13h without switching pages in the interrupt.
"Extended address wrap for 128K maps with 512K memory (allows 4 pages of Mode 13)"

and finally :
- Linear packed 13h!
"DO Selects High Resolution 256 Color Mode. The video data shift registers are configured so that one character clock equals eight pixels. This bit also enables true packed-pixel memory addressing.
“True packed-pixel addressing" means that all bytes are stored at every consecutive location in video memory; by contrast, in Chain 4 addressing as used in Mode 13h, consecutive pixels are stored in consecutive maps 0 through 3, at every fourth location in video memory."
Would love to see if there is any speed difference between stock 13h, modeX, and 13h in the above linear mode. Then again looking at http://www.os2museum.com/wp/fast-unaccelerated-vga/ AVGA2 is already as fast as its theoretically possible, (5.5MB/s at 11MHz ISA clock), at least with fast CPU.

Chained 13h where pixels are stored every 4 bytes definitely has potential of having an impact on performance. Linear addressing Vesa modes get rid of this kludge, and so does this AVGA2 special mode.

Very interesting info @rasz_pl, those are some pretty good features that can be used to optimize AVGA / Cirrus Logic cards. I've looked into datasheets from newer models (like the 5426) and those also have those features, so I can test them since I don't have any 5402 card. I wonder if UniVBE already uses those features for the VESA 320x200 mode. However I'm currently busy implementing dual videocard support (Hercules + CGA/EGA/VGA, the idea is to show the map on the Hercules card while playing the game on the other), so that will take some time.

Edit:

- Set/Reset and Compare registers extended to full 8 bits and read/write mode 1 extended to 8 bytes at a time 😮 with extra foreg […]
Show full quote

- Set/Reset and Compare registers extended to full 8 bits and read/write mode 1 extended to 8 bytes at a time 😮 with extra foreground/background masks. If Im calculating correctly this means you can perform internal copies at 12-20MB/s and lines/pattern fills at 24-40MB/s
"D3 Selects the memory read data latches to be eight bytes wide, instead of the normal four bytes.
This bit can be used in Write Mode 1, in order to rewrite 8 latched pixels (64 bits) back into display
memory. This bit should be used in X8 addressing mode only."

I'm pretty sure this can be used to optimize the status bar copy from VRAM to VRAM using 64 bits copies instead of 32 bits copies with the mode Y executable (same as Vanilla Doom). This is the only case where Doom use VRAM to VRAM copies. I wonder why ID didn't use the same to optimize the font rendering.

Something I've always wanted to implement, dual screen support. Right now I'm testing on MAME (the only emulator that supports Hercules+CGA emulation, Hercules+VGA it's currently broken on the emulator), it'll be available on the next release.

Edit: Proof of concept video https://twitter.com/viti95/status/15327660317 … h9E3DXt308jeczQ

Edit 2: FastDoom dev build with Hercules automap (Hercules + VGA) demo: https://www.youtube.com/watch?v=GBY1Ti_Q4Ac

New release! FastDoom 0.8.14

Changelog:

- Performance uplift, avoid AGI stalls on column and visplane rendering code (486). Also small optimizations in sound code.
- Dual screen support. Now it's possible to use an Hercules card/monitor to render the automap. Use the command line parameter '-hercmap'.
- Better performance on 8-bit ISA cards and special backbuffered modes (Hercules, CGA, Plantronics ColorPlus, EGA, ATI 640x200).
- Removed Hercules 640x200 mode. It only worked on emulators, didn't work at all on real hardware. Even can cause serious problems on B&W monitors.
- Added transparent automap support. Press 'T' while on automap mode. Only supported while in 'fullscreen' mode.

Grab it here: https://github.com/viti95/FastDoom/releases/tag/0.8.14

https://youtu.be/h5WOvUuK1uw

Thanks for the continual updates and improvements! Really appreciated.

Timedemo fps is up to 16.358 on my bridgeboard 😀

Would be a nice comparision PPC66 vs. DX2/66 on the same machine (PM6100/DOS)

Hey, ViTi95. Is there a way to turn always run off? I've been playing Fastdoom version 0.8.13 on a laptop and it acted as if the shift was pressed. And pressing the shift slowed it down to normal. Interestingly, in Dosbox all was fine.

Yeah use the F12 key to enable/disable the autorun feature.

I'm not sure if this has already been reported, but I've just tried the latest version in DOSBox with Doom shareware v1.9, and the first demo desyncs after less than 30 seconds. I've run FDOOM.EXE and FDOOMVBD.EXE + S3 VBE/Core 2.0. I'm capping DOSBox cycles at 47810 and also tried the -capped and -vsync command line options, but they don't seem to affect the issue at all.

I have not tested the other shareware demos.

Yes there are some demos desyncing, It's in my to-do list to fix it but it's hard as there are lot's of code changes that can make the demos desync

Not sure if it gives a clue to the code most easily affected, but back in the day I found demo desynching from turning on advanced features of Cyrix 5x86/6x86. .... and it's probably a timing thing, since I saw it on some later, faster CPU also.

edit: maybe based on a flaky meat memory, but I seem to recall that anything borderline bugged on demo 2 first, at a point where a large lift was used. So possibly lift timing vs rest of game timing?? I dunno.

Is doom multithreaded? I dont think so 😀 so it cant be execution speed related, right? That leaves accuracy (rounding, clever math optimizations). Things like realtic /gametic/fractional ticks and physics - what happens when you keep running at the wall.

To have stable demos DOOM logic runs at constant 35 fps or rather game logic is iterated 35 times per second. Everything that is processed within each iteration has to be dependent only on game logic itself and previous iterations of logic loop. This will guarantee stable demos on all hardware.
If you change anything within logic loop like RNG behavior, collision calculation, monster AI, etc. it will break demos. Even setting FPS to other value than 35 will break things. You can still get more FPS, by using frame interpolation. Modern game engines do that, like 30/60 fps mode in Diablo 2 Resurrected, while game still runs in 25 FPS like original.

Multithreaded code isn't a problem here, since you can use as many threads as possible if you organize code correctly. For example you need to divide job into smaller, but independent tasks that can be processed simultaneously and when they finish, you can calculate final results in the main thread.

All of this is rather basic stuff. Usually the only thing you need to be careful with is RNG, since every time you call it, new seed value is generated. So if you want stable results, you must call RNG function exactly the same way while recording and while replaying demo.

RNG in general can be problematic. It is recommended to create your own RNG functions when doing cross-platform code. So RNG would have same behavior on every platform. If you're using built-in RNG in SDK, then compiling for different platform or using different SDK might generate different results.

Am i able to run doom mods?

0.8.16 is out, with some love for Covox users. 😀

Yep, also support for the Creative Music System (C/MS, also named GameBlaster), it can be used as an stereo 4-bit DAC for PCM sound.

My balls hurt wrote on 2022-07-26, 04:02:

Am i able to run doom mods?

Yes, but not all mods will work. You have to test by yourself.

so...
when voxels will be added? 😁 😁 😁

keropi wrote on 2022-08-30, 18:56:

so...
when voxels will be added? 😁 😁 😁

I guess someone will have to port LZDoom to DOS 😂😂