CarWorks - a different approach to car making

[Zapper]

I follow these considerations when creating STDA*. files:

- The image resource "ins2" should have a certain WxH that results in a integer value when divised by 8, for example:
    on Jaguar JR9 "ins2" has 48 pixels width and 34 pixels height:
         48x34=1632 -> 1632/8=204
    the result 204 has no decimal value, so it should be ok.
    I also use this rule on "whl1-3".

- The image resources "ins1", "ins3", and their associated alpha masks "inm1" and "inm3", have the same width and height dimentions has "ins2". In this case they all have to use 0,0 (x,y) starting coordinates since they are all referenced by "ins2" starting coordinates  (wiki).
    If "ins1" and "ins3" ("inm1", "inm3" respectively) have smaller images than "ins2", they can be placed on other starting coodinates, but they are all relative to "ins2" (check STDAFGTO.3SH example), and the rendered image cannot overlap "ins2" image area.

There are other considerations that have not been fully clarified. It turns out that when I edit these image resources to make a perfect rendering in the context of CGA or EGA game setup, there is some misalignment rendering "ins*" and "whl*" that I think it has relation with the width x height pixel proportions. (check for example Caterham Super 7 JPE in EGA)

 

[Cas]

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!

[KyLiE]

It turns out that when I edit these image resources to make a perfect rendering in the context of CGA or EGA game setup, there is some misalignment rendering "ins*" and "whl*" that I think it has relation with the width x height pixel proportions.

I've noticed this as well.  Speaking of which, I've asked about this in another topic, but do you have any information on the translation tables for the alternative CGA and EGA palettes?  I know how they work, but I would like to make a list of each alternate colour/shade and its corresponding value and I'm not sure which is the best way to do that.

[Zapper]

It turns out that when I edit these image resources to make a perfect rendering in the context of CGA or EGA game setup, there is some misalignment rendering "ins*" and "whl*" that I think it has relation with the width x height pixel proportions.

I've noticed this as well.  Speaking of which, I've asked about this in another topic, but do you have any information on the translation tables for the alternative CGA and EGA palettes?  I know how they work, but I would like to make a list of each alternate colour/shade and its corresponding value and I'm not sure which is the best way to do that.

I think there is no direct translation between pallets, if you compare the dashboards show above, a simple plain "yellow" on the MCGA / VGA pallet is rendered as a "striped" pattern in CGA, but not in EGA... And other examples like the windscreen or the steering wheel, just by visual comparison we find color patterns apearing in different places of the same dashboard.
So, I believe that several other mechanics are implemented in the game engine.

[Cas]

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.

[KyLiE]

I don't think I'll be covering the EGA/CGA palettes in CarWorks, at least for now.

I didn't think you would be.  The only reason I mentioned it is because I haven't had much response to the other topic and when I saw Zapper mention it, I thought I'd ask.

[Daniel3D]

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 can not reproduce this statement. In the February 25, 1991 edition all looks normal. all offsets are correctly given for ins1.
Can you give me an example where (or when) this is not so?

[Cas]

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

[Daniel3D]

- The image resource "ins2" should have a certain WxH that results in a integer value when divised by 8, for example:
    on Jaguar JR9 "ins2" has 48 pixels width and 34 pixels height:
         48x34=1632 -> 1632/8=204
    the result 204 has no decimal value, so it should be ok.
    I also use this rule on "whl1-3".

Since i don't have any programming experience or detailed understanding of the inner workings of the code I try to understand this matter theoretically and by comparing it to other things I come across.

In reading the forum and the wiki I found some bits interesting.
- all dashboard (part) images have a with of a multiple of 8 in the original cars.
- the game was made with time pressure
- its build with a lot of concessions in favor of memory usage.
- and some other things that nagged my brain.

If you divide the 320 pixels in part of 8 you get 40 columns.
That made me think of old 2d graphics (like in Commodore 64 and such)

Could the dashboard animation be like that and therefore work with images and parts in multiples of 8?

It's an idea, and it does not hold if the quoted statement is true for cases where X is not a multiple of 8.
It does however seem to fit all original cars.

Maybe it's noting... Like I said. It's not based on anything solid. Just a link I made between bits of information that may or may not have any relation.
I don't even know if the bits of 8 are a restriction in commodore and such.

Afterthought:
Maybe the engine just maps area's of 8 as animated parts and the others as static. Then only the columns with animations have a render cycle and the other parts do not.
that would save memory as well...

[Cas]

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.

[Daniel3D]

That makes more sence 

[Zapper]

Cas, for me those considerations are safe enough to take into account on developping this tool. 

[Cas]

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!

[Ryoma]

Congratulations and thank you. I have no project for the moment but I will surely try it.

[KyLiE]

It's great to hear that you have reached that milestone!  As you know, I have been delayed with the development of the Chevrolet Corvette CERV III.  However, when I get the chance I will definitely be using the latest version of CarWorks to continue working on it.