Track editing progress notes

[checkpoint10]

I tried my app with the Rendition version, and even though it found the texture in the Dosbox process where the game is in memory, when it overwrote the memory with a new texture, it doesn't update it in the game. So, in other words, with the DOS version, the game is constantly reading the texture from that part of memory as it redraws each frame, but with Rendition, it reads that part once and maybe converts or stores it somewhere else.

It's stored as a texture in VRAM. The game itself transfers the texture to the GPU and probably doesn't mess with it anymore. The transfer is explicit, the game actually has to tell the GPU to DMA it across. The transfer doesn't include source addresses, just a the destination address (in VRAM), maybe the stride and height OR the number of bytes followed by the actual block of data (stride * height Or num bytes bytes of data).

This would need explicit wrapper support to work.

[EDIT] I can give you an API to access virtual VRAM in Dosclient and possibly signal changes and the wrapper could detect it and reload the texture. I could expose GPU RAM as a block of shared memory with a specific name, but simply changing it alone won't work because the wrapper avoids reloading textures to the physical GPU though I could force reloading for icr2. Also the texture format in virtual VRAM might not be the same as on disk.

Appreciate your offer to include an API - it might be getting a little complicated though for the amount of benefit it provides. I am thinking of a workaround where I can make a bunch of objects, each one representing a frame of the animation, and then cycling through them using the same technique as moving objects (which does work in Rendition). That would be good enough if we just need to do 1-2 seconds and I can't imagine why we would need an animation for much longer than that (besides for the fun of it).

[sharangad]

I tried my app with the Rendition version, and even though it found the texture in the Dosbox process where the game is in memory, when it overwrote the memory with a new texture, it doesn't update it in the game. So, in other words, with the DOS version, the game is constantly reading the texture from that part of memory as it redraws each frame, but with Rendition, it reads that part once and maybe converts or stores it somewhere else.

It's stored as a texture in VRAM. The game itself transfers the texture to the GPU and probably doesn't mess with it anymore. The transfer is explicit, the game actually has to tell the GPU to DMA it across. The transfer doesn't include source addresses, just a the destination address (in VRAM), maybe the stride and height OR the number of bytes followed by the actual block of data (stride * height Or num bytes bytes of data).

This would need explicit wrapper support to work.

[EDIT] I can give you an API to access virtual VRAM in Dosclient and possibly signal changes and the wrapper could detect it and reload the texture. I could expose GPU RAM as a block of shared memory with a specific name, but simply changing it alone won't work because the wrapper avoids reloading textures to the physical GPU though I could force reloading for icr2. Also the texture format in virtual VRAM might not be the same as on disk.

Appreciate your offer to include an API - it might be getting a little complicated though for the amount of benefit it provides. I am thinking of a workaround where I can make a bunch of objects, each one representing a frame of the animation, and then cycling through them using the same technique as moving objects (which does work in Rendition). That would be good enough if we just need to do 1-2 seconds and I can't imagine why we would need an animation for much longer than that (besides for the fun of it).

Just try messing with Dosclient.exe's memory. I *think*modifying the texture there might work. I've set the wrapper to reload the texture from RAM there. There should be a 128 MB texture buffer there of which only the first 16 MB is used for DOS apps (because only 24 bits are  used for the destination address by Rendition hardware with the other 8 bits used for flags). The textures will be the there, the geometry won't be.

[Tjerk]

In BB&B's TRK file description I read the following at the start:

Papyrus has conspired against hackers making the tracks with a little
"wrong orientation". This "trick" makes all values differ from segment
to segment in a little (non constant) value that affects angles and
coordinates.

Does anyone know anything more about this, if this is even true or just a misunderstanding of the file format, or where I could look to get that information?

[checkpoint10]

Does anyone know anything more about this, if this is even true or just a misunderstanding of the file format, or where I could look to get that information?

I don't think this is true, because it is possible to reconstruct the track layout without any sort of decryption. I also have this Python tool that converts SG to TRK: https://github.com/skchow03/icr2_sg2trk Although I haven't actually used it very much since I still use the Papy tools in my workflow, as I recall, the results of the Python tool should be identical or close enough to be usable in the game.

I remember it was challenging to figure out some of the values, especially track section lengths in the TRK can vary from SG lengths due to elevation changes that add a tiny bit of length in the TRK, but I believe we figured that out and it should be incorporated in my tool.

[Tjerk]

Thank you. I pretty much could not imagine this being true and (considering the many unknowns about the file formats at the time) deemed it more likely to just be a false presumption on their end.

[samsepi0l]

This reminds me of track editing in gp2. Even to this day, so many of the hex commands are unknown and not understood.