Finally working.

I forgot to add 1 to the number of vertices for Flavour 2 (and Flavour 1) nodes.

Many thanks to checkpoint20 for his awesome 3DO script.

Videos:
Cars2020
https://youtu.be/V0AeFDpuwBs

Modded carset:
https://nirvtek.com/downloads/cars2020%2CRenditionReady.7z
MD5: e2a29cfea8360052138cc1c9578abad5

1982Cart:
https://youtu.be/_7fyDFqDhJk

Modded carset:
https://nirvtek.com/downloads/1982CART.RenditionReady.7z
MD5: 8bc0862c2f22d234fd1b16626643bb63

The track converter (TREdit x64):
https://nirvtek.com/downloads/TREdit.7z
MD5: 63848dcb4a6c4f7f3ee3131764e581e3

Currently only supports carset conversion.
[EDIT]
Fully Qualified input and output paths are required at the moment.
[/EDIT]

Usage:

To convert an unpacked carset:
TREdit <unpacked DAT folder> -convert <target folder>

You may have to copy in files outside the dat file like drivers.txt.

To unpack a DAT:
TREdit <path to DAT file> -unpack <output folder>

Files outside the dat file are not currently copied to the output folder.

To extract or explode MIPs from an unpacked track DAT:
TREDit <Unpacked DAT folder> -explode <output folder>

To extract or explode MIPs from an unpacked carset:
TREdit <Unpacked DAT folder> -palette <path to sunny.pcx> -explode <output folder>

The sunny.pcx can be found by unpacking one of the built in track DATs.

Sweet, sweet music to my wrapper ears:
https://www.techspot.com/news/106046-no-more- … mlined-x86.html

Shrinking carsets even further to 16 colour Mi4s from 256 colour Mip files allows the custom track Detroit Downtown to run. There's no dithering at the moment, so that's the next step:

Cars2020+ Detroit Downtown
https://youtu.be/k9WQcZkkngU

1982 Cart
https://youtu.be/fA5zMND9IHQ

Download link and instructions in video details.

The second pass uses:
[EDIT2]
TREdit <ShrunkMIPFolder> -palette <pathToSunny,.cx> -track -convert <Mi4Folder>
[/EDIT2]

[EDIT]
https://nirvtek.com/downloads/cars2020.Mi4.No … nditionReady.7z
MD5: b024a30ccdf7e18ee640cd3c141b9d68

https://nirvtek.com/downloads/1982CART.Mi4.No … ditionReady..7z
MD5: 4090048745bcd2cc41e5908cf9d2a0aa
[/EDIT]

@Raven-05 we really need to hack this game to support more VRAM.

Ok, first off all we need to know where to start. It sounds simple but could be not trivial to expand to more vram, also i am novice to dos hacking.
did you ever saw any app or game which looking for more or less than 4mb?
hacking constant values is difficult to spot them, as they do not change.
i remember Whiplash/Fatal Racing can change between some vram memory sizes. But i am not sure if it ever changes something. and not just simple programming left over .
from other side , lets say we have 8mb, and we force fill them, did dos app can use addresses beyond 4mb, or every function uses fixed addresses for certain graphical things?
probably memory fixed size (4mb) hardcoded inside of API that statically linked inside game? and *.uc files are just helpful microcode for video card.

or we need to know exact value of vram game uses (hardcoded) so we can find that value in INT like types. i really doubt it uses 32/64/80bit floats or string. String easiest to find. but as preactice shows older games prefer binary compled data. so knowing exact vram limit value hardcoded in game can potentially make easier to find this value and replace.

did any app/game ever sees more or less 4mb?
What will happen if you limit VRAM to 2mb - games crash or how they react?

RaVeN-05 wrote on 2024-12-26, 17:46:

Ok, first off all we need to know where to start. It sounds simple but could be not trivial to expand to more vram, also i am no […]
Show full quote

