I have mirrored dstien's SVN repository for restunts to BitBucket, both to have a backup and for ease of access. I don't intend for any work to go ahead on it, but it's useful to point at files.
https://bitbucket.org/dreadnaut/restunts/
https://github.com/4d-stunts/restunts
That's useful, thanks for the initiative! (In particular, y'all can now look at the code from the comfort of your browser, so if you are curious feel free to have a stroll around it.)
Yep, this is really to make the restunts code accessible, so that it become easier to talk about it. It's not that difficult to check it out from dstien's SVN, but this is easier.
In particular, it's easy to link to a specific file and line:
https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asm/seg001.asm#lines-6171
It would be interesting to compare the assembly for that function in different Stunts versions 🤔
Quote from: dreadnaut on March 20, 2021, 12:14:48 AM
Yep, this is really to make the restunts code accessible, so that it become easier to talk about it. It's not that difficult to check it out from dstien's SVN, but this is easier.
In particular, it's easy to link to a specific file and line:
https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asm/seg001.asm#lines-6171
It would be interesting to compare the assembly for that function in different Stunts versions 🤔
Late response but I was looking a bit in the part of the code that starts at your line.
If i read it correctly this part looks at grip per wheel (corners of the hitbox?)
and takes the sum of it. then applies that to the angle of the wheels (eg steering)
that produces skidding.
(im not a programmer so this could be wrong. but seems right)
what i also notice is that the code takes the steering input for left and right steering in the same code.
so there should not be a difference in left and right steering.
I was scanning throug this part kind of hoping to see some indications of the source of the left corner bias.
Now the reason for reading this topic again. [edit typo, accidentally quoted myself earlier today]
I would like to play a bit with the code (maybe i learn something along the way)
but for me it is difficult to compile the executable because i dont have enough information.
I have 0 experience in this, so could somebody give me a step by step?
What software do I need? (on what platform | in my case DOS or windows)
How do i setup the make file?
Do i need to configure the software before compiling?
I saw referenc to turboC. i assume that refers to Borland Turbo C.
and Tasm and BCC, (bcc is also borland i think) but that is as far as my info goes.
I think everything is in the repo, most of the programs and description, there is a docs or something folder that describes all
Quote from: llm on October 25, 2021, 08:08:04 PM
I think everything is in the repo, most of the programs and description, there is a docs or something folder that describes all
You are right. I found it this afternoon after a bit of idly browsing through the data.
I had been looking in the |
restunts/docs | section.
I looked at the readme in the main directory to, but not good enough. All the information is in there.
https://bitbucket.org/dreadnaut/restunts/src/master/readme.txt (https://bitbucket.org/dreadnaut/restunts/src/master/readme.txt)
How to build restunts on Windows:
1) Double click tools\mount_stunts_to_s.bat (only needed once per reboot)
2) Start cmd.exe and enter the following commands:
S:
cd tools
setpath.bat
cd \src\restunts
makelooks simple enough.
Quote from: Daniel3D on October 25, 2021, 11:19:38 AM
Late response but I was looking a bit in the part of the code that starts at your line.
If i read it correctly this part looks at grip per wheel (corners of the hitbox?)
and takes the sum of it. then applies that to the angle of the wheels (eg steering)
that produces skidding.
Pretty much so. It adds up the grip for each wheel and compares it to the grip that would be required, given the car speed and steering angle, in order to decide whether the car should be skidding. There are a few places in which the turning direction is looked at, in particular to use the absolute value of the turning angle (look for
jge and
neg; there's also a multiplication by minus one/
imul with
0FFFFh). Though I couldn't see it back in the day, or simply didn't look at it closely enough, I think its quite likely left corner bias arises somewhere in there.
I'm trying to find it because I think it is a bug.
A chance to the steering that was either badly changed or changed, cancelled, and badly reversed.
I want to find out more.
I tried compiling but it uses the C code in assembly I believe.
How can I change the makefile to build just from assembly code?
Changes I want to do (like moving buttons or changing the default car) I can do now in the assembly code directly. (I understand that much)
For the rest, I'll pass it through CAS for verification.
Do we have a decompiled version of the same piece of code in 1.0? It would be interested to compare the grip calculations between the two versions.
Nope, we only have 1 version decompiled (stunts 1.1 I believe)
I would like to have the PC-98 version decompiled because it is so different but the replays are 1.1 compatible.
Quote from: Daniel3D on October 26, 2021, 08:07:00 AM
I tried compiling but it uses the C code in assembly I believe.
How can I change the makefile to build just from assembly code?
Alright,
reading English late at night is apparently not easy.
It was all there in the read me. Just didn't understand at first.
Also, the map to S function didn't function. So a made a different solution to get the S drive.
The end result is the same, and I can compile the game now.
I've found a typo in a makefile.
Not serious, but it made my first attempt fail.
https://bitbucket.org/dreadnaut/restunts/src/aa1e714a66f8f9bd0d78bb1c0c3ab6b69252721d/src/restunts/dos/makefile#lines-14 (https://bitbucket.org/dreadnaut/restunts/src/aa1e714a66f8f9bd0d78bb1c0c3ab6b69252721d/src/restunts/dos/makefile#lines-14)
ASMORIG_OBJFILES = $(ASM_OBJDIR)\segments.obj $(ASMORIG_OBJDIR)\seg000.obj
should be ASMORIG of course.
If the file exists there then it won't be a problem I think, but still.
I will not touch the repository, I do not consider myself qualified to do so.
Sorry. Me again.
I compiled a original stunts and a restunts with the readme. And besides the above mentioned false start they both were compiled without issues.
But.
ReStuntoexe is 808kb large and ReStunts.exe is over 970kb.
How did they become so large?
They run fine as far as I can tell..
The original asm code should produce a skimcga.exe like size, due to its assembler nature it could be only grow as big as the asm code more or less exactly defines
The size of the build with ported c code will be compiler defined, usually c based code could be (much) larger, but ~900 kb seems very large, maybe its the debug information thats get added to the executable
Quote from: llm on October 28, 2021, 06:11:44 AM
maybe its the debug information thats get added to the executable
As far a can tell that is the case.
The header is different, then the game file and then a lot of data that seems to be the original game file's (all of the them) and some text about included programs and makefile information.
How do I create a clean executable?
QuoteI saw referenc to turboC. i assume that refers to Borland Turbo C.
and Tasm and BCC, (bcc is also borland i think) but that is as far as my info goes.
Borland (Turbo) C is the Development System from Borland (Borland in Product names sometimes refer to the Professional Version (with Lib sources etc) and Turbo in name refer to some sort of Semi-Professional)
Tasm ist the Turbo Assembler from Borland
and BCC.EXE is the Borland C Commandline compiler, BC.EXE is the Borland IDE
Future ideas: (if i remember correct)
-the TASM is still the 16bit version - that could be change to the 32bit TASMX (so no dosbox need) or its maybe possible to switch to UASM x64 or Microsoft MASM
-for the C part i would also like to switch to a more recent Compiler version - but it woul be great to have source debugging support
the Problem is: the tools are very old and there were several competing debugger standards around that time - so Microsoft ist using CodeView, the Borland tools got its own format, i think Watcom also uses CodeView
it would be great to have source-level debugging support for asm (and C) source - at best not in a 80x25 Textmode interface :)
but the damn Assembler code is 16bit Segment/Offset x86 code - so it can't be just translated to 32bit systems even we get rid of the hardware access
it would have been very easy if it was originaly developed for 32bit systems - like many other DOS games - then we could only replace the hardware access stuff and it would then run on windows/linux and we could have used todays development tools - but its just way too old :(
i still have not found the perfect environment for working on the code - and not suffering of 16bit area textmode debugger systems :)
my hope is that the Open Watcom v2 Project could be of help here - the github project is very vibrant - issues getting resolved very fast - but
for that the asm and C code needs to get ported (a little) to the Watcom environment
another big hope is the https://github.com/xor2003/masm2c project which could convert the asm source to C like source that could work on any 32bit/64bit system
- the conversions produces C code that behaves like the original - so one is able to just debug the "original" assembler code in a recent IDE - that eases porting/fixed adding code a lot - we can't get Stunts ported to 32/64Bit Windows/Linux without the C translation phase (using this tools or manual)
but all these steps are only doable by a experienced developer with time :/
That would be make reengineering a lot easier indeed.
But for the time being, I would like to understand the setup as it is and learn to work with it.
I'm not doing very well at the moment. I followed the instructions and that seems to work. The errors I got earlier I could understand and troubleshoot.
Now I have a compiled and working executable without errors that is way to big. It seems to contain debug data, but I haven't the foggiest idea how to fix it ???
How can i create a game executable like game.exe with asmorig?
-------
I am using the Restunts repository (local copy) to learn, test and modify the game code with the goal to make small changes (like described in small steps)
This is not aimed at reengineering. Is it wise to continue this in a new repository so they don't get mixed?
Quote from: Daniel3D on October 28, 2021, 09:43:24 AM
That would be make reengineering a lot easier indeed.
even for the changes you want to make - assembler is a beast, even beastier without able to follow it in source (dosbox debugger is ok but not great for that)
Quote from: Daniel3D on October 28, 2021, 09:43:24 AM
But for the time being, I would like to understand the setup as it is and learn to work with it.
I'm not doing very well at the moment. I followed the instructions and that seems to work. The errors I got earlier I could understand and troubleshoot.
Now I have a compiled and working executable without errors that is way to big. It seems to contain debug data, but I haven't the foggiest idea how to fix it ???
How can i create a game executable like game.exe with asmorig?
can't help currently - at least 10 years ago i did that
Quote from: Daniel3D on October 28, 2021, 09:43:24 AM
I am using the Restunts repository (local copy) to learn, test and modify the game code with the goal to make small changes (like described in small steps)
This is not aimed at reengineering. Is it wise to continue this in a new repository so they don't get mixed?
its a git repo - just add a local branch and commit to this - won't mixup with the gitlab repo - because you won't push it - and even if that happens it is seperated from the master using a branch (btw: GitExtensions or GitAHead are good client for Windows)
Quote from: llm on October 28, 2021, 09:53:45 AM
its a git repo - just add a local branch and commit to this - won't mixup with the gitlab repo - because you won't push it - and even if that happens it is seperated from the master using a branch (btw: GitExtensions or GitAHead are good client for Windows)
That is true.
But then I will only add relevant or promising stuff to the branch. (I'm afraid it will explode with useless data otherwise)
For research purposes, I also want [try] to disassemble Stunts 1.0 as suggested and the PC-98 version.
To compare certain parts, like grip and steering(left corner bias) in 1.0 and the menu structure and replay saving in the PC-98 version.
No idea yet what I will understand of it. Or if it is doable at all. I'll document this in a separate topic.
Quote from: Daniel3D on October 28, 2021, 10:25:52 AM
But then I will only add relevant or promising stuff to the branch. (I'm afraid it will explode with useless data otherwise)
you create as much branches as neeed - you can't harm anyone or anything - and you are not able to push that stuff out-of-the box to gitlab (you need write access for that) - there is no need to commit only relevant or promissing stuff - just create two braches: wild_ideas_stuff and the_good_ones :)
Quote from: Daniel3D on October 28, 2021, 10:25:52 AM
For research purposes, I also want [try] to disassemble Stunts 1.0 as suggested and the PC-98 version.
you won't get far if it also uses a load.exe - the parts that gets combined in memory using a different packing as 1.1 (according to dstien)
so the 1.1 way of just using the exe_combiner will not work - unclear if its is only the missing unpacker and the tool could then work
there is no game-code to reverse if you not unpack/exe_combine the code fragments - you will only see the load.exe code
(but mayber load.exe of 1.1 is compatible with 1.0? - also a interresting test)
Quote from: llm on October 28, 2021, 11:40:05 AM
there is no game-code to reverse if you not unpack/exe_combine the code fragments - you will only see the load.exe code
(but mayber load.exe of 1.1 is compatible with 1.0? - also a interresting test)
In that case I'll start that.
And if it doesn't work with disassembly of load.exe 1.0, 1.1 and the one from 4D boxing.
Who knows.
[Add]
Maybe the differences in the load.exe programs can give info to get it to work on stunts 1.0 and patch the exe combiner
Quote from: Daniel3D on October 28, 2021, 12:59:45 PM
Quote from: llm on October 28, 2021, 11:40:05 AM
there is no game-code to reverse if you not unpack/exe_combine the code fragments - you will only see the load.exe code
(but mayber load.exe of 1.1 is compatible with 1.0? - also a interresting test)
In that case I'll start that.
And if it doesn't work with disassembly of load.exe 1.0, 1.1 and the one from 4D boxing.
Who knows.
you don't need a disassembly of load.exe just the exe itself
just to make it clear: the exe_combiner tool was developed for one reason: for beeing able to disassemble the game code - its impossible without (no disassembler can disassemble runtime loaded code)
ehm, that kind of makes sense.
(I may be completely wrong here)..I thought..
Stunts.com - reads setup.dat and starts load exe with the instruction of the right graphics and sound.
Load.exe contains the game code and combines it with the graphics files. (and sound setup parameters)
Or is the graphical part of the game written and translated to the different graphics modes and stored separately, and they need to be merged to one to make a coherent piece of code?
In simple terms (as i understand). If game code is G and graphics is V (visuals)
I thought it was like GGGGGGVVVVV
But now it think its build more like GGVGGVGVGVGG 8) 8) 8)
Like I said many times, I know very little about this stuff. But I want to understand.
Quote from: Daniel3D on October 28, 2021, 02:07:17 PM
Load.exe contains the game code and combines it with the graphics files. (and sound setup parameters)
load.exe does not contain any game, graphics or sound code - its only the runtime-combiner which create the full game exe in memory (which then gets just execute like every other ordinary executable under dos) -> at this point the game exe start what directly results in a exepack uncompressed of the game further in memory and then the real game code takes over and starts to load the sound drivers given as command line parameter
you will not find any code of load.exe in skimcga.exe and the others full-blown-game-executables
I'll reread the bypassing load.exe topic. That probably will make more sense now.
About the pc-98 version. That was not written for DOS. But doesn't use load.exe either.
So I hope it can still be disassembled into ASM.
(But maybe I am saying something stupid again :P)
The game engine code should still be similar in regard to menu's right?
Quote from: Daniel3D on October 28, 2021, 10:25:52 AM
But then I will only add relevant or promising stuff to the branch. (I'm afraid it will explode with useless data otherwise)
Remember that any investigation notes are useful, even those about dead ends! Documentation helps going in the right direction, but also avoiding the same mistakes.
If you think having a separate fork is a chore, I could add you to the GitHub repository, and you can push extra branches directly there.
Quote from: dreadnaut on October 28, 2021, 07:10:20 PM
If you think having a separate fork is a chore,
I honestly don't know how to do such thing 8)
QuoteI could add you to the GitHub repository, and you can push extra branches directly there.
I'd be honoured.
Especially because half the time I barely know what I'm doing and the other half I talk nonsense.
Quote from: llm on October 28, 2021, 01:15:06 PM
just to make it clear: the exe_combiner tool was developed for one reason: for beeing able to disassemble the game code - its impossible without (no disassembler can disassemble runtime loaded code)
LightbulbFor game.exe and the separate executables for the new mod 1.0.
Did you just use execombiner to create those?
Quote from: Daniel3D on October 28, 2021, 07:29:52 PM
Especially because half the time I barely know what I'm doing and the other half I talk nonsense.
You'll need a BitBucket account then ;)
Quote from: Daniel3D on October 28, 2021, 07:37:33 PM
Quote from: llm on October 28, 2021, 01:15:06 PM
just to make it clear: the exe_combiner tool was developed for one reason: for beeing able to disassemble the game code - its impossible without (no disassembler can disassemble runtime loaded code)
Lightbulb
For game.exe and the separate executables for the new mod 1.0.
Did you just use execombiner to create those?
1. Alle the to combine files need to get unpacked with dstiens unpacker
2. The exe_combiner creates based on the different files hrd,cod,... a exe variant
3. Manually unpacke the resulting exes with unp (get rid of exepack)
4. Patch the password check with a hex editor
Quote from: dreadnaut on October 28, 2021, 08:17:44 PM
Quote from: Daniel3D on October 28, 2021, 07:29:52 PM
Especially because half the time I barely know what I'm doing and the other half I talk nonsense.
You'll need a BitBucket account then ;)
I'll make one and send you a PM in a couple of hours. (Done)
Quote from: llm on October 28, 2021, 08:36:24 PM
Quote from: Daniel3D on October 28, 2021, 07:37:33 PM
Quote from: llm on October 28, 2021, 01:15:06 PM
just to make it clear: the exe_combiner tool was developed for one reason: for beeing able to disassemble the game code - its impossible without (no disassembler can disassemble runtime loaded code)
Lightbulb
For game.exe and the separate executables for the new mod 1.0.
Did you just use execombiner to create those?
1. Alle the to combine files need to get unpacked with dstiens unpacker
2. The exe_combiner creates based on the different files hrd,cod,... a exe variant
3. Manually unpacke the resulting exes with unp (get rid of exepack)
4. Patch the password check with a hex editor
So if I understand correctly,
The makefile in the readme that is used to compile a stunts executable is aimed at research.
It adds debugging data and that is why it is so big.
I verified the contents (manually) and besides a difference in header (and a lot of stuff behind) the compiled version is exactly the same as the execombined version.
so thats a good thing.
But can somebody tell me how to make compile a clean version without debug data?
Quote from: Daniel3D on October 29, 2021, 11:05:12 AM
I verified the contents (manually) and besides a difference in header (and a lot of stuff behind) the compiled version is exactly the same as the execombined version.
so thats a good thing.
Quote from: Daniel3D on October 29, 2021, 11:05:12 AM
But can somebody tell me hou to make compile a clean version without debug data?
your are using this makefile with "make restunts-original" or "make asmorig"?
https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/makefile
the names with : behind are the target names that can be made - i think default is all
the top makefile uses then this one
https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asmorig/makefile
this defines the assembler call
ASM = tasmbox /m2 /s /zihttp://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
Page 11, "Turbo Assembler command line"
/m2 --> /m# Allow # mUltiple passes to resolve forward references (be very time consuming) - nowerdays assembler doing that per default
/s --> Source-code segment ordering (generate the code in the order in the file - not alphabetic) - keeps it very very near to the original
/zi --> Debug info: zi=ful
/zi is very relevant for your work - that means you can Debug the Assembler-Code on Source-Code-Level with the Turbo Debugger
(its part of the repo: https://bitbucket.org/dreadnaut/restunts/src/master/tools/bin/, but the very latest dos version can be found here: https://winworldpc.com/product/borland-c/5x)
its called TD.EXE or TD386.EXE
it should be possible to get rid of the Dosbox -> tasmbox.bat -> tasmx.exe call to a 16bit version of the assembler
tasm32.exe is 32/64bit able without dosbox, and the linker is also not needed to run under dosbox - only the debugger if someone want to debug under a x64 system
or should work from window if using a real 32bit system
latest tasm: https://winworldpc.com/product/turbo-assembler/5x
btw: "make clean" cleansup everything
I will have to read that a couple of times ;D
Thanks for the explanation. I'll be busy with this for a while.
But I used "make restunts-original".
What does make asmorig do?
Quote from: Daniel3D on October 29, 2021, 12:32:09 PM
I will have to read that a couple of times ;D
Thanks for the explanation. I'll be busy with this for a while.
But I used "make restunts-original".
What does make asmorig do?
asmorig only builds the pure assembler stuff
restunts-original seems to combine the original asm code with C based startup code (but all in-game routines are still original asm)
I'll try that. It only takes about 10 minutes on my laptop.
Quote from: Daniel3D on October 29, 2021, 07:13:05 PM
I'll try that. It only takes about 10 minutes on my laptop.
It would take some seconds using 32bit versions of the tools without dosbox
I want to try that. I'll will see how far I can get.
But I will probably need some help setting up.
Quote from: llm on October 29, 2021, 06:16:43 PM
Quote from: Daniel3D on October 29, 2021, 12:32:09 PM
I will have to read that a couple of times ;D
Thanks for the explanation. I'll be busy with this for a while.
But I used "make restunts-original".
What does make asmorig do?
asmorig only builds the pure assembler stuff
restunts-original seems to combine the original asm code with C based startup code (but all in-game routines are still original asm)
If I "make asmorig", then all i get are the obj filles.
To make a executable out if it i looked at the make file and with "make restunts-original" it calls an other makefile that starts linkbox
call tlinkbox /s /P- /v /js:\tools\lib\ @restunts.lnktried that in various way but always get the 808kb file.
Quote from: llm on October 29, 2021, 11:41:21 AM
/zi --> Debug info: zi=ful
Got rid of that [and even changed it to zn]. Down to 300kb for the executable [both times]. so that certainly helps. Still, it is close but not the same as game exe.
the header is 386 bits larger (to start of the game code). But at the end of the game code it is 1040 bits smaller.
So somewhere in the code 1408 bits are missing. The file runs though. No errors.
Also still unwanted crap in the last 100.000 bits.
Quote
it should be possible to get rid of the Dosbox -> tasmbox.bat -> tasmx.exe call to a 16bit version of the assembler
tasm32.exe is 32/64bit able without dosbox, and the linker is also not needed to run under dosbox - only the debugger if someone want to debug under a x64 system
or should work from window if using a real 32bit system
I have a real 64bit system, and although I have NTVDM running and can run some 16bit programs, tlink is not one of them.
Tasm32 however works super. that safes a lot of time.
EDIT ___
I analysed the compiled exe and compared it with game.exe.
Besides about 100kb at the end that is not needed the file is clean.
in game exe there is some code in near the end that is not in the compiled one.
Bits 187008 > 188423.. ???
so am I comparing the result against the wrong file?
Its, 1:30 AM, i'm getting a bit tired 8)
But I made progress.
I cleared all debugging parameters out of TASM and TLink. and now i have a clean compiled executable.
It is not perfect.
the bits I talked about in the previous post.
QuoteEDIT ___
in game exe there is some code in near the end that is not in the compiled one.
Bits 187008 > 188423.. ???
so am I comparing the result against the wrong file?
That i have located the bits in my new file. But not inside the game part but at the end of the file ...
So, maybe one segment is in the wrong location or someting...
its for an other day though.
i need sleep...
Like Daniël, I managed to compile all OBJ files out of the ASM files in the asmorig directory; however, I'm not certain on the best way to link this. I am trying to do the whole thing inside a single DOSBox, like I would do it in pure DOS, since outside, I have a GNU/Linux OS.
So is there no entry point in any of the ASM files in asmorig? In other words, can I not just link from the ASM and get a running executable? I understand from this thread that the resulting binary, if I did that, would not work because it would still be needing to be combined with the graphics. Am I right?
No, it is combined with graphics.
Restunts is based on the mcga version of stunts 1.1.
And only that version.
Changes to the code will only be available for those users. CGA, EGA, Tandy and Hercules graphics are not supported.
some notes:
Build-System:
the complexity of the build system is a tribute to the 16Bit/dosbox/win/linux base and testability (you will always inter-test different version builds
to check if the C port behaves identical and using makefiles makes it not super easy for starters but makes it a fully automatic process
to build all the variants), there are even pure C or SDL based builds possible - to manage that all with some batch-files or manually is not a good idea
- so just believe this all had its reasons, and makefiles are your daily business if working as a software developer with C/C++... code
IDA-DB/Scritps:
for users that own an IDA License analysing in IDA and using the scripts and functions lurking around are of big help - but its completely
unclear for non-IDA users why it is that good
the asm code is still not 100% analysed, it assembles but its not fully described - adding notes to the IDA database will automaticly
extend other parts of the code if IDA is able to detect dependencies - that is totaly missing when not using IDA, a C port on this level is nearly
impractiable reachable without having such a tool
for example: the porting overview html and the functions replace with Ported C code in the asm code is completely done on the fly using a IDA script - hard to
replace with something else - is just a huge recurrung process and also the making diassemblery build out of the box with TASM is done using IDA scripts - or
else these 2MB of asm would just spit out hundreds of errors
so the former life cycle was:
1. Analyse/Annotate in IDA
2. Run Scripts
3. Build
4. Port stuff to C or check behavior in Debugger to understand der Asm-Code better
5. back to 1.
that cycle is dead not using IDA - its ok, but not the best
so: there is much to see/understand in this repo - and its easy to not see what helps alot
Debug-Info:
ASM = tasmbox /m2 /s /ziQuotecall tlinkbox /s /P- /v /js:\tools\lib\ @restunts.lnk
the /v parameter of tlink.exe is the counter-part to TASMs /zi - both are needed to get debug info
and please ALL: try Turbo Debugger - its way more easy then Dosbox Debugger etc.
don't throw that stuff away - its needed for easier development
try to add a DEBUG flag or something to have a DEBUG or RELEASE build - same like the /DTARGET=original feature
@Daniel3D
you need to stop calling it "Bits", ASAP - its "Bytes" - there is no need to go the Bit-Level (1 Byte = 8 Bits) for explain findings :)
@Cas
QuoteLike Daniël, I managed to compile all OBJ files out of the ASM files in the asmorig directory; however, I'm not certain on the best way to link this. I am trying to do the whole thing inside a single DOSBox, like I would do it in pure DOS, since outside, I have a GNU/Linux OS.
you need to replace the tasmbox.bat and tlinkbox.bat files with direct calls to these tools (the batch files are only creating a dosbox-config on the fly, run the dos executable with the give parameter - thats it
speed and platforms is another reason for me wanting to switch to newer (or multi-platform) assembler/linkers
but the automatic IDA output needs TASM/MASM style and the linking for some of the builds are a little obscure (overwriting standard libs etc.) so not every normal tool can do it - best would be UASM or WASM (both Linux/Win x64) and WLINK (also Win/Linux,x64)- nasm would be great but the TASM/MASM like source is completely incompatible, but it will also currently not build with UASM/WASM or MASM due to minor syntax differences
the only real options are: using the current tools - to also get Turbo Debugger compatiblity or later use Open Watcom v2 to build on Win/Linux and use the CodeView debugger under DOS, or else your sitting in front of 2MB ~230.000lines of code and can't even set a breakpoint or watch a variable
QuoteSo is there no entry point in any of the ASM files in asmorig? In other words, can I not just link from the ASM and get a running executable? I understand from this thread that the resulting binary, if I did that, would not work because it would still be needing to be combined with the graphics. Am I right?
no, restunts is the reversed version of the complete, combined, unpacked MCGA game exe - to have that statical game exe for disassembling was the first big part of the restunts project
there is another link script
due to the fact that the asm orig stuff is differently linked then the C+asm restunts (the complete c-standard library code in asm is then ignored and linked with the original Microsoft C 1.5 libs)
Quote from: llm on October 30, 2021, 08:43:00 AM
@Daniel3D
you need to stop calling it "Bits", ASAP - its "Bytes" - there is no need to go the Bit-Level (1 Byte = 8 Bits) for explain findings :)
Haha, I wasn't sure if I was looking at bit or byte level. That was pure sleep deprivation because it it was bit level I would have seen only 1or 0. 8)
I'll edit the post.
Quote from: llm on October 30, 2021, 08:43:00 AM
try to add a DEBUG flag or something to have a DEBUG or RELEASE build - same like the /DTARGET=original feature
I wanted to know how to make without debug info.
To know if it works.
When we change something full debugging is very useful. Just trying to learn as much as possible.
and i would also replace the bin dosbox.exe with a recent dosbox-staging - it seems faster for file operations
sadly tasm32 is just the 32bit version of 16bit tasm with same feature-set, but tlink32 can only produce 32bit exes, the 16bit tlink.exe also dos executables :/
and you need both from borland or else there will be no turbo debugger compatible debug info
its a mess that all the tools of that types only support their very own debuggers
Well, I use tasm32 and that saves a lot of time.
Tlink is only one DOSBox execute (and not over 40 time's opening and closing DOSBox like tasmbox does)
So, I'm content with the setup.
Quote from: Daniel3D on October 30, 2021, 02:51:35 PM
Well, I use tasm32 and that saves a lot of time.
Tlink is only one DOSBox execute (and not over 40 time's opening and closing DOSBox like tasmbox does)
So, I'm content with the setup.
Sounds good
@Cas
You can also use tasm32 from within dosbox for speedup but it think there is a 32RTM.exe missing for doing that in the bin folder, this is not needed if tasm32 gets directly called from win 32/64 bit, i,ve got this file somewhere in my borland compiler installs, you should also use recent dosbox staging build for better filesystem speed
@All
Another idea is to use a small 32bit (not 64 bit) virtual machine windows, like XP or Win7 32bit, this way it should be possible to directly call the 16bit tlink and even the turbo debugger could work without using dosbox
Advising CAS to use Windows... ??? ::). ;D
But doing it all within DOSBox sounds reasonable.
Any ideas about using bare metal DOS or freeDOS?
I tried calling tlink from within DOS and using make but both didn't seem to work that way.
Quote from: Daniel3D on October 30, 2021, 03:56:34 PM
Advising CAS to use Windows... ??? ::). ;D
But doing it all within DOSBox sounds reasonable.
Any ideas about using bare metal DOS or freeDOS?
I tried calling tlink from within DOS and using make but both didn't seem to work that way.
Some of the tools are 16bit, like tlink and tasm that should work under DOS,FreeDos
Tasm32 could work but 32rtm.exe is missing, make.exe also needs 32rtm.exe
its a wild mixture of old and semi new tools that are needed
The only question for projects like these are "what is the most productive combination that fullfill the technical needs" because reversing or writing 16bit asm and debugging is already hard enough
And it makes no sense for nostalgic reasons to use these tools under dos, the original devlopment mostly used microsoft c 5.1, at a time when borland was the evil competitor ;)
I am pretty sure Stunts was compiled with Microsoft. Scrolling through the binary I read "MS run-time library - copyright (C) 1988, Microsoft corp"
Quote from: Daniel3D on October 30, 2021, 07:13:21 PM
I am pretty sure Stunts was compiled with Microsoft. Scrolling through the binary I read "MS run-time library - copyright (C) 1988, Microsoft corp"
No need to be just sure - it is a prooved fact because all the old microsoft compilers leave a signature in the exe, stunts got the signature of microsoft c 5.1, and the memory model is "small" because the standard c library that is linked is the one for the small memory model (binary exact)
that is also the reason for microsoft c 5.1 libs and includes in the tools folder, the c based port gets linked to this c lib, that removes the burdens to port any of the standard lib functions
Thanks. I'll be trying to get it to link and see what works faster here. And yeah, ha, ha... whenever I can avoid using Windows, I do, even if it takes twice as long. On the other hand, I do agree completely that Borland and MS were very much the same kind back then. I tend to see the binary code that comes with Stunts as one thing, like, we know it works that way, so try to change as little as possible, but it's not because of love or hate, or nostalgia, at all. If Stunts were to be made from scratch now, I would of course favour free software platforms instead.
Some modding of Stunts surely is pretty feasible. Other things would be super hard without truly understanding most of the code in it. If we have to comprehensively analyse everything, like getting it all completely to C, that would take years. But well, many things can be done without that, so I'll try to find those.
O I love cherry picking.
I've been reading the make files. Looks kinda like a batch file. Could you do the same thing with a batch file in DOS?
Quote from: Daniel3D on October 30, 2021, 08:42:16 PM
O I love cherry picking.
I've been reading the make files. Looks kinda like a batch file. Could you do the same thing with a batch file in DOS?
More or less yes, but makefiles are the standard for this at least for the last 30 years
they are some sort of declarative description with some batching features
today i would use cmake or meson for easily being multi compiler/platform able
The makefile just calls tasm to assemble the segment files all with the same parameter but different files, switching some directories and then calling tlink, doable with DOS batch, but one prevent to retype the parameters etc. 40 times or so, these param can change over development and the makefile keeps it simple, nowerdays make variants even better
Make works fine for me.
But for CAS t doesn't. But he can easily write a batch version of it and modify if needed. (Assumption)
Tasm and tlink work in dos so the whole thing be done in DOS.
Quote from: Daniel3D on October 30, 2021, 10:26:41 PM
Make works fine for me.
But for CAS t doesn't. But he can easily write a batch version of it and modify if needed. (Assumption)
Tasm and tlink work in dos so the whole thing be done in DOS.
make can run in DOS, what makes you think it doesn't, there is only 32RTM.exe missing i think, this borland make was part of the compiler suite for ages, it must work under dos, maybe not this version but at least the 16bit version
Quote from: llm on October 30, 2021, 11:10:08 PM
make can run in DOS, what makes you think it doesn't,
I thought I read it was a windows program.
Not sure, post is edited.. doesn't matter then.
Quote from: Daniel3D on October 31, 2021, 06:34:10 AM
Quote from: llm on October 30, 2021, 11:10:08 PM
make can run in DOS, what makes you think it doesn't,
I thought I read it was a windows program.
Not sure, post is edited.. doesn't matter then.
Sorry my fault, im testing it currently
my findings - make is Win only, maybe Borland C++ 3.1 contains a compatible make program :/
Program origins:
from "Borland C++ 5.x" (https://winworldpc.com/product/borland-c/5x), Version: 5.02
bcc.exe "Borland C++ 5.2 Copyright (c) 1987, 1997 Borland International"
Borland C command line compiler: Win32/64, or in DOS(Box) with 32RTM.exe
(there is also bcc32.exe available, not checked if useable for restunts)
Borland DPMI Servers (Win 32/64 provides its own DPMI Server so only needed for DOS(Box))
rtm.exe (16bit Borland/DMPI Server)
dpmi16bi.ovl (for RTM.EXE)
(needed to be able to run bcc.exe under DOS(Box))
32rtm.exe (32 bits Borland/DMPI Server)
dpmi32vm.ovl (for 32RTM.EXE)
tlink.exe: "Turbo Link Version 7.1.32.2. Copyright (c) 1987, 1996 Borland International", 16Bit runs only in DOS(box))
(there is also tlink32.exe but the 32bit version can't link DOS programs - so no option for restunts)
wlink from the Open Watcom v2 project could be used - or the asmorig builds (currently not for the C ported builds)
td.exe: "Turbo Debugger Version 5.0 Copyright (c) 1988,97 Borland International", 16Bit run only in DOS(box)
(there is also a td386.exe that could run under 32 Bit Windows (like XP, Win7)
from "Borland C++ Builder 6" (https://winworldpc.com/product/borland-c-builder/6x)
or Freeware "Borland C++ 5.5" (https://edn.embarcadero.com/article/41337)
make.exe - "MAKE Version 5.2 Copyright (c) 1987, 2000 Borland", 32 Bit only, manually patched for restunts
at fileoffset: 0x157C9 "@@@" replaced with "!!!"
\readme.txt
> Borland Make 5.2 uses MAKEFILE.@@@ as the filename for temporary inline files.
> WLINK interprets @ in a special way on the command line and will not take the
> inline file as a parameter. As such make.exe was patched to use MAKEFILE.!!!
> as the temporary filename instead.
but wlink is currently not in use (if i understand it correct)
i don't know if Borland C++ 4 or 3.1 contains a compatible 16bit version
from "Tasm 4.x" https://winworldpc.com/product/turbo-assembler/4x
tasmx.exe "Turbo Assembler Version 4.0 Copyright (c) 1988, 1993 Borland International", DOS(Box) only
from "Tasm 5.x" https://winworldpc.com/product/turbo-assembler/5x or later (can't find the binary exact version)
http://bytepointer.com/tasm/index.htm its the one with md5=8016445b7c7fdddafdf8625ef9d36a35
binary exact version is this file:
https://vetusware.com/download/Borland%205.5%20Compatible%20Turbo%20Assembler%2032%205.3/?id=11041
tasm32.exe "Turbo Assembler Version 5.3 Copyright (c) 1988, 2000 Inprise Corporation", Win32/64 only
from Open Watcom 1.8 (could be replaced with Win/Linux OpenWatcom v2 Linker - but currently not in use)
wlink.exe
wlink.lnk
wlinkd.dll
unp.exe - 16Bit DOS(box) only, Ben Castricum EXE unpacker UNP 4.11 (for unpacking "exepack"-ed exes)
https://bencastricum.nl/unp/
(alternative for Win/Linux: https://www.bamsoftware.com/software/exepack/)
Ah. I remember reading that. But that was before u started using it.
Well, I think CAS can figure it out 8)
I'll try to run something through the turbo debugger.
I have never done anything remotely like that. So I will not be hindered by any form of knowledge.
Dont forget to re-add the /zi and /v parameter or else you wont get source level debbuging, but just binary level debugging, like in dosbox
Well. I thought I just restore from backup.
I haven't changed anything in the files yet.
(Because the mount to s: script doesn't work on my 64bit windows machine, I just dumped a copy on a USB and mount that as s:)
Edit..
It seems that mapped drives are not visible if you run CMD as administrator...
QuoteI just dumped a copy on a USB and mount that as s:
that should be changed to relative pathes, i cant remember why clvn did that s: thing
Quote from: llm on October 31, 2021, 02:00:40 PM
QuoteI just dumped a copy on a USB and mount that as s:
that should be changed to relative pathes, i cant remember why clvn did that s: thing
Because the paths have to be mounted in dosbox as well every time it starts a operation.
So I guess this is the easiest way.
https://bitbucket.org/dreadnaut/restunts/src/master/tools/mount_stunts_to_s.bat
creates the "subst" drive s:
does that script not work for you?
@dreadnaut
Can you change your repo description, its not dstiens svn repo, its clvn's repo your repo is based on
Quote from: llm on October 31, 2021, 03:28:36 PM
https://bitbucket.org/dreadnaut/restunts/src/master/tools/mount_stunts_to_s.bat
creates the "subst" drive s:
does that script not work for you?
It seems to work fine in Windows but I can't access the drive in CMD. But I automatically start CMD as administrator. It should work better if I don't. (Windows logic)
QuoteBut I automatically start CMD as administrator.
bad idea, in any way :o
Quote from: Daniel3D on October 31, 2021, 05:41:00 PM
It seems to work fine in Windows but I can't access the drive in CMD. But I automatically start CMD as administrator. It should work better if I don't. (Windows logic)
Yep,
subst are per-user if I remember correctly. That makes sense to me, as you wouldn't want another use messing with your drive letters, possibly tricking you into saving files in the wrong place.
Quote from: dreadnaut on October 31, 2021, 05:52:15 PM
Quote from: Daniel3D on October 31, 2021, 05:41:00 PM
It seems to work fine in Windows but I can't access the drive in CMD. But I automatically start CMD as administrator. It should work better if I don't. (Windows logic)
Yep, subst are per-user if I remember correctly. That makes sense to me, as you wouldn't want another use messing with your drive letters, possibly tricking you into saving files in the wrong place.
Also every file thats get create only useable by administrator, thats just evil
So dereadnaut, just replace
QuoteA clone of dstien's restunts SVN repository.
with
QuoteA clone of clvn's restunts SVN repository.
dstien got no public SVN repo
Quote from: llm on October 31, 2021, 05:45:05 PM
QuoteBut I automatically start CMD as administrator.
bad idea, in any way :o
I know, bad practice. I needed administrator rights regularly for a while so it became automatic.
Quote from: Daniel3D on October 30, 2021, 02:51:35 PM
Well, I use tasm32 and that saves a lot of time.
Tlink is only one DOSBox execute (and not over 40 time's opening and closing DOSBox like tasmbox does)
So, I'm content with the setup.
Tried compiling with subst drive and tasm32 instead of tasmbox.
Tlink gave an error that seg0001 contains a 32bit something..
So tasm32 doesn't seem to work out of the box..
Quote from: llm on October 31, 2021, 09:52:04 AM
Dont forget to re-add the /zi and /v parameter or else you wont get source level debbuging, but just binary level debugging, like in dosbox
I tried debugging but something goes wrong in the setpath in dosbox. (see image below)
when i go to tools en run "td s:\stunts\restunto.exe" it loads, but it doesn't run (probably because it runs from the wrong dir)
Moving TD to the stunts dir solves it, but isn't clean.
FYI: i currently try to fix the IDA Database and port the findings over to IDA Freeware 5 (the only free, DOS-exe able version)
so that all of you can also use IDA for adding findings
Quote from: llm on November 01, 2021, 08:05:31 AM
FYI: i currently try to fix the IDA Database and port the findings over to IDA Freeware 5 (the only free, DOS-exe able version)
so that all of you can also use IDA for adding findings
https://bigsoundbank.com/UPLOAD/wav/1020.wav (https://bigsoundbank.com/UPLOAD/wav/1020.wav)
my current problem is:
the /asmorig and /asm files are generated based on one of these IDA databases (clvn only did changes in IDA and then generate the asm)
so one of the idb (game2.idb or game3_mod.idb) is the latest version - or maybe even more documented then the asmorig/asm code
its unclear what the best version is - need to re-run the script etc.
Info: it does not change anything in the resulting binaries - its only more findings, function names and comments - its irrelevant for assembly
if we are just outputing a bunch of not understand bytes or if that is a cleanly disassembled routine - its only for the viewer, not the machine
to bring back that automatism stuff is the only way ever be able to port it cleanly
checked it!
game_mod3.idb is the correct one
1. i've fixed license issues that prevents the IDA database from loading (replaced that with the freeware license)
2. run the src\idc\anders.idc script in IDA
this generates mini/minor changes in the asm/asmorig files (maybe due to a more up to date license)
and a new status.hml (just the inner timestamp changed)
next step will be to proove if i can bring that info to the freeware IDA version - with the same results
so the process still seems to work
UPDATE: i can't (easily) transfer the information into IDA Freeware 5 (the export script contains some stuff that is unknown to IDA 5)
nor Ghidra - Ghidras export-Script of IDA idb just crashes somewhere in between (need to file an issue)
Quote from: dreadnaut on March 19, 2021, 12:00:36 AMI have mirrored dstien's SVN repository for restunts to BitBucket, both to have a backup and for ease of access. I don't intend for any work to go ahead on it, but it's useful to point at files.
https://bitbucket.org/dreadnaut/restunts/
Tired of Bitbucket and Atlassian quirks, I have migrated all my repositories to GitHub for the moment. The last remaining on Bitbucket is the mirror of Restunts. Should I migrate it as well, or do we have a more official (non-SVN) place for its code at this point?
I know
@dstien put stunpack (https://github.com/dstien/stunpack) online, not sure if restunts also exists somewhere.
Quote from: dreadnaut on November 05, 2023, 12:50:14 PMTired of Bitbucket and Atlassian quirks, I have migrated all my repositories to GitHub for the moment. The last remaining on Bitbucket is the mirror of Restunts. Should I migrate it as well, or do we have a more official (non-SVN) place for its code at this point?
You made me curious.. (not that hard, I know)
What about: Gogs.. (https://gogs.io/)
Gogs is a Go-based, open-source Git server designed for self-hosting. It welcomes both public and private repositories, offering a web interface with extensive configuration options.
Its unique features include support for SSH keys and HTTP authentication and the ability to manage multiple repositories.
Quote from: dreadnaut on November 05, 2023, 12:50:14 PMI know @dstien put stunpack (https://github.com/dstien/stunpack) online, not sure if restunts also exists somewhere.
Not to my knowledge at least. But he did update stressed on his GitHub (https://github.com/dstien/stressed).
QuoteAdd option to build for DOS using Watcom compiler
I would like to also have it mirrored non-SVN-ly at some point. Maybe the cleanest, earliest version, just generated would be good to have it at several places.
Quote from: dreadnaut on November 05, 2023, 12:50:14 PMTired of Bitbucket and Atlassian quirks, I have migrated all my repositories to GitHub for the moment. The last remaining on Bitbucket is the mirror of Restunts. Should I migrate it as well, or do we have a more official (non-SVN) place for its code at this point?
Migrating sounds good -- for one, Bitbucket's online code browsing is pretty bad, which gets irritating while chatting about the code. I don't think there is any relevant amount of links from the outside world to the current repository. For the most part, it's just a smattering of references in forum/Telegram archives, plus a handful of branches
@Daniel3D and me might want to bring over.
(It's worth noting that there is a restunts clone/fork at GitHub, namely the one set up by
@xor2003 at https://github.com/xor2003/restunts . I have occasionally used permalinks to it out of frustration with Bitbucket's interface.)
Quote from: dreadnaut on November 05, 2023, 12:50:14 PMI know @dstien put stunpack (https://github.com/dstien/stunpack) online, not sure if restunts also exists somewhere.
dstien isn't the initial creator/svn maintainer of restunts - clvn is - so he never controlled the source
Quote from: llm on November 07, 2023, 06:38:29 AMQuote from: dreadnaut on November 05, 2023, 12:50:14 PMI know @dstien put stunpack (https://github.com/dstien/stunpack) online, not sure if restunts also exists somewhere.
dstien isn't the initial creator/svn maintainer of restunts - clvn is - so he never controlled the source
Yeah, I know. But dstien is traceable to an extent outside this community. I know nothing about clvn. So impossible to tell for me if he maintains a copy..
Quote from: Daniel3D on November 07, 2023, 06:59:33 AMI know nothing about clvn. So impossible to tell for me if he maintains a copy..
last change to the "official" svn server (seems to be down) from clvn is from ~2015
Quote from: llm on November 07, 2023, 01:10:57 PMQuote from: Daniel3D on November 07, 2023, 06:59:33 AMI know nothing about clvn. So impossible to tell for me if he maintains a copy..
last change to the "official" svn server (seems to be down) from clvn is from ~2015
The web version is also down. And not archived as far as I can find..
http://anders-e.com/code/browser/restunts/trunk/restunts (http://anders-e.com/code/browser/restunts/trunk/restunts)
Quote from: Daniel3D on November 07, 2023, 03:31:34 PMhttp://anders-e.com/code/browser/restunts/trunk/restunts (http://anders-e.com/code/browser/restunts/trunk/restunts)
i've got a recent svn backup
but i think that xor2003 and Duplodes fork are recent - there wasn't changes in the last years
I cloned the SVN repo in 2021, and that's where the Bitbucket (https://bitbucket.org/dreadnaut/restunts/src/master/) repo comes from. I was thinking about resiliency, seems like it was a good idea 😅
We are forever grateful for it...
I did the same with kalpen.de (JTK stunts site) in 2007, because it was at that moment the only stunts resource known to me..
The repository is receiving similar treatment... 8)
Quote from: dreadnaut on November 07, 2023, 04:08:59 PMI cloned the SVN repo in 2021, and that's where the Bitbucket (https://bitbucket.org/dreadnaut/restunts/src/master/) repo comes from. I was thinking about resiliency, seems like it was a good idea 😅
Apparently he didn't migrate it to His own GitHub (https://github.com/clvn?tab=repositories)
So in the end, where can Restunts be found now? 8)
Quote from: Cas on November 08, 2023, 08:35:56 PMSo in the end, where can Restunts be found now? 8)
For the moment it's still available on dreadnaut his Bitbucket (https://bitbucket.org/dreadnaut/restunts/src/master/),
And on Xor2003 his GitHub (https://github.com/xor2003/restunts)
I have a few copies locally as well. And now also added to the STUNTS resources (globe icon)
So don't worry. It's safe and available..
Good! Yes, I asked primarily to add it to the wiki article I made: https://wiki.stunts.hu/wiki/Restunts. If one of these goes down, please update. I'll probably mirror it to notabug.org too and it'd be nice to host a selected part as non-SVN too.
Quote from: Daniel3D on November 08, 2023, 11:54:29 PMQuote from: Cas on November 08, 2023, 08:35:56 PMSo in the end, where can Restunts be found now? 8)
For the moment it's still available on dreadnaut his Bitbucket (https://bitbucket.org/dreadnaut/restunts/src/master/),
And on Xor2003 his GitHub (https://github.com/xor2003/restunts)
I have a few copies locally as well. And now also added to the STUNTS resources (globe icon)
So don't worry. It's safe and available..
May I ask for the modified versions? For example 1.1.1 made by that you guys made? Are those opensource?
Quote from: viniciusferrao on December 11, 2023, 05:18:57 PMQuote from: Daniel3D on November 08, 2023, 11:54:29 PMQuote from: Cas on November 08, 2023, 08:35:56 PMSo in the end, where can Restunts be found now? 8)
For the moment it's still available on dreadnaut his Bitbucket (https://bitbucket.org/dreadnaut/restunts/src/master/),
And on Xor2003 his GitHub (https://github.com/xor2003/restunts)
I have a few copies locally as well. And now also added to the STUNTS resources (globe icon)
So don't worry. It's safe and available..
May I ask for the modified versions? For example 1.1.1 made by that you guys made? Are those opensource?
The mods for the Ferrari version and coloured needles are on dreadnaut his bitbucket.
As for the new original, that is merely rebuild executables. No new code.
Also, all new code is also detailed in the modifications topic.
Quote from: Daniel3D on December 11, 2023, 06:17:32 PMQuote from: viniciusferrao on December 11, 2023, 05:18:57 PMQuote from: Daniel3D on November 08, 2023, 11:54:29 PMQuote from: Cas on November 08, 2023, 08:35:56 PMSo in the end, where can Restunts be found now? 8)
For the moment it's still available on dreadnaut his Bitbucket (https://bitbucket.org/dreadnaut/restunts/src/master/),
And on Xor2003 his GitHub (https://github.com/xor2003/restunts)
I have a few copies locally as well. And now also added to the STUNTS resources (globe icon)
So don't worry. It's safe and available..
May I ask for the modified versions? For example 1.1.1 made by that you guys made? Are those opensource?
The mods for the Ferrari version and coloured needles are on dreadnaut his bitbucket.
As for the new original, that is merely rebuild executables. No new code.
Also, all new code is also detailed in the modifications topic.
Yes sure, but do we have a git repo that I can just clone and generate the 1.1.1 version with the disabled copy protection, new setup.exe and the new banner on the options stating the version 1.1.1?
I just asking that because it's simpler to keep the updates and it lowers the bar for newcomers.
Thanks.
Quote from: viniciusferrao on December 11, 2023, 08:31:53 PMQuote from: Daniel3D on December 11, 2023, 06:17:32 PMQuote from: viniciusferrao on December 11, 2023, 05:18:57 PMQuote from: Daniel3D on November 08, 2023, 11:54:29 PMQuote from: Cas on November 08, 2023, 08:35:56 PMSo in the end, where can Restunts be found now? 8)
For the moment it's still available on dreadnaut his Bitbucket (https://bitbucket.org/dreadnaut/restunts/src/master/),
And on Xor2003 his GitHub (https://github.com/xor2003/restunts)
I have a few copies locally as well. And now also added to the STUNTS resources (globe icon)
So don't worry. It's safe and available..
May I ask for the modified versions? For example 1.1.1 made by that you guys made? Are those opensource?
The mods for the Ferrari version and coloured needles are on dreadnaut his bitbucket.
As for the new original, that is merely rebuild executables. No new code.
Also, all new code is also detailed in the modifications topic.
Yes sure, but do we have a git repo that I can just clone and generate the 1.1.1 version with the disabled copy protection, new setup.exe and the new banner on the options stating the version 1.1.1?
I just asking that because it's simpler to keep the updates and it lowers the bar for newcomers.
Thanks.
no, but that is maybe not for a git but just a good old download page...
Quote from: viniciusferrao on December 11, 2023, 08:31:53 PMYes sure, but do we have a git repo that I can just clone and generate the 1.1.1 version with the disabled copy protection, new setup.exe and the new banner on the options stating the version 1.1.1?
I believe the 1.1.1 build changes are all in the Modifications branch (https://bitbucket.org/dreadnaut/restunts/src/Modifications/) in that repo. In order to actually build it, there's a makefile typo to be fixed -- see this commit in my fork of the repo (https://bitbucket.org/duplode/restunts/commits/370477d66e349452a69af72ab2b7953dbd9fea83). There's indeed some consolidation and tidying up to be done, and the GitHub migration on the horizon should be a good opportunity for doing that.
Now that I have my little repo, I've been thinking of hosting Restunts in a non-version-controlled way there. We'll soon have a direct mirror there, but yes, I want to tidy it up a little too
Quote from: Duplode on December 12, 2023, 01:33:23 AMQuote from: viniciusferrao on December 11, 2023, 08:31:53 PMYes sure, but do we have a git repo that I can just clone and generate the 1.1.1 version with the disabled copy protection, new setup.exe and the new banner on the options stating the version 1.1.1?
I believe the 1.1.1 build changes are all in the Modifications branch (https://bitbucket.org/dreadnaut/restunts/src/Modifications/) in that repo. In order to actually build it, there's a makefile typo to be fixed -- see this commit in my fork of the repo (https://bitbucket.org/duplode/restunts/commits/370477d66e349452a69af72ab2b7953dbd9fea83). There's indeed some consolidation and tidying up to be done, and the GitHub migration on the horizon should be a good opportunity for doing that.
It doesn't include the rebuild executables for the other display options or setup. But we could add those to the stunts resource copy, if the obsolete HDR, cod and other files are still there we could (re)move those out of the folder.
Speaking of drivers, it's worth mentioning that with the Restunts builds you can choose the sound driver with command line switches when launching the executable: /spc, /ssb, /sad and /smt for PC speaker, Sound Blaster, AdLib and MT-32 respectively.
Quote from: Duplode on December 13, 2023, 12:34:37 AMSpeaking of drivers, it's worth mentioning that with the Restunts builds you can choose the sound driver with command line switches when launching the executable: /spc, /ssb, /sad and /smt for PC speaker, Sound Blaster, AdLib and MT-32 respectively.
That was a reason for me to include a new setup program and stunts executable similar to the original of the game in the new original package.
Quote from: Daniel3D on December 13, 2023, 01:06:15 AMQuote from: Duplode on December 13, 2023, 12:34:37 AMSpeaking of drivers, it's worth mentioning that with the Restunts builds you can choose the sound driver with command line switches when launching the executable: /spc, /ssb, /sad and /smt for PC speaker, Sound Blaster, AdLib and MT-32 respectively.
That was a reason for me to include a new setup program and stunts executable similar to the original of the game in the new original package.
Yes, the whole point of the new `setup.exe` program is to regenerate `stunts.bat`, which is cleaver since it will replicate the old functionally, but if I understood correctly that piece of software is closed source and not part of the restunts project.
Quote from: viniciusferrao on December 18, 2023, 05:10:58 AMQuote from: Daniel3D on December 13, 2023, 01:06:15 AMQuote from: Duplode on December 13, 2023, 12:34:37 AMSpeaking of drivers, it's worth mentioning that with the Restunts builds you can choose the sound driver with command line switches when launching the executable: /spc, /ssb, /sad and /smt for PC speaker, Sound Blaster, AdLib and MT-32 respectively.
That was a reason for me to include a new setup program and stunts executable similar to the original of the game in the new original package.
Yes, the whole point of the new `setup.exe` program is to regenerate `stunts.bat`, which is cleaver since it will replicate the old functionally, but if I understood correctly that piece of software is closed source and not part of the restunts project.
It's not closed source, but Indeed also not part of the stunts code.
It's made by CAS in
free Quickbasic and I have the source, but I'm not sure if I have the latest version. It wasn't shared because it is not complete. The basically unnecessary installer isn't working yet and I had some related plans regarding car management that I wanted to include.
Personal life got in the way of continuing it though.
Included the unfinished source and a file list that was to aid in making an installer that could differentiate between game files and others.
I made Setup2 in QuickBasic to resemble the original Setup. I don't know if I put license text somewhere, but I usually make everything free software under the GPLv3... so if it doesn't have it and you need it, I can add the license text.
The original Setup is part of Stunts and it's not free software. Important thing to note: while Restunts consists primarily in source assembly code, it is not free software (or "open source"). Stunts and any derivative product are "abandonware". We expect that we'll never get a word from the copyright holders and if we do, they probably will be OK with us to continue to do what we do and maybe even we could pay to have a special permission, but in the best case scenario, it'd become freeware, not free software. Good reason to make a new engine!
Pinning this topic (now with the updated GitHub link (https://github.com/4d-stunts/restunts) in the first post!) for extra visibility.
In related news, I have moved my Restunts fork to GitHub as well: https://github.com/duplode/restunts . There you can find the mods/daf-museum-edition branch, with the UI patches for the DAF museum exposition. Next step for me will be setting up
@HerrNove 's Wine build process here.
Thanks to
@llm 's efforts the restunts code can now be built much faster (1 second instead on 1 minute). I opened a merge request in
@dreadnaut 's repo with the changes (https://github.com/4d-stunts/restunts/pull/4).
I would ask all interested devs (
@Duplode ,
@Cas ,
@Daniel3D ,
@Overdrijf ) to check it out and verify whether it works on their configuration.
i also ported from Borland Make to a recent gnu make version
please test if everything is still working/playing as expected
Excellent work,
@HerrNove and
@llm ! It's taking me forever to be able to sit down and play with Restunts, but anyway I can't wait to try the improved build process!
That's great! Restunts is regaining momentum! :D I also don't have a lot of time, really. Actually, I have never been able to build the previous one, but I understand recently you found a way to build it in GNU. If I find the time, I'll give it a try.
Quote from: Cas on December 18, 2023, 10:28:19 PM[...] and maybe even we could pay to have a special permission, but in the best case scenario, it'd become freeware, not free software. Good reason to make a new engine!
Actually I only need new track elements, btw. Here's a suggestion:
https://github.com/andmarti1424/sc-im
Because
https://matei.one/idxscr.html#download
"tracks from Stunts made in 1990 are also available but for copyright (not mine) reasons, these are not free..."
I've actually thought of creating a new set of track elements. In part, so that not only my renderer is free, but also the data it reads from, but also because my painter's algorithm is different from that of Stunts and I can't (easily) analyse how it works, so some original elements display glitches with my renderer... glitches that are dependent of the algorithm's internals. This is akin to how OpenTTD gradually became independent from original TTD graphics :)
Simutrans is better.
https://www.simutrans.com/en/
I only played them a little ~8 years ago. Very unrealistic, you can't drive any of the vehicles and no 3D graphics. Anyway, with my game you can do a lot more than with Stunts, for which you can't change the track size or use more elements (besides the cars not moving properly), so there's no reason to create a new set of track elements for Stunts, because Stunts isn't free anyway. You can just keep the current tracks.
I'm starting to add collaborators to the https://github.com/4d-stunts/restunts/ repository, so folks can work directly on it.
Let me know thoughts and concerns, and let's move slowly at the start, as we understand how the whole thing works.
https://github.com/restunts
"Not Found"
Thanks for pointing that out, link fixed, and here again: https://github.com/4d-stunts/restunts/
Quote from: Daniel3D on October 27, 2021, 12:37:40 AMASMORIG_OBJFILES = $(ASM_OBJDIR)\segments.obj $(ASMORIG_OBJDIR)\seg000.obj
should be ASMORIG of course.
Not that it matters, but this was intentional.
segments.asm was handwritten and there was only supposed to be one copy shared by
asm and
asmorig.
Quote from: Daniel3D on November 07, 2023, 06:59:33 AMQuote from: llm on November 07, 2023, 06:38:29 AMdstien isn't the initial creator/svn maintainer of restunts - clvn is - so he never controlled the source
Yeah, I know. But dstien is traceable to an extent outside this community. I know nothing about clvn. So impossible to tell for me if he maintains a copy..
Sadly his batman.no domain has lapsed, but since anders-e.com (http://www.anders-e.com/) is still up I'm assuming he's well, just busy with middle-aged life. clvn was a bit of a celebrity (https://demozoo.org/sceners/12821/) in the Norwegian demo scene in the mid-90's. I was surprised to hear him namedropped in a Norwegian podcast about Amiga music a few years back.
Quote from: llm on October 31, 2021, 06:13:42 PMSo dereadnaut, just replace
QuoteA clone of dstien's restunts SVN repository.
with
QuoteA clone of clvn's restunts SVN repository.
dstien got no public SVN repo
Indeed, clvn started and ran this project. He figured out all the bit-trickery that allowed us to rebuild working executables injected with our own code. He did the majority of the analysis and porting to C. I mostly ported low-hanging fruit and cheered on the sideline.
I appreciate the efforts to make the code public, and I have thought about doing it myself from time to time. But I also wanted to do things a bit different, modernise the toolchain, cleaning up cruft, ensuring ported code is both portable and correct, and getting rid of the blobs. Particularly the database from the program whose vendor has a history of refusing to sell to people outside the infosec clique (https://multimedia.cx/eggs/ida-pro-freeware-update/). Seeing the spectacular work of
@HerrNove on SuperSight inspired me to have another crack at it. I decided to start with a clean slate (https://github.com/dstien/restunts2) to avoid said blobs and avoid offending anyone when deleting their code. Whether the new repo should be placed under the 4d-stunts org (https://github.com/4d-stunts) or be merged with the mainline repo (https://github.com/4d-stunts/restunts) is not for me to decide, it's still an experiment.
The first order of business was to convert the ID* Pr* database to Ghidra. After discovering that Ghidra provide an XML exporter script (https://github.com/NationalSecurityAgency/ghidra/blob/master/GhidraBuild/IDAPro/Python/7xx/plugins/xml_exporter.py) for ID*, I got my hopes up. Checking the output of the script confirmed that everything we needed were included, we could just use Ghidra's XML import and this project would be done in an evening or two.
Turned out it would take over a month before I had a working
restunts.exe built from Ghidra. First the export script ignored symbols it deemed automatically generated based on their prefix. When we used names like
"arg_cheeseburger" it would be dropped (https://github.com/NationalSecurityAgency/ghidra/blob/542c2aa617990c2b2ee2ac03bb0b66943a7af760/GhidraBuild/IDAPro/Python/6xx/plugins/xmlexp.py#L1675). It's just a Python script, so it was a quick fix. Next it turned out that our
"arg_cheeseburger" wouldn't be imported at all anyway, as Ghidra's importer ignores (https://github.com/NationalSecurityAgency/ghidra/blob/e4e2e4369e68948789206055e808e44c62240232/Ghidra/Features/Base/src/main/java/ghidra/app/util/xml/FunctionsXmlMgr.java#L179) function stack frames entirely. I think the reasoning is that Ghidra prefers to trust its own analysis to build the stack frame layout, which it does with its powerful decompiler that can infer arguments and their sizes. Our problem with that, besides losing argument and local variable names, is that Ghidra's support for working with segmented memory appears to be an afterthought. While ID* was first released in 1991 when 16-bit was still dominant, and its segmented memory handling remains a first-class citizen. There are many related issues filed for Ghidra about this, and many remains unactioned for years. There seem to be a, quite natural, distance between the NSA's and the retro community's priorities. I found quite a few pull requests for issues I was having that had been rejected. The maintainers seem understanding, but they don't accept duct tape patches, instead wanting to redesign their cores to properly support the features they initially hadn't accounted for. And it appears there's just never time granted for the NSA to accommodate to nostalgic gamers.
At this point I had long since given up on documenting all the Ghidra issues I found, and just did a LOT of manual fixups. The upside to this was that I got a solid refresher on Stunt's code. The next step was to port the IDC script to Ghidra. I chose the Jython approach to interface with Ghidra's Java API. It's archaic Python 2.7 and very, very slow, but it works right out of the box, no compilation needed, and it's thus very hackable. Initially I thought reproducing TASM output like the original script would be the easiest solution. But nothing is easy. While ID*'s native disassembly syntax is more or less MASM/TASM compatible, Ghidra goes its own way. Things that are implicit in Ghidra may have to be explicit in TASM, and vice versa. When I found myself writing my own x86 disassembler in Ghidra Script in order to format memory operands with proper TASM syntax I realised we might just target a contemporary assembler. I first pivoted towards NASM (https://nasm.us/), it's widely (pun intended) available and has the best documentation of any assembler by far. But its syntax is even further out there. I eventually settled on the Watcom Assembler, whose name unfortunately now means something very different (https://en.wikipedia.org/wiki/WebAssembly). There are several modern WASM forks, but I wanted to use the whole Watcom toolchain anyway, so I settled on the original to avoid further dependency complexity.
I wanted to make patching of the generated assembly code dynamic. This is done by using the tags <REPLACE>, <INSERT>, <NOP> and <DELETE> in comments. See the README (https://github.com/dstien/restunts2?tab=readme-ov-file#setting-up-the-ghidra-script) for more details. This also proved to be a convenient crutch when my Ghidra knowledge fell short:
(https://surr.no/pub/2025-10-05-restunts_Ghidra_patching.png)
Another change is that only one set of asm files is created, instead using a build-time toggle to determine whether to wire up ported or keep original functions.
Something we wasted a lot of time on back in the day was trying to use unofficial ID* database synchronisation tools so that we could work on it simultaneously. Ghidra comes with its own server which I have set up on re.stunts.no. Anonymous readonly-connections are accepted. For those who want to contribute, send me a PM with a username and I'll add you.
I've gone back to the trusted old
wlink. This sacrifices support for Turbo Debugger, but Watcom Debugger also seem very capable:
(https://surr.no/pub/2025-10-05-restunts2_debug_tn.png) (https://surr.no/pub/2025-10-05-restunts2_debug.png)
wlink can also produce DWARF and CodeView debug data, so it may open up for even more debuggers?
For the C code I wanted to carefully pull in one function at a time from the original restunts code. Making sure everything is portable and correct. So far I've only added the good old
sin_fast() and
cos_fast(), and made unit tests for these. The GitHub repo has a CI-task (https://github.com/dstien/restunts2/actions) for building and testing, and test output can be inspected there. I haven't yet made up my mind how we'd go about testing functions with side effects. I don't know how realistic it is, but I want to see how far we can take it by only using Stunts' clib in seg010 and not link in any Watcom libraries as long as we rely on linking with the original code.
I've only tested building on Linux. Adding Windows support again will probably take some work, and I don't know if it's worth it as it probably works out of the box in WSL. There's also no proper dependency tracking for incremental building yet. Compilation is so fast that I've just been doing
rm -drf build && make so far. Which I hear is in vogue with the handmade crowd (https://handmade.network/manifesto) these days anyway.
Quote from: llm on October 28, 2021, 09:25:30 AMit would have been very easy if it was originaly developed for 32bit systems - like many other DOS games - then we could only replace the hardware access stuff and it would then run on windows/linux and we could have used todays development tools - but its just way too old :(
There
are two 32-bit builds of Stunts; FM Towns and FM Towns Marty are built for i386, using the Phar Lap 386|DOS-Extender. While FM Towns isn't DOS compatible, and these versions aren't entirely bug-compatible with the DOS versions, there's a lot of shared code that is far more pleasant to explore without segmented memory. This is where the 32-bit anecdote was supposed to end, but I wanted to add these executables to the Ghidra server repo, and since Ghidra don't have a loader for Phar Lap payloads, I had a look at the files to see how much effort it would take:
(https://surr.no/pub/2025-10-05-4D_Driving_FM_Towns_debug_symbols.png)
That's some peculiar structured information
after the DATA section... I can't believe it took 32 years for us to find out that
WE HAD DEBUG SYMBOLS FOR STUNTS ALL ALONG! It's only public symbols, no types or stack variables, but still. It's over 2000 symbols. Since the porters appears to have kept many of the original DOS funtions as stubs, we even have these names.
Here's a function in the FM Towns Marty port and DOS side-by-side:
(https://surr.no/pub/2025-10-05-restunts2_Ghidra_symbol_comparison.png)
This is a striking example showing how spot-on some of the original analysis is, how unknown data now has clear names, and how the FM Towns code deviates from the DOS code when dealing with IO. When the FM Towns code has generated labels (_DAT_addr) it's usually because it is a struct member offset, but we only know the name of the root value.
I added both FM Towns executables in the Ghidra repo with all debug symbols loaded, no further analysis. I discovered this just now, so I haven't explored the symbols in depth yet. I'm not sure if we should adopt all the original names, as some are quitehardtoread compared to our snake_case_notation.
More details on how to connect to the Ghidra server, use the Ghidra script and build is in the repo readme: https://github.com/dstien/restunts2
The problems I encountered myself already are covered in the troubleshooting (https://github.com/dstien/restunts2#troubleshooting) section.
:o I'm going to need some time to wrap my head around this... Christmas is early this year it seems ::)
As I wrote before:
https://forum.stunts.hu/index.php?topic=4257.msg92963#msg92963
Quoteif, by any chance, the Chinese government will want it done, I can assure you that it will be done.
Besides, everything that can be obtained was already. Maybe some more motorbikes would work...
This is fantastic work
@dstien , thank you so much! Can't wait to try it out! (Yes, I've been repeating this since the beginning of the year about e.g.
@HerrNove 's improvements, but hopefully I'll stop getting sidetracked anytime soon! 😅) No longer needing the IDA-centric workflows and having the 32-bit symbols as a reference should be a huge boon to analysis.
Amazing,
@dstien! 8)
Is it possible to isolate the physical engine for analysis? I feel that many parts of the code, such as the menus, file loading functions, etc., would be easier to rewrite than to port, and the graphics engine, while more significant, is the one that could use an upgrade, but the physics engine is crucial so that we can actually reproduce the behaviour, remain replay-compatible, etc. If we could work shell by shell around the physics engine, great things could be achieved!
QuoteParticularly the database from the program whose vendor has a history of refusing to sell to people outside the infosec clique.
isn't that like the myth that IDA dropped DOS support (which is only true for IDA freeware versions)
i know serveral private people that bought an IDA license - like me - without any infosec background
Quote from: llm on October 07, 2025, 10:08:55 AMQuoteParticularly the database from the program whose vendor has a history of refusing to sell to people outside the infosec clique.
isn't that like the myth that IDA dropped DOS support (which is only true for IDA freeware versions)
i know serveral private people that bought an IDA license - like me - without any infosec background
Still, the fact remains that IDA is a pain in the but, especially for those that don't use it enough to warrant a paid licence. So whatever way you look at it, the Ghidra conversion makes a huge difference.
Quote from: Cas on October 06, 2025, 11:33:59 PMAmazing, @dstien! 8)
Is it possible to isolate the physical engine for analysis? I feel that many parts of the code, such as the menus, file loading functions, etc., would be easier to rewrite than to port, and the graphics engine, while more significant, is the one that could use an upgrade, but the physics engine is crucial so that we can actually reproduce the behaviour, remain replay-compatible, etc. If we could work shell by shell around the physics engine, great things could be achieved!
If we can isolate the part that replay dump uses I think we are halfway there. Maybe there is a "live" version of that calculation but I'm not sure.
That is the hart of the game, if we understand that part fully we can hook it to CAS his graphics engine, replace the track editor with a simplified version of bliss, replace the car and opponent selection and extend the track elements library with new and exciting possibilities. (For example, add snow, sand and dirt to the grass and water terrain options).
If we don't get to understand it fully, everything except the track elements library is still possible.. 8)
@dstien https://github.com/dstien/restunts2/commit/daa05e093c3e56bfa6a7a9610173dc5db2db8cfe
will you also try to compare to the original implementation - something like int_atan2 disassembly + C port over the complete integer range or is something like that too much?
for example: some x/y combinations don't give the same result
range from x/y -1000...1000 - the list contains only different result comparing the C port and the original disassembled function
https://pastebin.com/f9nucieg
my test-code looks somway like this
const int16_t min = -1000;
const int16_t max = +1000;
for (int16_t x = min; x < max; ++x)
{
for (int16_t y = min; y < max; ++y)
{
int16_t a = int_atan2_asm(x, y);
int16_t c = int_atan2(x, y);
if(c != a)
{
printf("x=%d, y=%d -> C=%d, ASM=%d %s\n",
x, y, c, a, (c == a) ? "OK" : "!!FEHLER!!");
}
}
}
compile with current Watcom V2 on Windows for DOS 16bit Model small exe using wcl+wasm
the test run was done on a real DOS 6.22 on VMWare Player (because dosbox failed to run the complete test without hanging)
but im not sure what the defined range for these functions are
Quote from: Daniel3D on October 08, 2025, 09:44:09 AMStill, the fact remains that IDA is a pain in the but, especially for those that don't use it enough to warrant a paid licence. So whatever way you look at it, the Ghidra conversion makes a huge difference.
100% ACK
Quote from: Daniel3D on October 08, 2025, 09:55:33 AMif we understand that part fully we can hook it to CAS his graphics engine,
CAS's graphics engine is in FreeBASIC, it's slow and it's not finished. You already have a usable graphics engine which includes CAS's part that reads tracks from Stunts, converted from FreeBASIC to C.
https://matei.one/idxscr.html
https://sourceforge.net/projects/simple3d/files/SDL_grf/
Documentation of the graphical functions included. You can combine the part that renders the graphics from SimcarStunts with the part that reads tracks from Stunts, in the same program. I already fixed the 3D models to be rendered properly. Next:
Quotereplace the track editor with a simplified version of bliss,
Why not just keep the track editor out as a separate program? Much easier.
Quoteand extend the track elements library with new and exciting possibilities.
Which I actually did from the start before using the tracks from Stunts - link above and I also made some programs to edit 3D models, also there.
Quote from: Matei on October 08, 2025, 11:07:37 AMCAS's graphics engine is in FreeBASIC, it's slow and it's not finished. You already have a usable graphics engine which includes CAS's part that reads tracks from Stunts, converted from FreeBASIC to C.
You are right. Still I personally prefer CAS his approach to the graphics. It isn't finished, maybe it is to slow and would need to be rewritten in C. But it it uses a painters algoritme like stunts. And that gives the same ambiance as the original.
CAS and I share the same opinion about what is unique about the game an should be preserved. That makes it easy to work with each other. I really like what you created and i think you did an amazing job on your games. It's is not what I'm personally looking for.
So that's why my first thought went to CAS. It was not intended to exclude you from this and I am genuinely interested in what it would do with your graphic engine. But that would mean you have to accept stunts pseudo physics.
QuoteWhy not just keep the track editor out as a separate program? Much easier.
That is true, but stunts has an track editor, so we want to keep it for future players to have one game that includes all. Including a build in car manager.
Quote from: Cas on October 06, 2025, 11:33:59 PMIs it possible to isolate the physical engine for analysis?
Yes, this was the motivation for the repldump utility. We took the code path that Stunts uses when loading a replay from the options menu and processes it to the end, then ripped away as much as we could without breaking it. Simulation still requires a fair bit of loading and initialisation. The old repldump was a bit hairy since we hadn't analysed enough to properly separate the graphics, audio and input initialisation. That's why it changes video mode on startup and throws a fatal error after processing in order to stop all the interrupts. clvn did a lot of analysis and porting since, so with the current knowledge I have streamlined repldump (https://github.com/dstien/restunts2/blob/main/src/tools/repldump/repldump.c) further.
The essential part is:
// ...initialisations...
while (gameconfig.game_recordedframes > state.game_frame) {
input = td16_rpl_buffer[state.game_frame];
state.game_frame++;
player_op(input);
}
repldump is slightly more complicated because we want it to create the exact same game state as the original code, so it also handles the movement of an opponent, the cameras, explosions and FPS smoothing.
player_op() (debug symbol
moveplayer) is translated to C in state.c (https://github.com/4d-stunts/restunts/blob/master/src/restunts/c/state.c) in the original restunts repo. The inner function call to update_car_speed (
doengine) is in statecar.c (https://github.com/4d-stunts/restunts/blob/master/src/restunts/c/statecar.c), and update_player_state (
movecar) is in stateply.c (https://github.com/4d-stunts/restunts/blob/master/src/restunts/c/stateply.c). These are mostly 1:1 unanalysed ASM to C translations. I can't remember whether they are 100% complete. The other inner function calls upd_statef20_from_steer_input (
dosteering) and update_grip (
dohandling) are not ported, but these are fairly simple functions. My current focus in restunts2 is to start with the basic leaf functions of the simulation and work my way down the call stack so that all ported code is tested for correctness when it is included.
Quote from: llm on October 07, 2025, 10:08:55 AMQuoteParticularly the database from the program whose vendor has a history of refusing to sell to people outside the infosec clique.
isn't that like the myth that IDA dropped DOS support (which is only true for IDA freeware versions)
i know serveral private people that bought an IDA license - like me - without any infosec background
Hehe, true. I got a bit carried away with my bombastic parroting of blog hearsay from 18 years ago. At least now I know that 50% of my IDA licence holding friends don't work in the sec biz.
Quote from: llm on October 08, 2025, 11:04:26 AMwill you also try to compare to the original implementation - something like int_atan2 disassembly + C port over the complete integer range or is something like that too much?
That's a good idea to catch corner cases. I added an "-x" option to the DOS build of the unit tests. The full range should be INT16_MIN + 1 .. INT16_MAX - 1 (peak values crashes both implementations), but it takes an eternity to run, so I just used -0x400 .. 0x400
Quote from: llm on October 08, 2025, 11:04:26 AMcompile with current Watcom V2 on Windows for DOS 16bit Model small exe using wcl+wasm
the test run was done on a real DOS 6.22 on VMWare Player (because dosbox failed to run the complete test without hanging)
Does this include the fix I pushed the other day? Strangely I can't reproduce it on my end with dosemu2 or DOSBox. Could you attach the exe file? I'm keen to have a look.
Quote from: dstien on October 09, 2025, 07:44:31 PMQuotecompile with current Watcom V2 on Windows for DOS 16bit Model small exe using wcl+wasm
the test run was done on a real DOS 6.22 on VMWare Player (because dosbox failed to run the complete test without hanging)
Does this include the fix I pushed the other day? Strangely I can't reproduce it on my end with dosemu2 or DOSBox. Could you attach the exe file? I'm keen to have a look.
no it didn't include the fix - with the fix i only get one difference on DOS, XP/Win7(32bit) running on VMWare
on x=0, y=0 the C code returns 0, asm returns 512
(building the C code for 32bit windows results also in 0 for x=0, y=0 )
but that does only happen in the loop with x/y not when calling the routines directly with 0/0 - the result of the asm code for 0/0 seems to be only non null in the x/y loop?
FYI: comparing all values from C with x/y -1000...1000 showing no difference between a 16 and 32bit build
Quotepeak values crashes both implementations
for me the testrun just takes ages on dosbox
my Test:
this i my free-standing test (i've copied the asm and C code into the test - quick & dirty):
https://filebin.net/gw4diq3oa6l2gas2/restunts2_tests.zip
for testing speed:
im using DOS 6.22 in VMWare Player because its super much faster - compared to dosbox - just install DOS in VMWarePlayer and share Files using a floppy image in VMWare, maybe a qemu+KVM DOS is similar fast, or just a 32bit Windows OS...
to create an floppy-image using linux
mkfs.msdos -C myfloppy.img 1440
mcopy -i myfloppy.img test16.exe ::/
mdir -i myfloppy.img ::/
test
const int16_t min = -2;
const int16_t max = +2;
for(int i = min; i < max; ++i)
{
printf("[%d](x=0,y=0) a: %d, c: %d\n", i, int_atan2_asm(0, 0),int_atan2(0, 0));
}
for (int16_t x = min; x < max; ++x)
{
for (int16_t y = min; y < max; ++y)
{
int16_t a = int_atan2_asm(x, y);
int16_t c = int_atan2(x, y);
printf("x=%d, y=%d -> C=%d, ASM=%d\n", x, y, c, a);
}
}
result
[-2](x=0,y=0) a: 0, c: 0
[-1](x=0,y=0) a: 0, c: 0
[0](x=0,y=0) a: 0, c: 0
[1](x=0,y=0) a: 0, c: 0
x=-2, y=-2 -> C=-384, ASM=-384
x=-2, y=-1 -> C=-332, ASM=-332
x=-2, y=0 -> C=-256, ASM=-256
x=-2, y=1 -> C=-180, ASM=-180
x=-1, y=-2 -> C=-436, ASM=-436
x=-1, y=-1 -> C=-384, ASM=-384
x=-1, y=0 -> C=-256, ASM=-256
x=-1, y=1 -> C=-128, ASM=-128
x=0, y=-2 -> C=512, ASM=512
x=0, y=-1 -> C=512, ASM=512
x=0, y=0 -> C=0, ASM=28 <======= ???
x=0, y=1 -> C=0, ASM=0
x=1, y=-2 -> C=436, ASM=436
x=1, y=-1 -> C=384, ASM=384
x=1, y=0 -> C=256, ASM=256
x=1, y=1 -> C=128, ASM=128
the asm code returns also 0 if i rotate the calls so first C then asm or the result-value of asm changes if i disable the C call complete
int16_t c = int_atan2(x, y);
int16_t a = int_atan2_asm(x, y);
maybe im calling the asm-code the wrong way but it only fails for 1 of thousands of calls?
what i can see so far:
ax seems to be undefined if x and y = 0 in the asm routine
int16_t a;
__asm{
mov ax,0
push ax
push ax
mov ax,1234
call int_atan2_asm
add sp,4
mov a,ax
}
printf("a:%d\n", a);
return 0;
returns 1234
so the question is: does Stunts rely on this "random" behavior? and if - how to fake it in C?
- bx is not safed (could that be problematic in combination with C code calls?)
@dstien - That's amazing. Yeah, I'd like to be able to write a function that performs exactly the same and the physics engine and compare the car positions. Your porting will be a lot more optimal, of course. I just want to be able to see that I understand it and have it in my mind analytically, not just copying the code.
But mostly yes, my interest is on putting that in the core and build shells out from scratch. I wonder how much is in the core that limits what can be added outside. For example, if there are references to the current memory distribution of track elements, maybe it isn't possible to make a bigger map without modifying the core. But perhaps the required changes would be minimal. I don't know.
@Matei - I think here is a misunderstanding. I'm going to get a little philosophical here, but just to clarify... Yes, my engine is a proof of concept. I wrote it to build and see that it actually did the thing and I didn't make any effort to make it fast enough or to perfectly render things without glitches, so it's not ready be to put on a game.
Now, this unfinished nature of it has nothing to do with it being FreeBasic. Because it is a graphical engine, it is impossible to port it to C, as C has no graphics functions. What you surely mean is to port it to SDL. I don't have much interest in doing that as there are tons of SDL-based 3D graphics engines out there already. They're not bad, but why reinvent the wheel? I would like to create a new painter's algorithm based engine analog to Stunts' original and software based, like that of Stunts, that runs natively on modern systems and allows for adding some more things. That's it.
There's a difference between
translating code between two programming languages and
porting code between two compilers. Porting is about creating a source code that can be compiled with another tool chain and result in a different binary that can be run on a different platform. Translating has to do with the syntax, with the language. Libraries play no role in translation and there's no software efficiency optimisation in translating code. In terms of languages, considering the functions that are present in FreeBasic and C and their definitions, there is no superiority in one on the other. Maybe we could say FB is superior because it can do graphics comprehensively, while see cannot (as a language). In terms of the compiler, there are many C compilers, most of which have had much more work on than FreeBasic's and are likely to be more efficient, but when talking about graphics code, since C does not include that, the C compiler will just "copy and paste" from the 3rd party library, say, SDL, so if you make a game in FreeBasic or in C that uses SDL, efficiency will be the same as regards graphics.
Beyond superiority, there's a trend of preference towards the C language (syntactically) because it's more commonly used and you have more compiler options. This makes a lot of sense and I would recommend to follow suit for non-graphical projects.
Quote from: Cas on October 10, 2025, 04:52:28 PMthere are tons of SDL-based 3D graphics engines out there already.
Any example that can be used for Stunts? I mean besides the one I know about.
Quotebut when talking about graphics code, since C does not include that,
C compilers sometimes do, but using SDL is much better and also much better than what functions FreeBASIC offers. I don't understand what's your problem with SDL. DosBOX uses it as well as OpenTTD, Simutrans, TyrQuake (https://disenchant.net/tyrquake/), Fuse (https://fuse-emulator.sourceforge.net/), practically all games that work on GNU/Linux and even NetSurf (https://www.netsurf-browser.org/).
https://matei.one/idxchess.html
QuoteThe version above uses SDL for graphics, but the version for DOS/DOSBox, which is available below, uses some graphical functions available with Open Watcom, as SDL has no support for DOS.
I know what why CAS doesn't want to use an SDL, and I'll try to give a simple example.
I like to fly RC planes, and there are several kind of people who fly planes at my club.
Two main groups are,
* those who built a plane piece by piece, cut and glue and paint for months to get is just the way they want..
And
* Those who buy a whole plane, mod it and go flying.
CAS is a programmer of the first kind.
He doesn't use libraries, if he needs one he will probably write it himself.
Takes more time but is more satisfying.
Simple DirectMedia Layer (SDL) is a cross-platform library providing low-level access to hardware via OpenGL and Direct3D, supporting Windows, macOS, Linux, ...
I don't really have a problem with SDL. I think it's good. It just doesn't do what I want to do. It's good for SDL to exist because it makes a standard instead of letting tons of different libraries take over. That's a very good thing. But programming for SDL feels very different to me from programming in a language. The library takes over and you really are no longer writing the graphics code. I was a low level programmer in DOS. Now, for GNU/Linux, that's practically banned, so I try to do the closest to it that is possible and SDL is not it. SDL is not C... it's SDL. With SDL, I'd feel that I'm no longer writing programs for the OS, but I'm writing scripts for some program. "SavePNG" (or whatever it's called) -> Boom! You have a PNG file. I don't like that. Then wanting to copy and run a 2MB program and having to download half a gigabyte from the internet for it to run.... Also not my type.
Quote from: Cas on October 10, 2025, 10:28:15 PMBut programming for SDL feels very different to me from programming in a language. The library takes over and you really are no longer writing the graphics code.
Excuse me, but I wrote the graphics code with SDL more than you did in FreeBASIC.
https://sourceforge.net/projects/simple3d/files/SDL_grf/
You never looked at that. SDL has a little problem, however. It's at version 3 and if you didn't start with it at version 1 like I did, you might get some wrong ideas about it.
@Matei CAS explained his views on third-parties serveral times over the years, he don't like (someway hates) 3rd-party dependencies (and the deployment/dependecy "burden" - he preferse tiny single exe builds without dependencies - like in the old times, 40 years ago) and FreeBasic is giving him an enviroment were he can get that and still be productive - its just the way he personally wants to do coding, and he wants to do it in a Basic-Language, and he wants the FreeBasic graphics interface - even if its nearly the same as SDL (its just a tiny fraction of less functions needed to get it running)
its clear for everyone that using third-parties, install and deploy them is just as normal in professional developing buisness as drinking water, writing non trivial multi-platform applications without third-parties just don't work anymore - you can do it but no one will pay you re-inventing wheels and consuming endless time doing it
maybe CAS does not work in professional software development, in a very small (lucky) niche were he could prevent using third-parties over a very long time or he choosed that way for his hobby-time - he chooses FreeBasic because it fits his needs fully out-of-the-box
it makes no sense to argue about it - he choose it for reasons we don't see as problematic as he do
but still, he creates nice tools for the community :-*
I always want the source code to compile it myself, so that single exe without dependencies, which has a lot of dependencies, is not very useful for me.
https://drv.nu/freebasic/building/freebsd/
Besides, I already used BASIC (for ZX Spectrum) and Pascal, so I know what we're referring to. Example:
https://matei.one/oprog.html
Click on "Power on", then on "Open" and select "Civil Engineering". JavaScript required, but the emulator and all the used files can be downloaded and used offline. Also, I wrote the BASIC program with Fuse, not when I was using a ZX Spectrum; I'm not that old.
I downloaded Cas's track viewer, it worked now and it's not actually that slow. How do I look up and down?
Quote from: llm on October 10, 2025, 02:00:01 PMax seems to be undefined if x and y = 0 in the asm routine
so the question is: does Stunts rely on this "random" behavior? and if - how to fake it in C?
clvn implemented this (https://github.com/4d-stunts/restunts/blob/master/src/restunts/c/math.c#L55) by just doing
return result; before assigning any value to
result. Since this type of randomness isn't portable, I did some (probably too brief) testing and determined that AX is always 0 in the game in these situations. But now that you brought it up I started wondering whether the case could be otherwise in certain circumstances. If I recall correctly, Stunts have a type of bug where a replay can't be fast-forwarded, because the simulation outcome is different than when it's played through, indicating that there's undefined behaviour that changes when the graphics code is involved. I did a repldump batch run on 100s of replays from the Zak Stunts archive, and it turns out that atan(0/0) happens frequently. But every occurrence that I tested in-game has AX=0, for example for
@Duplode on ZCT289:
(https://surr.no/pub/2025-10-12-restunts_atan_0_0_tn.png) (https://surr.no/pub/2025-10-12-restunts_atan_0_0.png)
(The replay controls aren't redrawn on every frame, so printf debugging kinda works.)
Does anyone remember some particular replays that has the "can't fast-forward" bug? If not, I guess we should be able to find them automatically. All competition replays are supposed to finish successfully, while a bugged run would either crash or never cross the finish line in repldump.
Edit: Found a bunch of files don't register as finished in the last frame, but the only one I have confirmed with this behaviour so far is
zct244/02-ROT.RPL. Haven't found any connection to atan(0/0) though. Looks like hitting water ends the joyride in the pure analysis, while the playback let the car continue straight over the surface.
Quote from: dstien on October 11, 2025, 03:22:42 PM(The replay controls aren't redrawn on every frame, so printf debugging kinda works.)
This was a funny part in my writeup :) If you need something more sophisticated, I recommend intro_draw_text which does the job quite nicely (example (https://github.com/AlbertoMarnetto/restunts/blob/c5eddc6f81ac3c35e81636c30dff5a1640c829e9/src/restunts/c/frame.c#L1412))
If you are analysing conformance, I remind you that the ported `update_car_speed` is currently disabled (https://github.com/4d-stunts/restunts/commit/fd8b5bb97de72c3dc4c816c70a5a71bdcc4e3ae6) because it leads to desyncs (https://forum.stunts.hu/index.php?msg=96550) with respect to the original game.
Quote from: dstien on October 11, 2025, 03:22:42 PMDoes anyone remember some particular replays that has the "can't fast-forward" bug? If not, I guess we should be able to find them automatically. All competition replays are supposed to finish successfully, while a bugged run would either crash or never cross the finish line in repldump.
I have attached a collection of unstable replays, which I had assembled last time we were doing in-game experiments about this behaviour.
(Side note: While we have eventually settled on taking the fast-forward/repldump outcome as canonical, because it is the one that's consistent across machines, competitions at times were more liberal than that about unstable replays. That being so, the collection includes two examples of replays that can finish successfully on a straight in-game replaying but not on repldump: 13gutix.rpl and C232OVE.RPL.)
@dstien do you test/compare 16- and 32bit (with wcl386 on DOS or even gcc/clang on Linux?) built results of the pure C functions tests?
to make clear that they give the same results
im currently doing wcl/wcl386 for dos,clang-32/64bit,msvc-32/64bit for windows and gcc/clang on linux builds for my simple test - thanks to your switch to "fixed-width integer" makes it easy to build the code, also using clang-tidy on it :)
Another thing:
Quote from: Daniel3D on October 10, 2025, 09:20:31 PMthere are several kind of people who fly planes at my club.
Two main groups are,
* those who built a plane piece by piece, cut and glue and paint for months to get is just the way they want..
And
* Those who buy a whole plane, mod it and go flying.
With the physics I did both:
https://matei.one/ - Open Dynamics Engine
If I hadn't used Open Dynamics Engine first, I would have never known how to do this:
https://matei.one/idxscr.html - my functions
Which I didn't do so much because I absolutely wanted to do it myself, but because I couldn't get the interactions with triangles to work properly with Open Dynamics Engine.
@dstien are you interested in generators for the "magic" value tables?
creates the values for "Quarter-wave lookup table for sin_fast()"
int16_t sine_table2[SIN_STEPS + 1];
for (int i = 0; i <= SIN_STEPS; ++i) { // +1 for last 90 degree
double angle = (M_PI / 2.0) * i / SIN_STEPS; // 0 .. Pi/2
int16_t val = (int16_t)round(SIN_SCALE * sin(angle));
sine_table2[i] = val;
}creates the values for "One-octant (45°) lookup table of the arctangent in 0x100 steps + the peak"
#define ATAN_STEPS 0x100 // 256 steps
#define ATAN_SCALE 128.0 / (M_PI / 4.0) // map radians 0..Pi/4 --> 0..128
std::vector<uint8_t> atan_table2(ATAN_STEPS + 1);
for (int i = 0; i <= ATAN_STEPS; ++i) {
double ratio = (double)i / ATAN_STEPS; // x/y ratio, 0..1
double angle = atan(ratio); // radians, 0..Pi/4
uint8_t val = (uint8_t)round(angle * ATAN_SCALE);
atan_table2[i] = val;
}
and math.h based implementations that scale to the integer range of the original routines
int16_t int_atan2(int16_t x, int16_t y)
{
if (x == 0 && y == 0) return 0;
double ang = atan2((double)x, (double)y);
int16_t v = round(ang * 512.0 / M_PI);
if (v > 512) v = 512;
if (v < -511) v = -511;
return v;
}
and
int16_t int_sin(uint16_t angle) {
double radians = angle * M_PI / 512.0; // 10-Bit angle -> 0..2Pi
return (int16_t)(sin(radians) * SCALE + 0.5); // rounded
}with a maximal error of 1 (which is still more correct but not exact as stunts implements it)
cleanuped version of the math.h usage with some tests
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#define _USE_MATH_DEFINES
#include <math.h>
#include "stunts_math.hpp"
namespace math_h_test
{
#define SCALE_BITS 14
#define SCALE (1 << SCALE_BITS)
// 0x400 steps = 2Pi
#define ANGLE_TO_RAD(a) ((a) * (M_PI / 512.0))
#define RAD_TO_ANGLE(r) ((r) * (512.0 / M_PI))
#define TO_FIXED(x) ((int16_t)lround((x) * SCALE))
#define FROM_FIXED(x) ((double)(x) / SCALE)
int16_t int_sin_math(uint16_t angle)
{
return TO_FIXED(sin(ANGLE_TO_RAD(angle)));
}
int16_t int_cos_math(uint16_t angle)
{
return TO_FIXED(cos(ANGLE_TO_RAD(angle)));
}
int16_t int_atan2_math(int16_t x, int16_t y)
{
double ang = atan2((double)x, (double)y);
return (int16_t)lround(RAD_TO_ANGLE(ang));
}
int16_t int_hypot_math(int16_t x, int16_t y)
{
return TO_FIXED(hypot(FROM_FIXED(x), FROM_FIXED(y)));
}
int16_t int_hypot_3d_math(const VECTOR* v)
{
double dx = FROM_FIXED(v->x);
double dy = FROM_FIXED(v->y);
double dz = FROM_FIXED(v->z);
return TO_FIXED(sqrt(dx * dx + dy * dy + dz * dz));
}
void test_sin_cos(void)
{
printf("=== SIN/COS compare ===\n");
int max_diff_sin = 0, max_diff_cos = 0;
for (int a = -0x400; a <= 0x400; ++a) {
int16_t ref_sin = int_sin((uint16_t)a);
int16_t ref_cos = int_cos((uint16_t)a);
int16_t new_sin = int_sin_math((uint16_t)a);
int16_t new_cos = int_cos_math((uint16_t)a);
int diff_sin = abs(ref_sin - new_sin);
assert(diff_sin == 0);
int diff_cos = abs(ref_cos - new_cos);
assert(diff_cos == 0);
}
}
void test_atan2(void)
{
printf("=== ATAN2 Compare ===\n");
int max_diff = 0;
for (int y = -0x400; y <= 0x400; y += 64) {
for (int x = -0x400; x <= 0x400; x += 64) {
int16_t ref = int_atan2(x, y);
int16_t newv = int_atan2_math(x, y);
int diff = abs(ref - newv);
assert(diff <= 1);
}
}
}
void test_hypot(void)
{
printf("=== HYPOT Compare ===\n");
int max_diff = 0;
for (int y = -0x400; y <= 0x400; y += 64) {
for (int x = -0x400; x <= 0x400; x += 64) {
int16_t ref = int_hypot(x, y);
int16_t newv = int_hypot_math(x, y);
int diff = abs(ref - newv);
assert(diff <= 3);
if (diff > 1)
printf("hypot(%4d,%4d): ref=%5d new=%5d diff=%3d\n",
x, y, ref, newv, diff);
}
}
}
void test_hypot3d(void)
{
printf("=== HYPOT_3D Compare ===\n");
int max_diff = 0;
VECTOR v;
for (int z = -0x200; z <= 0x200; z += 64)
for (int y = -0x200; y <= 0x200; y += 64)
for (int x = -0x200; x <= 0x200; x += 64) {
v.x = x; v.y = y; v.z = z;
int16_t ref = int_hypot_3d(&v);
int16_t newv = int_hypot_3d_math(&v);
int diff = abs(ref - newv);
assert(diff <= 4);
if (diff > 1)
printf("hypot3d(%4d,%4d,%4d): ref=%5d new=%5d diff=%3d\n",
x, y, z, ref, newv, diff);
}
}
int main(void)
{
test_sin_cos();
test_atan2();
test_hypot();
test_hypot3d();
return 0;
}
}
and wouldn't be a if-less vec_transform not faster?
or is failed branch prediction not a problem with older CPUs and multiply is much slower
void vec_transform(const VECTOR* src, const MATRIX* mat, VECTOR* dst)
{
dst->x = ((int32_t)mat->m11 * src->x + (int32_t)mat->m12 * src->y + (int32_t)mat->m13 * src->z) >> SCALE_BITS;
dst->y = ((int32_t)mat->m21 * src->x + (int32_t)mat->m22 * src->y + (int32_t)mat->m23 * src->z) >> SCALE_BITS;
dst->z = ((int32_t)mat->m31 * src->x + (int32_t)mat->m32 * src->y + (int32_t)mat->m33 * src->z) >> SCALE_BITS;
}