Disclaimer: this post is subject to change.
I have a dream.. and as with so many of them I lack the time, knowledge and skill to make it happen by myself.
But I asked around and the idea is solid, it can be done, but it is a lot of work.
There are two phases in this project.
- Dissecting a specific part of the game code containing the main menu and its i/o
- Replacing that part of code with newly assembled code.
The first part connects to the restunts project and we can continue on that base.
The second part will be mostly assembly programing on the back of CAS (sorry dude, more work)
Because phase one has a lot of unknowns, I can not be sure if we can reach phase 2.
Me, Duplode and CAS think it will be great and will get started.
Do you want to know what it's all about?
(I'm hesitant to tell the exact plans here because i'm not sure what is possible and how much can be done)
But if you opt in you'll get full disclosure, and you'll know why I'm hesitant.
This journey should not be started if you only care for the end goal and not the adventures along the wayBut anyone is welcome to travel with us.
To get a feel of what you'll be facing, check http://forum.stunts.hu/index.php?topic=3714.0 (http://forum.stunts.hu/index.php?topic=3714.0)
Well, that's a vague manifesto :P Here are some vague considerations.
I've long been of the opinion that if there is a future where Stunts evolves into a different software, that's a future in which we have understood the game engine, rebuilt its source code, and brought it forward into a modern package that supports higher resolution, long rendering distance, shadows and fancy graphics in general. But the game feeling stays precisely the same. Think about what source port (https://en.wikipedia.org/wiki/Source_port) have done for Doom or Quake for example. Any other game or engine that tries to be Stunts but is not Stunts at its core, will not succeed in holding the attention of the community. Very few people want a remake, and that's why remakes fail.
Alas, we start without sources, and that's a giant obstacle. It could be worth looking for them again, contacting people, investigating and asking around. The internet has changed, and the treasure hunt could attract people. In the meanwhile, reverse engineering takes time and patience, and as we age we might gain the latter, but it's difficult to make Stunts a priority.
If you chaps are renewing the effort in that direction, that's great news! My suggestions would be to document everything as the project evolves. Hopes, small steps, obstacles and breakthroughs—in public. The more information is out there, the easier for interested people to discover it, get involved, and bring help. It is also a project for the ages; you are not the first to start on its path, you might or might not be the ones who complete it.
I'm sure there'll be plenty of support, even if it's just infrastructure or cheering ;D
Quote from: dreadnaut on May 24, 2021, 06:59:39 PM
Well, that's a vague manifesto :P
You are absolutly right, I made it less vague.
It is a relative small part that could make a lot of difference.
Could make gtaman's april fools joke partly reality..
Well, I've been pretty busy these days and will continue to be. Even CarWorks is taking me time. I was able to complete the difficult part of it, so now other features will be easier to implement, but it's still lacking many things, so I have to dedicate the little free time I have to it.
On the other hand, what Daniel wants to do would be of significant importance among the projects in the community. From what we have been talking, I could say it's the opposite approach to that of my engine, or kind of. I know what Restunts is about, but I don't know the code in enough detail to be sure about whether the parts that are required for this have already been tackled. Essentially, if I understand Daniel correctly, the right approach would be to "detach" the code that's at the main menu screen in Stunts from the rest of the executable and then place new code there, reconnect the cables and turn the machine back on. The new code would, however, include sockets where plug-ins could be directly, well... plugged. This new code could itself be a menu or could be just a "lobby" and the new menu would be a plug-in that may or may not resemble the original one. Plug-ins would have to be aware of the memory structure in Stunts or else, the "lobby" would have to do that and provide some kind of an API. Of course, all plug-in code would be real-mode x86 code, but, while the "lobby" would have to be assembly, the plug-ins don't have to. They could be any compiled executable program, as long as they are real mode.
I tried to explain to Daniel how immense this work would be, but he's got a lot of enthusiasm and optimism and I think anybody with a such a view should be supported. So yes, if the project moves forward, I'll see where I can get some time and you guys can count on me.
Quote from: Daniel3D on May 24, 2021, 02:12:30 PM
- Dissecting a specific part of the game code containing the main menu and its i/o
- Replacing that part of code with newly assembled code.
that could become a hell lot of work - and i would not add new assembly code - link c code objs into the game (thats how the restunts porting is done)
you need to know that stuff very much in detail - 16bit assembler, dos memory segmentation, ... etc. if you use assembly
would be better to further/finish port restunts to C - but that will also costs month of hard work :(
its also possible to involve (testing etc.) yourself in the https://github.com/xor2003/masm2c project - its an converter for the assembly to "functional" equaivalent C code - the author uses restunts as testbed, maybe he needs some help in testing etc.
Quote from: llm on May 27, 2021, 08:59:25 AM
that could become a hell lot of work - and i would not add new assembly code - link c code objs into the game (thats how the restunts porting is done)
you need to know that stuff very much in detail - 16bit assembler, dos memory segmentation, ... etc. if you use assembly
We were thinking about disassemble the code into flat assembly with Fasm and replacing the relevant part (as little as possible) with new assembly code (By CAS)
that seems sensible, it keeps most of the game code unaltered and increases the chance of success.
The restunts project has done a lot of research already and I did opt to continue this project on that basis (not knowing how its done) so it may well be easier to continue in C.
Don't know at this moment. But thanks for bringing this up.
Quote from: llm on May 27, 2021, 08:59:25 AM
would be better to further/finish port restunts to C - but that will also costs month of hard work :(
I fear that will overshoot the goal of the project. It is supposed to be a small surgical operation to increase chance of success. (but the idea is now on the table)
Quote from: llm on May 27, 2021, 08:59:25 AM
its also possible to involve (testing etc.) yourself in the https://github.com/xor2003/masm2c project - its an converter for the assembly to "functional" equaivalent C code - the author uses restunts as testbed, maybe he needs some help in testing etc.
Thank you. I'll look into this.
On a side note, llm will you join the project? Your knowledge of the restunts project and the game in general would be very valuable to us.
This is indeed a ton of work, like something to take years, really.
I mentioned Flat Assembler because it's the best assembler I know and it allows you to concentrate on instructions and not have to deal with too many directives unnecessarily. But if the code has already been extracted in another assembly format, it would be a whole lot of additional and unnecessary work to translate it if it can already be compiled.
Inserting a piece of code can be done by creating a C function, but it would be a very low level function because it has to be aware of all the pointers in the code if it's going to be the place where other mods are plugged, so it's almost the same as assembly. If this part of the program is already translated to C (I mean, the lobby/main menu), then it could be done in pure C. If it hasn't yet been translated, we could try to translate that part to C or we could just make an assembly routine and plug it there. It wouldn't be very difficult for that particular part because it's the simplest bit of the whole code. The difficulty lies in how it connects to everything else.
Quote from: Daniel3D on May 27, 2021, 10:24:49 AM
It is supposed to be a small surgical operation to increase chance of success.
On that matter, a little piece of success. But it is low-hanging fruit.
The information was there already, it could have been done in 2009 if anyone had been interested in it and looked for it.
http://forum.stunts.hu/index.php?topic=3762.0 (http://forum.stunts.hu/index.php?topic=3762.0)
Really, there's a lot that can be done with the level of knowledge we currently have about Stunts. We can move further in learning, but I think we haven't been doing as much as we could already!
Quote from: Daniel3D on May 27, 2021, 10:24:49 AM
We were thinking about disassemble the code into flat assembly with Fasm and replacing the relevant part (as little as possible) with new assembly code (By CAS)
that seems sensible, it keeps most of the game code unaltered and increases the chance of success.
1. you
can't disassemble the code with "Fasm" - its just a assembler not a disassembler - and linear-sweep disassemblers like ndisasm does not work very good with the stunts code - nor is the resulting assembler notation to Fasm, IDA Pro (and maybe Ghidra) is the only choice for disassembling - and sorry the free version of IDA will not work with 16 bit DOS exes (only the old freeware version 5)
2. the code was
already and working disassembled more then 10 years ago - the asmorig folder contains the assembler-code that creates a (or did last i checked) a binary identical game.exe - in complete around 230.000 lines of assembler
its in TASM/MASM style - second most used assembler out there
3. the c-code is much easier to read (but not as pure original as the asm-code) but the asm code is and will be become easily 10 times more code compared to the C version
4. you can't port that code easily to windows or something more 32 bit so you need to stay with the old gibberish dos tools of that time - very hard itself
->i've started to port the asm over to a more recent assembler called UASM that is pure 32/64 bit hence no need for DOS for development tools - still a DOS exe result
but my spare time is just too limited currently
QuoteOn a side note, llm will you join the project? Your knowledge of the restunts project and the game in general would be very valuable to us.
sorry my spare time is too limited - but i can answer any question related the restunts project
tip: first you should build the pure asmorg stunts exe - everything is described in the repo - you should lower your goal if that becomes in any way a obstacle for you and your team :)
my big hope is the masm2c project - it will finally converts all the asm in asm-like C code buildable under win32/64,linux and then everyone can use their prefered IDE and debugger to help porting - currently you need to use DOS tools and that itself is such a annoying burden
Quote from: llm on May 31, 2021, 09:23:02 AM
1. you can't disassemble the code with "Fasm" - its just a assembler not a disassembler
I realized that to. I can't program myself, so there is a lot I don't know. But among all the crazy things I come op with, sometimes they are really good.
So I accept that I occasionally miss the bat.
Quote from: llm on May 31, 2021, 09:23:02 AM
2. the code was already and working disassembled more then 10 years ago
I've been going through the asm-code this weekend and i'm getting the scope of what is already done. And it is impressive.
Quote from: llm on May 31, 2021, 09:23:02 AM
3. the c-code is much easier to read (but not as pure original as the asm-code)
Although I can not write code, I can read it reasonably well. I have no problems with asm so far.
Quote from: llm on May 31, 2021, 09:23:02 AM
4. you can't port that code easily to windows or something more 32 bit so you need to stay with the old gibberish dos tools of that time - very hard itself
->i've started to port the asm over to a more recent assembler called UASM that is pure 32/64 bit hence no need for DOS for development tools - still a DOS exe result
but my spare time is just too limited currently
I am looking for people outside the community that like to reengineer games. (no luck so far though)
Quote from: llm on May 31, 2021, 09:23:02 AM
QuoteOn a side note, llm will you join the project? Your knowledge of the restunts project and the game in general would be very valuable to us.
sorry my spare time is too limited - but i can answer any question related the restunts project
Whatever you can share is more than welcome.
Quote from: llm on May 31, 2021, 09:23:02 AM
tip: first you should build the pure asmorg stunts exe - everything is described in the repo - you should lower your goal if that becomes in any way a obstacle for you and your team :)
I put CAS on the technical stuff. As for the goal. We are setting up base. Looking at how things are connected. We have several goals depending on what we find.
The Ferrari edition was on the table from the start. That was easier than expected. But I knew that would be possible.
Adding a new menu option, a extra button will be mush harder i think. Well see.
Quote from: llm on May 31, 2021, 09:23:02 AM
my big hope is the masm2c project - it will finally converts all the asm in asm-like C code buildable under win32/64,linux and then everyone can use their prefered IDE and debugger to help porting - currently you need to use DOS tools and that itself is such a annoying burden
That would be assome. That would make changes possible we can now only dream of..
I'm comfortable enough to work on pure assembly, especially DOS assembly code. Only problem is it's a huge lot of code and I'm in one of the busiest periods of my life. I have to learn to understand the directives, but that shouldn't take long
I think it's not necessary to perform a comprehensive analysis of the whole code to be able to work on it. I would concentrate in identifying how the original compiler stored local variables in functions and where it put the global ones. The MZ model is important too, because it will tell us how the position of the different memory segments can vary in case there's any code that assumes a location, but I don't think this is the case because Kevin Pickell once said everything but the 3D rendering (and perhaps collision) engine was made in C. Local variables of routines that we don't want to change can be left alone. With all that identified, we can make a "list" of the points the the program where global variables are accessed and also, local variables of a focal routine, such as the main menu, for instance, could be taken into account. With this, the code could be pretty cleanly separated from this function that would then be replaced by a mod dispatcher. It is complex, but it's not as huge as it seemed at first.
Another thing I'm seeing now is this same procedure could allow for converting the functions one by one to 32 bit code and replace the memory accesses accordingly, since each function almost never will access other segments except for falling other functions. Video memory access can be redirected to a buffer that can then be processed by a native function for each system. In other words, the code could be ported without having to really translate it or even go through a C-phase. I'll try to find a moment to dig more into it.
Quote
I have to learn to understand the directives, but that shouldn't take long
there are nearly no to none highlevel directives in the code - should be very easy comming from other assembler syntax
QuoteI think it's not necessary to perform a comprehensive analysis of the whole code to be able to work on it. I would concentrate in identifying how the original compiler stored local variables in functions and where it put the global ones. The MZ model is important too, because it will tell us how the position of the different memory segments can vary in case there's any code that assumes a location, but I don't think this is the case because Kevin Pickell once said everything but the 3D rendering (and perhaps collision) engine was made in C.
nearly everything is ready analysed in the asmorig code - even with names for the variables
this is the complete source that builds out of the box (using the Readme to understand how) which will produce a nearly binay exact version of the game
https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asmorig/
it sounds sometimes a little like you all want to skip that code - but maybe its just my interpretation
month of hard word were invested to reach that point - and there is even a IDA pro file that can be further added with new findings
the current state was done in a very professional manner:
1. using the original game.exe from the combine process and IDA Pro to analyse the game
2. changed the IDA assembler output to get the same binary results (100% identical to game.exe after reassembly)
3. a script that splits (automaticaly) the asm code into segments for easier porting/understanding
4. another part of the script generates source that combines with the c code
-> that means every change in the IDA Pro analyse database will be automaticaly reflected in the asm output
the more analysis, findings, renames etc is done the better the asm output looks
(around 3 Month of hard work of 2-3 developers)
so in short
game.exe -> IDA Pro -> IDA Script which creates
1. splitted into segments based code that reassembles to the very original game.exe (compared on byte-level with orginal segments) (src/restunts/asmorig)
2. the version that mixes the original Asm with C and the MSC 1.5 stdlib () --> src/restunts/asm
and the build is handled with make/batch-scripts
all i want to say is: please all, look first at what others have done already very professional
or related to your "menu" stuff - just search for "menu" in the asmorig code and you will see
Quote
Another thing I'm seeing now is this same procedure could allow for converting the functions one by one to 32 bit code and replace the memory accesses accordingly, since each function almost never will access other segments except for falling other functions. Video memory access can be redirected to a buffer that can then be processed by a native function for each system. In other words, the code could be ported without having to really translate it or even go through a C-phase. I'll try to find a moment to dig more into it.
could become hard - there are >700 functions, all segment registers are in use everywhere, so not only ds-register is responsible for accessing the data, offset calculation that is relative to its adressing segment etc. - not that easy
the C-phase solution (or what masm2c does) is more a way to get the complete game into a todays IDE/debugger - because there the changes are easy and much better to test (regression tests etc.) the DOS environment is just too limited for 230.000 lines of assembler to port- without introducing too much new errors
Quote from: llm on June 01, 2021, 08:05:39 AM
https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asmorig/
it sounds sometimes a little like you all want to skip that code - but maybe its just my interpretation
This part I had not found yet correction, it was what I've been digging in. We are very happy with the quality of what you have done. But for me it is very difficult to see/understand how much is done.
I believe I have read all the relevant information about it. But it's tough reading for a noob.
Quoteall i want to say is: please all, look first at what others have done already very professional
or related to your "menu" stuff - just search for "menu" in the asmorig code and you will see
That is exactly what I did. But in a few segment, not in the code yet.
The hard coded Countach I found with "set_default_car". Was nicely marked with notes as well. (thanks to Duplode for the hint in this direction)
Edited: extensivly because of failing memory.
Quote from: Daniel3D on June 01, 2021, 08:25:47 AM
We are very happy with the quality of what you have done. But for me it is very difficult to see/understand how much is done.
I believe I have read all the relevant information about it. But it's tough reading for a noob.
its a huge project even for very professional developers that do that stuff or system programming on daily basis
to reverse some algorithm is one thing, reverse a complete project or change parts of it is a complete different thing
the biggest problems are non-symbolic references (like non named offsets etc. in asm code) that forces you to keep the binary layout very near to the original
or else you will get hard to understand random bugs - but without a development background its nearly impossible to have an understanding of what that mean for debugging/bug fixing :o - i don't how much relative offset based code is still in there - that means for example adding code add the end is mandatory (or right before the stack)
problem ares: you are a noob and CAS did't not like industrie norm development ::)
I really have barely looked at the code at this point. This last month, I've been very busy and I'll be getting even more busy in the following weeks, so I really can't judge what has been done, even if I wanted to. I can only post about what comes to my mind and the things I imagine that I can do, but of course, I can't do anything in the end without first really digging in the code and seeing what has been done and how and what is pending, etc. To be honest, I don't know when I will be able to really sit down and do that... or rather, move my chair to my desktop computer and do that, because I've been spending the whole month sitting in front of my employer's laptop, ha, ha.
While I am a fan of FASM and I have never used another assembler to program (although I have read code in other assembly formats before), I don't really think there'll be a problem other than I will have to first learn the structural directives and try assembling the whole thing a couple of times to make sure I understood the thing well before touching anything. Believe me I don't want to skip any comprehensive analysis that has already been made. That's the most important part of what has been done! (and what takes the longest). Interpretation of variables and functions, where they are and what they do is precisely the single most fundamental part of the work and what I would like is to make sure this is complete in the parts of the code I'm going to touch, to prevent things like what llm describes. If any unlabeled offset or function call is found, I can't touch that until I know what that is. But if a function makes reference to local variables, I don't need to know what they are if I'm modifying a function somewhere else in the code. That's what I mean. So, looking at what has been done, I would be able to surgically unplug and plug something in the place of a single routine.
About the C part, this is another part of the project. It's very good that it's being done, but I really can't help myself from it at this point. But I see that the original assembly code is there nice and clean, separate from the C, so it shouldn't be any problem if I just work on the assembly. That's what I understand.
It's very difficult to define norms when a work is non-commercial, ha, ha. We really can do whatever we want. Programming has always been a hobby for me and, since I work alone, I don't try to follow any trend. I just do the things the way that I feel is more convenient, comfortable and elegant to my own taste. I could as well just call what I do my "norms". Of course, I do not intend to do anything on the code that will stay there and later, bring a hell to you guys. I would just use the code to do something completely separate from the project. In fact, I have been considering the option of doing the "plugging" in memory instead of compiling it... that is... a TSR. But I'm not convinced about that.
Slightly off-topic
On that, I've been looking for a good way to be able to make graphical programs in C and I'm kind of stuck. People quickly throw 3rd party libraries at me and they are usually unnecessarily large and complex, with external dependencies and requiring object oriented programming to use them. There is also the option of going down to XLib, but that would make my programs GNU/Linux-only. I would like to investigate the code of FBFGX, the library that comes with FreeBasic. It is portable, so if I understand how the core of the library works, I could make my own tiny portable core and work on top of that. I really only need something that can take a memory buffer to a graphical window. I can write the primitives myself. Anything much bigger than that is too much.
Quote from: Cas on June 02, 2021, 12:32:05 AM
On that, I've been looking for a good way to be able to make graphical programs in C and I'm kind of stuck. People quickly throw 3rd party libraries at me and they are usually unnecessarily large and complex, with external dependencies and requiring object oriented programming to use them. There is also the option of going down to XLib, but that would make my programs GNU/Linux-only. I would like to investigate the code of FBFGX, the library that comes with FreeBasic. It is portable, so if I understand how the core of the library works, I could make my own tiny portable core and work on top of that. I really only need something that can take a memory buffer to a graphical window. I can write the primitives myself. Anything much bigger than that is too much.
1. use SDL1 or SDL2 (https://en.wikipedia.org/wiki/Simple_DirectMedia_Layer) - its C code - no OOP - it is in use absolutely everywhere - a ton of tutorials around the internet (even for FreeBasic)
2. do not fall into the not-invented-here syndrom when 3rparties are needed - they are not that evil and also in no way reponsible for any complexity in "your" code
3. wrap the code in free basic like function names, put the stuff into a different compile unit and thats it - nothing to argue
4. every idea of writing a small, fast and good portable lib yourself will just fail ultimately, thats the reason for SDLs existence
5. don't distract yourself fixing everything "around" your target goal
6. this is the way it works with everything except FreeBasic - assimilate yourself :)
7. im in businness for +30years, written some million lines of code and never get in any trouble using 3rd-party - so whats the point
8. prevent them if possible, but don't fight them for unrelevant or emotional concerns
Quote from: Cas on June 02, 2021, 12:32:05 AM
About the C part, this is another part of the project. It's very good that it's being done, but I really can't help myself from it at this point. But I see that the original assembly code is there nice and clean, separate from the C, so it shouldn't be any problem if I just work on the assembly. That's what I understand.
that means 5-10 times more bug prone, non portable assembler lines of code because you don't want to read/write C code? hard to understand
I don't think it matters much if we work with assembly or the c code.
But I thought the game was not completely ported to c yet. And therefore we couldn't change in the c code anything until the game was fully ported.
My main goal with this project is understanding the way that the game is designed. Reading this Inc or assembly does not matter I think.
Changes I'm proposing to make are very small. And as a way to learn more. I'm hoping that this will help in creating a better port to c.
Then real changes can be made.
Of course, my understanding of the matter is rudimentary at best, so I could be wrong.
We did get a nice Ferrari edition this way though, and I am really happy with that.
Quote
I don't think it matters much if we work with assembly or the c code.
only a non-developer can write such a sentence without being embarrassed at all :)
do you know that assembler is at least 5 times more code then the equivalent C code? and the possiblity to make errors is much larger
Quote
But I thought the game was not completely ported to c yet. And therefore we couldn't change in the c code anything until the game was fully ported.
when your team understands how restunts does the C linking it is possible to introduce your new code as C code - also combined with the asmorig source
but that means you all need to understand and read that stuff - the docs etc. - decide to do it the one or other way only based on the current knowledge is
not very sensfull - and there is a need to learn much if you try to work on a reverse engineering project - its just much much more harder then C or normal/typical written assembler
and you need to become familiar with the tool-chain also - the assembler, linker etc. - it is not just a simple DOS program based on assembler, its an reversed DOS program with many more constraints/problems as a typical assembler code would have
Quote from: Cas on June 02, 2021, 12:32:05 AM
But if a function makes reference to local variables, I don't need to know what they are if I'm modifying a function somewhere else in the code. That's what I mean.
that works only if you add the new code at the end of the binary - or else you're changing - because of the different function size when doing changes , the binary layout behind, resulting in damaging all non-symbolic non-relativ offsets after that changed function - and you will then hardly understand why you getting randomly crashe etc.
and that can even happen if you make +- 1 byte changes
so first thing would be to find out if there are still evil offsets like that, i don't know
and that is something that does not happen at all in a typical/normal written assembler program that didn't come from reverse engineering
Quoteonly a non-developer can write such a sentence without being embarrassed at all :)
Guilty. But it has led to beautiful things in the past.
Quote
do you know that assembler is at least 5 times more code then the equivalent C code? and the possiblity to make errors is much larger
I do know. And I am aware of the limitations.
That's why we haven't made any alterations to the source so far besides directly in the binary so we would not risk any offset.
Quote from: llm on June 02, 2021, 11:31:04 AM
so first thing would be to find out if there are still evil offsets like that, i don't know
I am curious about that one as well.
I am wondering. And I am well aware that;
Quote from: llm on June 02, 2021, 11:17:19 AM
only a non-developer can write such a sentence without being embarrassed at all :)
Can it be that (because everything besides the game engine is written in c) there is no evil offset in the code and that the parts that were written directly in assembly are well contained?
I realize that when the game was developed the compiler would manage the offsets when it was recompiled after a change.
So a change in the originally c coded part can still influence the assembly written engine. But that is something I would like to test.
I'm still talking about minimal changes. But I hope that it will inspire people into joining the restunts project and help in the full port to c so that one day we can really upgrade the game. (hopefully including better graphics)
Quote
Can it be that (because everything besides the game engine is written in c) there is no evil offset in the code and that the parts that were written directly in assembly are well contained?
I realize that when the game was developed the compiler would manage the offsets when it was recompiled after a change.
So a change in the originally c coded part can still influence the assembly written engine. But that is something I would like to test.
it "could" be that, because of the very old MSC 1.5 compiler that was use building stunts, there isn't much optimization (like generated by todays compiler) in the C based executable code parts - and the original handwritten assembler would not use dirty tricks (it think) - so yes you can be right with your assumptions
Well... there's one thing I am not at all good at for sure and that's making my point clear with only a few lines. I always feel like I'm not being clear enough and write more and more and then people reach wrong conclusions. I'm going to try. It won't be very brief, but at least, orderly and each point synthetic:
- Yes, I'm aware that moving the code can break it if there are references to the code itself that have not been accounted for. I think I have mentioned this problem early in this thread.
- I do think Daniël's guess is probably right, which is not the same thing as assuming that to do my work. I think he doesn't assume that either. Because the code was originally C (mostly), likely it doesn't have (many) tricky references to itself
- Your work is very professional, no doubt. Mine is not. This is not my profession. It's my lifelong hobby. That's why I do it my way. I won't force anybody else to do it my way. My main objective is not to just complete the program, but to enjoy making it. If I can't enjoy making it, I don't do it. This is not meant to be rude, just synthetic and clear. I hope you understand.
- "The way it works" is relative. It's the way some people do it. They may be many, but that doesn't mean the rest is wrong. When the first few people thought the Earth was round, most people were wrong. That happens all the time. Also, there's no need for one of the "two groups" to be wrong. They may both be right.
- What do you mean when you say SDL was made because every attempt I would make at creating a portable library would fail? Ha, ha. Anyway, what I want is so, so, so much smaller than SDL that I can easily do it. The only reason I haven't is I don't know how because I don't know the protocols and they are not very well documented. I can find out, but now I'm so busy!
- I don't think SDL is bad. If it's non-OOP code in C, that sounds good to me.... as long as I can statically link it in my programs. But again, it's too big. It wouldn't make sense for small projects. There is one thing I don't know: whether I have to include the whole library source code with my program source code if I statically link it to it (to follow the GPL). Do you know that?
- There are good reasons for choosing to work on the assembly code instead of the C code depending on what you want to do. Mainly, that the C code is not complete yet and that, while the assembly is a very faithful representation of the original binary code, the C code is an interpretation of it, albeit a very good one. Sometimes, you will definitely want the C code, but many times, you will want the opposite for these reasons. It depends on what you want to do.
- Portability is not a concern at this point, in my opinion, since this is real mode code. Only if you get to the point to completely abstract the code from the memory structure, will you be able to consider portability... unless you're thinking of a specialised emulator.
Quote
- Yes, I'm aware that moving the code can break it if there are references to the code itself that have not been accounted for.
I think I have mentioned this problem early in this thread.
I do think Daniël's guess is probably right, which is not the same thing as assuming that to do my work. I think he doesn't assume that either. Because the code was originally C (mostly), likely it doesn't have (many) tricky references to itself
or there a just offsets that are not symbolized in the reverse engineering process that are not function stack local
but these are no problem if one works carefully :)
Quote
- Your work is very professional, no doubt. Mine is not. This is not my profession. It's my lifelong hobby. That's why I do it my way. I won't force anybody else to do it my way. My main objective is not to just complete the program, but to enjoy making it. If I can't enjoy making it, I don't do it. This is not meant to be rude, just synthetic and clear. I hope you understand.
our worlds are just too different - im currently working on 2 nearly
1 million lines of Code projects, multiplatform desktop, embedded, UIs, 3D, partialy very low level, multy system deplyment etc...
C/C++/Java/C#,Reversing,assembler etc. all of it and with around 10 3rd-party dependencies from Qt,boost,AWS,and,and,and - all stuff that you cannot
easily develop on your own in a decent time with a decent feature set, working in/guarding teams of 5-20 developers etc.
your pain with complexity and size of third parties or different languages are just far away from my work-livelong daily business - i just don't have
any pains at all - as long as no constraints like development speed, resource usage, quality, etc. are harmed
Quote
- "The way it works" is relative. It's the way some people do it. They may be many, but that doesn't mean the rest is wrong. When the first few people thought the Earth was round, most people were wrong. That happens all the time. Also, there's no need for one of the "two groups" to be wrong. They may both be right.
just two worlds - im living in a world wich is populated primarily with other developers of that background
Quote
- What do you mean when you say SDL was made because every attempt I would make at creating a portable library would fail? Ha, ha. Anyway, what I want is so, so, so much smaller than SDL that I can easily do it. The only reason I haven't is I don't know how because I don't know the protocols and they are not very well documented. I can find out, but now I'm so busy!
everyone is able to do everything - thats not the question - the question is how long does it take, is it really needed, what does it really help the project
you can target what you want - its your hobby - but the restunts project is that big that any talking about the evilness of 3rd-parties is just sensless - you can start
with SDL, OpenGL, finish the project and then replace all the stuff with integer-only-x64-MIPS-AMIGA-inline assembler if you want to - because its not the primary code part
(if you write a wrapper around it - what a pro developer would always do)
you arguments are just only relevant to you - as i've never got any problems with 3rd-party and also never got problems in distribution of software
and i also find rarly programs that are graphical that don't use SDL or OpenGL, etc. so whats the point of beeing the only one concernd?
the answer: you are just not used to them (and their bytesize :)), thats it, and your arguments in that area are just there to re-comfirm that
Quote
- I don't think SDL is bad. If it's non-OOP code in C, that sounds good to me.... as long as I can statically link it in my programs. But again, it's too big. It wouldn't make sense for small projects. There is one thing I don't know: whether I have to include the whole library source code with my program source code if I statically link it to it (to follow the GPL). Do you know that?
i don't know, but SDL2 comes with static libs and shared libs
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.so you can do what you want - even not mentioning the usage of it
Quote
- There are good reasons for choosing to work on the assembly code instead of the C code depending on what you want to do.
Mainly, that the C code is not complete yet and that, while the assembly is a very faithful representation of the original binary code,
the C code is an interpretation of it, albeit a very good one.
Sometimes, you will definitely want the C code, but many times, you will want the opposite for these reasons. It depends on what you want to do.
im talking about adding new C code to the asmorig-Code - not to base on the restunts-C code
Quote
- Portability is not a concern at this point, in my opinion, since this is real mode code.
Only if you get to the point to completely abstract the code from the memory structure,
will you be able to consider portability... unless you're thinking of a specialised emulator.
in assembler you see the algorithm AND memory model in code
in C you see only the algorithm (that would easily 5 times smaller and better to read)
for example the Watcom C compiler got a feature that allows to have all your variables in your own code-segment (im using that feature in my (still not finished) MT32.DRV port)
then you can write the C code, create a object from it and link that to the asmorig code without the need
to cope with not changing the binary layout to much or the need to add data to the original data segment
or trick your data into your functions
but maybe its just a knowledge problem here: you maybe know how to do that stuff in the pure asm, but not how to
do it with C
Quote from: llm on June 03, 2021, 10:16:07 AM
Quote
- There are good reasons for choosing to work on the assembly code instead of the C code depending on what you want to do.
Mainly, that the C code is not complete yet and that, while the assembly is a very faithful representation of the original binary code,
the C code is an interpretation of it, albeit a very good one.
Sometimes, you will definitely want the C code, but many times, you will want the opposite for these reasons. It depends on what you want to do.
im talking about adding new C code to the asmorig-Code - not to base on the restunts-C code
I was hoping that that would be possible.
Quote from: llm on June 03, 2021, 10:16:07 AM
Quote
- Portability is not a concern at this point, in my opinion, since this is real mode code.
Only if you get to the point to completely abstract the code from the memory structure,
will you be able to consider portability... unless you're thinking of a specialised emulator.
in assembler you see the algorithm AND memory model in code
in C you see only the algorithm (that would easily 5 times smaller and better to read)
for example the Watcom C compiler got a feature that allows to have all your variables in your own code-segment (im using that feature in my (still not finished) MT32.DRV port)
then you can write the C code, create a object from it and link that to the asmorig code without the need
to cope with not changing the binary layout to much or the need to add data to the original data segment
or trick your data into your functions
but maybe its just a knowledge problem here: you maybe know how to do that stuff in the pure asm, but not how to
do it with C
It its always a knowledge problem. I don't think it is possible to know everything anymore. But in this case I believe you (llm :Red) have a wealth of knowledge that is much appreciated.
I hope somebody else besides me has time to dig soon. Finding a few isolated references to play with is one thing.
Identifying the whole main menu and all ...
QuoteQuoting CAS his estimate on the matter here
there must be a loop and in it, a function dispatcher. There must be a variable that holds the "current option" and a key selector to check and see if this value has to be incremented or decremented. Then, there will be some call to a dedicated function to read the status of the mouse buttons and coordinates. This could be a bare call to int 33h or an actual call to some internal routine that processes this information. After that, there will be comparisons to check whether the mouse pointer is inside any of the button areas. This will require a "for" loop that counts to five and in assembly, will look a little bit long in the main loop. This causes a change in the current option.
That is a whole different story, and I'm not sure if I can do that with my level of knowledge.
Looking up the instructions that actually do the thing is very complex and would take a lot of time. This is why I've been saying that the way to do this is to completely replace the routine. Even that is a lot of work, but is much more feasible.
And llm, yes, two different worlds. I have no "problem with" 3rd party software. I just have almost null interest in it. I play a game and I play it for fun and my game is code everything. If can do it, I do it. If it's not possible, I don't go for any alternatives, because it's not my game and I'm not interested. It's boring to me. What really is surprising is how people like often people push so hard to try to make me do things their way. I don't do the same to them. I wonder why that happens. They don't win anything with that.
I wanted to make my own tournament page from scratch without using libraries and even without databases. I did it and it works well. I wanted to make my own editor from scratch without a toolbox, just make my own. I did it. Now I'm making a car editing program my own way and it's in an early stage, but as you can see, it's improving. It looks like my way of doing the things does work :)
Quote from: Cas on June 03, 2021, 09:11:40 PM
And llm, yes, two different worlds. I have no "problem with" 3rd party software. I just have almost null interest in it. I play a game and I play it for fun and my game is code everything. If can do it, I do it. If it's not possible, I don't go for any alternatives, because it's not my game and I'm not interested. It's boring to me. What really is surprising is how people like often people push so hard to try to make me do things their way. I don't do the same to them. I wonder why that happens. They don't win anything with that.
I don't think they are trying to push you to do things their way. I believe they see you struggling and try to help, and they naturally suggest the way they know.
It's difficult to understand that for you, it is the journey and the struggle that makes it fun and worth doing.
And to be honest, I want to see the new game engine become a success. But doing everything yourself makes it also much harder to do so.
To me, there's no fun in putting pieces together. Say I'm a piece maker. Of course, there's the making a few pieces and putting them together with others, but the more putting pieces together and the less coding there is in a project, the less interesting it is to me and I just don't want to do it.
Before beginning with my new job, I've been getting more and more into electronics, home-made computers and micro-controllers. I think with time, I'll end up programming only those things. It's a lot of fun!
Back on topic.
I originally had a very ambitious idea of replacing the entire menu structure.
That plan is still on the table but it requires research beyond my capabilities. I was unsure of the project at first, that is why I chose to start a bit obscured. The Ferrari edition is a direct result of this and although not major, it has made me more confident.
I am more confident now that we can do things to improve the game (left corner bias can be fixed I believe)) or make it a bit better playable (do something about continue driving)
So let's see what we can do.
So this is the already-moved post, right? Am I OK to post here? :)
Quote from: Cas on October 30, 2021, 02:00:06 AM
So this is the already-moved post, right? Am I OK to post here? :)
Ehm.. yeah, it's ok. 8)
Last night I found part of the code responsible for the car limit in the garage. I successfully lowered the limit. To verify its function. I suspect that there will be issues when raising the limit.
I got into trouble with a limit of 120 and 110 cars. But I don't know what caused it. 8) I was to tired to continue messing with it.
To test better I am going to make 100 test cars from the originals. (Number them 0001 to 0100) and edit the Res file accordingly.
I want to see what happens when you exceed the limit in the original stunts. I never researched that.
And of course use turbo debugger.
I expect the 32 limited to be there with a reason. But I really want to know that reason.
I would "guess" that Stunts simply has an array of 12 character long strings that it loads with the car file names. This array has a fixed size, so when reading the files from the directory, it doesn't continue filling it if there are more files than a certain number. We programmers get used to "rounding" numbers to powers of two, so sometimes it may look like it's something in the program architecture, but it is really just the programmer's choice that went on to set the limit at 32 instead of 30 or 40.
Some testing you can make is, for example, put in your Stunts directory redundant files and see if this reduces the number of loaded cars. What I mean is this: normally, each car has four files. But if you have both a STXXXX.P3S and a STXXXX.3SH files, only one will be used, yet the other one may potentially have been loaded to the file list array. I wonder if adding four redundant files will cause only 31 cars to be loaded in the showroom. If this is so, then we'll know the limit has to do with the array where file names are loaded. If this doesn't happen, then it might be or might not be, because Stunts might just be smart enough to remove redundant files from the list.
Many similar tests can be made without changing the code that could give you an insight on how this works, but touching the value in the code is a good way of testing too, because you can just set it back to normal when you're done :)
Quote from: Daniel3D on November 06, 2021, 01:25:28 PM
Last night I found part of the code responsible for the car limit in the garage. I successfully lowered the limit. To verify its function. I suspect that there will be issues when raising the limit.
I expect the 32 limited to be there with a reason. But I really want to know that reason.
After some testing, I am sure that the 32 I found is a return counter. After the number is reached, it goes back to 1.
If set to 6 only the first 6 cars are shown, when set to 20, 20 cars are shown. If set to 36 the game crashes at 33.
I found no code that limits the amount of cars in some way, so fear that the car limit can not be increased in this engine without extensive rewriting.
Quote from: Daniel3D on November 07, 2021, 10:28:30 PM
Quote from: Daniel3D on November 06, 2021, 01:25:28 PM
Last night I found part of the code responsible for the car limit in the garage. I successfully lowered the limit. To verify its function. I suspect that there will be issues when raising the limit.
I expect the 32 limited to be there with a reason. But I really want to know that reason.
After some testing, I am sure that the 32 I found is a return counter. After the number is reached, it goes back to 1.
If set to 6 only the first 6 cars are shown, when set to 20, 20 cars are shown. If set to 36 the game crashes at 33.
I found no code that limits the amount of cars in some way, so fear that the car limit can not be increased in this engine without extensive rewriting.
I think there is just a fixed size array with size 32 and the game starts to override other relevant data if you force it to go further, normaly there are no checks or dynamic constructs to just allow growing, due to the very limited memory/performance constraints of that time everything was static and as small as possible, the 32 is just a very typical programmers size value, there needs to be a 32 elements array in the data segment for this, plus some (index%32)+1 for the cycling, % means modulo
That's what I thought to. And if we find that array and increase it, it might override other data or of the other data gets shifted to make room it could be unavailable for the game if it looks in a specific memory region. So it still might be possible but not without extensive research.