I use a TNT2, which is VBE 3.0, and it works great with Duke3D - including mirrors.

badmojo wrote on 2023-12-30, 11:34:

I use a TNT2, which is VBE 3.0, and it works great with Duke3D - including mirrors.

Test it at higher resolution (1024x768 or higher) and type 'dnrate' to check FPS. In theory you should see some reduced FPS even on real hardware. It's because of DN3D in VBE 2.0 modes uses page flipped double buffering (no system memory is used as frame buffer) and in case of mirrors the engine needs to read from video memory that is slower than read from system memory.

Falcosoft wrote on 2023-12-30, 11:51:

It's because of DN3D in VBE 2.0 modes uses page flipped double buffering (no system memory is used as frame buffer) and in case of mirrors the engine needs to read from video memory that is slower than read from system memory.

So would that be an oversight by the game devs, not realizing the performance degradation?

Considering that the game seem to be working just fine on VBE 1.2 cards (at least in 86Box), why does Duke show that warning message about running it on a 2.0 card?

eddman wrote on 2023-12-30, 15:11:

Falcosoft wrote on 2023-12-30, 11:51:

It's because of DN3D in VBE 2.0 modes uses page flipped double buffering (no system memory is used as frame buffer) and in case of mirrors the engine needs to read from video memory that is slower than read from system memory.

So would that be an oversight by the game devs, not realizing the performance degradation?

Considering that the game seem to be working just fine on VBE 1.2 cards (at least in 86Box), why does Duke show that warning message about running it on a 2.0 card?

In theory page flipping should be always faster. Page flipping saves an unnecessary bit block transfer from system memory to video memory. If page flipping is enabled you have at least 2 video pages in video memory. The software always prepares content on the back buffer page and when the content is ready it simply swaps the back buffer for the front buffer page, thus the former back buffer becomes the front buffer and vice versa. It's only a simple pointer operation, no copying of data is necessary at all. When page flipping is not enabled the content from the system memory back buffer has to be copied to video memory that is not a simple pointer operation but a huge block transfer.
Although the situation is different when you need data from the frame buffer (that is you need to read from the frame buffer in video memory). Reading from video memory is always slower than reading from system memory. The magnitude of the slowdown is implementation dependent.
BTW, this kind of 'reading from video memory' slowdown is also present in e.g. Quake when page flipping mode is active and you press ESC to change settings meanwhile the game renders scenes at the background (so it has to combine 2 video memory surfaces to achieve transparent/translucent effect). This problem is also present in case of some Directdraw applications when they have to work with 2 (or more) video memory surfaces to achieve transparency.