Ok, first off all we need to know where to start. It sounds simple but could be not trivial to expand to more vram, also i am novice to dos hacking.
did you ever saw any app or game which looking for more or less than 4mb?
hacking constant values is difficult to spot them, as they do not change.
i remember Whiplash/Fatal Racing can change between some vram memory sizes. But i am not sure if it ever changes something. and not just simple programming left over .
from other side , lets say we have 8mb, and we force fill them, did dos app can use addresses beyond 4mb, or every function uses fixed addresses for certain graphical things?
probably memory fixed size (4mb) hardcoded inside of API that statically linked inside game? and *.uc files are just helpful microcode for video card.

or we need to know exact value of vram game uses (hardcoded) so we can find that value in INT like types. i really doubt it uses 32/64/80bit floats or string. String easiest to find. but as preactice shows older games prefer binary compled data. so knowing exact vram limit value hardcoded in game can potentially make easier to find this value and replace.

did any app/game ever sees more or less 4mb?
What will happen if you limit VRAM to 2mb - games crash or how they react?

I understand that it's difficult to change certain hardcoded limits and that address calculation for textures maybe thrown off.

- Eurofighter 2000+ writes to 8 MB of VRAM but uses only 4MB (i.e. selects textures from the first 4 MB) an as yet unreleased RReady bug fix rounds all write addresses for this game to 4 MB, eliminating texture corruption when switching between the menu and the actual game. I haven't released this yet, because I don't a) I don't have the time and b) EF2000+ Rendition Edition isn't the most popular game today and not many people are dying to play it right now. If someone requests it I can push it out. I will push this out in in January along with the GPL 60 fps interp. fix.
- Whiplash Rendition Edition in-game lists 4 MB Edition. Restricting reported VRAM to 2MB does nothing, the game continues to access 4 MB. Restricing actual virtual VRAM will probably crash the game. Pretty much every single game seems to ignore reported memory and I don't know why they assume there's 4 MB, the BIOS maybe. But from what I've discovered, the only part of the BIOS that they actually use doesn't seem to include a VRAM limit.

What I would like to see is someone running a replay using 1982Cart+DetroitDowntown on an 8 MB card and reporting back whether the world textures lose detail as happens here, towards the end:
https://youtu.be/fA5zMND9IHQ

1982Cart, paletted, no dither:
https://nirvtek.com/downloads/1982CART.Mi4.No … ditionReady..7z
MD5: 4090048745bcd2cc41e5908cf9d2a0aa
Detroit Downtown HQ:
https://www.icr2.net/forum/showthread.php?tid … =13943#pid13943

You said you were a novice hacker, well to learn to swim you dive into the deep end:)!

[EDIT] Are there any 2 MB BIOSs that I can take a look at?[/EDIT2]

[EDIT3]
A lot of the enhanced tracks fail to load on Rendition ICR2 because the track size alone is 4 MB and the carsets also add to that. I think boosting the limit somehow will allow a lot of these tracks to run unmodified.
[/EDIT3]

[EDIT4]
I think what we need to look for is bitwise AND with 0x003FFFFF.

OK will look if 0x3fffff is easy can be found.
Fixed link
https://nirvtek.com/downloads/1982CART.Mi4.No … nditionReady.7z

RaVeN-05 wrote on 2024-12-27, 11:42:

OK will look if 0x3fffff is easy can be found.
Fixed link
https://nirvtek.com/downloads/1982CART.Mi4.No … nditionReady.7z

Thanks!

Well i rolled back to older rready version, ones which work and successfully run icr2, got horrible performance, since i have very old laptop.
the new ones gives me error on compiling shaders.
'21:12:43.757 1676 [0] GL Error Fragment shader compilation error 0(65) : error C7011: implicit cast from "uint" to "int'
full log in attachment.

i tried dosbox and staging also, staging have vmemsize setting which default is auto i tried it to set to 8 which gives 8mb vram.
can't confirm anything at this stage, got idea- maybe vram is limited on dosbox side?

other idea , dosbox have #define (which turn on debug dosbox build) with this exe can be stopped and debugged, limited but we should start here to have debugger with rready.

i never tried it but i found this https://www.romhacking.net/utilities/1129/ source available

