Is there a way to find out how, what and where stunts stores temporary information.
I'm referring to the Global variables.
I can see they are set in some cases, like here at the end of seg000:
set_default_car proc far
mov gameconfig.game_playercarid, 43h ; 'C'
loc_146E9:
mov gameconfig.game_playercarid+1, 4Fh ; 'O'
loc_146EE:
mov gameconfig.game_playercarid+2, 55h ; 'U'
loc_146F3:
mov gameconfig.game_playercarid+3, 4Eh ; 'N'
loc_146F8:
mov gameconfig.game_playermaterial, 0
loc_146FD:
mov gameconfig.game_opponenttype, 0
loc_14702:
mov gameconfig.game_opponentmaterial, 0
loc_14707:
mov gameconfig.game_playertransmission, 1
loc_1470C:
mov gameconfig.game_opponentcarid, 0FFh
locret_14711:
retf
set_default_car endp
seg000 ends
Curiously, the player car is set by the four letters of the car individually.
But the opponent car id is a single value. 0FFh. (255 in decimal, but it could mean something else)
Quote from: Daniel3D on November 08, 2021, 12:20:12 PM
Is there a way to find out how, what and where stunts stores temporary information.
your question is way to broad/vague - do you mean a strategie to find that stuff or a tool?
if i understand your "question" correct - by reading the assembler code - there is no highlevel way of understanding the code/data relations
in IDA Pro there are references to variables feature but that won't help to get a good overview - assembler code is just too much able to do
crude things - so there nearly no standard way (the main reason for inventing C and the successors - assembler code is just too hard to read/follow)
What I'm after is how the settings are stored like, graphics detail, selected track, car and opponent. And all the static information that is needed when you click let's drive.
I know that it is a broad question. I can't explain it better.
Quote from: Daniel3D on November 08, 2021, 12:20:12 PM
Curiously, the player car is set by the four letters of the car individually.
But the opponent car id is a single value. 0FFh. (255 in decimal, but it could mean something else)
When selecting a opponent car all 4 id are set just like for the player.
The first is set to 0FF when no opponent is set to the first car value. This is an empty character in ASCII.
So nothing special about it.
Quote from: Daniel3D on November 08, 2021, 06:24:18 PM
What I'm after is how the settings are stored like, graphics detail, selected track, car and opponent. And all the static information that is needed when you click let's drive.
I know that it is a broad question. I can't explain it better.
you need to fully understand the code - there is no easy way - and reversed AND assembler makes that 10 times harder - because 1 line in C can be 10 lines or more in assembler
there is no easy way - except writing comments until the story is clear
thats why reversing is so damn hard - even for real developers
I will never be a real developer. Just not possible.
But I can figure things out. Often by testing my idea against somebody. Often I'm close, sometimes I am right. It's not always useful but still.
Quote from: Daniel3D on November 08, 2021, 12:20:12 PM
Is there a way to find out how, what and where stunts stores temporary information.
If you mean finding where some structure you know the layout is in live memory, a typical strategy is finding some sequence of bytes in the structure that you know for sure or can control, and which is unlikely to appear anywhere else, then use a debugger to search for it. For instance, these notes (https://github.com/duplode/stunts-cartography/blob/master/laptrace-old/instructions.txt), which describe what I used to do to get lap traces for Cartography before repldump was created, should give you an idea of how it might be done.
Quote from: Daniel3D on November 08, 2021, 12:20:12 PM
But the opponent car id is a single value. 0FFh. (255 in decimal, but it could mean something else)
0FFh fairly often turns out to actually be -1, represented in memory in two's complement (https://en.wikipedia.org/wiki/Two's_complement), and -1 is used fairly often as a special value to indicate something has not been set.
Edit: I had forgotten to mention that layouts for known structures are nicely laid out in structs.inc (https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asm/structs.inc#lines-274), or externs.h (https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/c/externs.h#lines-13) in the C code.
Quote from: Daniel3D on November 08, 2021, 08:11:54 PM
I will never be a real developer. Just not possible.
But I can figure things out. Often by testing my idea against somebody. Often I'm close, sometimes I am right. It's not always useful but still.
Im cool with that, try to come up with some smaller direct questions snd i will help were i can
Quote from: llm on November 09, 2021, 07:10:58 AM
Quote from: Daniel3D on November 08, 2021, 08:11:54 PM
I will never be a real developer. Just not possible.
But I can figure things out. Often by testing my idea against somebody. Often I'm close, sometimes I am right. It's not always useful but still.
Im cool with that, try to come up with some smaller direct questions snd i will help were i can
Haha, I will try.
In the process of replacing the entire menu I first want to build a sort of side loader.
A program outside the stunts executable that can start driving with options set there and not in stunts.
But I have no idea if it is possible without touching the game itself.
Sort of a hijack program.
So I try to find out what the requirements are for such thing.
Quote from: Daniel3D on November 09, 2021, 08:05:02 AM
In the process of replacing the entire menu I first want to build a sort of side loader.
A program outside the stunts executable that can start driving with options set there and not in stunts.
But I have no idea if it is possible without touching the game itself.
Sort of a hijack program.
So I try to find out what the requirements are for such thing.
so you want to change executable data before starting the game?
first problem: not every data is already in the correct state before starting - some routines will (maybe) change data, so it could be that your prepared data
gets just overwritten by some initialization process
I know. All car, player and opponent variables are set during startup. Also with the speedtest the record FPS is set but also graphic options like scenery off.
So that's why I chose the word hijack.
Maybe with loading a background program first that executes a script with a hotkey. Or even a console?
It doesn't add anything to the game of course. But it might give insight we can use if we want to replace the menus.
Quote from: Daniel3D on November 09, 2021, 08:47:37 AM
I know. All car, player and opponent variables are set during startup. Also with the speedtest the record FPS is set but also graphic options like scenery off.
So that's why I chose the word hijack.
Maybe with loading a background program first that executes a script with a hotkey. Or even a console?
due to its DOS nature that needs to be a TSR (Terminate and stay resident) program - also not trivial to implement (https://github.com/uzimonkey/shot/blob/master/shot.asm)
my idea is to use Dosbox as a backend to implement new stuff - this way it can be done with normal Windows/Linux - C/C++ and allows full access to the game in every stage (something like my StuntsVM but better quality) - but i don't think that you're able to implement the base for that and im too limited in time
i would call that thing StuntsBox - a Dosbox-Fork that exists only for porting/extending Stunts more easily (could be based on the Bright-Eyes project: https://github.com/Henne/Bright-Eyes) - he extended Dosbox that way that you can intercept/overwrite function calls and memory changes etc. at every position in game
or this project: https://www.reddit.com/r/REGames/comments/qmqq3g/systematic_method_to_reverse_engineer_and_rewrite/)
but that is not compatible with pure DOS - but i would throw away that burden until its pure C - then it can be again compiled for DOS
Beautifull,..
But indeed way beyond my league.
Quote from: llm on November 09, 2021, 10:50:00 AM
i would call that thing StuntsBox - a Dosbox-Fork that exists only for porting/extending Stunts more easily (could be based on the Bright-Eyes project: https://github.com/Henne/Bright-Eyes) - he extended Dosbox that way that you can intercept/overwrite function calls and memory changes etc. at every position in game
That sounds exactly like i have in mind.
But although extremely interesting, it may be easier to rewrite (parts of) Deseg and seg000. I think that the whole menu is in those two.
of course first find non symbolic offsets and the other things you mentioned.
Thanks for the info. I have a lot to read and ponder upon.
StuntsBox could be a good idea anyway, also for reverse engineering maybe?
Quote from: Daniel3D on November 09, 2021, 11:28:32 AM
But although extremely interesting, it may be easier to rewrite (parts of) Deseg and seg000. I think that the whole menu is in those two.
of course first find non symbolic offsets and the other things you mentioned.
its not too extreme - building Dosbox Staging (with VS2019) from source takes you ~20min and hook into exe starts etc is easy because
if its only the same executable the offsets never change etc.
Quote from: Daniel3D on November 09, 2021, 11:28:32 AM
StuntsBox could be a good idea anyway, also for reverse engineering maybe?
the best for 16Bit reverse engineering - hope to start that some time and do the port completey in this environment - means everyone can use there primary development system as usual
I don't think it will be ~20 minutes for me.
But I'll see how far I can get this weekend..
;D
Quote from: Daniel3D on November 09, 2021, 03:49:53 PM
I don't think it will be ~20 minutes for me.
But I'll see how far I can get this weekend..
;D
1. just install VS2019 community (with english language pack for vcpkg)
2. create a dosbox_dev folder
3. clone dosbox-staging git in the dosbox_dev folder
4. clone vcpkg git in the dosbox_dev folder
5. build and run dosbox staging from source
then you are prepared - if i ever get the stuff running :)
the masm2c project (https://github.com/xor2003/masm2c) started to use dosbox as its porting backend: https://www.vogons.org/viewtopic.php?f=32&t=84572
and Stunts and Bright-Eyes are the testing games for the maintainer
the converted asm code looks not super easy in this example: https://github.com/xor2003/Bright-Eyes/blob/masm2c/src/custom/src/snake.cpp#L87
BUT it runs on every dosbox platform and can be compiled/debugged/extended with every dosbox-able C/C++ compiler (gcc,vstdudio,xcode...)
that is the StuntsBox i've talked about - but far more developed :)
it would be a very good idea to support the author with testing etc.
Wow, that's great. Haven't had time to look at it yet. But it will be a busy weekend now ..
Quote from: Daniel3D on November 10, 2021, 11:35:08 AM
Wow, that's great. Haven't had time to look at it yet. But it will be a busy weekend now ..
more background:
1. the project uses cleanly assembleable MASM/TASM compatible assembler code as base - we've got that :)
2. parses the complete code and transform it into some assembler looking C code - mixed with dosbox for the hardware(VGA,Sound,Mouse,...)/DOS implementation
it should then run completely under Windows/Linux - still hard to read assembler like C code and still needed a dosbox backend - but then in pure 32/64 Bit :)
Well. That sounds like a good step in the right direction.
Quote from: llm on November 10, 2021, 02:53:42 PM
still hard to read assembler like C code
Is there software that can clean up C code into better readable C code?
No, because most tools do not understand the semantic and trivial reformatting isn't of help
The "hard to read" just comes from the fact that masm2c just ports the assembler code semantic using C, equally hard to read as the original assembler code
There are disassemblers that can translate assembler to "more" readable C but they are either not working good enought and most of them do not support 16bit Segment/Offset code - but even the best disassembler (IDA Hexrays ~2500$, im using that in work sometimes) - which does not support 16bit produces still can produce huge mess (that only looks nicer on first view): https://user-images.githubusercontent.com/680819/48862937-99641200-ed7c-11e8-9e0c-301ecace1cf5.png
All these tools would be fully useable if stunts would be a 32bit dos games :(
Yep. This is why, while working on the disassembled source is nice and allows for some good tricks, the new engine project is important. I have to get back to work on that. And it's true that I've been doing everything in FreeBasic, but this won't be a problem for C programmers. One reason is that between C and FreeBasic, the difference is just syntax, so the source can be perfectly converted between them keeping comments and all if you wish (because it'll be free software with the source available, of course). Another is that FreeBasic allows for plugging whatever you want to it, so C libraries and mods would work perfectly on a FreeBasic base anyway. I'm also doing the thing in a way that any graphics library can be plugged where the current one is, so even that can be changed. The idea is that the code isn't forcefully dependent on any 3rd party library.
Quote from: Cas on November 13, 2021, 02:18:30 PM
Yep. This is why, while working on the disassembled source is nice and allows for some good tricks, the new engine project is important. I have to get back to work on that. And it's true that I've been doing everything in FreeBasic, but this won't be a problem for C programmers. One reason is that between C and FreeBasic, the difference is just syntax...
But C is way more in use (millions of project compared to some in freebasic), nearly equal in syntax and useable on more platforms and got much much better compiler optimization and better IDEs, there is practical no reason not to use C ;) but i dont care if its in freebasic or javascript as long as its having the real stunts feeling
I think that the collision and physics engine are easier to write in C, it has been done before and there is a lot of info on it.
A search on the internet with "physics engine collision" gives about 10 million hits with pages of tutorials and info in c.
When doing the same for free basic, it's under 2 million and just pages with help requests.. ???
I know CAS loves freebasic for many reasons. But ... CAS, don't be so stubborn.. ;D ;D ;D
Quote from: Daniel3D on November 13, 2021, 08:15:09 PM
I think that the collision and physics engine are easier to write in C, it has been done before and there is a lot of info on it.
A search on the internet with "physics engine collision" gives about 10 million hits with pages of tutorials and info in c.
When doing the same for free basic, it's under 2 million and just pages with help requests.. ???
I know CAS loves freebasic for many reasons. But ... CAS, don't be so stubborn.. ;D ;D ;D
and there is even a very small clean C/C++ version of stunts: https://github.com/riperjack/stunts_remake (that builds out of the box under Windows/VS2017, but should easy build under linux) that uses the widely in use Bullet physic engine/and OpenGL - that project is so small that its a very good start - also for others because of the used mainstream technologies - but that would be my way to get the stuff running/not fighting with the basics - maybe its just not funny enough for you :)
It looks promising. It doesn't have a grid based world, and it is not making use of any data the stunts files can provide. Sizes are off. But it uses similar solutions for collision models and road detection if I interpret the description correct.
I see great potential in this.
I've seen some projects wanting to be sequels or free versions of Stunts, but they all seem to be trying to do something very different from Stunts. Although some of those ideas are very good, I think this differentiation is what ultimately makes them not that appealing for the community and just there for curiousity. My idea is to do something that is as Stunts as possible so that we can continue to work on top of that. If it can use the original files, as many of them, that's much better.
About C vs. FreeBasic, I do see what you guys (and many, many people) say, but there is one very strong rule in my mind for everything and it goes like this: how many people do things a certain way is never a reason to do things that way. Reasons are things like how efficient or affordable or powerful something is, but popularity has zero value. Unless, of course, popularity "is" your project (say, you want to sell a cookie, you want people to like it). Now, I won't deny C has many positive things, but to give it a number, 95% of the good things C has, FreeBasic also has and for the other 5%, FreeBasic has another 5%, a different set, that C does not. And because they're fully compatible and the differences between them are merely a matter of keywords, well...
Now to be honest, I'm choosing FreeBasic here specifically because of FBGFX, the portable graphics library it includes, that gets statically linked to my programs and is syntactically blended into the language instead of being itself a "language". This transparency and independence is what I seek. If I could have a very simple library like this one, free software, totally portable, statically linkable and not crazy big, that I can use with C, I would probably have chosen to write the engine in C to make it more comfortable for the programmers in the community current and future. And this is still open. Find the jewel and you'll get the prize ;D
Quote from: Cas on November 14, 2021, 05:37:34 PM
About C vs. FreeBasic, I do see what you guys (and many, many people) say, but there is one very strong rule in my mind for everything and it goes like this: how many people do things a certain way is never a reason to do things that way.
just keep it short - you like FreeBasic the most and dislike any micro burdens above it - simple as that :)
Quote from: llm on November 14, 2021, 12:39:46 PM
that uses the widely in use Bullet physic engine/and OpenGL - that project is so small that its a very good start -
It looks indeed promising like i said.
but upon reading further i noticed this remark by the creator:
QuoteEventually I think I'm going to implement my own vehicle class or a simple physics engine since I'm not sure if I will be able to configure Bullet so that it mimicks the physics engine of the original game closely enough.
That is an issue with main stream, out of the box physics engines. They can not do what stunts physics does. (and I dont know if they can be simplified enough to do so) so it could be that writing it from scratch is the way to do it.
Quote from: Cas on November 14, 2021, 05:37:34 PM
If I could have a very simple library like this one, free software, totally portable, statically linkable and not crazy big, that I can use with C, I would probably have chosen to write the engine in C to make it more comfortable for the programmers in the community current and future. And this is still open. Find the jewel and you'll get the prize ;D
well, FBGFX is compatible with c apparently,
How can I use fbgfx in C?https://www.freebasic.net/forum/viewtopic.php?t=28745#p274795 (https://www.freebasic.net/forum/viewtopic.php?t=28745#p274795)
Main Ingredients are:
- fbgfx lib and fbrt lib compiled for your target system (win/lin 32/64bit non/multi-threaded ... etc)
- gfxlib and rtlib headers from sources
- command line options for gcc to let it know where the headers and libs are
- reading fbgfx lib source code, because we don't document the public API or internal functions anywhere.
8) 8) Just trying to help..
here is the source: https://github.com/freebasic/fbc/tree/master/src/gfxlib2
should build from root with the correct environment using
https://github.com/freebasic/fbc/blob/master/makefile
in root folder:
make gfxlib2
should build the libs
Yes, well, I forgot to mention that fbgfx is actually written in C. I already know this. The thing is when you install FreeBasic, this library is already blended with the project and you just build your source like: fbc myprogram.bas, so you don't actually get to the linking part of the library manually or compiling it to be used separately and all that. I need to become familiar with how that works and then yes, I could just use that same library from C.
If I can eventually go a little further, I could strip some things out from it, because this is a very completely library with functions for things like alpha channel blitting and double precision coordinate line rendering, plus several other things that are not really needed for a 3D rendering engine, but I guess the library is not that huge anyway, so that could be left for later. If I get to play around with it in C, I'll let you know. I tried some time ago and I'm sure I was doing something wrong. I had problems importing/exporting the function identifiers and I must admit I didn't feel like trying to solve the problem at the moment. Not precisely a fun part of programming, but it'd be nice once I do get it working.
Quote from: Daniel3D on November 08, 2021, 12:20:12 PMIs there a way to find out how, what and where stunts stores temporary information.
I'm referring to the Global variables.
I can see they are set in some cases, like here at the end of seg000:
set_default_car proc far
mov gameconfig.game_playercarid, 43h ; 'C'
loc_146E9:
mov gameconfig.game_playercarid+1, 4Fh ; 'O'
loc_146EE:
mov gameconfig.game_playercarid+2, 55h ; 'U'
loc_146F3:
mov gameconfig.game_playercarid+3, 4Eh ; 'N'
loc_146F8:
mov gameconfig.game_playermaterial, 0
loc_146FD:
mov gameconfig.game_opponenttype, 0
loc_14702:
mov gameconfig.game_opponentmaterial, 0
loc_14707:
mov gameconfig.game_playertransmission, 1
loc_1470C:
mov gameconfig.game_opponentcarid, 0FFh
locret_14711:
retf
set_default_car endp
seg000 ends
Curiously, the player car is set by the four letters of the car individually.
But the opponent car id is a single value. 0FFh. (255 in decimal, but it could mean something else)
Upon reading some bits on replay files, they have this set stored as well and load it into memory.
So we could see from a repay file how an opponent is set.
Yep, that 0ffh is not a single byte, but the first of four. That is the way to set the car to "none" when you're not playing against any opponent. This is a static variable. Some variables are dynamic. This is common in functions inside which a variable is defined. The memory is allocated for them when the function is called and freed when you exit the function, so you won't find a location where the variable is. Still, you will find it's definition if it's initialised and you can change the value of initialisation, but you have to take into account that, if the function is called recursively, there will be many instances of the variable a different locations, so the fact that you find a definition like this does not imply that there will be a fixed place in memory where you'll find the variable.
In this case, for player and opponent car, it's static.
Exactly. But I want to make sure that we know how the game stores the opponent car. I think the easiest way is to look at how replays are loaded into memory.
Reading the code, of course, is the only source to the truth, ha, ha. I often give you my guesses on how something was probably done because it's quicker that way and I've worked with similar tools in the past and programmed that way, but you always get surprises when you get to the source code.
What I know is that there is a memory region in which all the paramaters from the simd field in the RES file are loaded in the same order, as a single block and I've used that to make the needle colour mod. I assume exactly the same thing is true for the pipsqueak's car and it makes sense to also think the 3D shapes of both cars as well as their dashboard graphics are also kept in memory all the time during the game until you switch to another car. This means that, if you just change the car ID of one car in memory, not much will change. You have to load all car files.
Quote from: Cas on October 20, 2022, 01:30:33 AMit makes sense to also think the 3D shapes of both cars as well as their dashboard graphics are also kept in memory all the time during the game until you switch to another car.
I know that is not true. In the showroom only the res file data and the shape that is needed are loaded, not the whole car. The car is set, but only in name. The car is loaded when you actually start driving.
So if you change the name in memory before you press let's drive the new care is loaded.
Oh! I didn't expect that! Very interesting