Side by side comparison of Mexico; almost identical with a few small things of note: both good performers - Practice full field starts in 50s and hits 60 leaving pit. Oddly, I'd say my hand built version has a hard to pin point "smoother" feel at times even with both running at 60 - really subtle. It seems to find that glassy smooth spot a little easier.

Popup is about the same, but the barriers in RR have a blue color at distance while in my hand fixed version they remain a flat gray. So the RR version is a bit more distracting at the horizon.

Fence/grandstand popup about same.

Track warning lights - in RR colors are visible at distance but my hand fixed color pops in only as you drive by. I tested the RR mip but the track didn't load - a cumulative mip effect? Overall though hard to find much difference.

OTOH there's an additional difference to the real CART layout. It uses the turn 4 cutoff to skip turns 5-6. So as Pavel said on ICR2.net it's def not the correct layout. But it's fun, looks good and pretty close.

tincup wrote on 2025-04-08, 19:02:

Side by side comparison of Mexico; almost identical with a few small things of note: both good performers - Practice full field […]
Show full quote

Side by side comparison of Mexico; almost identical with a few small things of note: both good performers - Practice full field starts in 50s and hits 60 leaving pit. Oddly, I'd say my hand built version has a hard to pin point "smoother" feel at times even with both running at 60 - really subtle. It seems to find that glassy smooth spot a little easier.

Popup is about the same, but the barriers in RR have a blue color at distance while in my hand fixed version they remain a flat gray. So the RR version is a bit more distracting at the horizon.

Fence/grandstand popup about same.

Track warning lights - in RR colors are visible at distance but my hand fixed color pops in only as you drive by. I tested the RR mip but the track didn't load - a cumulative mip effect? Overall though hard to find much difference.

OTOH there's an additional difference to the real CART layout. It uses the turn 4 cutoff to skip turns 5-6. So as Pavel said on ICR2.net it's def not the correct layout. But it's fun, looks good and pretty close.

So the differences are somewhat minor. Are the replacement textures you used the same size as the original?

tincup wrote on 2025-04-08, 19:02:

Popup is about the same, but the barriers in RR have a blue color at distance while in my hand fixed version they remain a flat gray. So the RR version is a bit more distracting at the horizon.

sharangad, how about using a different way of reducing mipmapping: this 3rd way instead of 2nd way?
so not removing smaller mips completely, but replacing them with the smallest mip so that at least the colours will be right on objects instead of completely different solid colors

or how about making it that only mipmap's header is stored in verite's memory and the rest of mipmap is stored somewhere else.

robertmo3 wrote on 2025-04-09, 07:34:

sharangad, how about using a different way of reducing mipmapping: this 3rd way instead of 2nd way? so not removing smaller mips […]
Show full quote

tincup wrote on 2025-04-08, 19:02:

Popup is about the same, but the barriers in RR have a blue color at distance while in my hand fixed version they remain a flat gray. So the RR version is a bit more distracting at the horizon.

sharangad, how about using a different way of reducing mipmapping: this 3rd way instead of 2nd way?
so not removing smaller mips completely, but replacing them with the smallest mip so that at least the colours will be right on objects instead of completely different solid colors

Can't. They horizontal and vertical resolutions have to be half the previous level's. The game won't load the track without them.

robertmo3 wrote on 2025-04-09, 07:55:

or how about making it that only mipmap's header is stored in verite's memory and the rest of mipmap is stored somewhere else.

I actually came up with a method of avoiding texture loads by keeping every single texture loaded permanently after initial load using md5 checksums.

It didn't improve performance at all. Dosbox copies textures across byte by byte into the dma buffer, so the actual the game itself still has to go through the motions and in fact that's what takes up the most cpu in dosbox.

i wasn't about cpu usage (that possibly can be fixed in qemu, or disabling thyper threading, and/or simply faster cpus in the future),
but about fails to load tracks caused by lack of memory, so that you don't have to reduce track's mipmaps, so that distant objects remain properly textured

Hmm it is possible to fake the game to 'think' it can load all mips, while at wrapper side mips got loaded until buffer filled, and then next mips will not be stored, but mimics that it uploaded and stored.

