sharangad wrote on 2024-05-27, 09:53:

Does anyone have vquake v1.06 and it's associated microcode? There's a report of a 486/Verité based system that has the same problems that I have with dosbox with vquake v1.08.

the reason was
Re: Rendition Verite Thread

robertmo3 wrote on 2024-05-27, 16:12:

sharangad wrote on 2024-05-27, 09:53:

Does anyone have vquake v1.06 and it's associated microcode? There's a report of a 486/Verité based system that has the same problems that I have with dosbox with vquake v1.08.

the reason was
Re: Rendition Verite Thread

Thanks for that! You saved me a lot of time.

Could someone with a Verité board run this and post the output (from Run.bat):
https://1drv.ms/u/c/5277ef8d4f2a9dcf/EUp6dvPN … 63WJww?e=pFfrHR
or
https://nirvtek.com/downloads/Fifo.20240528.001.zip

MD5: 1108f5f1b91b7e67a192e9a10082425d

What I'm actually after is the output of the INT10h 1580 call at the end and thanks!

Hi Sharangad

I was able to test the latest build with IndyCar II and most of the keyboard controls are functioning. 'W' still does not do anything, and 'F10' is also still not working, but otherwise the controls to adjust the car are working which is great!

The update to add 'threadsafe' to the conf file has improved performance a lot with the higher polygon mod carsets and they load correctly now. There are some small graphical glitches on the texturing for the higher polygon 3d wheels. Im not sure this is caused by the wrapper but I thought I would note it:

If you want to try this carset with higher polygon tires you can replace the default 'cars95' folder with this one:

I have recorded a video of how the game looks at one of the custom tracks which was able to load. There are some graphical glitches in the wall textures but I am not sure if this is an incompatible setting for the textures on the mod, or something to do with the wrapper.

https://www.youtube.com/watch?v=fWMsukX4WxA

gplaps wrote on 2024-05-28, 02:37:

Hi Sharangad

I was able to test the latest build with IndyCar II and most of the keyboard controls are functioning. 'W' still does not do anything, and 'F10' is also still not working, but otherwise the controls to adjust the car are working which is great!

F10 should definitely work. Try this build:

https://nirvtek.com/downloads/Speedy3D.202405 … 7.Alpha.001.zip
MD5: 812bf0e104f75ead64898c6614eec13a

Going forward I'll add the latest build to the first post.

gplaps wrote on 2024-05-28, 02:37:

The update to add 'threadsafe' to the conf file has improved performance a lot with the higher polygon mod carsets and they load correctly now. There are some small graphical glitches on the texturing for the higher polygon 3d wheels. Im not sure this is caused by the wrapper but I thought I would note it:

I think on faster systems it works ok. On slower ones it may kill the framerate, but DMA mode should be fully stable.

gplaps wrote on 2024-05-28, 02:37:

https://i.postimg.cc/D00zH39S/image.png […]
Show full quote

If you want to try this carset with higher polygon tires you can replace the default 'cars95' folder with this one:
cars95.zip

Not sure. Will look into it.

gplaps wrote on 2024-05-28, 02:37:

I have recorded a video of how the game looks at one of the custom tracks which was able to load. There are some graphical glitches in the wall textures but I am not sure if this is an incompatible setting for the textures on the mod, or something to do with the wrapper.
https://www.youtube.com/watch?v=fWMsukX4WxA

The adverts on the barriers are corrupted. It could be that they're in an incompatible format or size OR the wrapper is messing the byte width up.

Which track is that?

@robertmo3, I retested my Haswell dual core/HD 4000 and it's actually faster with threadsafe=true (higher franerates, hits 30 fps after around 10s. Without this the framerate maxes out at 22 fps.

My ryzen/8 core with Gtx1060 has audio stutter at track load and then it's fine. No difference in frame rates.

ICR2 Rollbars and Camera Cycling (F10):
https://youtu.be/7nSQj3xwDhw

sharangad wrote on 2024-05-27, 23:36:

Could someone with a Verité board run this and post the output (from Run.bat): https://1drv.ms/u/c/5277ef8d4f2a9dcf/EUp6dvPN … 6 […]
Show full quote

