Messages

this game has SLOW and FAST simulation options!! I do not know differences and impact on replays. I guess everyone has set up a fast simulation option. Gutix's replay ran OK with both options.

The game runs some relatively heavy code during startup and measures how much time it takes.  Based on the amount of time, the game runs in either 10 FPS or 20 FPS IIRC. DosBox' emulation flags obviously affect the timing code. Also the FPS is saved in replays, which affects how the replay is played back on other slower/faster machines as well.

The measurement code has been ported and can be seen here (near the comment "// Timing measures.")
http://anders-e.com/code/browser/restunts/trunk/restunts/src/restunts/c/restunts.c#L1334

I think almost all bugs in Stunts has something with over/uderflow of registers/variables. If I understand correctly  game_pc.exe is a re-compiled executable. Are you there are registers/variables exactly the same size as in the original game?

The stunts code that has been ported to C so far has been written carefully to retain any important weirdness, so indeed the registers/variables should be exactly the same size as in the original game.

Looks like its been almost a year since anybody last worked on this. The source can be browsed in its entirety online here:

http://anders-e.com/code/browser/restunts/trunk/restunts

fyi, the executable has been updated:

http://dl.dropbox.com/u/213479/restunts.exe

Total functions: 625 / Ignored: 143 / Ported: 98

keyboard support, math routines, 2d/3d shape loading and rendering are areas where there have been great progress. testers are encouraged to give this new version a spin.

note there is a section of code missing causing premature program termination at the end of the intro and when entering the track editor. alas, not everything works yet.


something else; theres a simple 3d shape browser based on the stunts engine:

http://dl.dropbox.com/u/213479/restunts-alt.exe

arrows right/left choose shapes and any action key exits. note the arrow keys react way too fast.

the link is for fun, but the purpose of this program is to demonstrate the minimum code that renders a 3d mesh on screen. hopefully the same program will compile and run on windows+SDL not too far in the future.

Hi,

I wanted to share with you this zip of MIDI files converted from the original game files:

http://dl.dropbox.com/u/213479/stuntsmidi.zip

It is not a perfect conversion, things like modulation and pitch bend (?) are not converted. C++ source code for the converter is included.

There are also MIDI files from the game on this page: http://stunts.kalpen.de/specials.htm, however these are not related.

hello!

i believe we are past the biggest initial obstacles now. hopefully the next months will require mostly "mindless" porting from asm to c. the following pages are updated whenever something happens:

status: http://dl.dropbox.com/u/213479/status.html
cia.vc: http://cia.vc/stats/project/restunts

if anyones interested to join the effort, we still hang out on irc on #stunts/efnet. feel free to ask there, and we'll provide access to source codes, tools and scripts to get going. our tool chain has been tested on windows xp.

testers are also welcome:

http://dl.dropbox.com/u/213479/restunts.exe

restunts.exe currently features 40+ functions coded by dstien and i, running nicely side-by-side with the original code. the functions ported so far are related to file loading+writing and memory management. llm also gave valuable feedback in early critical phases.

hello!

the project has come to the point where the original game executable is successfully disassembled and recompiled back into a new executable:

http://dl.dropbox.com/u/213479/restunts.exe

could interested people please download this exe, put it in your stunts directory and give it a test run? id like to hear about any problems/crashes/etc. feedback is welcome here or on irc #stunts /efnet

and it think John Jordan is a good person to ask for the "right" way of doing the port
he creates jjffe - the reverse engeneered version of ffe (frontier first encounters) - from 16bit, dos-extender -> 3dbit win32(directx)

http://jaj22.org.uk/jjffe/jjffefaq.html#q3

as you can read here he used a special version of the ndisasm from the nasm assembler
maybe he could give good avises for doing the port

thats a mad cool project, but apparently the original ffe was written for 32-bit to begin with (borlands dpmi extender to be specific). that simplifies things dramatically from a porting point of view since e.g access to pointer variables and structs containing pointers is basically not a problem. thus most of their disassembly can be copy/pasted without any processing. our case however will require quite a bit of manual fixing to run on 32-bits. that said, i'm still gonna check the output of ndisasm at some point.


btw, ive updated the .idc-script that automates idapro: http://dl.dropbox.com/u/213479/anders.idc

