Stunts Forum

Stunts - the Game => Stunts Related Programs => Topic started by: alanrotoi on February 02, 2013, 08:58:42 PM

Title: Replay logging
Post by: alanrotoi on February 02, 2013, 08:58:42 PM
Is there a possibility to make an automatic statistic program? Only with reading the replay?
Title: Re: Replay logging
Post by: dreadnaut on February 03, 2013, 12:23:46 AM
What kind of statistics?
Title: Re: Replay logging
Post by: alanrotoi on February 03, 2013, 08:54:52 PM
Section times.
Title: Re: Replay logging
Post by: Friker on February 03, 2013, 10:51:48 PM
Section times.

Nope.
Title: Re: Replay logging
Post by: Duplode on February 03, 2013, 11:05:58 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.)
Title: Re: Replay logging
Post by: 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?
Title: Re: Replay logging
Post by: Friker on February 04, 2013, 10:13:48 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, ...). 
Title: Re: Replay logging
Post by: CTG on February 04, 2013, 11:11:44 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).
Title: Re: Replay logging
Post by: dstien on February 04, 2013, 12:28:07 PM
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.
Title: Re: Replay logging
Post by: Duplode on February 04, 2013, 04:09:12 PM
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.)
Title: Re: Replay logging
Post by: dreadnaut on February 04, 2013, 04:28:43 PM
@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! :)

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.


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.
Title: Re: Replay logging
Post by: alanrotoi on February 04, 2013, 11:49:47 PM
@CTG stallin shut up!

Zak once did some code where the result was how meny times accel and breaks butons were pressed, remember?
Title: Re: Replay logging
Post by: 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 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?
Title: Re: Replay logging
Post by: dreadnaut on February 05, 2013, 02:24:27 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!

Quote
btw 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.
Title: Re: Replay logging
Post by: dstien on February 06, 2013, 01:14:22 AM
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.

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.
Title: Re: Replay logging
Post by: Duplode on February 06, 2013, 02:07:11 AM
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  :)

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  ;)

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.
Title: Re: Replay logging
Post by: Chulk on February 06, 2013, 03:53:36 AM
Would be neat to overlay the resulting paths on a track map in order to compare racing lines.
That would be so cool!
Title: Re: Replay logging
Post by: dreadnaut on February 06, 2013, 02:49:48 PM
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"...)
Title: Re: Replay logging
Post by: Duplode on February 07, 2013, 05:00:17 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)
Title: Re: Replay logging
Post by: 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.
Title: Re: Replay logging
Post by: Chulk on February 07, 2013, 06:30:34 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.
Title: Re: Replay logging
Post by: CTG on February 07, 2013, 08:57:20 AM
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?)
Title: Re: Replay logging
Post by: BonzaiJoe on February 07, 2013, 09:40:02 AM
The curve on the top of the top graph looks like a classic power gear slide turn.
Title: Re: Replay logging
Post by: Friker on February 07, 2013, 04:00:45 PM
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?
Title: Re: Replay logging
Post by: Chulk on February 07, 2013, 04:22:50 PM
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
Title: Re: Replay logging
Post by: CTG on February 07, 2013, 04:31:31 PM
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
Title: Re: Replay logging
Post by: Duplode on February 07, 2013, 08:13:52 PM
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 ;)

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...)

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.
Title: Re: Replay logging
Post by: alanrotoi on February 07, 2013, 08:20:37 PM
Yes, I guess it's an excel chart!  :-[
Title: Re: Replay logging
Post by: Chulk on February 07, 2013, 09:14:14 PM
Yes, I guess it's an excel chart!  :-[
Explanation is there on facebook for you ;)
Title: Re: Replay logging
Post by: CTG on February 07, 2013, 09:47:32 PM
Corvette or GTO (30 mph after ~2.1 seconds, Indy's acceleration is a lot better)
Title: Re: Replay logging
Post by: Chulk on February 07, 2013, 09:50:16 PM
It's your Z138 winning vette replay
Title: Re: Replay logging
Post by: CTG on February 07, 2013, 10:05:37 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)
Title: Re: Replay logging
Post by: 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?!?)
Title: Re: Replay logging
Post by: CTG on February 07, 2013, 10:53:29 PM
Shipwreck? (tricky turns by Gutix, that's a legendary replay - was it really 6 years ago?!?)

Yes, it is. :D
Title: Re: Replay logging
Post by: dstien on February 08, 2013, 02:12:16 AM
Teaser.
Nice-o-rama! But please don't tell me you extracted that data set manually...?
Title: Re: Replay logging
Post by: CTG on February 08, 2013, 11:45:21 AM
But there are some more clues ;)

