Is there a possibility to make an automatic statistic program? Only with reading the replay?
What kind of statistics?
Section times.
Quote from: Friker on February 03, 2013, 10:51:48 PM
Quote from: alanrotoi on February 03, 2013, 08:54:52 PM
Section times.
Nope.
Because the .RPL file saves laps as keystrokes, so you need the game engine to know where the car is at each instant. (That's the same reason why the various RPLInfo implementations can't detect penalty time.)
How much code from restunts is reusable? Could the replay engine (i.e., the fast forward button) be used to run replays?
Quote from: dreadnaut on February 04, 2013, 02:26:31 AM
How much code from restunts is reusable? Could the replay engine (i.e., the fast forward button) be used to run replays?
I don't know. I was thinking about simulating a replay and now - blink - that's it - guys from stuntschallenge.net could run the game with a given replay, couldn't they? And also they could determine a time with penalty! Oh.. definitely we should ask them how is it possible (to run the game with a given replay). At least, it should be possible to run an environment which can capture key strokes and they make a list of key strokes to input (press enter at 10 secs, right key twice at 15 secs, x times down, then type a filename of replay, ...).
Quote from: Friker on February 04, 2013, 10:13:48 AM
Quote from: dreadnaut on February 04, 2013, 02:26:31 AM
How much code from restunts is reusable? Could the replay engine (i.e., the fast forward button) be used to run replays?
I don't know. I was thinking about simulating a replay and now - blink - that's it - guys from stuntschallenge.net could run the game with a given replay, couldn't they? And also they could determine a time with penalty! Oh.. definitely we should ask them how is it possible (to run the game with a given replay). At least, it should be possible to run an environment which can capture key strokes and they make a list of key strokes to input (press enter at 10 secs, right key twice at 15 secs, x times down, then type a filename of replay, ...).
The stuntschallenge guys are in our midst... I don't really like the way of this whole hacking development. It will be a great weapon for "high-tech" cheaters (although I think some of us already have the tools for creating superb replays without touching stunts_k.exe).
The only way to avoid any kind of cheating is a special rule set, like in ZSC 2007, for example: you should hit all the signs, stay in the right lane or whatever - anything that can't be generated by softwares (or at least it's too much effort to write a new code for that).
Quote from: dreadnaut on February 04, 2013, 02:26:31 AM
How much code from restunts is reusable? Could the replay engine (i.e., the fast forward button) be used to run replays?
Restunts is just a 1:~1 translation from ASM to C. The replay functions haven't been documented yet, but I don't think there should be any problems* creating a separate executable that loads a replay, iterates through the buffer and dumps the final game state without the need to invoke any display code. Locating the needed functions and their signatures should be enough, as we are mixing ported and untouched code in the build process.
*) No problems besides lack of time.
Quote from: Friker on February 04, 2013, 10:13:48 AM
I was thinking about simulating a replay and now - blink - that's it - guys from stuntschallenge.net could run the game with a given replay, couldn't they? And also they could determine a time with penalty!
IIRC Wind (one of the stuntschallenge.net developers) said they ran the replays in-game used a modified DOSBox. That doesn't sound convenient for simulations...
While I'm not terribly excited about any dreams of automated replay generation (see CTG's post), I would be very happy with after-the-fact analysis tools. The crucial one, I guess, would be a logger which recorded the car position at every instant over a lap. (Dstien and co.: how hard would be doing that today given what we already know? I believe we already have located where the coordinates are stored in the ASM, but I am too clueless about debuggers and other low-level stuff to know how far along the way that takes us.)
@CTG: You're smart enough to sketch a dimensional analysis for the problem of automatically generating a decent replay yourself. Not sure why you keep bringing this up :| And sections times would indeed be an interesting stat to extract from replays, we could make all sorts of crazy graphs! :)
Quote from: dstien on February 04, 2013, 12:28:07 PM
The replay functions haven't been documented yet, but I don't think there should be any problems* creating a separate executable that loads a replay, iterates through the buffer and dumps the final game state without the need to invoke any display code. [...] *) No problems besides lack of time.
This, included the footnote, is what I was thinking. Run the game "engine" and print a list of tiles and times when a tile is reached —that's what you need for most statistics, including section times.
Quote from: Duplode on February 04, 2013, 04:09:12 PM
While I'm not terribly excited about any dreams of automated replay generation (see CTG's post), I would be very happy with after-the-fact analysis tools. The crucial one, I guess, would be a logger which recorded the car position at every instant over a lap. (Dstien and co.: how hard would be doing that today given what we already know? I believe we already have located where the coordinates are stored in the ASM, but I am too clueless about debuggers and other low-level stuff to know how far along the way that takes us.)
Two other things related to this come to my mind: dosbox has an integrated debugger —can it watch memory locations? and also, if we know where tile coords are kept in memory, we could just write a small tsr to dump them to a text file.
@CTG stallin shut up!
Zak once did some code where the result was how meny times accel and breaks butons were pressed, remember?
well, i have to admit that - for me - write a replay generator is far more easier than getting some idea about low level code/ debugging. still i cannot spend a time with that (and its level is comparable to high-level master degree theses at our faculty).
btw a car position is probably irrevelant for section times because you can leave (at least) one tile out w/o penalty. which is leading to a question - does anyone know how is penalty counting?
Quote from: Friker on February 05, 2013, 01:17:54 AM
well, i have to admit that - for me - write a replay generator is far more easier [...]
You may think that, but on top of the dimensionality issue you have others: it's hard to evaluate solutions (need to run the replay¹), it's hard to evaluate partial solutions (need to reach the finish line, or set mid-lap goals which might be tiles you would actually skip), etc. A probabilistic/big-data solution might have more success, feeding on thousands of replays of winning drivers, but it's still much more than an MSc thesis.
[1] and this actually solves the whole "let's get section times!" idea!
Quotebtw a car position is probably irrevelant for section times because you can leave (at least) one tile out w/o penalty.
Section times would be measured on tiles you are sure to drive through, I suppose. It's still arbitrary stats anyway, so it's not really a problem.
Quote from: Duplode on February 04, 2013, 04:09:12 PM
Dstien and co.: how hard would be doing that today given what we already know? I believe we already have located where the coordinates are stored in the ASM, but I am too clueless about debuggers and other low-level stuff to know how far along the way that takes us.
Should just be a matter of getting the coordinates from the player matrix for each tick. Would be neat to overlay the resulting paths on a track map in order to compare racing lines.
Quote from: dreadnaut on February 04, 2013, 04:28:43 PM
Two other things related to this come to my mind: dosbox has an integrated debugger —can it watch memory locations? and also, if we know where tile coords are kept in memory, we could just write a small tsr to dump them to a text file.
The DOSBox debugger allows you to browse the memory and set breakpoints on changes. It's very helpful to locate and inspect code. Replays loaded from Main screen -> Options are fully processed to the end before the world is rendered, so going from there with a breakpoint on file reads (DOS interrupt) would probably be sensible.
Regarding the conspiracy theory/pipe dream about a perfect replay generator; you must have been watching too many computer science Hollywood movies, CTG. The individuals who are capable of doing that aren't tapping their feet, waiting for us hand them reversed code they could write themselves in their sleep. They're busy raking in Nobel prizes and building self-aware quantum computers.
Quote from: dstien on February 06, 2013, 01:14:22 AM
Quote from: Duplode on February 04, 2013, 04:09:12 PM
Dstien and co.: how hard would be doing that today given what we already know? I believe we already have located where the coordinates are stored in the ASM, but I am too clueless about debuggers and other low-level stuff to know how far along the way that takes us.
Should just be a matter of getting the coordinates from the player matrix for each tick.
For the moment, I found a way to do that using scanmem (http://code.google.com/p/scanmem/) (a memory inspector running in the host system), with our annotated ASM from 2010 as guidance. As you can imagine, the mechanics of the procedure I devised suck, so any low-hanging alternative would still please me :)
Quote from: dstien on February 06, 2013, 01:14:22 AM
Would be neat to overlay the resulting paths on a track map in order to compare racing lines.
Leak from the Southern Cross labs: I'm working on it as we speak ;)
Quote from: dstien on February 06, 2013, 01:14:22 AM
Replays loaded from Main screen -> Options are fully processed to the end before the world is rendered, so going from there with a breakpoint on file reads (DOS interrupt) would probably be sensible.
Well spotted, I had kinda forgotten that.
Quote from: dstien on February 06, 2013, 01:14:22 AM
Would be neat to overlay the resulting paths on a track map in order to compare racing lines.
That would be so cool!
Quote from: Chulk on February 06, 2013, 03:53:36 AM
Quote from: dstien on February 06, 2013, 01:14:22 AM
Would be neat to overlay the resulting paths on a track map in order to compare racing lines.
That would be so cool!
And now we also need a 3d map viewer to overlay these racing lines on the track :)
(mmmh, just when I was thinking "oh, I should learn WebGL"...)
Quote from: Chulk on February 06, 2013, 03:53:36 AM
Quote from: dstien on February 06, 2013, 01:14:22 AM
Would be neat to overlay the resulting paths on a track map in order to compare racing lines.
That would be so cool!
Teaser. Can any of you guess the replay just by looking at the data?
(http://i49.photobucket.com/albums/f283/Duplode/234bd623-b456-4da1-b55b-dcd25fa8c37c.jpg)
I can't but am fascinated by the graphs :)
my guess is it is an Indy powergear replay - the blue line on the bottom graph seems like speed.
Quote from: zaqrack on February 07, 2013, 05:46:38 AM
I can't but am fascinated by the graphs :)
my guess is it is an Indy powergear replay - the blue line on the bottom graph seems like speed.
It says "column D" so it's probably "Speed". I also thought about a PG track... and that's as far as I can guess.
1:1x.xx long PG track, hmmmm... give some hints about the graph, please!
(the first one is a raw map of the track, am i right?)
The curve on the top of the top graph looks like a classic power gear slide turn.
wow, that is fascinating :) is there a description of main algorithms and data structures of stunts? (i know about some work on track elements but car and car collision - also the reason of PG (overflowing/round presicion of floats - but some line of pseudocode would be nice :) ))
btw - that is strange - y is axe of height?
Quote from: CTG on February 07, 2013, 08:57:20 AM
1:1x.xx long
Where did you get that from?
IF first graph is a raw map of the line driven (not the track as we often don't use it that much), it resembles the line of a default 2x secs lap. Straight, 2 left turns to complete about 180º then straight again, turn 180º again and finish
Quote from: Chulk on February 07, 2013, 04:22:50 PM
Quote from: CTG on February 07, 2013, 08:57:20 AM
1:1x.xx long
Where did you get that from?
Speculation from the X axis of the second graph: the last point is at ~1450-1500 units. But only if it's a time scale... :D
Nice guesses so far; CTG in particular is hot on the trail (his interpretation of both plots is correct). But there are some more clues ;)
Quote from: Friker on February 07, 2013, 04:00:45 PM
is there a description of main algorithms and data structures of stunts? (i know about some work on track elements but car and car collision - also the reason of PG (overflowing/round presicion of floats - but some line of pseudocode would be nice :) ))
There is no neat documentation that I know of, though the assets of the restunts project include a substantial amount of unsystematically annotated assembly. (Writing notes on some of that stuff, specially on track building, is in my TODO list for almost three years now...)
Quote from: Friker on February 07, 2013, 04:00:45 PM
btw - that is strange - y is axe of height?
Yup, y is height (cf. 3D coordinates in CarBlaster and stressed). Naturally, There are y values along the x and z ones; I didn't log them thus far due to minor technical annoyances.
Yes, I guess it's an excel chart! :-[
Quote from: alanrotoi on February 07, 2013, 08:20:37 PM
Yes, I guess it's an excel chart! :-[
Explanation is there on facebook for you ;)
Corvette or GTO (30 mph after ~2.1 seconds, Indy's acceleration is a lot better)
It's your Z138 winning vette replay
Quote from: Chulk on February 07, 2013, 09:50:16 PM
It's your Z138 winning vette replay
Yeah, it would fit in length and car. But the track is not enough p.s. ;D
(and I reached powergear a bit later)
Shipwreck? (tricky turns by Gutix, that's a legendary replay - was it really 6 years ago?!?)
Quote from: CTG on February 07, 2013, 10:33:26 PM
Shipwreck? (tricky turns by Gutix, that's a legendary replay - was it really 6 years ago?!?)
Yes, it is. :D
Quote from: Duplode on February 07, 2013, 05:00:17 AM
Teaser.
Nice-o-rama! But please don't tell me you extracted that data set manually...?
Quote from: Duplode on February 07, 2013, 08:13:52 PM
But there are some more clues ;)
What kind of clues? Except the big one: how could you... ;D
Quote from: CTG on February 07, 2013, 10:33:26 PM
Shipwreck? (tricky turns by Gutix, that's a legendary replay - was it really 6 years ago?!?)
Now you can check it :) Be sure to watch in fullscreen, you won't see much otherwise.
http://www.youtube.com/watch?v=Dwnej8PUsjg&hd=1
Quote from: dstien on February 08, 2013, 02:12:16 AM
Nice-o-rama! But please don't tell me you extracted that data set manually...?
Well, I said the logging process sucks, but it doesn't suck
that much :D Later I will post technical notes to satisfy your curiosity and CTG's.
Quote from: Duplode on February 08, 2013, 09:01:41 PM
Quote from: CTG on February 07, 2013, 10:33:26 PM
Shipwreck? (tricky turns by Gutix, that's a legendary replay - was it really 6 years ago?!?)
Now you can check it :) Be sure to watch in fullscreen, you won't see much otherwise.
http://www.youtube.com/watch?v=Dwnej8PUsjg&hd=1
WHAT THE ...! hmm.. next age of stunts is coming? :)
stallin nice! ;D
Finally I understand this replay which is, in my opinion, one of the best there is, and definitely the best power gear replay ever.
Very impressed by the bird's eye animation!
Quote from: Duplode on February 08, 2013, 09:01:41 PM
Well, I said the logging process sucks, but it doesn't suck that much :D Later I will post technical notes to satisfy your curiosity and CTG's.
You should hurry, 'cause my curiosity left a bit ago with a serious look on its face, saying it was going to get some important information in Brasil :D
This is amazing, Dup!! I guess increasing car size and putting some kind of trail shouldn't be that hard now, right?
You rock!
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 (http://projects.haskell.org/diagrams/). 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...
Quote from: Chulk on February 08, 2013, 11:45:53 PM
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 (http://scr.stunts.hu/files/misc/z70.svg) 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 :)
It would be so cool to see the podium replays and compare lines!! This tool is great (though I haven't got the faintest idea on how to use it)!!
DAMN YOU CHINA for blocking youtube AND my VPN. :(
I hope I can check the video soon.
Quote from: zaqrack on February 09, 2013, 02:15:05 PM
DAMN YOU CHINA for blocking youtube AND my VPN. :(
I hope I can check the video soon.
some DNS hacking helped :) AWESOME work!!!
Quote from: zaqrack on February 09, 2013, 02:15:05 PM
DAMN YOU CHINA
Beware, Zak McKracken, the Chinese CIA (how do they call it anyway?) is watching you! :D
It's the MicroMachines version of Gutix' ZCT 70 replay.
Dumping Stunts' memory with dosbox's debugger, I seem to find the gear/surface string at 0000:37684 consistently, which would place the player vector at 375C6.
Could it be easier to dump data inside dosbox?
Quote from: dreadnaut on February 09, 2013, 07:39:57 PM
Could it be easier to dump data inside dosbox?
It probably is if you, unlike me, know how to operate a DOS debugger properly :D The problem with DOSBox's debugger is that there seems to be no way to dump a running log of a location in memory while the game plays. I imagine that a more sophisticated debugger should be able to do that, though for me it was quicker to use the scanmem hack given the aforementioned ignorance. (And please do tell us if you know a better tool, or how to make one!)
Quote from: dreadnaut on February 09, 2013, 07:39:57 PM
Dumping Stunts' memory with dosbox's debugger, I seem to find the gear/surface string at 0000:37684 consistently.
Indeed; that kind of shows up in scanmem too - in my tests the final three digits of the 64-bit address I get with it appear to be always 6
94 due to, I believe, contingent facts about how DOSBox allocates memory.
Quote from: Duplode on February 09, 2013, 07:50:37 PM
It probably is if you, unlike me, know how to operate a DOS debugger properly :D
So far from reality, I've never used it before! It took me half an hour to get a dump of the memory and just as much to find the saved file! :P
I was thinking more of a dos TSR program, dumping the contents of the correct memory location to disk. However, I don't have much experience in writing those either. At that point, it might be easier to modify dosbox and add the feature.*
* quick look at the code: no, it's probably not :D
Now that's just awfully awesome! 8)
I tried another approach at dumping the data, and ended up with a restunts based tool. It's in the repo as repldump. It basically initializes the game engine with a replay, steps through each frame, performs update_gamestate(), and dumps the entire 1120 byte gamestate structure to a file for every iteration.
(http://surr.no/pub/2013-02-10-stunts_repldump-tn.png) (http://surr.no/pub/2013-02-10-stunts_repldump.png)
Usage
Put the attached repldump.exe in your Stunts folder and run repldump.exe replname in a 16-bit DOS environment, such as DOSBox. The replay must be located in the same folder, and the file extension must not be included in the command. The program will then read replname.rpl and write replname.bin. The result file has the following format:
uint16 numFrames;
uint8 gamestate[numFrames][1120];
I also attached an example C program for parsing this file. Take the struct declarations with a grain of salt. I suspect that some of the field names are at best misleading. But all in all this info should enable us to compute penalty time, detect DNF, provide analysis, and maybe find the cause of some bizarre bugs.
Whoa! :o
The post above is the most important in this thread by far. For those of you not familiar with the restunts technical context: the innocent-looking tools attached to it aren't just a way to extract the coordinates in two simple steps, getting rid of all the annoying hacks I had been using. Rather, what you can see above is, for the first time ever, the game engine being used to run a replay outside of Stunts. Dstien hinted at some of the possibilities that opens above and elsewhere. In particular, earlier I said "The tools described above likely won't be convenient to use for a while". Now that "while" might get significantly shorter ;)
Three cheers for Dstien! Next to him, I'm just a pipsqueak. :)
we live in exciting times! :o
The day of my real retirement is getting closer and closer.
Quote from: Duplode on February 10, 2013, 08:51:19 AM
... the game engine being used to run a replay outside of Stunts ...
I just didn't want to tell it loud.
Ok, this means some simulating can be applied...
Brilliant job dstien!
First feature requests then ;D Dump only the last state of the simulation, and maybe dump to stdout so I can pipe it into other programs.
I'd also like to point out how great this thread is, how it started simple and to the point
Quote from: alanrotoi on February 02, 2013, 08:58:42 PM
Is there a possibility to make an automatic statistic program? Only with reading the replay?
how it was there all along
Quote from: dreadnaut on February 04, 2013, 02:26:31 AM
How much code from restunts is reusable? Could the replay engine (i.e., the fast forward button) be used to run replays?
and how high it soared in less than a week!
edit: also, at least on windows the program could run in the standard 16bit environment, without dosbox; the only issue is that it switches to graphics mode. Would it be possible to make it a console program?
Quote from: CTG on February 10, 2013, 12:13:53 PM
The day of my real retirement is getting closer and closer.
Unlike other future events?
Quote from: BonzaiJoe on February 10, 2013, 05:45:06 PM
Quote from: CTG on February 10, 2013, 12:13:53 PM
The day of my real retirement is getting closer and closer.
Unlike other future events?
There's the point. ;D
(retirement is not a necessary one)
Quote from: dreadnaut on February 10, 2013, 02:05:11 PM
First feature requests then ;D Dump only the last state of the simulation, and maybe dump to stdout so I can pipe it into other programs.
edit: also, at least on windows the program could run in the standard 16bit environment, without dosbox; the only issue is that it switches to graphics mode. Would it be possible to make it a console program?
Do you run a pre-Vista 32-bit OS? Didn't expect it to run natively on any platform released in this century. ;D
The reason why the program acts a little flaky is because I chose to link it to entirely unmodified original Stunts code to ensure there were no possible regressions from our ported code. The main stunts initialization function does a whole lot of stuff besides loading data. Like changing the video mode and hooking up interrupt callbacks. To halt the program after closing the output file handle I just invoke Stunt's fatal_error() function to unwind it all. I plan to add another build target so that we can use repldump with both stock code and our ported code, then we can easily test the restunts code automatically by comparing the output from the two programs. This will also enable us to use a ported init function that sets up only the bare minimum for a properly behaving command line program and implement more features. There's a lot of code that remains to be ported, so the build target will remain 16-bit DOS only for the foreseeable future.
Once we've got a clearer view of the gamestate content, and I don't think that will take Duplode long, we could probably set up a web service that takes care of the processing and parsing so that phpStunts don't need to depend on an x86 hypervisor and little-endian data parsing. :)
Quote from: dstien on February 10, 2013, 11:22:11 PM
Quote from: dreadnaut on February 10, 2013, 02:05:11 PM
First feature requests then ;D Dump only the last state of the simulation, and maybe dump to stdout so I can pipe it into other programs.
edit: also, at least on windows the program could run in the standard 16bit environment, without dosbox; the only issue is that it switches to graphics mode. Would it be possible to make it a console program?
Do you run a pre-Vista 32-bit OS? Didn't expect it to run natively on any platform released in this century. ;D
(OFF: I ran 32-bit Linux until about a month ago, first out of ignorance when I was a Linux newbie, and then due to laziness to do a full reinstall :D)
Quote from: dstien on February 10, 2013, 11:22:11 PM
There's a lot of code that remains to be ported, so the build target will remain 16-bit DOS only for the foreseeable future.
At least that means anyone with DOSBox can run it regardless of the host OS :)
Quote from: dstien on February 10, 2013, 11:22:11 PM
Once we've got a clearer view of the gamestate content, and I don't think that will take Duplode long,
I will do my best ;)
Quote from: dstien on February 10, 2013, 11:22:11 PM
Do you run a pre-Vista 32-bit OS? Didn't expect it to run natively on any platform released in this century. ;D
Er... Windows 7? And it dumps bin files alright, if you ignore the video driver complaining.
Changing the target platform would be nice, but we'll need to test it properly and make sure that no bugs depend on some architecture "feature" or limit. Can't lose those bugs :) I misread :-p
I noticed the "abnormal termination" so I guessed the fast "error" way out of the program loop, but with the speed at which you produced the tool, it's just fair!
As Stunts Cartography advances, I am slowly returning to the original task we set up in this thread. Here is a rough roadmap of what to expect:
- Now that there is a map annotation system, the next step is adding lap traces a fourth kind of annotation, with an option to overlay cars over the trace. With that done, creation of animation frames, like the ones I used to make the Z70 video, will be at an arm's length - all that it will take is adapting the animation code I wrote in February to fit the rest of the program and changing the drawing engine so that it doesn't redraw the full map if the track has not changed (so that rendering the frames doesn't take half an hour).
- That is half of the task - the other half being generating the traces with repldump (i.e. dstien's tool, published a few posts above). For that, I plan another program (probably separated from the Cartography viewer) which extracts the coordinates and angles from the raw output of repldump and writes them into a sensible format, which will then be read by Cartography.
- Finally, there is the issue of making repldump reasonably easy to use. I believe our best bet is running DOSBox with a dosbox.conf set on autorun to execute repldump with a specially-named replay, coupled to something like a .BAT (or bash) script which makes it work by copying files to the right places. Wiring it all should allow for generating the trace coordinates in a single step; than it would be just a question of loading them into Cartography and following your heart's desires.
We should have a live race again so we can use this to check results (besides, I miss those meetings and races)
Quote from: Chulk on September 05, 2013, 03:30:44 PM
We should have a live race again so we can use this to check results
Excellent excuse :) That Silverstone track is still waiting!
I have uploaded the code I am using to process repldump output to this repository (https://bitbucket.org/duplode/stunts-repldump-analysis). The coordinate extraction program is likely to be incorporated by Stunts Cartography once it stabilizes. If you have the Haskell platform (and the Chart-cairo dependency mentioned in the readme) you can easily make exploratory plots of game state data. For instance, the following GHCi session...
Prelude> :l Plots.hs
*Plots> foo <- parseFile "070ZGUT.BIN"
*Plots> writePlot frame [fst3 . pos1 . player, snd3 . pos1 . player, thd3 . pos1 . player] foo
...will read the 070ZGUT.BIN repldump output file and write a chart with the three player position coordinates plotted against the replay frame number to test.png.