Color changing of the needle

[Ryoma]

Click on the earth bellow my avatar

[Daniel3D]

As of this mod the game is not original anymore.
This is the first mod that was only possible by rewriting part of the game engine.

So, a bit of a milestone.

It sure is! Great job! 

For extra peace of mind, I have tested the modified RES file with all GTO winning replays from ZakStunts, as well as in a test replay against Skid. All of them played correctly, and I didn't see graphical artefacts or any other weirdness. That is not surprising, of course -- in particular, over the years Cas and I have tried several times to identify what those bytes are supposed to do, and yet never managed to find anything. Still, that's at least some extra evidence in case anyone ever asks about it 

Out of curiosity I ran the edited cars in EGA, CGA and Tandy graphic (emulation in dosbox) but didn't experience anything strange with the graphics either.

[Cas]

I have made an update to the patch that would allow us to configure each needle independently. It's backward-compatible with the previous change, so it should be fine if you guys have been changing cars already. But I'll need Daniël to test it first, as I can't currently compile the source myself.

[Daniel3D]

I have made an update to the patch that would allow us to configure each needle independently. It's backward-compatible with the previous change, so it should be fine if you guys have been changing cars already. But I'll need Daniël to test it first, as I can't currently compile the source myself.

And I was already asleep so I'll try tonight. If it works I'll have it ready in about 16 hours from now.

[Daniel3D]

I have made an update to the patch that would allow us to configure each needle independently. It's backward-compatible with the previous change, so it should be fine if you guys have been changing cars already. But I'll need Daniël to test it first, as I can't currently compile the source myself.

Some cars have a red tachometer and a white speedometer. And the solution is almost as noninvasive as the first.
It uses bites that are standard 16(White) and 00(black) for speed and tacho respectively.
Basically, if the second byte is 00, then both needles are the colour of the first byte. If the second byte is non-zero, then the speed-o-meter is the colour of the first byte and the tach-o-meter is the colour of the second byte.
What it means is that colour 00(black) is only available for the tach-o-meter if the speed-o-meter colour is also zero. All other colours can be configured separately.

We are working on it, with variable success.

[Daniel3D]

DONE..
You can now set both needles.
Either one colour for both, or individual colours.
By changing also the value next to it in stressed.
Works as intended and explained in the previous post.

[Cas]

Yep, we nailed it!

First, the code just didn't work and produced glitches. Then, I realised that I was making a mistake, misinterpreting Turbo Assembler's syntax. I fixed that and we kept on getting glitches, but now the needle colours were the correct ones. As we weren't having success with compiling, I brute-forced the code into the binary and that worked perfectly, but that was the end of the road: we needed to get it to be "buildable". So we decided we'd try many combinations. Clearly, the main problem here has to do with alignment. Stunts doesn't want its code to be misaligned. After fifteen tries, we found the correct alignment.

[Daniel3D]

Misalignment is very easy to spot while testing. Because it always produces graphical disturbance.
The extremes I posted before, but sometimes the are minor.
The "alignment cycle" is 16 bytes long(adding 17 bytes produce the same disruption as adding 1does) . It has minimal disruption around 4, 8 and 12 bytes misalignment.
I believe it has to do with a memory offsets or something.

Edited on account of a true remark by llm and cut down a bit on the nonsense.

[llm]

Misalignment is very easy to spot while testing. Because it always produces graphical disturbance.
The extremes I posted before, but sometimes the are minor.
The alignment cycle is 16 bytes long. It has minimal disruption around 4, 8 and 12 bytes misalignment.
I believe it has to do with a memory counter. Memory segments are 4, 8 or 16 bytes long.  So some parts read well even if they are misaligned.

what is a "alignment cycle"? there is alignment - which do not create "cycles"
what is a "memory counter"? really no idea
what are "memory segments"? there are real mode segments and these can be 64kb in size

i humbly beseech you Daniel3D don't invent new names or use names that mabye fit
for stuff that is 40 and more years old - its funny to read but hard to follow 

the problem with all that statements are: the x86 architecture is not alignment criticial - it should not crash if you read/write unaligned data (it should be just way slower) - so i think its not a problem of alignment but more a problem of moving code blocks a little

it would be more interesting to see the bad/good asm code

Misalignment is very easy to spot while testing. Because it always produces graphical disturbance.

that is one of many posibilties - the see/hearable glitches are the easiest - im always afraid of glitches that do
not show up for a while (that is the bigger problem with changing the binary/asm code)

