Track location vs car position (reverse engineering)

[hatcher]

Hello, learned people! I'm new to hacking the Grand Prix series. I've spent the last few weeks familiarising myself with the inner workings of GP1 and 2 and writing test programs. Everything was going swell until I noticed a problem.

What is the exact formula for matching up the track position (starting from the location given in the track config section) and the car position from the memory? I thought I had it figured out but the car seems to be very slightly off (that's with the track width commands implemented) and I'm not sure if I draw the track a bit wrong or the positions are off.

Also, why do the X/Y coordinates stay 0 in the car struct when the car is driven by the computer? That's not the case in GP2, only in GP1. Where does GP1 store the car's position when it's driven by the AI?

Thanks!

[hatcher]

So I was reading the decompiled file that I stumbled upon on this forum and I found this. I don't do this. I was wondering though how the game matches the end of the track with the beginning of the track since they don't exactly match, not just for me but also in the editors. So it does some extra calculations with it that may affect the angles and positions of all track segments which could result in my rendering of the track being off a bit (?). Curious.

[F1GP Archive]

Hello and welcome,

I can point you towards a couple of programs that deal with the car positions on the track.
Hopefully, looking at their source code will give you some answers.

GPPerf has the ability to log the path of the cars over a lap.
https://sites.google.com/view/f1gpwc/file-archive/tsrs/gpperf
https://github.com/f1gp/f1gp-utils/tree/master/GpPerf

The logs can be read using the GP Race Analyser.
https://drive.google.com/file/d/11DQDUs5mFeiakXoaRkQS9P_YlZt1flra/view


GPLapTim has the ability to detect when the player's car goes off the circuit.
This is shown on the pit indicator during qualifying laps. The logs can be analyzed using GPLap or GPLapW.
https://sites.google.com/view/f1gpwc/file-archive/tsrs/gplap
https://github.com/f1gp/f1gp-utils/tree/master/GpLapTim


I hope some of the guys more familiar with track editing can reply to the rest of your questions.



Cheers

[hatcher]

Thanks but I'm quite sure now the cause is the recalculation process that I'm missing. If anyone knows anything about what the game does there, let me know, I'm all ears. I won't be able to figure it out from the assembly code.

[hatcher]

I've just realised the segments struct in the memory holds this converted data. I've always just assumed it's the same data that I load from the file but no, it's the data after all that recalculation and recalibration and whatever process so it should be good. :D

[Klaus Six]

Hi there, and welcome to F1GP research :)
Well, it looks like you already found what you need. Basically, the game does what you already showed in the screenshot: once track data has been read from the track file, the difference between start and end of the track (which does not fit together exactly) is calculated and the position of all track segments is adjusted a little bit to make it fit.
You can see the process in the ChequeredFlag editor where all calculations are in Java, not assembler. It's quite some time since I wrote it, so I don't remember the details. Anyway, the result is exactly the same as in the game.
If you wonder about calculations for the CC line, these are even more complicated and still not fully understood. Again, ChequeredFlag has a calculation that works, which is a transcription of the assembler code. Many variables are still named like in the disassembler sources as we just don't know their meaning.
Hope that helps, and good luck.

[hatcher]

Thanks for the reply! I'll check your code out. I wonder if this makes the tracks more accurate or less accurate. Was this taken into consideration when they made the tracks in the original editor?