will try, also if this debugger can be integrated with rready, would be cool, it will enable us to find more hacks in future , maybe.

also rr.exe have 3fffff two times as hex search. didn't tried to change it.
cart.exe have it more than two times, can be a chance , need to try.

also dosbox command vmem needed as read only commend which will show vram memory. staging have it and can be set.
with horrible performance i can't do it. its either crashes, or black screen, or hang, or when it works i have blinking graphics which works from 2fps to 16 max
oh

*************************************************
RReady Alpha, December 28, 2024 (Untested Alpha Release)
*************************************************
https://nirvtek.com/downloads/RReady.Alpha.20241228.001.7z
MD5: 4ac88593b03b798f10f2a4a08ef6d6d4

- Corrects OpenGL glsl shader "error C7011: implicit cast from "uint" to "int'" error
- 60 fps Frame Generation/interpolation supported for Gr*nd Pr*x L*egends and "Die by the Sword." Note GPL will have to be run at default resolution/4:3 (fill screen aspect) aspect as the game has a mouse lock. Higher resolutions can be selected from within the game, Your GPU's internal aspect ratio controls from its control panel should be used for aspect ratio selection. "Die by the Sword" can be upscaled without issue.
- Fixes Eur*figher 2000+ texture corrutpion when switching between menu and active mission. This was caused by the game writing to 8 MB of VRAM and choosing textures within the 4 MB range. Rounding write addresses modulo 4 MB, effectively restricting writes to the first 4 MB for this game, corrects the issue.
- Whiplash minor fixes.

This release probably won't go into testing for a few more weeks and has undergone rather severe and sudden shader changes as well as enhanced logging, so pretty much nothing is guaranteed to work. I really have to finish off the TREdit tool over the next two-three weeks before getting around to do a release. If you do spot any bugs, please let me know and I will fix them.

@Raven-05, can you see if this corrects your uint<-->int glsl error? It should fix it, though I'm not entirely sure that it hasn't broken anything.

https://www.romhacking.net/utilities/1129/: this looks promising. If you need any changes to support debugging I'll make them. I'll be occupied with TREdit and *possibly* pushing out a release for the next few weeks.

TREdit with Floyd-Steinberg dithered Mi4 (4-bit colour conversion):
https://youtu.be/bBfwM0Tchng

https://nirvtek.com/downloads/TREdit.20241228.001.7z
MD5: ae8c971be850f0f6bb94a7b6dbe2bdad

Cars2020 (with dithered Mi4):
https://nirvtek.com/downloads/cars2020.Dither … nditionReady.7z
MD5: 5e05861b72299226c675fffc07e5c615
1982Cart (with dithered Mi4):
https://nirvtek.com/downloads/1982CART.Mi4.Di … nditionReady.7z
MD5: fc7e0699b2c05ada7564f746283f801a

[EDIT2] Nope no issue with 198Cart, just with my a development build of TREdit which produced a garbage carset. The version I posted here should be ok, i.e. no issues at all. But it's always good to have a base state backup of the .CFG files with Cars95 selected[/EDIT2]
[EDIT] Backup all the CFG files in the game folder so they can restored. There is currently some sort of memory issue with 1982Cart.[/EDIT]

RaVeN-05 wrote on 2024-12-27, 19:39:

Well i rolled back to older rready version, ones which work and successfully run icr2, got horrible performance, since i have ve […]
Show full quote

Well i rolled back to older rready version, ones which work and successfully run icr2, got horrible performance, since i have very old laptop.
the new ones gives me error on compiling shaders.
'21:12:43.757 1676 [0] GL Error Fragment shader compilation error 0(65) : error C7011: implicit cast from "uint" to "int'
full log in attachment.

i tried dosbox and staging also, staging have vmemsize setting which default is auto i tried it to set to 8 which gives 8mb vram.
can't confirm anything at this stage, got idea- maybe vram is limited on dosbox side?

other idea , dosbox have #define (which turn on debug dosbox build) with this exe can be stopped and debugged, limited but we should start here to have debugger with rready.

