Either I'm onto something or this is some fantasy that ChatGPT has dreamed up from more work in Ghidra. But apparently I found three data tables that could be engine performance tables, and ChatGPT has offered the following interpretation which is also based on poking around some functions that are known to relate to boost. The field labels and notes are speculative, but the values are real.
Code:
Engine Parameter Blocks:
Ford = 0x004f3b20
Mercedes = 0x004f3b40
Honda = 0x004f3b60
+--------+-------------------------------+--------+---------+--------+----------------------------+
| Offset | Field Purpose | Ford | Mercedes| Honda | Notes |
+--------+-------------------------------+--------+---------+--------+----------------------------+
| 0x00 | fuel_consumption_rate | 6282 | 6282 | 6282 | All identical |
| 0x04 | base_boost_pressure | 6500 | 6500 | 6750 | Honda slightly higher |
| 0x08 | boost_ramp_curve_scalar | 3900 | 3900 | 4100 | Honda more aggressive |
| 0x0C | torque_or_throttle_factor | 1290 | 1236 | 1180 | Honda most efficient |
| 0x10 | boost_threshold_pressure | 8675 | 8308 | 7637 | Ford highest, Honda lowest |
| 0x14 | boost_energy_pool | 0 |2000000 |1000000 | Mercedes longest reserve |
| 0x18 | duplicate_boost_base_pressure | 6500 | 6500 | 6750 | Matches offset 0x04 |
| 0x1C | fuel_consumption_rate_scaler | 18 | 18 | 18 | 0x120000 >> 16 |
+--------+-------------------------------+--------+---------+--------+----------------------------+
If we would know all the values and could manipulate them, it would be possible to get more accurate car performances for older cars.
But I think, to match AI performance to it, it would be necessary to make new LP files with the modified settings.
I would love to be able to change the sound scaling so we could make certain cars with certain engines sound lower tone as they went by you. This way we could make stockblock V8 sounds like they really had in the early 80s and sounds of the buick v6 which rev'ed higher than the stockblock v8 but not as high as the indy race engines.
(05-02-2025, 05:00 PM)checkpoint10 Wrote: [ -> ]Either I'm onto something or this is some fantasy that ChatGPT has dreamed up from more work in Ghidra. But apparently I found three data tables that could be engine performance tables, and ChatGPT has offered the following interpretation which is also based on poking around some functions that are known to relate to boost. The field labels and notes are speculative, but the values are real.
When you have time and if you don't mind can you see if you can spot the memory allocation limit for carsets and tracks? As far as I can tell it allocates a few hug blocks of RAM and there are smaller allocation routines which can allocate up to 65536 * 16 KB (this can't be increased because the call uses 16-bit registers. There maybe an analogous call which uses 32 bit registers and a much bigger pointer size.
Some offsets (from the start of the file) of note in the DOS4/GW binary (patched and unpatched):
For the DOS32/A build, subtract 0x21E34 from the DOS4/GW binary offset.
0xF06F7 Texture heap size (original value 0x001B1000, patched: 0x00C04000)
0xF027B Possible maximum VRAM size allowed maybe (Original value 0x000039F0. The actual maximum is constrained by Speedy3D API/hardware limitations under DOS to 16 MB).
0xF076B Speedy3D command buffer size limit (original value0x00060000. Doesn't seem to actually do anything. Using much smaller values can cause instability, more than what the game has at the moment ).
[EDIT] The DOS32/A build can use large values for these (larger than 0x00FFFF00), the DOS/4GW generally caps the maximum allowed for a lot of these to 0x00FFFF00 (for some like the texture heap size, much lower). The command buffer size is divided by 4 (*so I think based on how RRedline works*).
[/EDIT]
(05-02-2025, 06:54 PM)Dennis Wrote: [ -> ]If we would know all the values and could manipulate them, it would be possible to get more accurate car performances for older cars.
But I think, to match AI performance to it, it would be necessary to make new LP files with the modified settings.
This would a wonderful problem to have, if we can really change the physics. I did a little more testing and when I edit the first table, there is some impact to physics but I need to do more to figure out what exactly each value does. The second and third tables don't seem to change anything, so perhaps those are not the other 2 engines and represent something else.
(05-03-2025, 02:00 AM)samsepi0l Wrote: [ -> ]I would love to be able to change the sound scaling so we could make certain cars with certain engines sound lower tone as they went by you. This way we could make stockblock V8 sounds like they really had in the early 80s and sounds of the buick v6 which rev'ed higher than the stockblock v8 but not as high as the indy race engines.
Indy 500: the Simulation had different sounds for the Buick V6 right? I can't remember if ICR1 did too. So maybe some of that code is still in there to have different revs depending on the engine?
(05-03-2025, 03:14 AM)sharangad Wrote: [ -> ] (05-02-2025, 05:00 PM)checkpoint10 Wrote: [ -> ]Either I'm onto something or this is some fantasy that ChatGPT has dreamed up from more work in Ghidra. But apparently I found three data tables that could be engine performance tables, and ChatGPT has offered the following interpretation which is also based on poking around some functions that are known to relate to boost. The field labels and notes are speculative, but the values are real.
When you have time and if you don't mind can you see if you can spot the memory allocation limit for carsets and tracks? As far as I can tell it allocates a few hug blocks of RAM and there are smaller allocation routines which can allocate up to 65536 * 16 KB (this can't be increased because the call uses 16-bit registers. There maybe an analogous call which uses 32 bit registers and a much bigger pointer size.
Some offsets (from the start of the file) of note in the DOS4/GW binary (patched and unpatched):
For the DOS32/A build, subtract 0x21E34 from the DOS4/GW binary offset.
0xF06F7 Texture heap size (original value 0x001B1000, patched: 0x00C04000)
0xF027B Possible maximum VRAM size allowed maybe (Original value 0x000039F0. The actual maximum is constrained by Speedy3D API/hardware limitations under DOS to 16 MB).
0xF076B Speedy3D command buffer size limit (original value0x00060000. Doesn't seem to actually do anything. Using much smaller values can cause instability, more than what the game has at the moment ).
[EDIT] The DOS32/A build can use large values for these (larger than 0x00FFFF00), the DOS/4GW generally caps the maximum allowed for a lot of these to 0x00FFFF00 (for some like the texture heap size, much lower). The command buffer size is divided by 4 (*so I think based on how RRedline works*).
[/EDIT]
I will keep this in mind but I need to improve my skills before tackling this.
A couple discoveries:
0x04 - rpm for auto-shifting (default value: 6500)
0x18 - rpm where engine blows (default value: 6500)
I found the bytes for engine power! It's the 4th value in the engine lookup table. Default is 1290, and if I change it to 5000, this is what I get:
The same lookup table is in all 3 versions of ICR2 - DOS, Windy and Rendition. I will try to learn more about the other values and hoping to create a tool for easier editing.
(05-03-2025, 02:40 PM)checkpoint10 Wrote: [ -> ]I found the bytes for engine power! It's the 4th value in the engine lookup table. Default is 1290, and if I change it to 5000, this is what I get:
The same lookup table is in all 3 versions of ICR2 - DOS, Windy and Rendition. I will try to learn more about the other values and hoping to create a tool for easier editing.
If the addresses in Dosbox RAM where these values live can be worked out, I could add support to RLauncher to auto modify these value or keep them constant.
I would love to know what DLONG value the game uses to put cars at a distance behind each other when they are under yellow. It must be some constant in the EXE. Spacing them out better would make restarts much safer.
(05-03-2025, 11:02 AM)checkpoint10 Wrote: [ -> ]A couple discoveries:
0x04 - rpm for auto-shifting (default value: 6500)
0x18 - rpm where engine blows (default value: 6500)
Nice findings.
It seems the number is then half of the RPM value, Ford and Mercedes is known to shift at 13000 RPM, while Honda at 13500. As for the second number, the engine does not actually blows at that RPM, might it be the value when the RPM light in the cockpit lights up?