ViTi95 wrote on 2026-04-19, 22:16:

I'll take a look, I'm sure I introduced a bug when I made changes to how the executable's texts are stored 😅

Hi!! how are you? do you think is possible to keep sprites in high resolution while use low mode?

Hi! It's definitely possible to have different detail levels for sprites and world rendering, but it all comes down to having spare time to develop it, which sadly I don't have right now. Also, keep in mind that some walls are actually rendered as sprites, so this might cause some unexpected behavior.

New release, FastDoom 1.3.0

Changelog:

- Improved frame interpolation in uncapped framerate modes for smoother rendering
- Fixed frame skipping in uncapped framerate modes when FPS drops below 35
- Added integer scaling support (up to 5×) for backbuffered VESA modes, enabling any VESA resolution in FastDoom

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

"Removed network gaming support" 😥

maybe performance related?

schlang wrote on 2026-09-14, 16:37:

maybe performance related?

I believe the doom netcode basically relies on the 25fps cap, I can see how that would cause issues with fastdoom..

appiah4 wrote on 2026-09-15, 06:11:

schlang wrote on 2026-09-14, 16:37:

maybe performance related?

I believe the doom netcode basically relies on the 25fps cap, I can see how that would cause issues with fastdoom..

35 fps cap?
afaik other doom ports interpolate for higher framerates

AncapDude wrote on 2026-09-07, 02:39:

"Removed network gaming support" 😥

good tbh, would be a cheater's engine if it still had it given the texture/flat/lighting removal options available.

rasz_pl wrote on 2026-09-15, 22:26:

appiah4 wrote on 2026-09-15, 06:11:

schlang wrote on 2026-09-14, 16:37:

maybe performance related?

I believe the doom netcode basically relies on the 25fps cap, I can see how that would cause issues with fastdoom..

35 fps cap?
afaik other doom ports interpolate for higher framerates

35, yes, sorry.

What about FastHeretic ? 😀

Last night, while playing with the CPU renderer options, I noticed an issue in the upper-left when I select Pentium MMX. The first several pixels are black, then there is a very bright pixel, before showing normal. There is also a noticeable change in floor textures on the right-half of the screen. System is a Pentium 233 MMX and a Sierra Screamin' 3D video card and I am using the FDOOMVBR exectuable. I didn't notice this behavior on my P3 w/ Ti 4200, though that system hard-locks when I exit any of the executables.

y2k se wrote on 2026-10-10, 13:51:

System is a Pentium 233 MMX and a Sierra Screamin' 3D video card and I am using the FDOOMVBR exectuable.

IIRC, the Rendition cards are notoriously buggy with just about everything, so I could see how that would just be a problem on its own. Seem to remember that Doom would just straight-up refuse to run Doom correctly on them, but maybe that's been patched idk.

7F20 wrote on 2026-10-14, 04:55:

IIRC, the Rendition cards are notoriously buggy with just about everything, so I could see how that would just be a problem on its own. Seem to remember that Doom would just straight-up refuse to run Doom correctly on them, but maybe that's been patched idk.

Original DOOM ran, just with poor performance compared to other video cards.

7F20 wrote on 2026-10-14, 04:55:

y2k se wrote on 2026-10-10, 13:51:

System is a Pentium 233 MMX and a Sierra Screamin' 3D video card and I am using the FDOOMVBR exectuable.

IIRC, the Rendition cards are notoriously buggy with just about everything, so I could see how that would just be a problem on its own. Seem to remember that Doom would just straight-up refuse to run Doom correctly on them, but maybe that's been patched idk.

I've never seen this bug before, it's really weird. Since FDOOMVBR renders the scene to a backbuffer in RAM and then copies it to VRAM, the issue must be happening during the backbuffer to VRAM copy. I haven't run into this problem on my Rendition Verite V2200, though to be fair I haven't tested the MMX codepath on that card yet. Can you try FDOOMVBD and FDOOM13H to see if this happens with either of those modes?

ViTi95 wrote on 2026-10-14, 12:17:

7F20 wrote on 2026-10-14, 04:55:

y2k se wrote on 2026-10-10, 13:51:

System is a Pentium 233 MMX and a Sierra Screamin' 3D video card and I am using the FDOOMVBR exectuable.

IIRC, the Rendition cards are notoriously buggy with just about everything, so I could see how that would just be a problem on its own. Seem to remember that Doom would just straight-up refuse to run Doom correctly on them, but maybe that's been patched idk.

I've never seen this bug before, it's really weird. Since FDOOMVBR renders the scene to a backbuffer in RAM and then copies it to VRAM, the issue must be happening during the backbuffer to VRAM copy. I haven't run into this problem on my Rendition Verite V2200, though to be fair I haven't tested the MMX codepath on that card yet. Can you try FDOOMVBD and FDOOM13H to see if this happens with either of those modes?

Now I can't reproduce it. Maybe one confounding factor is I am using renutil to force a higher refresh rate for my CRT. I'm using renutil 4 1 to get 640x480 @ 85 Hz. But I would disregard since I apparently don't have reproducible steps.

I was betting ViTi95 had left in some debug indicators that most people probably wouldn’t notice. Guess it’s not that.