the script spits out an .asm file for each function and an .inc for each segment in the currently open ida-project. still a work in progress. i was able to compile all functions in stunts into separate .obj files using tasm and a few minor adjustments. which is pretty neat, but then linking with tlink failed miserably. i believe the linking issue can be resolved by reorganizing the script a bit to either 1) output an .asm per segment rather than per function, or 2) reduce the number of publics/externs in the asm-files. but i havent found time for it yet.

please let me know how we can get in touch. I can pass you my e-mail and Skype IDs and will be glad to participate in the IRC

irc is an ancient yet popular way to chat in real time. you need an irc client such as irssi on linux or mirc on windows, connect it to irc.efnet.org and join the channel #stunts. we're two people in there right now

hello!

still busy at work here, but havent completely forgotten about this.

so far i've probed into automating idapro with .idc-scripts. i really like the idea of automating idapro to generate a compilable and extendable project.  such a script would have to do something like this:

Code Select Expand

- for each segment, generate segN.inc containing extrns to all symbols in that segment (procs, locs and data)
- for each function, generate functionname.asm file with:
- include all seg0..segN.inc, EXCEPT for the segment where the function belongs
- extrns for all symbols in the same segment EXCEPT the current function and data
- public definitions of data and procs
- the implementation of the function and related data
- also, the datasegment must be split into at least two files, since the source code is too big for tasm
- some .bat or project file that assembles and links everything

if this turns out to work, we will have a working exe compiled from the disassembly and the possibility to start porting to C. further reverse engineering can still take place in idapro. e.g when a new variable is discovered and properly renamed, the source files can simply be re-generated from scratch by executing the idc. already-ported c functions may still need to have symbol names back-ported manually, but i still believe this approach would be more convenient than porting everything by hand.

there might turn up some interesting issues related to optimizations made by the original compiler. and lateron the script needs some features related to porting, e.g generate c headers and ignore already ported functions.

here's my attempt at an idc so far. its not usable for anything, but i learnt a great deal when writing it. it was left like this a few days ago, some parts are commented out after testing the built-in method to generate the assembly:

http://dl.dropbox.com/u/213479/anders.idc

1- Do not abandon the game support for pure DOS!  This is an opportunity to support the FreeDOS project. Stunts was born a DOS application and it can still be improved with 32bit code without necessarily having to separate from DOS. Make sure any new code can also be compiled to run under pure DOS. I can dedicate to that myself.

agreed. dos support would be nice.

2- MASM and TASM are not very comfortable to receive decompiled code because of the way they structure the sources (ASM files)... having lots of required directives. I strongly suggest Flat Assembler: http://flatassembler.net

in regards to prefered compilers, assemblers etc, i dont really care. in the beforementioned approach the output can presumably be formatted to suit any assembler. if fasm can compile ida's output with less hassle, then im all for it. the ultimate end-result wouldn't depend on any assembler anyway, so i propose whoever makes (and shares) an idb+idc that produces a compilable project gets to decide on the assembler.

3- What do you need help with? Smiley

i need help with "everything". i'll likely resume coding on the idc whenever time permits, unless somebody does it before me. or comes up with a better approach where i can participate. im open for good suggestions.


everybody are also welcome to join on irc in #stunts/efnet. im still alone in there, hardcore idling

i just saw the differences beween 4.9 and (i think) a recent 5.x version - and it produces a much better and smaller output

ok. sounds like its worth further investigation. perhaps even to the point its worth starting almost from scratch again in idapro, but using sane naming conventions etc. at least the existing work could be used as a reference.

>so im still considering how to move forward. maybe making an intermediate 16-bit port in
>turbo c + tasm as the first step

the idea sounds good - got an version of tc/tasm around? maybe you use watcom c or djgpp

tc 2.01 is available from here:
https://downloads.embarcadero.com/free/tc201 ->
http://altd.embarcadero.com/download/museum/tc201.zip

while tasm 5 is no longer officially available, it can be found here:
http://www.phatcode.net/downloads.php?id=280

tried to locate some ancient microsoft c compilers as well (apparently used for the original game), but google wouldnt tell me. tasm+turboc may be just as good, idapros output should be compatible with tasm.


ive done some investigation into the tasm-approach. for example, just passing the entire .asm-file to tasm doesnt work too well; after getting rid of the obvious errors it stops on "out of memory", presumably and hopefully due to a too large code file.

