Messages

If no one else are going to pick the low-hanging points, I might as well do it.

Edit: Should have watched the other replays before pipsqueakin' myself...

First feature requests then   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.

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.

[Usage]

Now that's just awfully awesome!

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.



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 Expand


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.

Teaser.

Nice-o-rama! But please don't tell me you extracted that data set manually...?

I'm running out of superlatives to describe my appreciation of your contributions, Duplode. That sure is a mighty fine piece of good work!

I don't have any plans to improve the hex editing capabilities of stressed. What you describe could be done in a real hex editor with data templates. But I am working on tuning support for stressed. First version will just have a single control for editing for each available value, plus some visual guidance. Then we'll see how we can add convenient unit conversions and such. I guess Duplode have quite a few ideas about that.


As for a track editor, I don't know. There are some embedded track files in TEDIT.PRE for the terrain presets, though...

First commit in 18 months.

Finally checked in the remaining decompression functions. Now to focus on some more exciting parts of the code. There are currently some regressions in the ported simulation code that I'll look into.

Current status: http://re.stunts.no/status/2013-02-05.html

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.

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.

[P]

If I try to edit OPP[number].PRE files, Stressed can't recognize the 'lose' part. Whatever I choose from 'opening as...' list, saving the file after modification will result a crash in opponent's selection menu. How can I avoid it, if I want to edit the opponents' performance?

lose is an animation. To get it recognized automatically you can delete %APPDATA%\stuntstools\stressed.ini to get the settings regenerated. Since .PRE files are packed, you'll have to save as .RES. I guess we should try to merge the config when launching, and add a dummy compression header when saving as a packed file. Well, well.

I will test cross-compiling it in the way you describe once I am done with rearranging my environment (just moved from Fedora to Arch, after five long years).

But... I hardly described anything. Well, here's my Qt config:

Code Select Expand

./configure -prefix ~/build/qt/inst -opensource -confirm-license -release -static -xplatform win32-g++ -device-option CROSS_COMPILE=i686-pc-mingw32- -nomake tests -nomake examples -no-sql-odbc -no-sql-sqlite -no-javascript-jit -no-accessibility -qt-zlib -qt-libpng -qt-libjpeg -no-openssl -qt-pcre -no-audio-backend

Where -prefix foo is the prefix for the install paths and CROSS_COMPILE is the prefix of the toolchain command names. There's probably room for improvement on what to exclude from the build. When all is compiled just generate new makefiles for stressed with qmake from the install path and make as usual to build with the alternative libs and toolchain.

Heh, that didn't even take a month to accomplish. Updated the builds thread with version 0.2.1. Looks like a few Qt things have changed for the better during the last 5 years. Cross-compilation was a breeze. Even managed to link the dependencies statically, so now the numerous DLLs are replaced with one humongous EXE file.

I'll see if I can whip up some updated binaries in the foreseeable future. A majority of the post 0.1.0 commits are likely just OCD code sanitation, though.

Hahaha! Most excellent, CTG. Most excellent.

Some of the ideas I've had with restunts involves automated replay analysis, which, in addition to aid completely automated competition verification, also could help develop perfect AI using genetic algorithms. Unfortunately, none of us have had time to work on restunts in years.