first alpha version of StuntsVM is ready

[llm]

its some sort of Dosbox but based on Fake86 (http://sourceforge.net/projects/fake86/) and only able to emulate the environment enought to run stunts

the zip contains 3 files

game_pc.exe - the 16bit dos game, build with clvn's execombiner and my own sound driver integration tool for pc-speaker sound
stuntsvm.exe - executes/emulates game_pc.exe
SDL.dll - for Keyboard/Mouse/Gfx (https://www.libsdl.org/)

copy these into your stunts directory (where the tracks, sound and others files are - but make a backup before) and run stuntsvm.exe

what can you do with stuntsvm - test and play - for me its the base of my statical recompilation ideas for stunts

[Duplode]

Cool! I did a very quick test under Wine, and noticed two things:

• Very minor issue: files with names longer than 8 characters are ignored (I mention this mostly to remind other testers to rename their files if need be).
• More significantly: the physics do not seem to be 100% faithful yet. Both Gutix's ZCT070 replay and Akoss' ZCT168 one fail to complete. In the former, the car crashes at various points, depending on how much you rewind it, while in the latter the car is oddly deflected rightwards while climbing a hill at ~34s. Those issues should probably be confirmed by reproducing them in an actual Windows system (as opposed to Wine).

[llm]

Very minor issue: files with names longer than 8 characters are ignored

my DOS-File-API emulation does not support long filenames - easier to implement

More significantly: the physics do not seem to be 100% faithful yet. Both Gutix's ZCT070 replay and Akoss' ZCT168 one fail to complete. In the former, the car crashes at various points, depending on how much you rewind it, while in the latter the car is oddly deflected rightwards while climbing a hill at ~34s. Those issues should probably be confirmed by reproducing them in an actual Windows system

thats bad - can you attach the replays so i can compare real DOS/dosbox and stuntsvm? maybe the hardware timer isn't correctly programmed

[Duplode]

can you attach the replays so i can compare real DOS/dosbox and stuntsvm?

Here they are. The Z168 lap was arbitrarily chosen, but I picked the Z70 one because full powergear replays are trickier to get right - even the original game engine gets confused with them sometimes. I can suggest additional test cases if/when you need them.

[llm]

reproducing them in an actual Windows system

so what was your compare system - linux/dosbox, a real dos-machine?

[Duplode]

so what was your compare system - linux/dosbox, a real dos-machine?

Linux/DOSBox, which is how I usually play Stunts. It is safe to use DOSBox as a reference for physics: out of several thousand competition replays there are no known cases of divergences between laps played in DOSBox and in real DOS. (By the way, in the previous post I forgot to mention that I managed to reproduce the issue with StuntsVM running in a Windows XP virtual machine.)

[llm]

so what are exactly the steps (1.,2.,3.) i need to take to see the "bug" - reproduceable for both replays

[Duplode]

so what are exactly the steps (1.,2.,3.) i need to take to see the "bug" - reproduceable for both replays

Load the replays from the "Option" menu, rewind to the beginning with the "|<" command, and watch them at normal speed. In the Z168 replay, the car will leave the track unnaturally at ~34s; in the Z70 one, the car will land on water at ~50s. (Note: If you rewind the Z70 replay after the sinking and play it again it will crash at a different point. That in itself is not an issue, as such things occasionally happen with powergear replays in the original game.)  In the original executable, both laps are completely successfully by following the same steps.

[llm]

it seems that fake86 already got that problem

[llm]

StuntsVM is much slower compared to DosBox (or better said inaccurate) - because of the missing dynamic core - could it be that stunts got these errors if the environment is too slow?

[Friker]

With Dosbox config:
[cpu]
#      core: CPU Core used in emulation. auto will switch to dynamic if available and appropriate.
#            Possible values: auto, dynamic, normal, simple.
#   cputype: CPU Type used in emulation. auto is the fastest choice.
#            Possible values: auto, 386, 386_slow, 486_slow, pentium_slow, 386_prefetch.
#    cycles: Amount of instructions DOSBox tries to emulate each millisecond.
#            Setting this value too high results in sound dropouts and lags.
#            Cycles can be set in 3 ways:
#              'auto'          tries to guess what a game needs.
#                              It usually works, but can fail for certain games.
#              'fixed #number' will set a fixed amount of cycles. This is what you usually need if 'auto' fails.
#                              (Example: fixed 4000).
#              'max'           will allocate as much cycles as your computer is able to handle.
#           
#            Possible values: auto, fixed, max.

core=simple
cputype=386
cycles=fixed 1000

which should mimics non-dynamic core, running in Linux Gutix's replay ran OK. Well - i did not notice up until today that 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.

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?

[Duplode]

I think almost all bugs in Stunts has something with over/uderflow of registers/variables.

I believe power gear has something to do truncation handling, though it seems entirely possible it being an over/underflow triggered by bad truncation. I probably should have investigated it further back when I was messing with restunts stuff 

[Friker]

I think almost all bugs in Stunts has something with over/uderflow of registers/variables.

I believe power gear has something to do truncation handling, though it seems entirely possible it being an over/underflow triggered by bad truncation. I probably should have investigated it further back when I was messing with restunts stuff 

A-ha. Still, let's assume different handling of PG is caused by truncation differencies. And truncation differencies are probably caused by register/variable bit-size, aren't they? Does restunts code uses same-precision floats as the original game etc.?

Btw is restunts code somewhere available? No that I would understand it, but I have more time to look at some random characters now.

[Duplode]

Btw is restunts code somewhere available? No that I would understand it, but I have more time to look at some random characters now.

There is a repository at svn://anders-e.com/restunts/trunk (cf. this post), but I kind of lost track of the latest developments. I suggest you ask dstien for (possibly updated) directions.

[clvn]

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