i never tried it but i found this https://www.romhacking.net/utilities/1129/ source available

will try, also if this debugger can be integrated with rready, would be cool, it will enable us to find more hacks in future , maybe.

also rr.exe have 3fffff two times as hex search. didn't tried to change it.
cart.exe have it more than two times, can be a chance , need to try.

also dosbox command vmem needed as read only commend which will show vram memory. staging have it and can be set.
with horrible performance i can't do it. its either crashes, or black screen, or hang, or when it works i have blinking graphics which works from 2fps to 16 max
oh

There're 2 settings you can change for older machines (dosbox-rendition.conf):

[EDIT]
For older systems

1[rendition]
2Highperformance=false
3Threadsafe=true
4PicDMA=false

For faster quad core systems:

1[rendition]
2Highperformance=true
3Threadsafe=false
4PicDMA=true

I should really make this a checkbox in RLauncher,
[/EDIT]

(the defaults for these two are the opposite)

add/alter these two to dosbox-rendition.conf and the previous performance level should be accessible. Custom carsets and replays in icr2 will be slower, a lot slower.

I'm nearly done with tredit, so I should be able to test and deploy the latest alpha.

Let me know if the shader error is fixed.

yes error fixed, will try to experiment with.
For moment i have two questions
what if we can try use Creative 3DB PCI bios? i think its most compatible video card.
in dosbox-rendition.conf there is two times fullscreen setting can be founded, those two refers to one real fullscreen in dosbox, or this supposed to be various settings?
they might conflict each to other.

RaVeN-05 wrote on 2024-12-28, 11:59:

yes error fixed, will try to experiment with. For moment i have two questions what if we can try use Creative 3DB PCI bios? i th […]
Show full quote

yes error fixed, will try to experiment with.
For moment i have two questions
what if we can try use Creative 3DB PCI bios? i think its most compatible video card.
in dosbox-rendition.conf there is two times fullscreen setting can be founded, those two refers to one real fullscreen in dosbox, or this supposed to be various settings?
they might conflict each to other.

I've already tried the 3DB BIOS and it made no difference, unfortunately. I'll try again when I get back to it in the new year. Really need to finish of TREdit now, it's taken too long.

The dosbox two times fullscreen setting has no effect on RReady, you need to use RLauncher's windowed mode support. The dosbox setting only affects Dosbox's own window.

[EDIT] The setting in the [rendition] section does have an effect on rready, but it's better to use rlauncher's setting (windowed). [/EDIT]

RaVeN-05 wrote on 2024-12-28, 11:59:

yes error fixed, will try to experiment with. For moment i have two questions what if we can try use Creative 3DB PCI bios? i th […]
Show full quote

yes error fixed, will try to experiment with.
For moment i have two questions
what if we can try use Creative 3DB PCI bios? i think its most compatible video card.
in dosbox-rendition.conf there is two times fullscreen setting can be founded, those two refers to one real fullscreen in dosbox, or this supposed to be various settings?
they might conflict each to other.

The Rendition stuff works with the 3D Blaster BIOS and I already have considered making it the default BIOS. The problem is that I don't want to be sued by Creative for distributing their stuff, they're very very litigious.

[EDIT] Don't really need a full BIOS anymore anyway. I still load the BIOS, but only a small subset is needed. I think I posted what was needed earlier in this thread.[/EDIT]

[EDIT2] Nope no issue with 198Cart, just with my a development build of TREdit which produced a garbage carset. The version I posted here should be ok, i.e. no issues at all[/EDIT2]

Starting up with 1982Cart and running Downtown Detroit produces a lockup with other carsets not being selectable. Quitting and restarting the game results with the game exiting.

I would avoid 1982Cart (dither5ed) for now.

Backup all the CFG files in the game folder so they can be restored.

Riverside 81 ICR2 Track working, download link to track in video:
https://youtu.be/_GMqqvwaoCU

Custom carsets don't currently work with it and the maximum texture width is 64 and not 128.

