checkpoint20 wrote on 2024-05-29, 15:54:

Hi sharangad, we were in touch on racesimcentral previously - posting over here to join the conversation. Really amazing progres […]
Show full quote

Hi sharangad, we were in touch on racesimcentral previously - posting over here to join the conversation. Really amazing progress lately and I've also been working to understand, using my Detroit Downtown mod, why the track doesn't load. Suspecting it is the memory limitation we have been talking about, so I hope there is a way to exceed the 4 MB.

You may have already noticed this but some of the modded tracks are not in .dat files due to a limitation in the number of files possible to pack into a dat file. But tracks that use more than approximately 300 files can have their folders unpacked and the game will load whatever is in the folder. However if a .dat file is present, I believe it will prioritize the file from within the .dat file first.

If you want more documentation on file formats, particular the 3DO and MIP file, those are here: https://www.simcyberworld.com/html/bbb/fileinfo.shtml

Some gaps in knowledge may also be discussed on the ICR2 forums: https://icr2.net/forum/

Hi, thanks for the info. Will check it out tomorrow.

I did briefly look at the. Mip format and noticed there was no colour format info there. Is the pixel data always specced as 32 rgba?

MIP files can be viewed with MipExplorer:
https://www.drnoisepaints.com/utilities/mipexplorer_2003.zip

They can be opened and saved as an editable format with Winmip:
https://drnoisepaints.com/utilities/WinMip2v16.zip

Thanks!

sharangad wrote on 2024-05-29, 16:07:

Hi, thanks for the info. Will check it out tomorrow.

I did briefly look at the. Mip format and noticed there was no colour format info there. Is the pixel data always specced as 32 rgba?

Mip colors are based on a 256-color palette in each track's SUNNY.PCX. The pixels should refer to the color index of this palette.

I believe Mi4 and M16 files are RGB colors but there are currently no tracks using those besides the HQ ones that came with the Rendition ICR2.

i think you guys should try whether those tracks work on real verite cards first

I was looking at the readme file for the Rendition ICR2 and saw this information (among other discussion of memory):

"The game prints a memory report at startup that shows the size of the texture heap (a buffer in system memory that must hold all textures) and the texture cache (a buffer in graphics card memory that holds textures temporarily) and the memory used by the rest of the game (the normal ICR2 memory hi / lo / all message, except these numbers reflect the amount free AFTER some buffers, especially the texture heap, are allocated)."

I ran INDYFAST.BAT which makes the game output the memory report and I saw the following:

Memory Check: 616944 LO 5414896 HI 6031840 ALL
Texture heap size: 6928 K
Texture cache size: 2166 K

I am curious to know why the "texture heap size" is higher than the 4 MB that we've been discussing. And is that number an indicator of how much textures we can have?

checkpoint20 wrote on 2024-05-29, 20:37:

I was looking at the readme file for the Rendition ICR2 and saw this information (among other discussion of memory): […]
Show full quote

I was looking at the readme file for the Rendition ICR2 and saw this information (among other discussion of memory):

"The game prints a memory report at startup that shows the size of the texture heap (a buffer in system memory that must hold all textures) and the texture cache (a buffer in graphics card memory that holds textures temporarily) and the memory used by the rest of the game (the normal ICR2 memory hi / lo / all message, except these numbers reflect the amount free AFTER some buffers, especially the texture heap, are allocated)."

I ran INDYFAST.BAT which makes the game output the memory report and I saw the following:

Memory Check: 616944 LO 5414896 HI 6031840 ALL
Texture heap size: 6928 K
Texture cache size: 2166 K

I am curious to know why the "texture heap size" is higher than the 4 MB that we've been discussing. And is that number an indicator of how much textures we can have?

4 MB is the amount of VRAM on the card. That's not a hard limit on how many textures you can have in a track or carset.
At texture can be loaded, rendered and erased and replaced with a texture in one frame. The 4 MB limit is the maximum amount of textures that can be kept in RAM at one instant. However a single frame can contain more than 4 MBs worth of textured polygons.

The actual limit is the heap size the game can allocate from DOS(Dosbox).

I'm looking at your Detroit '91 track right now. The textures seem fine. The texture sizes seem fine. Elkhart HQ has a 64x1600 texture and none of the textures in D'91 exceed that. The fix to support the md-Ohio track allows a horizontal texture width of 1024 (16 bit texels). I wonder if the 3DO files have a size limit (based on RAM).

The Meadowlands track should render correctly now BTW.

sharangad wrote on 2024-05-29, 21:59:

4 MB is the amount of VRAM on the card. That's not a hard limit on how many textures you can have in a track or carset. At textu […]
Show full quote