to get past that, it would be obvious to split game.asm into many smaller ones, which can be assembled and linked separately. like one function per file. but, unless the work in idapro is completely done, one would have to backport any new discoveries in idapro back to the separated .asm-files manually.

so to workaround that, its maybe an idea to automate the process of splitting game.asm into smaller pieces. either as a script that parses game.asm and spits out many smaller ones, or finding or writing a plugin for idapro that does the job directly. this would allow testing+porting in tc/tasm and further reverse engineering iteratively. im guessing a script is the most efficient way to split up game.asm anyway.

alas im stuck with other stuff atm, so i wont be able to follow through with any of this in the near future though.

what version of ida do you use - newer version seems to do a much better job in reversing
im currently thinking about buying the latest edition

i did use the freeware 4.1 version, which is rather old. mostly out of habit. after reading into collabreate, ive installed a newer version and upgraded the .idb, but havent really progressed any further. using the newer version still feels annoying due to some changed hotkeys.

---

to follow up on an earlier post, i was trying to port the disassembly to inline 32-bit assembler in msvc. which is now on hold. fixing the related pointer issues is possible with a well-planned approach (and even trivial with a smaller program), but now its turning into a mess.

so im still considering how to move forward. maybe making an intermediate 16-bit port in turbo c + tasm as the first step... or maybe look for a plugin for ida that helps porting single functions... ideas are most welcome.

is the exe fully tested, are there any known problems?

as far as my testing goes, there are no problems using the new exe

hello!

i can't create the game.exe with your program - i get an access violation in apply_dif
after serveral runs of the while loop - i think your break condition does not met with my data
what game version did you use?

it says stunts version 1.1, feb 12 1991.

most obvious point of failure i can think of is not uncompressing the datafiles with stunpack in advance. dunno.

for convenience, heres a zip with the vs project, including the final game.exe both uncompressed and cracked;
http://dl.dropbox.com/u/213479/execombiner.zip

If we could make the manual decompilation process a collaborative effort it'll speed up the job. The collabREate approach looks interesting.

ooh, collabreate looks like a good tool for sharing the effort, considering a regular versioning tool wont work with idapros .idb-file.

im gonna have to try and set up collabreate in a local vm for testing. alas i dont have access to a suitable public server. if anyone here wants to set up a collabreate-server for the task, ill support it for sure.

1. With the information you have already dissected is it possible to locate the materials table and the colour palette(s) used to build it?

2. After locating materials and palettes, how hard would it be to make a patch for modifying the default colours of sky and ground? Or, more ambitiously, to substitute materials entirely?

well, this depends.. of course there is the 768 bytes "!pal"-structure in sdmain.vsh. thats the global 256-color palette used throughout the entire game. tweaking it may have unexpected side effects though.

from what ive learned so far, it is possible to tweak hard coded material assignments for all the individual tile types. e.g render a normal road as icy road, or rotate, move or replace a shape with another one. this could be done before, but not without modifying the 3d files themselves. but the ground and the sky are handled in special ways, and i cant tell which color indexes are used for those.

also, there should indeed be a material index table in there somewhere. it has mappings between the 3d shape materials/paintjobs and the global "!pal" palette. i've ripped some stuff from stressed in order to get the colors in my d3d-rendering correct, but havent located this in the disassembly either.

The little reverse engineering project has continued at full pace. Check out the latest .asm-dump from idapro:

http://dl.getdropbox.com/u/213479/game2.asm

While a lot of analysis remains, the disassembly now has many better-named functions and variables and a bunch of structs. The readability is much improved. Big chunks of the data segment was identified, including tables with mappings between track-tiles and 3D-shapes with rotation, materials, etc.

On a side note, a greater plan is starting to emerge. I've reconstructed enough of the resource manager and original memory layout to code a .trk-viewer-app under windows/d3d. Its pretty lame, so no betas, screenshots nor source code yet. It is meant as a testbed for analyzing and porting assembly from the disassembled stunts game executable. This way the vital parts of the game engine could be reimplemented in inline 32-bit x86 msvc-assembly with only minor changes. Further porting to C/C++ and other platforms would of course be for later.

There are approx 25000+ lines of code (out of 100000+) that are relevant to the core game engine and needs to be ported. So far only 1500 lines in 3 functions were ported in a couple of hours. There is work for at least a few weeks-to-months for somebody with a lot of spare time