Forums

(07-09-2025, 03:43 AM)samsepi0l Wrote: [ -> ]

(07-08-2025, 07:57 PM)sharangad Wrote: [ -> ]I'm fixing my roof today and tomorrow and possibly later . If you guys haven't found it by then, I'll take a look.

Funny you mention this- I am fixing my roof tomorrow!

Heh! Maybe we need a thread for that!

I should have some free time tomorrow. Let's see if this can be tracked down.

(07-08-2025, 07:54 AM)jxeboy Wrote: [ -> ]In the Rendition EXE the bytes are as follows:

Draw Ahead -> A1124 and A112D
Draw Behind -> A1174 and A117D

I am working on an update to my parameters list and I found these in different addresses for Rendition.

Draw Ahead: C2F58, C2F61
Draw Behind: C2FA8, C2FB1

Can you please check these bytes? Wanted to make sure you don't have a different Rendition exe than me.

(07-22-2025, 12:34 AM)checkpoint10 Wrote: [ -> ]

(07-08-2025, 07:54 AM)jxeboy Wrote: [ -> ]In the Rendition EXE the bytes are as follows:

Draw Ahead -> A1124 and A112D
Draw Behind -> A1174 and A117D

I am working on an update to my parameters list and I found these in different addresses for Rendition.

Draw Ahead: C2F58, C2F61
Draw Behind: C2FA8, C2FB1

Can you please check these bytes? Wanted to make sure you don't have a different Rendition exe than me.

There is the DOS32A bound version. The values I quoted for the max opponents (I *think*) was for the DOS4GW version.

(07-22-2025, 12:34 AM)checkpoint10 Wrote: [ -> ]

(07-08-2025, 07:54 AM)jxeboy Wrote: [ -> ]In the Rendition EXE the bytes are as follows:

Draw Ahead -> A1124 and A112D
Draw Behind -> A1174 and A117D

I am working on an update to my parameters list and I found these in different addresses for Rendition.

Draw Ahead: C2F58, C2F61
Draw Behind: C2FA8, C2FB1

Can you please check these bytes? Wanted to make sure you don't have a different Rendition exe than me.

Maybe this is the issue, I am using the Dos32 extender edition that Sharangad shared here:
https://nirvtek.com/downloads/ICR2.DOS32...0Buffer.7z

I didnt think it would have different offsets but maybe they are

This is the version I have been using by the way and the performance is good, I havent had any crashes either

(07-22-2025, 02:42 AM)jxeboy Wrote: [ -> ]Maybe this is the issue, I am using the Dos32 extender edition that Sharangad shared here:
https://nirvtek.com/downloads/ICR2.DOS32...0Buffer.7z

I didnt think it would have different offsets but maybe they are

This is the version I have been using by the way and the performance is good, I havent had any crashes either

Got it. I was using a different version Sharangad posted as "Indycar2.HeapUnlocked.v1k.v2k". I missed the "ICR2.DOS32A.Test.256 MB Texture Buffer" when it was first posted, and it looks like it has a different file size too, which will cause my tool to refuse to open it. I can look into adding support for "ICR2.DOS32A.Test.256 MB Texture Buffer" if that is a good version.

EDIT:

@sharangad Will you please point me to the differences between those versions, and which one is preferred at this point?

(07-22-2025, 03:18 AM)checkpoint10 Wrote: [ -> ]

(07-22-2025, 02:42 AM)jxeboy Wrote: [ -> ]Maybe this is the issue, I am using the Dos32 extender edition that Sharangad shared here:
https://nirvtek.com/downloads/ICR2.DOS32...0Buffer.7z

I didnt think it would have different offsets but maybe they are

This is the version I have been using by the way and the performance is good, I havent had any crashes either

Got it. I was using a different version Sharangad posted as "Indycar2.HeapUnlocked.v1k.v2k". I missed the "ICR2.DOS32A.Test.256 MB Texture Buffer" when it was first posted, and it looks like it has a different file size too, which will cause my tool to refuse to open it. I can look into adding support for "ICR2.DOS32A.Test.256 MB Texture Buffer" if that is a good version.

