As promised, the technical notes (with an answer to Chulk's question included).
1. GETTING HOLD OF THE COORDINATES
The zip file attached to this post contains instructions on how to extract the coordinates for those who wish to try it at home, as well as samples of what the program for processing the raw scanmem dump and the required special-purpose dosbox.conf might look like. The procedure is somewhat arcane, Linux-centric (for one, you'd have to find something to replace scanmem in Windows) and has a number of obvious shortcomings - e.g., it requires us to play the lap in-game in real time; it makes it hard to get the corresponding height values; it misses frames if the car stops completely during the replay, and so forth. I will welcome any suggestions of improvements and/or better tools.
2. DRAWING MAPS AND PATHS
A few words should be added on the other half of the demo; that is, the rendering of the animation. The idea of tracing lap paths only came as an afterthought in the context of my attempt to write a track viewer using the Diagrams EDSL
. That viewer isn't meant for convenient embedding in Stunts sites like those by dreadnaut and Oscar; rather, I envisage a tool for preparing annotated track maps with minimal fuss. Anyway, Diagrams has, among other things, basic support for animations; i.e., given the proper instructions it can produce PNG frames, which in turn can be made into a video through something like ffmpeg. The rest follows naturally.
The comments above segue nicely into...
I guess increasing car size and putting some kind of trail shouldn't be that hard now, right?
Indeed, that is entirely trivial by now. In fact, I actually reduced the car size for the video on purpose, to give a better sense of scale and speed. Here you have a single-frame render
implementing both of your suggestions (the cars are separated by 100 frames = 5s). Note that the link points to a SVG file. The map is fully vectorial, which makes it much easier to customize - arbitrary resizing of the output, scaling adjustments to the track pieces, palette changes, and so forth.
The tools described above likely won't be convenient to use for a while. The vectorial track viewer is still very crude, and needs a lot of things to become a convenient application (as of now it doesn't even have a command line interface, let alone graphical). I will probably upload the code somewhere once it is a little more fleshed out. As for the replay logging procedure, it requires fooling around with debugging tools, and I guess there will be no way around that until there is an independent reimplementation of the game engine. In any case, if any of you finds an use to replay traces and annotated maps in the vein of these demos I will be glad to prepare them on demand