sharangad wrote on 2025-04-08, 02:35:

It'll be interesting to see how well qemu /freedos based icr2 runs.

i think you can have a taste of that by running 3dfx version of nascar racing 2 in my build of qemu3dfx, with some heavy carsets/tracks 😀

robertmo3 wrote on 2025-04-09, 08:48:

sharangad wrote on 2025-04-08, 02:35:

It'll be interesting to see how well qemu /freedos based icr2 runs.

i think you can have a taste of that by running 3dfx version of nascar racing 2 in my build of qemu3dfx, with some heavy carsets/tracks 😀

I'll try that at some point.

RaVeN-05 wrote on 2025-04-09, 08:45:

Hmm it is possible to fake the game to 'think' it can load all mips, while at wrapper side mips got loaded until buffer filled, and then next mips will not be stored, but mimics that it uploaded and stored.

I still can't tell if it's the number of mipmaps or the texture size that's killing it.

The problem with the game is that some of its memory allocation is done using old school dos allocs which can only dish out limited amount of RAM. A lot of memory management is done using 16 bit allocation calls and it's a bit difficult to change this. In fact in a lot of places it ANDs 32 bit registers with 0xFFFF, which chops of the upper 16 bits. I have tried changing this to AND 0xFFFFFFFF but the game doesn't seem to like it very much. In fact on one of the calls it crashes DOS32/A with a not enough pages failure.

[EDIT] DOS32/A does use up all available RAM, but sub-allocation seems to be restricted to 16 bit quantities.

sharangad wrote on 2025-04-09, 09:23:

I still can't tell if it's the number of mipmaps or the texture size that's killing it.

that should be easy to tell:
if you are able to remove less big mipmaps than small mipmaps, then it is not number of mipmaps but texture size

robertmo3 wrote on 2025-04-09, 09:40:

sharangad wrote on 2025-04-09, 09:23:

I still can't tell if it's the number of mipmaps or the texture size that's killing it.

that should be easy to tell:
if you are able to remove less big mipmaps than small mipmaps, then it is not number of mipmaps but texture size

Excellent point! I'll try that after these Windows updates.

robertmo3 wrote on 2025-04-09, 09:40:

sharangad wrote on 2025-04-09, 09:23:

I still can't tell if it's the number of mipmaps or the texture size that's killing it.

that should be easy to tell:
if you are able to remove less big mipmaps than small mipmaps, then it is not number of mipmaps but texture size

The reason I didn't try that is because texture coordinates need to be modified. TREdit's arbitrary texture resizing (coords) is currently broken.

I should probably fix that first before anything else. I'll do all that after these infernal updates.

i recommend disabling hyper threading for windows updates as they use only one core for that
actually i see no use for hyper threading at all

It's not a texture size issue, I *think*, because Cars95 doesn't work with the MIP reduced Mexico. It does work with other MIP reduced carsets, most of which have much larger textures. Cars95 is relatively lightweight.

I don't seem to be able to get the tracks working with the larger mipmaps dropped, not at all. Probably a bug in my code somewhere.

[EDIT]
It does work with software rendered ICR2 under DOS with corrupted graphics, since I haven't fixed the coordinates yet.
[/EDIT]

Software rendered ICR2 doesn't seem to have any frame rate issues with Houston+Reyn1999 with A32/B32.

sharangad wrote on 2025-04-09, 06:50:

So the differences are somewhat minor. Are the replacement textures you used the same size as the original?

Yes, the mips in my hand made fix are smaller. But I noticed some of the tree and horizon mips have the same size so it's likely I could skip those. I swapped those two groups en masse for simplicity sake.

sharangad wrote on 2025-04-10, 06:58:

It's not a texture size issue, I *think*, because Cars95 doesn't work with the MIP reduced Mexico. It does work with other MIP reduced carsets, most of which have much larger textures. Cars95 is relatively lightweight.

I noticed the same thing with CARS95 which I initially used for baseline testing since it's light. But Mexico wouldn't load - tho did with the other heavy carsets.

Tested Rebel Moon 1996 version only - runs fine.
But 1995 version isn't run - don't recognise 3d blaster and auto-closes.
1995 version is avaliable here - 3206 (57.55 MB)