EDIT:

@sharangad Will you please point me to the differences between those versions, and which one is preferred at this point?

There's also a DOS32A bound version of software rendered Cart.exe/indycar.exe. I think I posted a link to it somewhere.

The main difference is that the DOS4GW bound version can only allocate at most 64 MB of RAM. The Dos32A version can use up to 4 GB of RAM (the upper limit for a regular 32 bit app). The heap unlocked versions of DOS4GW cart support up to 48 MB of texture heap,
DOS4GW:
- App can use a maximum of 64 MB of system RAM. DOS4GW is blind to anything beyond this.
- Heap unlocked version can use at most 48 MB of this for texture heap.

DOS32A:
- App can use a maximum of 4 GB of RAM. This is the limit for most 32 bit apps since a 32 bit flat pointer can only store 4.2 billion distinct values. Even though various extensions exist for 32 bit apps to use more than this, for DOS apps this is the limit.
- The Heap unlocked version you linked to allocates up to 128 (or maybe 256) MB of RAM for the texture heap. It can in fact be set to be much higher (up to 2 GB in my testing). Unfortunately the game still can't use all of it due to a limitation elsewhere. Fixing this is one of the things I've looed at it with IDA, an older version. I'm migrating to Ghidra so maybe I'll have better luck with that. The actual heap limit is dumped in the console output when the game runs.
- DOS32A fixed a bunch of bugs in DOS4GW and is a lot newer than DOS4GW.

Note once the heap limit is extended the game will require extra RAM, even on a physical DOS machine to run. a 256 MB version will require more than 256 MB of RAM to run.

(07-22-2025, 02:42 AM)jxeboy Wrote: [ -> ]

(07-22-2025, 12:34 AM)checkpoint10 Wrote: [ -> ]

(07-08-2025, 07:54 AM)jxeboy Wrote: [ -> ]In the Rendition EXE the bytes are as follows:

Draw Ahead -> A1124 and A112D
Draw Behind -> A1174 and A117D

I am working on an update to my parameters list and I found these in different addresses for Rendition.

Draw Ahead: C2F58, C2F61
Draw Behind: C2FA8, C2FB1

Can you please check these bytes? Wanted to make sure you don't have a different Rendition exe than me.

Maybe this is the issue, I am using the Dos32 extender edition that Sharangad shared here:
https://nirvtek.com/downloads/ICR2.DOS32...0Buffer.7z

I didnt think it would have different offsets but maybe they are

This is the version I have been using by the way and the performance is good, I havent had any crashes either

The offset difference between versions is constant for every single offset. The block at the beginning is different so it's a matter of adding the difference in size between DOS4GW and DOS32A extenders.

(07-22-2025, 03:18 AM)checkpoint10 Wrote: [ -> ]

(07-22-2025, 02:42 AM)jxeboy Wrote: [ -> ]Maybe this is the issue, I am using the Dos32 extender edition that Sharangad shared here:
https://nirvtek.com/downloads/ICR2.DOS32...0Buffer.7z

I didnt think it would have different offsets but maybe they are

This is the version I have been using by the way and the performance is good, I havent had any crashes either

Got it. I was using a different version Sharangad posted as "Indycar2.HeapUnlocked.v1k.v2k". I missed the "ICR2.DOS32A.Test.256 MB Texture Buffer" when it was first posted, and it looks like it has a different file size too, which will cause my tool to refuse to open it. I can look into adding support for "ICR2.DOS32A.Test.256 MB Texture Buffer" if that is a good version.

EDIT:

@sharangad Will you please point me to the differences between those versions, and which one is preferred at this point?

DOS32A is preferred because if we can make the game use more than 64 MB of actual RAM the texture heap limit can be increased to 2 GB. Thirty-two bit Dosbox-Rendition can't practically use more than 2.2 GB offers RAM out of the 4 GB limit for 32 bit apps. At the moment they're both supported and I will continue to patch them as necessary. If we do unlock the extra texture ram, DOS32A will  be mandatory.

The offset difference between the versions is is 0x21E34 in my now disabled automatic modification code, which tallies with your figures.