4 MB is the amount of VRAM on the card. That's not a hard limit on how many textures you can have in a track or carset.
At texture can be loaded, rendered and erased and replaced with a texture in one frame. The 4 MB limit is the maximum amount of textures that can be kept in RAM at one instant. However a single frame can contain more than 4 MBs worth of textured polygons.

The actual limit is the heap size the game can allocate from DOS(Dosbox).

I'm looking at your Detroit '91 track right now. The textures seem fine. The texture sizes seem fine. Elkhart HQ has a 64x1600 texture and none of the textures in D'91 exceed that. The fix to support the md-Ohio track allows a horizontal texture width of 1024 (16 bit texels). I wonder if the 3DO files have a size limit (based on RAM).

Thank you for looking at Detroit. I did use the wrapper from yesterday and have been rebuilding my Detroit track, first without objects, and then gradually adding them back in. It doesn't take long before I hit an apparent memory limit. I can confirm that your latest wrapper fixed all the wall textures, so thank you very much for that.

It is very possible I am running into 3DO size limit. I have been using a technique of "nesting" 3DOs - for example I have one big 3DO file for Turn 1 that references other 3DOs. So detroi91.3do refers to Turn 1 3do which refers to trees, buildings, etc. Maybe the game can't handle that for some reason? It works fine in vanilla DOS and is a technique that I understand Papyrus used for some of the later NASCAR games.

checkpoint20 wrote on 2024-05-29, 22:32:

sharangad wrote on 2024-05-29, 21:59:

4 MB is the amount of VRAM on the card. That's not a hard limit on how many textures you can have in a track or carset. At textu […]
Show full quote

4 MB is the amount of VRAM on the card. That's not a hard limit on how many textures you can have in a track or carset.
At texture can be loaded, rendered and erased and replaced with a texture in one frame. The 4 MB limit is the maximum amount of textures that can be kept in RAM at one instant. However a single frame can contain more than 4 MBs worth of textured polygons.

The actual limit is the heap size the game can allocate from DOS(Dosbox).

I'm looking at your Detroit '91 track right now. The textures seem fine. The texture sizes seem fine. Elkhart HQ has a 64x1600 texture and none of the textures in D'91 exceed that. The fix to support the md-Ohio track allows a horizontal texture width of 1024 (16 bit texels). I wonder if the 3DO files have a size limit (based on RAM).

Thank you for looking at Detroit. I did use the wrapper from yesterday and have been rebuilding my Detroit track, first without objects, and then gradually adding them back in. It doesn't take long before I hit an apparent memory limit. I can confirm that your latest wrapper fixed all the wall textures, so thank you very much for that.

It is very possible I am running into 3DO size limit. I have been using a technique of "nesting" 3DOs - for example I have one big 3DO file for Turn 1 that references other 3DOs. So detroi91.3do refers to Turn 1 3do which refers to trees, buildings, etc. Maybe the game can't handle that for some reason? It works fine in vanilla DOS and is a technique that I understand Papyrus used for some of the later NASCAR games.

Dunno. If it works with the DOS version it should work here. The geometry is handled by the CPU, the Verité card don't do accelerated geometry or cache them in VRAM.

How exactly do you hit the limit? When exactly is it triggered? What's the last change you made before it stopped working? It might just be some parameter somewhere that it doesn't like.

I've fixed the smoke/dust/sparks textures, so the 50 KB high res effects.dat file should work just fine. The 36 KB low res file shouldn't be used anymore.

https://youtu.be/_XL2kaKnJhw

Binary:
[EDIT]Use this instead:
https://nirvtek.com/downloads/Speedy3D.202405 … 0.Alpha.002.zip
MD5: 28925fa96424cff7280f5b4c504c2907
[/EDIT]
https://nirvtek.com/downloads/Speedy3D.202405 … 0.Alpha.001.zip
MD5: 39567353de706d6ffe3293072f86c46e

Just to be clear, the correct way to install this is:
1) Extract the dosbox package into a fixed folder.
2) Extract RReady into another folder.
3) Run RLauncher, switch to the win apps tab and add dosbox (from the fixed fodler). If it's already here or points to a different installation, right click and remove the existng installation. If dosbox is in the same folder, removal is unnecessary.
3) Launch dosbox from RLauncher.

Once the store release is ready., running RLauncher (from the start menu) and lauching dosbox from there is all that needs to done. The dosbox-rendition.conf and rendition.cfg will be editable from rlauncher. Updates to the package from the store will be auto-deployed every tme Rlauncher runs dosbox. Once ICR2 is fully functional (which it appears to be), I'll do an interim store release with just ICR2 as the sole Speedy3D app.

sharangad wrote on 2024-05-29, 23:09:

