Messages

I really haven't looked at the Restunts code in detail. I imagine that things go more or less like this:

- Stunts original binary was packed and the first thing it did was load itself to memory unpacked. This is no longer relevant to Restunts
- After that, the code would load the graphics "driver" file and proceed to merge it with itself in memory, resulting in the actual program code. This, again, has been hard-wired in Restunts so it should now be irrelevant
- At this point, I assume the code jumps to a loader function or maybe a chain of loader functions. Some fixed memory is reserved at the beginning to contain the main program variables, such as what car is currently loaded, with which colour and whether transmission is automatic or manual, also there's a memory region that's always reserved for a track and the replay events right after it. Which opponent is currently selected, with which car, etc., all this goes to this fixed memory that's reserved at the beginning and is only freed when the program ends. There surely is a lot more being stored there. I don't know if engine-time variables are also stored here or if a dynamic memory region is allocated when the main game engine is started up and freed every time a race ends. After defining the fixed part, the default track and replay are loaded.
- Now the loader begins bringing up the dynamic part. It starts loading resource files. When a resource file is loaded, surely memory is allocated for it and surely, resources in memory can be freed dynamically and indeed, are, very frequently. I assume the intro is loaded, run, and then removed from memory by the time you get to the main menu. The game loads all car files dynamically, even though these ones are not removed until the program ends. At this point, the loader routine likely jumps to a Main Menu routine. I really hope this is done this way.
- The Main Menu routine calls the dynamic resource loader function, the same used for loading cars, to load the menu background image. Not sure if music is loaded dynamically or all tracks at the beginning. A small dynamic region is allocated that corresponds to the local function variables. These hold, for example, the current option being selected. Because Stunts replaces the BIOS keyboard routine with its own, the Main Menu surely invokes other functions to control the keyboard and mouse. Besides, the mouse pointer is drawn by Stunts. It does not use the default arrow cursor. The menu either regularly calls a mouse cursor maintenance function or this is already installed at the timer interrupt. I expect the second and it'd be the best. If not, we will need to identify this maintenance function. When the user presses Enter or clicks on one of the signs, the Main Menu either calls a main branch function for that option or returns a section ID value and exits to the main program loop. We have to know which of these is the case. It's the Main Menu function that we have to replace and we have to give it the same form as the original one.
- Each other part of the program surely loads dynamically. I know for a fact that the internal track editor is really an external executable, yet the mouse cursor remains functional, which makes me think there is some for of API set up in memory, probably in the form of an interrupt. One good way of understanding this API would be to disassemble the track editor, but this is such a big thing to do that we better first try to figure things out by only looking at the Main Menu function.

What I think we should do is to not try to actually modify the original code too much. Only replace this one function. The code will have to be recompiled once so that the new function is blended with the rest of the program, but any other mod we want to make should just be plugged there and run as an external EXE, just like the track editor. Of course, if we want to make a mod that does something "during the execution" of another program section, this won't work. We'll have to make a TSR part for it or something. Good news is that even though Stunts didn't, we can use 32bit registers and we can use XMS.

Do let me know if I'm missing something important or if something is very, very different from my guesses. I'm writing this as a base to start putting the cards on the table.

That's really interesting!  I'll take a look at CarEdit3

EDIT: I copied CAREDIT3.EXE and its BGI file to Stunts directory and ran it with DOSBox. It gives me an error saying something like the RES file ended unexpectedly. I gave an RES file as a parameter and it still says the same. I'm not sure what I'm doing wrong. I would like to take a closer look to this tool. Reading the readme file that comes in the package, I can tell the author really loves working on this. I feel great respect for the people that made other tools for Stunts, especially the most classical ones.

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.

Great video!  The part when they split and take separate ways.... 
The new shape looks great and still preserves the essence of the old one!

Well, in Argentina, there's a duality between what's allowed in theory and what people actually do. On Thursday or Friday evening, it was announced that we'd be going back to phase 1 beginning on Saturday (yesterday). The national government had already attempted something similar in the Buenos Aires surroundings some time ago and it hadn't worked. Now they have support from the governors of different provinces. This phase 1, however, is supposed to be only for nine days, after which, we'd be back to how we've been doing and then, the following weekend, we'd try another phase 1 and so on, like intermittent, if I understood correctly.