What kind of clues? Except the big one: how could you... ;D
Title: Re: Replay logging
Post by: Duplode on February 08, 2013, 09:01:41 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

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.
Title: Re: Replay logging
Post by: Friker on February 08, 2013, 09:05:34 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? :)
Title: Re: Replay logging
Post by: CTG on February 08, 2013, 09:38:57 PM
WHAT THE ...!

Exactly the same feeling here...
Title: Re: Replay logging
Post by: alanrotoi on February 08, 2013, 09:54:45 PM
stallin nice!  ;D
Title: Re: Replay logging
Post by: BonzaiJoe on February 08, 2013, 10:02:22 PM
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!
Title: Re: Replay logging
Post by: dreadnaut on February 08, 2013, 11:30:31 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
Title: Re: Replay logging
Post by: Chulk on February 08, 2013, 11:45:53 PM
This is amazing, Dup!! I guess increasing car size and putting some kind of trail shouldn't be that hard now, right?

You rock!
Title: Re: Replay logging
Post by: Duplode on February 09, 2013, 06:22:00 AM
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...

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  :)
Title: Re: Replay logging
Post by: Chulk on February 09, 2013, 07:53:14 AM
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)!!
Title: Re: Replay logging
Post by: 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.
Title: Re: Replay logging
Post by: zaqrack on February 09, 2013, 02:25:10 PM
DAMN YOU CHINA for blocking youtube AND my VPN. :(
I hope I can check the video soon.

some DNS hacking helped :) AWESOME work!!!
Title: Re: Replay logging
Post by: CTG on February 09, 2013, 02:25:39 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.
Title: Re: Replay logging
Post by: 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, which would place the player vector at 375C6.

Could it be easier to dump data inside dosbox?
Title: Re: Replay logging
Post by: Duplode on February 09, 2013, 07:50:37 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!)

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 694 due to, I believe, contingent facts about how DOSBox allocates memory.
Title: Re: Replay logging
Post by: dreadnaut on February 09, 2013, 08:02:08 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
Title: Re: Replay logging
Post by: dstien on February 10, 2013, 04:56:18 AM
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:
Code: [Select]
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.
Title: Re: Replay logging
Post by: Duplode on February 10, 2013, 08:51:19 AM
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.  :)
Title: Re: Replay logging
Post by: zaqrack on February 10, 2013, 10:50:43 AM
we live in exciting times!  :o
Title: Re: Replay logging
Post by: CTG on February 10, 2013, 12:13:53 PM
The day of my real retirement is getting closer and closer.
Title: Re: Replay logging
Post by: Friker on February 10, 2013, 12:35:57 PM
... 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...
Title: Re: Replay logging
Post by: dreadnaut on February 10, 2013, 02:05:11 PM
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
Is there a possibility to make an automatic statistic program? Only with reading the replay?
how it was there all along
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?
Title: Re: Replay logging
Post by: BonzaiJoe on February 10, 2013, 05:45:06 PM
The day of my real retirement is getting closer and closer.

Unlike other future events?
Title: Re: Replay logging
Post by: CTG on February 10, 2013, 05:49:26 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)
Title: Re: Replay logging
Post by: dstien on February 10, 2013, 11:22: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. :)
Title: Re: Replay logging
Post by: Duplode on February 10, 2013, 11:29:07 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)

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  :)

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  ;)
Title: Re: Replay logging
Post by: dreadnaut on February 11, 2013, 01:21:18 AM
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!
Title: Re: Replay logging
Post by: Duplode on September 05, 2013, 05:18:26 AM
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:
Title: Re: Replay logging
Post by: Chulk on September 05, 2013, 03:30:44 PM
We should have a live race again so we can use this to check results (besides, I miss those meetings and races)
Title: Re: Replay logging
Post by: Duplode on September 06, 2013, 05:03:44 AM
We should have a live race again so we can use this to check results

Excellent excuse  :) That Silverstone track is still waiting!
Title: Re: Replay logging
Post by: Duplode on September 22, 2013, 08:48:22 PM
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...

Code: [Select]
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