tincup wrote on 2025-03-28, 00:24:

You'll find Pavel's reyn1999 and his other carsets/tracks in this link. I found it in a forum thread at ICR2.net - they should r […]
Show full quote

sharangad wrote on 2025-03-27, 21:25:

tincup wrote on 2025-03-27, 20:52:

EDIT: Probably the worst combo I've seen is reyn1999 + Clevland (7-23-2012 dat); formation lap never above 30s.

Where can I find these? I think the problem with the carset is that there're a lot of cars and they all have to be rendered at high detail.

You'll find Pavel's reyn1999 and his other carsets/tracks in this link. I found it in a forum thread at ICR2.net - they should really sticky it in the forum.

https://drive.google.com/drive/folders/1MjSDl … Nh25495Q6DcZBz1

Also I can confirm this carset is taxing on performance - I had to prune the Draw Ahead number a fair amount to even start in mid 40's, say at Gateway98. Still drivable, but starts are also critical to get through cleanly so FPS are your friend.

The performance issues with high-poly carsets appear to be with the number of polygons being rendered. For instance on the Houston track with 32 cars drawn ahead and 32 behind over 13000 polygons are being rendered. With the game's default setting it's around 4000. If this is dosbox-rendition choking on transforming all those polygons, fixing it will be difficult. If it's RReady, it can probably be fixed.

More testing needs to be done. The RReady thread is busier (has a higher CPU load) with fewer polygons.

sharangad wrote on 2025-03-30, 17:45:

tincup wrote on 2025-03-28, 00:24:

You'll find Pavel's reyn1999 and his other carsets/tracks in this link. I found it in a forum thread at ICR2.net - they should r […]
Show full quote

sharangad wrote on 2025-03-27, 21:25:

Where can I find these? I think the problem with the carset is that there're a lot of cars and they all have to be rendered at high detail.

You'll find Pavel's reyn1999 and his other carsets/tracks in this link. I found it in a forum thread at ICR2.net - they should really sticky it in the forum.

https://drive.google.com/drive/folders/1MjSDl … Nh25495Q6DcZBz1

Also I can confirm this carset is taxing on performance - I had to prune the Draw Ahead number a fair amount to even start in mid 40's, say at Gateway98. Still drivable, but starts are also critical to get through cleanly so FPS are your friend.

The performance issues with high-poly carsets appear to be with the number of polygons being rendered. For instance on the Houston track with 32 cars drawn ahead and 32 behind over 13000 polygons are being rendered. With the game's default setting it's around 4000. If this is dosbox-rendition choking on transforming all those polygons, fixing it will be difficult. If it's RReady, it can probably be fixed.

More testing needs to be done. The RReady thread is busier (has a higher CPU load) with fewer polygons.

Cool - lets us know if we can test any car/track combos if it helps.

Disabling the polygon rendering adds around 4-5 frames to the frame rate. So that's not the culprit.

Well, what do you know, the game actually uses z-buffering. Saw z-buffer write enable commands pop up, so I just enabled it.

Actually works on original hardware as well.

[EDIT] But it *might* not be using it correctly. It doesn't handle having part of VRAM allocated to an z-buffer *and* seems to use a centre of object (painter's algorithm) to determine if an object is visible. On the Riverside track, cars show up on the other side of rises, even with original hardware, so I don't really know what the z-buffer write enable commands are doing here.

On the polygon front , there are three times as many state changes as there are polygon calls (rendering 1 or more lines or triangles). For the built-in Australia track with Reny1999 and a reduced # of cars, there are 3,000-4,000 polygon calls per frame and 12000 state changes. For Houston/Reyn1999 with 32/32 there are 13,000 polygon calls and ~39,000 state changes. Each state change can involve around 3 or more function calls which means there are ~ 120,000 function calls per frame., not including the OpenGL ones which can be quite heavy. Most of them are relatively light, but function calls are expensive. This could be why the frame rate is so low.