This sounds smarter than previous attempts because it is known that people are not listening and if at least, they see they will have a chance later to go out, then maybe they stay at their homes for the days of curfew. Or so I though. Yesterday, I went for a walk nearby, with my mask, of course, and to buy bread. What I saw makes it clear it just didn't work. More than half of people are not taking any measures, even the ones that are easiest to take!  Really, there are some things that I understand about people who complain, like... businesses need to work to some measure because they need to survive or it will all collapse, I agree. But...wearing a mask, not hanging out for just drinking... simple things and they don't do them!  I guess it's like a movie we just have to watch

Personally, I have to say my family is doing fine. My parents already received their vaccines... at least the first dose. So it's something. Hope you guys are all OK!

If I were to go back to 1993 when I just got my first PC and I could carry only one diskette of data from today, I'd save the Melange in it!  Looking forward to seeing more about it

If you guys think there's something regarding engine graphs and the sort that could be useful to have in a car making tool, let me know, so that I can implement that in CarWorks. I really don't know much about cars and seeing these graphs I realise there probably is a lot more I could easily do.

The dashboard really does look great!

Thanks, guys!  I'll try to have an update with a nice file management system soon. There are many things I want to add and fix.

Afullo, thanks for the .so5-based binary. I'll make sure to include it in the package. CarWorks is now at official level, but still in an early version, so I expect it will have many updates and I don't know if you'll always be comfortable with producing another such binary. When you're to busy to do it, I'll understand. I think I should just make a virtual machine for these things, but even that would take lots of time and sometimes I just want to compile the program quickly and use the time for programming.

My job has also been absorbing much more of my time than it happened with the previous one. As a matter of fact, I've been working the two jobs and will continue to do so till the end of the month, when I'll be dropping the old one.

Alright. I'm proud to announce that the first snapshot of CarWorks 1.0 that can do everything that the old CarWorks 0.1 and Dash Manager 0.1 could do is already up. Of course, it not only can do that much; it can do a lot more; but I felt it was a requirement to get to this point so that the old alpha versions can now be considered obsolete. As a result, this snapshot is now an official release and version 1.0 will apply to it alone. Next time I upload changes, I'll be modifying the version number.

Anyway. The package is, as usual, in the project site, which will soon be upgraded, at http://www.raceforkicks.com/projects/carworks.html. You will notice that the file loading and saving part of the program still looks ugly, but it does its job. I've been leaving that for the end to be able to complete the tools as soon as possible. The three parts are implemented, to a reasonable degree: the 3D modelling and paint-job section, the parameter configuration area and the dash manager, that now has become part of it and hopefully, is more stable and doesn't have as many bugs.

I would like you guys to put the program to the test of normal usage. I have been testing each feature I implemented, but I am not actually building a car, so it's likely that some bugs will have come unnoticed by me. Thank you all so much for your help so far and of course, I'm open to suggestions. I'll be focusing in improving the file handling section now and fixing any bugs that come up. Cheers!

Well, this is all speculation from my part, but, in my opinion, the multiple-of-eight rule is part of a strategy of optimisation for speed. We know the following:

