NeoG_ wrote on 2026-11-01, 23:45:

Performance optimisations are a mixed bag, there is improvement when out on the street but the rooftop at the start is now only 20fps

Also I can see now that the framerate is soft limited to 60, which is probably the right thing to do. But since there's no framerate limited software version it is a bit tough to compare out right performance figures.

I've reuploaded the files, can you retry ?

TgamesFR wrote on 2026-11-02, 08:48:

I've reuploaded the files, can you retry ?

I just grabbed a fresh copy - still has the issue. I was able to narrow down the performance issue specifically to areas with a high % of the skybox visible. It happens on the rooftop in Hollywood Holocaust and also when pressed up against the windows in Spaceport.

jh80 wrote on 2026-10-28, 05:26:

BitWrangler wrote on 2026-10-27, 14:25:

I don't get why anyone would put a V3 in anything slow enough to not run Duke at 800x600 well on a 2D card. It only takes a P166 or so and VBE 2.0 card.

While I get the point you're making... I don't think this statement is accurate at all. Can you confirm? Even on a P200 MMX I probably only get 20-30 fps at 800x600 on Duke3d. If you want to play at anything like 60 fps you need a much faster CPU. So, it is possible that someone may have a period-accurate Voodoo 3 in a system that otherwise could not run Duke3d at 60 fps in 800x600.

Can confirm, Duke3D shareware on P200MMX 800x600 all sound and video options on runs at about 28FPS dnrate walking around LA Meltdown(12MB Matrox Millennium II but Duke leans on CPU anyway). Which is perfectly playable and feels smooth. But it ain't 60FPS.

I've reupdated the files again, without increasing version number as the previous one was not effective.

It should improve framerate at some specific spots where it was lagging.

I tired the update before going to work this morning. The high coverage skybox issue is fixed, general performance is also up across the board.

There is one more performance bottleneck I noticed with large explosion animations. E.G. when a flying pig cop vehicle crashes down and the explosion covers a decent amount of the screen, the framerate temporarily reduces to about 30. It may be the graphics or something associated with those events.

Input delay is starting to become noticable as well, if any of the imput delay optimisations from the ROTT patch are applicable here they would be welcome

My target hardware for 3dfx retro-gaming is mostly a P1mmx or a P2mmx below 350mhz with a single voodoo1.
For the main-gfx card I avoid a voodoo3 due to a card that has a wide range of driver support like MGA Mystique/G1xx/G2xx or a RagePRO PCI/AGP.
Is it possible to make the Build-Engine use dosglide for voodoo1 on such a machine?

dr.zeissler wrote on 2026-11-03, 11:06:

My target hardware for 3dfx retro-gaming is mostly a P1mmx or a P2mmx below 350mhz with a single voodoo1.
For the main-gfx card I avoid a voodoo3 due to a card that has a wide range of driver support like MGA Mystique/G1xx/G2xx or a RagePRO PCI/AGP.
Is it possible to make the Build-Engine use dosglide for voodoo1 on such a machine?

It's probably possible but you would need to get a voodoo1 into the hands of someone with the motivation to do it

Update: 04/11/2026, V1.00b

1Lot of performances optimizations (for better FPS)

OK so I didn't see any major issues with this version, on my 550mhz machine this is pretty much constantly stuck at 60fps which is what you would expect. I also didn't notice any significant bottlenecks related to action happening on screen. Input delay is not back to an acceptable level and fine to play with.

I don't know how far you want to go down the optimisation route - I can artificially reduce down to 200mhz natively and intentionally bottleneck the CPU to understand the relationship between the 3dfx renderer and CPU load. At 550Mhz there is enough CPU power to calculate the game logic and handover to the graphics card at 60fps continuously.

When moving down to 200Mhz, there is a non-linear benefit between the software and 3DFX renderer. When graphics load is high, there is a +82% benefit, when graphics load is low there is a -45% benefit. That may indicate that geometry setup and GPU management is taking a significant amount of CPU time.

Alternatively, it may mean that the voodoo3 card can't take advantage of dirty rendering like the software version does and has to re-render the entire screen every frame even when the viewport size is reduced. But I don't think it's that because a similar effect is observed between 640x480 and 800x600, where the software renderer gains 50% and the 3DFX renderer only gains 12% even though both are full screen. Plus the voodoo 3 has plenty of fill rate anyway.

At 800x600, the 3DFX renderer at 200Mhz has about the same performance as the software renderer at 550Mhz. So at least you can say there is a significant benefit at high resolutions. It's not a constant 60fps but it keeps you in the 30-60 range. I was also thinking, the geometry setup probably requires FPU and pentium CPUs will overperform there compared to K6, Cyrix and 5x86 class CPUs.

Note: This is standing on the cinema bathroom stalls looking towards the mirror in hollywood holocaust, it's a heavy render for the engine

Just thinking about how this patch works, as long as the conversion to glide is based on converting columns to triangles there will be significant unavoidable CPU overhead, so this patch will not be worth using on slower CPUs at low resolutions and the effect will be more pronounced the weaker the FPU is on a particular CPU. In my case at 550Mhz the result is very good, specifically because there is spare CPU time at 60fps to run the geometry conversion without hitting a CPU cap. I imagine the only way to break though the hardware path overhead is to use surface translation instead of column translation which would significantly reduce the triangle count, but that would be a lot more work.

I think this version is pretty much good to go, no obvious bugs and good performance.

Can confirm the latest version improves performance a good amount on my AMD 5x86, nice work!

Chadti99 wrote on Today, 01:22:

Can confirm the latest version improves performance a good amount on my AMD 5x86, nice work!

What difference in framerates are you seeing with DNRATE? And 640x480 or 800x600?

I tested the new patch on a few systems. Using dnrate on the same scene (on the roof of the buliding watching the fan spin from afar):

Cyrix Media GX1-300 w/Banshee @800x600
software = 27 fps
old patch = 16 fps
new patch = 34 fps
It is playable now!

Cyrix 5x86-133/4x w/Voodoo3 @800x600
software = 12 fps
old patch = 7 fps
new patch = 12 fps

Cyrix 5x86-133/4x w/Voodoo3 @640x480
software = 17 fps
old patch = not measured
new patch = 14 fps

The improvement with the new patch is considerable, approximately double on my GX1-300. Unfortunately, on slower systems, like a Cyrix 5x86, the patch is still slower than software mode. User input in 3dfx mode felt more laggy than in software mode.