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/
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!