Could someone with a Verité board run this and post the output (from Run.bat):
https://1drv.ms/u/c/5277ef8d4f2a9dcf/EUp6dvPN … 63WJww?e=pFfrHR
or
https://nirvtek.com/downloads/Fifo.20240528.001.zip

MD5: 1108f5f1b91b7e67a192e9a10082425d

What I'm actually after is the output of the INT10h 1580 call at the end and thanks!

Sure, I'll try it as soon as I'm back from work.

sharangad wrote on 2024-05-28, 02:52:

Which track is that?

I have attached the track here. It is a total replacement for the "midohio" folder that comes with the game:

gplaps wrote on 2024-05-28, 10:38:

sharangad wrote on 2024-05-28, 02:52:

Which track is that?

I have attached the track here. It is a total replacement for the "midohio" folder that comes with the game:
MIDOHIO.zip

Thanks! That's a job for tomorrow, unfortunately.

sharangad wrote on 2024-05-27, 23:36:

Could someone with a Verité board run this and post the output (from Run.bat): https://1drv.ms/u/c/5277ef8d4f2a9dcf/EUp6dvPN … 6 […]
Show full quote

Could someone with a Verité board run this and post the output (from Run.bat):
https://1drv.ms/u/c/5277ef8d4f2a9dcf/EUp6dvPN … 63WJww?e=pFfrHR
or
https://nirvtek.com/downloads/Fifo.20240528.001.zip

MD5: 1108f5f1b91b7e67a192e9a10082425d

What I'm actually after is the output of the INT10h 1580 call at the end and thanks!

Here's the output for my two V2x00 boards. One is the Diamond Stealth S220 4MB PCI, the other is the QDI Vision V2200 8MB AGP

MSxyz wrote on 2024-05-28, 14:15:

sharangad wrote on 2024-05-27, 23:36:

Could someone with a Verité board run this and post the output (from Run.bat): https://1drv.ms/u/c/5277ef8d4f2a9dcf/EUp6dvPN … 6 […]
Show full quote

Could someone with a Verité board run this and post the output (from Run.bat):
https://1drv.ms/u/c/5277ef8d4f2a9dcf/EUp6dvPN … 63WJww?e=pFfrHR
or
https://nirvtek.com/downloads/Fifo.20240528.001.zip

MD5: 1108f5f1b91b7e67a192e9a10082425d

What I'm actually after is the output of the INT10h 1580 call at the end and thanks!

Here's the output for my two V2x00 boards. One is the Diamond Stealth S220 4MB PCI, the other is the QDI Vision V2200 8MB AGP

Both return the same thing, just like the other board. This app returned the right mem size but not the strings.

Thanks!

Function keys seem to work in ICR2, a user on youtube asked about it so here's another tired boring video:
https://youtu.be/Rab_1q21SA0

gplaps wrote on 2024-05-28, 02:37:

The update to add 'threadsafe' to the conf file has improved performance a lot with the higher polygon mod carsets and they load […]
Show full quote

The update to add 'threadsafe' to the conf file has improved performance a lot with the higher polygon mod carsets and they load correctly now. There are some small graphical glitches on the texturing for the higher polygon 3d wheels. Im not sure this is caused by the wrapper but I thought I would note it:

If you want to try this carset with higher polygon tires you can replace the default 'cars95' folder with this one:
cars95.zip

I have recorded a video of how the game looks at one of the custom tracks which was able to load. There are some graphical glitches in the wall textures but I am not sure if this is an incompatible setting for the textures on the mod, or something to do with the wrapper.

With the high res CARS95 models, edge antialiasing appears to cause the issue. Hitting [ALT+A] when on a track will disable edge AA.

https://youtu.be/Ah10I8Nd2EY

gplaps wrote on 2024-05-28, 10:38:

sharangad wrote on 2024-05-28, 02:52:

Which track is that?

I have attached the track here. It is a total replacement for the "midohio" folder that comes with the game:
MIDOHIO.zip

This release should fix the issue with the high-detail MID-OHIO track.