I'm not quite ready to release the converter yet, it's a bit buggy. Now to see if I can get Indianpolis working.

Garbage quality (max width 8 pels) Denver 91 and Indianapolis tracks:
https://youtu.be/FegelUQHS4c

https://nirvtek.com/downloads/TREdit.20250101.001.7z
MD5: 924c346f0e48251caea27935c5c4a3d8

************************************************************************************************************
TREdit V1.0
Built on: Jan 1 2025, 16:46:50
Designed to convert incompatible carsets and tracks for the Rendition Edition of Indy Car Racing II
************************************************************************************************************
Usage TREdit <DATfile if unpacking|source folder> [-width <width>][-height <height>][-info]|[-report]
[-unpack | -convert | -explode <output path>]
-Unpack, -convert or -explode must be specified at the end of the line
-unpack <ExtractionPath>
To convert a carset:
-convert <Extraction Path>
To convert a track or Mi4 (paletted):
-track -convert <Extraction Path>
To extract the contents of MIP and MI4 files
for a track:
The -width and -height parameters have no effect on carsets
-explode <Output path>
for a carset
-palette <full path to sunny.pcx> -explode <Output path>
************************************************************************************************************
To convert tracks two passes will have to be carried without and with -track. When carrying out the second pass (with -track) -palette <path to sunny.pcx from carset> will have to be passed.

Some tracks currently will have to be shrunk down to 8x4 textures, in extreme cases . Riverside only required -width 64 with height omitted.
If width or height is omitted width will be 128 and height will be left alone ( left at some insanely large level).

TREdit <unpacked dat folder> -width <target width> [-height <target height>, this is optional] - convert <MIP output folder>
TREdit <MIP output folder> -palette <unpacked dat folder\sunny.pcx> -track -convert <Mi4 output folder>
Copy contents of <MIP output folder>, <Mi4 output folder> and files other than the .dat file into the track subfolder under <Indycar>\TRACKS
At the moment custom carsets will not work with high res carsets. This is being looked at at the moment. Shrinking track textures down to 8x4 (in extreme cases) isn't very pretty and work is being done to hack ICR2 to support 16 MB of VRAM, Speedy3D's limit.

To convert a carset:

TREdit <unpacked dat folder/source folder> - convert <MIP output folder>
TREdit <MIP output folder> -palette <some default track dat folder\sunny.pcx> -track -convert <Mi4 output folder>
Copy contents of <MIP output folder>, <Mi4 output folder> and files other than the .dat file into the carset subfolder under <Indycar>\CARS

Carsets generally will work after the first pass for the built in tracks. Custom carsets, such as the Detroit Downtown (Rendition specific version) will require the second pass for the carset as well.

To unpack a .DAT fild
TREdit <Path to dat> -unpack <dat folder>.

To extract the contents of MIP and Mi4 files:
TREdit <folder with unpacked/shrunk MIP or MI4 files> -palette <path to sunny.pcx (for track track specific, for carset use one from built in track> -explode <output folder>
Images will be extracted as PNGs.

Possible VRAM boost for Dosbox-Rendition/RReady. On the MiroV1k changing the byte at offset 0xA6D appears to control the amount 0f VRAM. For instance altering it to the maximum of 0xFF from 0x40(default) produces this in ICR2:
Before the change Dosbox shows this:

1...
2Digital Sound
3IRQ 7 DMA 1
4Conf irmed with SB16 8 ST
5Memory Check: 604576 LO 54603760 HI 55208336 ALL
6Texture heap size : 6928 K
7Texture cache size: 2166 K
8...

After the change Dosbox shows this:

1...
2Digital Sound
3IRQ 7 DMA 1
4Conf irmed with SB16 8 ST
5Memory Check: 604576 LO 54603760 HI 55208336 ALL
6Texture heap size : 6928 K
7Texture cache size: 14390 K
8...

d_mipscale 0 appears to be usable in vQuake at 60 fps (mostly). Video coming soon. ICR2 doesn't perform any better or support more carsets or tracks, just claims to have a much bigger texture cache.