Dunno. If it works with the DOS version it should work here. The geometry is handled by the CPU, the Verité card don't do accelerated geometry or cache them in VRAM.

How exactly do you hit the limit? When exactly is it triggered? What's the last change you made before it stopped working? It might just be some parameter somewhere that it doesn't like.

I was putting in the objects, area by area. So I had the track working after putting in the objects along the pit straight (including trees which are PMP based objects and several simple buildings that use a couple MIPs) and then when I put in the collection of objects for Turn 1, it had the problem loading.

I then looked at my Turn 1 object and rebuilt it with the individual 3DOs, adding them one by one until I reached the limit. There was a far away apartment building with a new (but not a big) texture lafa.mip that triggered it. I switched it with another building 3DO to see if it’s specific to the apartment building, and it’s not. Then, I switched the texture of the apartment building to crowds.mip that was already being used on the pit straight, and the track loaded! So I thought what happened is that the game reached some maximum number or size of textures that it could load upon track loading. But maybe instead it was reaching a maximum number of textures per 3DO? That doesn’t make too much sense though, given the main track 3DO has no trouble referring to many MIPs.

checkpoint20 wrote on 2024-05-30, 00:00:

sharangad wrote on 2024-05-29, 23:09:

Dunno. If it works with the DOS version it should work here. The geometry is handled by the CPU, the Verité card don't do accelerated geometry or cache them in VRAM.

How exactly do you hit the limit? When exactly is it triggered? What's the last change you made before it stopped working? It might just be some parameter somewhere that it doesn't like.

I was putting in the objects, area by area. So I had the track working after putting in the objects along the pit straight (including trees which are PMP based objects and several simple buildings that use a couple MIPs) and then when I put in the collection of objects for Turn 1, it had the problem loading.

I then looked at my Turn 1 object and rebuilt it with the individual 3DOs, adding them one by one until I reached the limit. There was a far away apartment building with a new (but not a big) texture lafa.mip that triggered it. I switched it with another building 3DO to see if it’s specific to the apartment building, and it’s not. Then, I switched the texture of the apartment building to crowds.mip that was already being used on the pit straight, and the track loaded! So I thought what happened is that the game reached some maximum number or size of textures that it could load upon track loading. But maybe instead it was reaching a maximum number of textures per 3DO? That doesn’t make too much sense though, given the main track 3DO has no trouble referring to many MIPs.

It could be a limit to the number of sub-objects that an object can contain. If you add the building directly (not sure how easy this is to do), instead of a sub-object does the track load?

[EDIT]
Alternatively add turn2 without turn1's problematic building.

checkpoint20 wrote on 2024-05-30, 00:00:

Then, I switched the texture of the apartment building to crowds.mip that was already being used on the pit straight, and the track loaded! So I thought what happened is that the game reached some maximum number or size of textures that it could load upon track loading. But maybe instead it was reaching a maximum number of textures per 3DO? That doesn’t make too much sense though, given the main track 3DO has no trouble referring to many MIPs.

Sorry, reading comprehension doesn't appear to be my strong suit at 6am.

It's probably a maximum number of textures limit per subobject. If you added turn 1 to the main track object (effectively making them a single object) does it work?

sharangad wrote on 2024-05-30, 00:33:

Sorry, reading comprehension doesn't appear to be my strong suit at 6am.

It's probably a maximum number of textures limit per subobject. If you added turn 1 to the main track object (effectively making them a single object) does it work?

Yes, I agree it probably has something to do with number of textures. I will do some more work on this in the coming days and report back what I learn.

checkpoint20 wrote on 2024-05-30, 05:13:

sharangad wrote on 2024-05-30, 00:33:

Sorry, reading comprehension doesn't appear to be my strong suit at 6am.

It's probably a maximum number of textures limit per subobject. If you added turn 1 to the main track object (effectively making them a single object) does it work?

Yes, I agree it probably has something to do with number of textures. I will do some more work on this in the coming days and report back what I learn.

Could you add each tree, building and barrier directly to the track and see if it works? That is instead of grouping them into subobjects. If you take a look at the elkhart hq track, I think this is how it's done.

Alternatively move the problem building into its own object (turn 1.5) and add turn 1 and turn 1.5 to the track. That might be easier.

https://nirvtek.com/downloads/Speedy3D.202405 … 0.Alpha.003.zip
MD5: a74c1547069d8e102905d118bf7e575e

- Whiplash menus fixed.

Menus in action AND ... track view looks wrong:

https://youtu.be/mMTH4sGUZ3A

robertmo3 wrote on 2024-05-29, 18:20:

i think you guys should try whether those tracks work on real verite cards first

They probably don't, but I think it's worth fixing them so they do. If it works in the wrapper, it should work on a board.