https://nirvtek.com/downloads/Speedy3D.202405 … 9.Alpha.001.zip
MD5: d4e86db95698d0b73ea4b4053f77fc09

You can see it in action here:
https://youtu.be/GPsD3yzrKw8

sharangad wrote on 2024-05-29, 12:55:

This release should fix the issue with the high-detail MID-OHIO track. […]
Show full quote

gplaps wrote on 2024-05-28, 10:38:

sharangad wrote on 2024-05-28, 02:52:

Which track is that?

I have attached the track here. It is a total replacement for the "midohio" folder that comes with the game:
MIDOHIO.zip

This release should fix the issue with the high-detail MID-OHIO track.

https://nirvtek.com/downloads/Speedy3D.202405 … 9.Alpha.001.zip
MD5: d4e86db95698d0b73ea4b4053f77fc09

You can see it in action here:
https://youtu.be/GPsD3yzrKw8

Thanks for the continued work on this! I was able to try this out and the issue appears fixed and the track looks great now.

I also discovered I wasn't properly replacing the RReady version of dosclient.exe and the dll files, so the "F10" issue was my fault and can confirm it now works as you describe.

Overall it appears like the game is working really well, the Anti-Aliasing toggle fixes the problems with the tire texture too.

I will continue testing, but for the default game it appears to run as expected!

One question I have is regarding the memory used by the wrapper. I have been using the following parameter when launching the game:
set SPEEDY3D_MEMSIZE=8

Does the card itself use 8mb or is it still using 4mb? It appears a lot of the modifications we have developed over the years use more than 4mb which is why we are unable to load a lot of the tracks with the 'Insufficient Memory' error. Is the 4mb a limitation of the card or is there an opportunity to include more memory? I do not know much about this topic so forgive me if it is a silly question!

Again, appreciate all the hard work on this!

gplaps wrote on 2024-05-29, 13:55:

Thanks for the continued work on this! I was able to try this out and the issue appears fixed and the track looks great now. […]
Show full quote

sharangad wrote on 2024-05-29, 12:55:

This release should fix the issue with the high-detail MID-OHIO track. […]
Show full quote

gplaps wrote on 2024-05-28, 10:38:

I have attached the track here. It is a total replacement for the "midohio" folder that comes with the game:
MIDOHIO.zip

This release should fix the issue with the high-detail MID-OHIO track.

https://nirvtek.com/downloads/Speedy3D.202405 … 9.Alpha.001.zip
MD5: d4e86db95698d0b73ea4b4053f77fc09

You can see it in action here:
https://youtu.be/GPsD3yzrKw8

Thanks for the continued work on this! I was able to try this out and the issue appears fixed and the track looks great now.

I also discovered I wasn't properly replacing the RReady version of dosclient.exe and the dll files, so the "F10" issue was my fault and can confirm it now works as you describe.

Overall it appears like the game is working really well, the Anti-Aliasing toggle fixes the problems with the tire texture too.

I will continue testing, but for the default game it appears to run as expected!

One question I have is regarding the memory used by the wrapper. I have been using the following parameter when launching the game:
set SPEEDY3D_MEMSIZE=8

Does the card itself use 8mb or is it still using 4mb? It appears a lot of the modifications we have developed over the years use more than 4mb which is why we are unable to load a lot of the tracks with the 'Insufficient Memory' error. Is the 4mb a limitation of the card or is there an opportunity to include more memory? I do not know much about this topic so forgive me if it is a silly question!

Again, appreciate all the hard work on this!

The game appears to be rejecting the tracks based on the sizes of individual components.

Whep the game came out, Verité boards didn't have more than 4 MB of RAM and the Speedy3D API wasn't particularly forward looking to support more. Rredline has both a low level mode like speedy3d and a high level abstraction model.

The wrapper supports 128 MB of VRAM for RRedline apps when using the abstraction mode. For Speedy3D the structures used don't allow more than 16 MB of VRAM. In practice the api capped VRAM to 4 MB.

The environment variable is used by the speedy3d library static linked to the game, but it may be internally capping it to 4 MB, using the var only if it's below that.