You mean inline functions needed?
As I remember correctly they work faster but raise code size significantly

RaVeN-05 wrote on 2025-03-31, 02:02:

You mean inline functions needed?
As I remember correctly they work faster but raise code size significantly

Most of them are library functions.

There's some call here which is expensive for some reason.

On original hardware Houston+Reyn1999 8/8 runs at 11 fps
32/32 runs at 8 fps

RReady doesn't appear to be much faster than an actual board.

p4 or ryzen?
you can compare cpu performance of your dosbox, p4 and ryzen in dos with this little proggie:
Re: Suggested specs for a full speed DOSbox machine?

It looks like it's Dosbox's CPU thread that's taking too long. The most expensive function calls are for memory access by ICR2 and then the core_dynamic code.

robertmo3 wrote on 2025-03-31, 11:41:

p4 or ryzen?
you can compare cpu performance of your dosbox, p4 and ryzen in dos with this little proggie:
Re: Suggested specs for a full speed DOSbox machine?

Didn't realise Dhrystones and Whetstones were still around.

i see on this picture this houston track has a lot of rounded buildings at start

just wanted to notice that Reyn1999 cars have sprite helmets so there is still possibility to lower fps by adding 3d helmets 😉

maybe its time to move on to qemu with its whpx cpu virtualisation 😀

robertmo3 wrote on 2025-03-31, 12:04:

just wanted to notice that Reyn1999 cars have sprite helmets so there is still possibility to lower fps by adding 3d helmets 😉

😁
Ryzen 2700X Dosbox (cycles=max 105%)

1Microseconds 1 loop:          4.36
2Dhrystones / second:      229555
3VAX MIPS rating:            130.65

Pentium 3.4 GHz MS-DOS(Win98)

1Microseconds 1 loop:          1.06
2Dhrystones / second:      939794
3VAX MIPS rating:            534.89

I should really be running my wrapper on the P4! 😁

[EDIT] FreeDOS Ryzen 2700X (native)

1Microseconds 1 loop:          0.17
2Dhrystones / second:     6015038
3VAX MIPS rating:           3423.47

Ryzen 2700X QEMU (Windows Hypervisor Platform/WHPX)

1Microseconds for one run through Dhrystone: 0.13
2Dhrystones per Second: 7424594
3VAX MIPS rating = 4225.72

Ryzen VMWare Win98 Command prompt under Win11:

1Microseconds 1 loop:          0.14
2Dhrystones / second:     7281001
3VAX MIPS rating:           4144.00

Dhrystone 2 benchmark QEMU i7 2600 with HAXM (Win10):

1Microseconds for one run through Dhrystone:0.74
2Dhrystones per Second: 1360544
3VAX MIPS rating = 774.36

Windows Hypervisor Platform on my Win10/i7 2600:

1Time for loop iteration 0.33 ms
2Dhrystones 3065134
3VAX MIPS 1744.xx

i7 12600 VMWare WIn98 under Win10:

1Microseconds 1 loop:          0.32
2Dhrystones / second:     3100775
3VAX MIPS rating:           1764.81

check your ryzen without dosbox too 😀

robertmo3 wrote on 2025-03-31, 12:12:

check your ryzen without dosbox too 😀

There's no Windows version? I found one which was a 16 bit Windows app.

[EDIT] Needs a 16 bit VB DLL.

boot to dos

you can also run it in vmware, virtualbox and qemu with whpx enabled

robertmo3 wrote on 2025-03-31, 12:16:

boot to dos

I doubt if Ryzen could correctly boot DOS

BEEN_Nath_58 wrote on 2025-03-31, 12:42:

robertmo3 wrote on 2025-03-31, 12:16:

boot to dos

I doubt if Ryzen could correctly boot DOS

Yup doesn't work. Ryzen won't boot into FreeDOS. It reads the flash drive and then boots into Windows.

[EFI].