• For all original cars, every image in a VSH/PVS file has its X and its width (both) as multiples of eight. The odds of this being sheer chance are super small, like one over eight to the eleventh to one small!  So no way: this was made by design
• Images are raw bitmaps contained in the VSH file. We have handled them and know that is so, which means we know for a fact this is not a tile-based graphics system. Besides, the Y and height do not follow the multiple-of-eight rule and they would if the thing were tiled
• Saving a car with non-aligned images does work to a very good extent. It only tends to cause problems with the instrument images when turning the steering wheel, but this issue can happen sometimes even with properly aligned images. Additional measures, such as making all instrument images exactly the same dimensions, appear to reduce even more the chance of failure, but there seems to be no guarantee
• Stunts was made at a time when the fastest PCs people had were 386s (Correct me if I'm wrong). I've tried it myself on a 286, a 386 and faster computers and I feel a 286, while it can run Stunts, is a bit too slow and usually requires 10 frames per second, while on a 386DX, Stunts runs like a charm. On a 486 or higher, I felt it was even smoother than on a 386, but it was such a slight thing that I'm not sure if I imagined.
• XTs and 286s are 16bit computers. They handle words and can store them in memory directly (and read them), but internally, they can only do it in an aligned fashion. This means that you can write a byte at any position, but words have to go at even positions. The microprocessor instructions allow you to place a word at or read it from an odd position, but if you do this, the CPU will actually emulate this by performing two byte operations, which will take twice as long. This is why programs at the time tried to keep everything aligned when optimising for speed. But this wouldn't explain why multiples of eight. Even positions should be enough.
• A very popular optimisation for speed in assembly language is to use bit shift operations for multiplying and dividing instead of the proper arithmetic operations. This means that, instead of telling the computer: "multiply this number by four", you tell it to "shift the bits of this register to the left two times". This greatly increases the speed of your code, but has the limitation that the factor has to be a power of two. If the blitting routing that draws the dashboard exploits this strategy, there's a chance it's not well tested with non multiples-of-eight and contains a bug that causes it to fail sometimes when this configuration is not given.
• The fact that the vertical coordinates do not follow the multiple-of-eight rule suggests that whatever the reason is for this rule, it has to do with something that sees the image as a sequence and not as a 2D field. Most likely, something related to memory read/write events.

On a side note, I've just uploaded another snapshot of CarWorks to the project page. It already contains some Dash Manager code, but not to the point of it being useful. You can load VSH files and see the images, even "drive", moving the steering wheel, but that's it for now. I don't remember how I had left the 3D part before this update, so maybe you find a difference there as well.

Sorry... I've been making more tests and it looks like I was somehow reading the data incorrectly. X and Y coordinates match the correct position for ins1 and ins3, relative to the coordinates of ins2.

It would indeed be nice to eventually support the CGA/EGA graphics one the palette format were fully understood. I'm not prioritising it now, but hopefully, when CarWorks already does everything it has to do, we can have an implementation for this in the program

I don't think I'll be covering the EGA/CGA palettes in CarWorks, at least for now. Too complex and there are other, more common things, we still don't fully understand. Maybe in the future, when we have a clearer understanding of it and the rest has been sorted out.

I'm really puzzled to see that, when the width of ins1 and ins3 differs from that of ins2, that first pair still shares the same width and coordinates, yet, they are not placed at the same location, one being aligned to the right and the other one to the left. I wonder if the one on the left gets its position calculated from right to left or if it just ignores the X. I'm going to have to run some tests.

I have noticed something similar too, and like you, I cannot be exactly sure about why, but some actions seem to reduce or eliminate the chance of these bugs happening. Reading the values from original cars, I've seen that both the X displacement and the width W for every image are always multiples of 8. The Y and the height H don't follow this rule, but of course, with the first rule, if you multiply these, you'll always get a multiple of 8 as well. However, playing with these values and changing them seems to have no effect... until it does!  In other words, Stunts does accept other values, but if you stick to those, you know some bugs won't occur.

About INS1 and INS3 and their corresponding masks, I agree that the best is to use the same dimensions as those of INS2 and set X and Y to zero. That's the safest. Yet, looking at original cars, which usually do not follow this rule, I find that these two images are always aligned at the bottom-right and bottom-left of INS2 and their X and Y seem to be ignored, yet values are saved there!  I also saw that the unknown word fields are a vector too!  And when two Xs have a certain delta, the first of those words (unknown X) appears to also display the same delta. Again, nevertheless, changing this vector appears to have no effect!

I'm now working on the Dash Manager part of CarWorks 1.0 and I'm having problems. Since I'm being a lot more careful with this project than with the old CarWorks 0.1 and Dash Manager 0.1, many issues have become apparent, but not enough to easily solve them. One thing has to do with the coordinates of ins1, ins3, inm1 and inm3. These four dash items provide X and Y screen coordinates that do not match anything. At first, it looks like they should be relative to the coordinates of ins2, but not really. I can see that there are slight deviations, which explains why there were problems with the old version. KyLiE has also been telling me that something similar happens with the location of the gear box. I reckon maybe Ryoma and Zapper can shed some light on this, as they are the most experienced ones in car making. If you guys can give me a hint, I'll appreciate it:

How do you calculate the correct  instrument image coordinates from the VSH based data?

I'll keep on researching. Maybe the "unknown" words and bytes have something to do with this.