The game binary (exe) is rejecting maps and tracks, long before anything is passed on to the wrapper.

The game would have to be hacked to increase the limit.

Also, if you could point me to some documentation on the .dat files maybe I can modify them to work.

You could try setting the environment variable to 16 MB, but I don't think it'll make a difference.

sharangad wrote on 2024-05-29, 15:05:

The game appears to be rejecting the tracks based on the sizes of individual components. […]
Show full quote

gplaps wrote on 2024-05-29, 13:55:

Thanks for the continued work on this! I was able to try this out and the issue appears fixed and the track looks great now. […]
Show full quote

sharangad wrote on 2024-05-29, 12:55:

This release should fix the issue with the high-detail MID-OHIO track. […]
Show full quote

This release should fix the issue with the high-detail MID-OHIO track.

https://nirvtek.com/downloads/Speedy3D.202405 … 9.Alpha.001.zip
MD5: d4e86db95698d0b73ea4b4053f77fc09

You can see it in action here:
https://youtu.be/GPsD3yzrKw8

Thanks for the continued work on this! I was able to try this out and the issue appears fixed and the track looks great now.

I also discovered I wasn't properly replacing the RReady version of dosclient.exe and the dll files, so the "F10" issue was my fault and can confirm it now works as you describe.

Overall it appears like the game is working really well, the Anti-Aliasing toggle fixes the problems with the tire texture too.

I will continue testing, but for the default game it appears to run as expected!

One question I have is regarding the memory used by the wrapper. I have been using the following parameter when launching the game:
set SPEEDY3D_MEMSIZE=8

Does the card itself use 8mb or is it still using 4mb? It appears a lot of the modifications we have developed over the years use more than 4mb which is why we are unable to load a lot of the tracks with the 'Insufficient Memory' error. Is the 4mb a limitation of the card or is there an opportunity to include more memory? I do not know much about this topic so forgive me if it is a silly question!

Again, appreciate all the hard work on this!

The game appears to be rejecting the tracks based on the sizes of individual components.

Whep the game came out, Verité boards didn't have more than 4 MB of RAM and the Speedy3D API wasn't particularly forward looking to support more. Rredline has both a low level mode like speedy3d and a high level abstraction model.

The wrapper supports 128 MB of VRAM for RRedline apps when using the abstraction mode. For Speedy3D the structures used don't allow more than 16 MB of VRAM. In practice the api capped VRAM to 4 MB.

The environment variable is used by the speedy3d library static linked to the game, but it may be internally capping it to 4 MB, using the var only if it's below that.

The game binary (exe) is rejecting maps and tracks, long before anything is passed on to the wrapper.

The game would have to be hacked to increase the limit.

Also, if you could point me to some documentation on the .dat files maybe I can modify them to work.

You could try setting the environment variable to 16 MB, but I don't think it'll make a difference.

Hi Sharangad,

This program can be used to unpack dat files via dos command line:

It would be placed in the same directory as the DAT file and can be used to unpack and pack dat files:

1/unpack datfilename.dat

1/pack datfilename.pck

The dat files contain all of the 3d (.3do) and texture (.mip, .mi4, .pmp, and some others) files for each track.

A lot of the addon tracks are much bigger than the base ones which came with the game, so it seems we are running out of memory because they contain many more textures. The tracks load correctly in the Dos version of the game, so the memory constraints written in the .exe file must be different dealing with rendition.

I will continue to explore

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/

gplaps wrote on 2024-05-29, 15:37:

This program can be used to unpack dat files via dos command line: dat.zip […]
Show full quote

This program can be used to unpack dat files via dos command line:
dat.zip

It would be placed in the same directory as the DAT file and can be used to unpack and pack dat files:

Copy code to clipboard

1/unpack datfilename.dat

Copy code to clipboard

1/pack datfilename.pck

The dat files contain all of the 3d (.3do) and texture (.mip, .mi4, .pmp, and some others) files for each track.

Thanks for that, but how do you edit a. Mip file? Do I have to use a special program for that?

[EDIT] This post is redundant. [/EDIT]