everyone that changes thes asm code needs to proove that code behind gets not moved - or every bug in every way is possible (pure random generator)
its just gambling if you don't proove or not ask how to do it

you need to check if the code of the object files is still at the same position in the executeable - because there ARE non symbolic offsets in the disassembly
that won't follow size/re-arange steps in the asm code before - that means your newly introduced needle-color-code can create a crash in the Sound settings menu or somewhere else

its soo damn easy to introduce hard to see errors - everything in asm can produce undefined behavior and the DOS/x86 environment allows even more shit to happen without crashing or glitching in any way

be carefull

btw: funny pictures

[Daniel3D]

I am careful but I depend heavily on CAS his experience.
I mess around a lot, learning how to break it.

I thought that everything beyond "let's drive" would be impossible to change because that is written in assembly and not in C.

And I don't know how it works in detail. And i don't know the right names.

[Daniel3D]

i humbly beseech you Daniel3D don't invent new names or use names that mabye fit
for stuff that is 40 and more years old - its funny to read but hard to follow 

Thinking about stuff you barely understand and writing about it after 3 hours of sleep makes a messy post.

[Cas]

Daniel3D is not talking about word alignment, but about the alignment of memory blocks. These "cycles" make sense, although the reason why they come up may have to do with several different things.

The primary reason why adding or removing code will cause "misalignment" is because of the paragraph size of 16 bytes. Programs built for DOS frequently point to sections of the code and data by using a segment and assuming the offset is zero. This requires the physical address of the start of the section to be divisible by 16. Here we don't even know what the start of the section is and looking at the assembly code, it's hard to estimate the number of bytes it'll compile to, so after any change that modifies the size, we definitely need to make sure it remains congruent to the previous size modulo 16. Of course, not all of the code will require this, because there can be some far references that do include an offset, but alignment to 16 bytes is crucial.

Like Ilm says, there is also word alignment, that shouldn't break anything but can make code slower. The 80x86 processors just take the memory address you give them and they do the read or write transparently, although inside, they may do it in one, two or maybe even four steps. The good news is that because it's transparent, nothing should break. The bad news is that, because it's transparent, again, you have no way of easily seeing the misalignment and your code may be sub-optimal for speed. Thankfully, you really do have a way in the end, because code that's not aligned to 4 bytes also is not aligned to 16 bytes, so you'll see the glitches of the first type.

There's one more thing. Even though word misalignment is done internally by the microprocessor, sometimes memory can be incorrectly referenced by the code simply because the programmer chose to store the position of a field in multiples of 2 or 4. We already know that this is done many times in Stunts. See the width of VSH images, for instance. Glitches appear if they're not multiple of 8 and this is without changing any code. And sadly, outside of the scope of the compiler, the code itself can perfectly have been written in a way that assumes that a certain block of memory is aligned to other sizes, perhaps 64 bytes, and there's nothing we can do about that but test and see, unless we comprehensively analyse the whole of the code. But well, this isn't very likely.

About these two particular mods we have made. The first change we made on the needle colour is super stable because only two words were modified in the code and the size remained the same. It's totally safe. The second change should be OK, but we were forced to add new code and realign. Everything seems to work perfectly, but the more testing we do, the better, because of all of the above.

[llm]

We could add alignment checks to every segment so that the asembling will fail if its not divideable by 16 or forcing the alignment to be paragraph aligned

currently all segements in assembler segment byte, segment para would align them to paragraph alignment

and the linker could generate a map file with decent information about segment/function start,size

But its really needed to find the rest of the non symbolic offsets, could be just a few
then changes are 100% safe

Some script that show magic numbers in the asm code would be a good start

All in all - there are more ways to keep everything clean and working if one is familiar with all the default techniques doing it, so first learn then change

[Daniel3D]

I agree with you. Cleaning up the code and fixing non-symbolic offsets is important. And forcing the alignment sounds like a very sensible choice.

Those are definitely important if we want to combine more changes. The more we change, the more risk of obscure and difficult to find bugs.

But I don't agree with "first learn then change"
It's from change we learn. It's change that inspires progress.
Is it the best approach, probably not.
But it does yield results.

Before we commit to a rebuild of a version with combined changes I want to have the code clean as well. I talked about it with CAS earlier. But not in such details as you did. (I sort of understand the principle but don't know the terms)

[llm]

But I don't agree with "first learn then change"
It's from change we learn. It's change that inspires progress.
Is it the best approach, probably not.
But it does yield results.

Im talking about the basics like how the functions,segments get layouted etc, map files from the linker