Stunts Forum

While working on the Delta, I made a mistake with inm1 and succeed to change color of needle.

I try again with the Musa and it works only when turning wheel.

See enclosed pictures.

I think that is because that mask is only active when the wheel is turned.

Yes in order to priority of display : insX and inmX and after dasX. And inm2 does not exist anymore.

So this solution is not the way to go. I made a lot of tests.

O don't think that changing the color of the needle is possible.
The car files contain the graphics and the needle position.
But no information about the animation of the needle.
Therefore, I think that the needle is drawn by the main game engine.
That is where the color is given. If the color can be changed, then it will be for all cars.

Red for all cars will be cool!!!!

I had a quick look in the source and found this.

https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asm/seg005.asm#lines-2710 (https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asm/seg005.asm#lines-2710)

meter_needle_color


loc_23456:
    cmp     [bp+var_6], 0
    jnz     short loc_23485
    mov     ax, si
    shl     ax, 1
    mov     [bp+var_20], ax
    push    meter_needle_color
    mov     bx, ax
    mov     al, (simd_player.spdpoints+1)[bx]
    sub     ah, ah
    push    ax
    mov     al, simd_player.spdpoints[bx]
    push    ax
    push    simd_player.spdcenter.y2
    push    simd_player.spdcenter.x2
    call    preRender_line
    add     sp, 0Ah
loc_23485:
    mov     ax, di
    shl     ax, 1
    mov     [bp+var_20], ax
    push    meter_needle_color
    mov     bx, ax
    mov     al, (simd_player.revpoints+1)[bx]
    sub     ah, ah
    push    ax
    mov     al, simd_player.revpoints[bx]
    push    ax
    push    simd_player.revcenter.y2
    push    simd_player.revcenter.x2
    call    preRender_line
    add     sp, 0Ah
    mov     al, [bp+var_2]
    cbw
    or      ax, ax
    jz      short loc_234BE
    cmp     ax, 2           ; st. whl. position flag
    jz      short loc_234EC
    jmp     short loc_234DE
    ; align 2
    db 144


After tracing the meter_needle_color back it is loaded without value, it seems to be tied to the font color.

Tweaking the code a little bit, it could be possible to get this value loaded from a byte in "simd" instead of that variable. This would make the needle colour configurable. Just loading it this way maybe can be done without changing the opcode length, but there are a few catches.

I think the best candidate in "simd" for this is the byte right after the number of gears. That is, the number of gears is being stored as a word, but only the lower byte is interpreted, so the high byte is normally zero, but if you change it, it has no effect. Of course, 0 is black, so doing this would make the needle of all previously created cars to be black. With some additional code, this byte could be, for example, XORed against 0Fh or ADDed 0Fh to, in order to make white the default.

I'll be researching on that, although I have a ton of other things to do and not much time.

Adding something here...

My idea is that the line that says:
push    meter_needle_color
is actually pushing from a memory location in Stunts data, something like push [3215h]. This position is fixed relative to Stunts data segment.

Unless Stunts uses more than one data segment for its configuration data, the current car parameters must also be located at some other point within the same segment. Now, I don't know if all the resources are loaded at fixed positions, but it would make sense if they were. If the whole CAR*.RES file is loaded as one thing, then it's going to be more complicated and will require recompilation. But let's say that "simd" is always loaded at the same offset relative to DS. Then, there exists another offset that we can place at that push, maintaining the same binary length, that points to an unused parameter from the car.

The simplest way to get this done then would be to pick what CarWorks calls the "red#5 mysterious parameter" because this one appears to be 16 for all cars by default and 16 happens to be white in Stunts palette. Then, every already existing car would still keep a white needle, but it would only take a simple edit with CarWorks to make a car use any other colour from the palette.

Notice that this does not change the value of the variable "meter_needle_color". What it does is pass another variable as a parameter instead. If we were instead to change the former, then the needle colour would change, but would be the same for all cars.

EDIT: I found it... If I am not mistaken, that single line of code should be changed to:
push simd_player.field_A6+4
Of course, to know the new value, we would have to assemble Restunts anyway, but once we do, if it works, we'll be able to spot the single word that has changed in the binary file and from then on, we only need a tiny patch. This... if I'm right about my assumptions.

If I read the source correctly the needle is loaded after the dashboard images. So taking a parameter from the car should work.

Following the trail of parameters leads to the color of the text.
So if we would have changed the text color of the menus at one point the needle would have changed as well.
Pointing to the car files sounds really good.

You will have to update carworks, and the unused byte you want to use has to initial be set to default white for all cars. (The current value would result in black I believe)

I chose Red#5 because it defaults to 16, which is white in Stunts. I was thinking that the line to be replaced appears twice in the code and I think this is because the parameter is passed to the function twice: once for each instrument. If so, then we could actually issue different parameters and therefore, allow for different colours for the needles, but there isn't another parameter that defaults to a value that's white in Stunts palette, so if we do that, original cars will change the colour of one of their needles and we would have to touch their RES files. Not something I would like to do. Anyway, it'd be very interesting to test if that works, because it'd give us an idea of what we can do for future modifications.

If, instead of a patch, we really do reassemble Restunts, then we can simply add more lines and have the two needle colours be read from the same word parameter as two bytes and default to white when the values are the same that we find in original cars.

I have never compiled/assembled Restunts. I can do my tricks to patch this via binary research, but if anybody can hint me on the best way to do this, I'll appreciate it. I'm reading the code and there's this makefile, but while I know what it is for, I really don't know the format very well. Besides, I should compile this in DOSBox, so I'm not sure if I would have to use this file.

Teaser

So yes!  We did it! :D

Basically, what we have achieved after some work with Daniël was the following:

• You can change a field previously unused in the CAR*.RES file of your car to select any needle colour from the 256 palette colours Stunts uses
• Both needles will change to that colour for your car
• All cars already in existence will continue to display white needles, which is the default

We also tried to achieve more, but have been having some problems so far:

• Tried to make the colours separately configurable without breaking the white default. This broke the code
• We can easily make the colours separate, but one of them would not default to white
• We'll be researching to see why the code breaks. I suspect that Stunts assumes some code lengths

The file is attached. It's compatible with Stunts 1.1 and the new Stunts 1.1 Mod 1.0.
This change will only be for the MCGA graphics versions.

With CarWorks, currently, you can change it by going to the "mysterious" parameters and changing Red#5.

But a better way will be available when CAS updates it, Because it is not "mysterious" anymore.
The GTON attached is the GTO with the needle color changed, we used it for testing.

The value can be changed in stressed by changing the same byte.
Red#5 is marked in the picture below.
The number 16 (decimal) is default, and that is white in the stunts palet.(second row first)

In stressed it is 10 (hexadecimal) the pallet starts at 0.
1st row = 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F (in hexadeximal)
each row has the next starting number. Below a lookup table to quickly translate dec to hex.
https://www.javatpoint.com/hexadecimal-numbers-list (https://www.javatpoint.com/hexadecimal-numbers-list)

So 07 is grey, and 27 is bright red.

EDIT Dec 18th: added a reference picture with the hex numbers filled in to attachments.

Yep!  I'll update CarWorks for this, but I would like to see if we can solve the differentiation problem between the needles first, so I just make one change in CarWorks instead of two. In preparation for that, I advise to try this new feature this way: when you make a new car or edit your custom car, set the myterious red #5 field to your desired needle colour value from 0 to 255 according to Stunts palette (http://wiki.stunts.hu/index.php?title=File:Stunts-pal-vga.png). This field is a word. Make sure to keep its high byte zero. In other words, don't set it to anything greater than 255 or else, this will break your car look in the future if we add separate colours for the needles. My idea is to make it so that the high byte will be an offset between the needle colours. Thus, the current default (zero) will result in both needles being the same colour. A value of one would make the RPM meter needle the following colour from that of the speed-o-meter and so on.

Following these rules, not only will original cars continue to look the same in the modded version, but new cars will also look the closest to normal in the original Stunts and besides, you'll always know what that look will be, so you can take that into account.

Good news well done guys...a lot of modification will come.

 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.

Please open a branch for the Mod, its still easy to follow the current few changes, but that will get harder and harder if the change count grows

Yes I'll try to figure out how tonight.
I will make one for the Ferrari edition as well.
CAS and I are going to redo that properly.

Quote from: Daniel3D on November 02, 2021, 07:43:19 AM
Yes I'll try to figure out how tonight.
I will make one for the Ferrari edition as well.
CAS and I are going to redo that properly.

first of all, git is a distributed version control system - so there is no need to work permanently with the gitbucket server, create as much branches you need and work on them locally

you can always merge (using git, not manually) changes in one branch into another (or update you branch with master/main) - try to understand the concept and do not work around - that keeps the history intact

good clients (at first, easier to understand then the command client)
http://gitextensions.github.io/ (Windows only)
https://gitahead.github.io/gitahead.com/ (Windows and Linux)

I find it difficult to understand how it works.
I get the principle. But I have never done anything remotely like this.

So I'll install the software, get the repository in and go from there.

Quote from: Daniel3D on November 02, 2021, 08:18:01 AM
But I have never done anything remotely like this.

watch this: https://www.freecodecamp.org/news/learn-the-basics-of-git-in-under-10-minutes-da548267cc91/
or some youtube videos - you only need to know the basics (clone, pull, push, merge)

here is a git-extension how to video/tutorial:
https://bytescout.com/blog/beginner-guide-to-git-on-windows-using-git-extensions

important: you can create a local test repo and clone from that into a different work repo folder and test all the new stuff you learn - even pushing is possible

c:\temp\remote_repo <- create this for fun
  add,commit,pull etc.
c:\temp\work_repo --> clone of remote_repo
  add,push,pull,merge

you can test every "remote-repo" feature completely local - there is no need for a server like github/bitbucket etc. to learn that - due to the "distributed" nature of git
every repo can act as a sever or client branch

We definitely need to branch out, yes. Still, I do find it really confusing to work with Git and similar. I'll give an example. Say you have an original source made of files A and B. Then, you make a change that consists on patching A resulting in a new source composed of A' and B. After that, you make a separate change, that causes a completely different thing by patching B. We have a A' + B' source now. A third patch is created finally that modifies A' resulting in A"+B'.

Now. It is clear that patch 3 is causally posterior to patch 1 and can only be applied on the source that already has patch 1, but patch 1 and patch 2 could in theory each be applied or not independently. Is there an organised and clear way to specify things like that?  That is, to separate what is patch 1, patch 2 and patch 3, maintaining the dependencies of each patch on others and allowing maximum flexibility on which patches are on and which are off?

Well CAS I think that is exactly the reason for the git.
Keeping track of things like that.

Quote from: Cas on November 01, 2021, 11:55:16 PM
So yes!  We did it! :D

Excellent work!  I look forward to finding out if it's possible to specify different colours for the two needles.

Quote from: Cas on November 02, 2021, 02:24:24 PM
Is there an organised and clear way to specify things like that?

Yes, though the dependency tracking works in a somewhat different way. Git doesn't give you full flexibility because it arranges history by keeping track of the parent of each commit. However, it does offer ways of managing and reconciling diverging patches when there is a need to. For instance, here is a slight variation on your example. Let's say you were working on file A, changed it in commits x and y, and pushed your changes to our shared repository:


(A, B) ---[x]--> (A', B) ---[y]--> (A'', B)


Now, while you were still working on your patches, I started working on file B, and changed it in my local repository with commit z:


(A, B) ---[z]--> (A, B')


If I pull your changes to update my repository now, I will end up with diverging history lines:


(A, B) ---[x]--> (A', B) ---[y]--> (A'', B)
  |
  +---[z]--> (A, B')


The usual way of dealing with that is for me to ask Git to rebase my changes, that is, rewrite z so that it is applied after y:


(A, B) ---[x]--> (A', B) ---[y]--> (A'', B) ---[z*]--> (A'', B')


(If there were any conflicts between our patches -- that is, if we happened to have changed the same thing in different ways -- I would be asked by Git to deal with them at this point.)

Now that the history in my repository no longer diverges from the shared one, I can push my commit to the shared repository, and you, in turn, can pull it.

Quote from: Daniel3D on November 02, 2021, 03:20:11 PM
Well CAS I think that is exactly the reason for the git.
Keeping track of things like that.

yepp - that is exactly what git does - keep track of sub-mergeable changes - but as usual - one can work around git's feature-set and break everything real fast :)

Quote from: llm on November 02, 2021, 04:16:36 PM
but as usual - one can work around git's feature-set and break everything real fast :)

I'll try not to do that...

Oh, well, I really don't want to make it harder for Git to do its work!  I think I would be working on my local copy for testing, but then if I like what I have, I'll just redo the thing working in team, so we don't collide. My interest in these patch dependency trees comes from the idea that perhaps somebody would want to apply certain mods, but not certain others, so I was wondering if there was a clean way to exploit Git so that one could get different sources for any combination of mods... things like that.

That is possible I think. If they don't influence the same piece of code. So documentation and organisation is important.
But I want to redo the Ferrari edition and apply the needle change to that.
So 2 branches already..

The only thing that saddens me a bit is that we can only mod the mcga version this way.

Quote from: llm on November 02, 2021, 08:12:09 AM

Quote from: Daniel3D on November 02, 2021, 07:43:19 AM
Yes I'll try to figure out how tonight.
I will make one for the Ferrari edition as well.
CAS and I are going to redo that properly.

first of all, git is a distributed version control system - so there is no need to work permanently with the gitbucket server, create as much branches you need and work on them locally

you can always merge (using git, not manually) changes in one branch into another (or update you branch with master/main) - try to understand the concept and do not work around - that keeps the history intact

good clients (at first, easier to understand then the command client)
http://gitextensions.github.io/ (Windows only)
https://gitahead.github.io/gitahead.com/ (Windows and Linux)

I looked around for a good client (I was curious). Found GitKraken which seems a good choice for me.
Got it working and i kind of understand how it works.
Going to look at some tutorials later before I commit to anything.
But I did make some local branches already. So, so far so good.

Quote from: Cas on November 02, 2021, 06:19:29 PM
Oh, well, I really don't want to make it harder for Git to do its work!  I think I would be working on my local copy for testing, but then if I like what I have, I'll just redo the thing working in team, so we don't collide. My interest in these patch dependency trees comes from the idea that perhaps somebody would want to apply certain mods, but not certain others, so I was wondering if there was a clean way to exploit Git so that one could get different sources for any combination of mods... things like that.

a branch is:
-a thing you work on for a while - to be able to commit/track your changes even if you throw it complety away after weeks of work or gets completely merged after finishing it - without stressing other developers
(commit on logical finished steps - no need to keep the commit rate low to visual beautiness, its still possible to combine commits when merging a big new feature)

-some sort fork (with super-special features) that can easily update with the master or can bring back fixes etc. to the master - but keep its very own changes local to the branch

there shoudln't be too many or missue of branches for every itsy bitsy feature
better work with /D[DEFINE] and #IFDEF, #ENDIF to enable/disable some "features"

http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
Page 24 - how to set DEFINE per command line with /d
Page 184 - Using conditional directives
(test that stuff in a small asm to get familiar with)

something like tasm.exe /dNEEDLE_COLOR

and in code

IFDEF NEEDLE_COLOR
... changed code
ELSE
... original code
ENDIF

the Mod is then a build with serveral of that features activated in the make/batch-file

its the same thing with the /DTARGET=original in the makefile, thats is also IFDEF usage

there is really no need to invent a new style of doing it - branching and feature-configuration is so plain boring that you can copy that nearly from
every (multi developers) open source project around

and try keeping that all as automated as possible - use IFDEF, replace manual hex-editor patching with a script etc., build the variants out of the box
i would got that far to use github project and autobuild that stuff with the CI of github on every change - so there are always fresh build binaries around

O, I can make a parameter for the Ferrari edition.
So I can build the normal modified version or the same for the Ferrari edition with /dFerrari.

Quote from: Daniel3D on November 03, 2021, 09:24:18 AM
O, I can make a parameter for the Ferrari edition.
So I can build the normal modified version or the same for the Ferrari edition with /dFerrari.

yes, you can - or else the world would have been very hard for developers, the last 30 years :)

and normaly you do also the complete packaging with make or additional scripts - so also copying files, etc. - everything that is needed to get from source + additional changes to the release version without manual interaction

Ah, of course!  Yes, "defines" would be the best for this. At this time, it's a very tiny change, but if I see it'll become diverse, I'll start placing "flags".

Now I would like to tackle the matter of the independently configurable colours for both needles.

Quote from: Daniel3D on November 02, 2021, 07:30:51 AM
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  :)

...and now I have to modify a lot of my cars.....

Quote from: Ryoma on November 04, 2021, 03:03:24 AM
...and now I have to modify a lot of my cars.....

You don't have to.
Only if you want to change the colour.

Quote from: Duplode on November 04, 2021, 02:23:23 AM

Quote from: Daniel3D on November 02, 2021, 07:30:51 AM
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  :)

I've been thinking about that. It might be a piece of code that is used in a different display graphic setting. So it might give some issues in EGA CGA or Tandy graphics.
The game executable is only for the MCGA version. But the car.res file that has the bit changed is not limited to the MCGA.

Yes I want red for some Ferrari, the musa and the phedra. Black for the Ypsilon. And verify all 5he real dashboard. I will put a list of change here.

Quote from: Daniel3D on November 03, 2021, 09:24:18 AM
O, I can make a parameter for the Ferrari edition.
So I can build the normal modified version or the same for the Ferrari edition with /dFerrari.

sample code

; http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
; Chapter 15, Using conditional directives

; run tasm32 ifdef.asm
; run tasm32 ifdef.asm /DMY_MOD
; run tasm32 ifdef.asm /DMY_MOD /DMY_VERSION=1
; run tasm32 ifdef.asm /DMY_MOD /DMY_VERSION=3

; intern Symbols

MY_FLAG EQU "hello"
MY_FLAG2 = 1

ifdef MY_FLAG
%OUT MY_FLAG defined
endif

ifdef MY_FLAG2
  if MY_FLAG2 EQ 1
    %OUT MY_FLAG2 == 1
  endif
endif

; extern Symbols

ifdef MY_MOD
  %OUT do the mod code
else
  %OUT no modding code
endif

ifdef MY_VERSION

  if MY_VERSION eq 1
    %OUT its version 1
  elseif MY_VERSION eq 2
    %OUT its version 2
  else
    .ERR "Unkown version"
  endif

else
  %OUT no version given
endif

end


i did not find out how to print the conent of the symbol with %OUT or DISPLAY
something like %OUT the version: <MY_VERSION>

Quote from: llm on November 04, 2021, 09:24:08 AM

Quote from: Daniel3D on November 03, 2021, 09:24:18 AM
O, I can make a parameter for the Ferrari edition.
So I can build the normal modified version or the same for the Ferrari edition with /dFerrari.

sample code

Code Select Expand

; http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
; Chapter 15, Using conditional directives
etc.


i did not find out how to print the conent of the symbol with %OUT or DISPLAY
something like %OUT the version: <MY_VERSION>

That is ok.
I don't think it is possible with %OUT or DISPLAY to show a text with a variable.
(did a search in the documentation myself)
So if i want a message displayed, i will have to write it.
But thanks for the code and the doc.

QuoteTurbo Assembler provides two directives that let you display a string on the console
during assembly: DISPLAY and %OUT. You can use these directives to report on the
progress of an assembly, either to let you know how far the assembly has progressed, or
to let you know that a certain part of the code has been reached.
The two directives are essentially the same except that
DISPLAY displays a quoted string onscreen,
and %OUT displays a nonquoted string onscreen.

In both Ideal and MASM modes,the syntax for DISPLAY is

Code Select Expand

DISPLAY "text"
Where text is any message you want to display.
The syntax for %OUT in both Ideal and MASM modes is

Code Select Expand

%OUT text
Where, again, text is the message that you want displayed.

Here the cars list I want to change :
126C3   Yellow
355   green
408   red
512M   red
512tr   red
637   black
641   black
911   red
959   red
962   yellow
a164   yellow
Beta   red
c1      orange
Corvette   orange
CX      orange
delta hf   yellow
delta s4   red
diablo      orange
gto      red
hyena      red
ecv1      red
ecv2      red
mclaren F1   black
Musa      orange
mythos       red
Phedra      orange
Quattro    Orange
Testarossa   red
V16T      orange
Viper      Orange
XM      Orange
Ypsilon      Black

Quote from: Ryoma on November 04, 2021, 06:06:37 PM
Here the cars list I want to change :

Code Select Expand

126C3 Yellow
355 green
408 red
512M red
512tr red
637 black
641 black
911 red
959 red
962 yellow
a164 yellow
Beta red
c1 orange
Corvette orange
CX orange
delta hf yellow
delta s4 red
diablo orange
gto red
hyena red
ecv1 red
ecv2 red
mclaren F1 black
Musa orange
mythos red
Phedra orange
Quattro Orange
Testarossa red
V16T orange
Viper Orange
XM Orange
Ypsilon Black

That is quite a list. But easy to change if you know the Colour values.
But for orange, I do not really see a strong candidate.
0D could be one. (first row, near the end)
39 or 3A in the fourth row could work.
[made a quick reference card for you]

Done on my méga. I used 39.

Very happy, thanks. It's great step for the game.

Quote from: Ryoma on November 04, 2021, 08:37:28 PM
Done on my méga. I used 39.

Very happy, thanks. It's great step for the game.

Where is your mega link?

Click on the earth bellow my avatar

Quote from: Duplode on November 04, 2021, 02:23:23 AM

Quote from: Daniel3D on November 02, 2021, 07:30:51 AM
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.

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.

Quote from: Cas on November 05, 2021, 01:06:33 AM
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.

Quote from: Cas on November 05, 2021, 01:06:33 AM
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.

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.

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.

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.

Quote from: Daniel3D on November 06, 2021, 08:08:27 AM
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  :o

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

QuoteMisalignment 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 :)

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.

Quote from: llm on November 06, 2021, 09:15:07 AM
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  :o

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

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.

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

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)

Quote from: Daniel3D on November 07, 2021, 01:46:21 PM
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

Quote from: llm on November 07, 2021, 07:26:40 PM

Quote from: Daniel3D on November 07, 2021, 01:46:21 PM
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

Ah, that. I'm working on that. There is a lot I don't know. Leaning heavily on CAS again.

Trying to get my head around the Git. And working with that. But the program I found seemed ok but got stuck. I could make a local branch no problem, but to change code was a hassle, and I couldn't find any way to commit the change. Could not save it. Very annoying.
So I am saving everything local, just the changed files, and ill look for a simpler program. Something even I can understand.

Quote from: llm on November 07, 2021, 11:50:46 AM
But its really needed to find the rest of the non symbolic offsets, could be just a few
then changes are 100% safe

How can I recognize them?
Am I correct in assuming that these offsets are pointing at a specific line in the code and not a named stating point?
A fixed point that would change to the wrong value if you add lines before. (I'm thinking about how basic works, so I'm not sure how to see this in ASM)

Quote from: Daniel3D on November 07, 2021, 07:43:57 PM
Trying to get my head around the Git. And working with that. But the program I found seemed ok but got stuck. I could make a local branch no problem, but to change code was a hassle, and I couldn't find any way to commit the change. Could not save it. Very annoying.
So I am saving everything local, just the changed files, and ill look for a simpler program. Something even I can understand.

Its very easy, no idea what your struggeling with

Clone a repo, change files in you prefered editor/IDE, commit and push (if there is a remote repo attached) - thats it, there are tons of tutorials, videos - but im using different version control systems for decades, that makes it easy for me  8)

Dont mixup commit(lokal) and push/pull(remote or other local repo, gitlab, github, ...)
You never ever change a file in a git client

You need to add /m to the linker commandline to get a map file thats gives you infos about segment/function start in the resulting exe, and then you can use winmerge or other tool to compare original map file against changed sources

It's true that adding code, like we did, if there's any non-symbolic reference after the point that's changed, would distabilise the program. One thing we could do about it is, instead of just inserting code wherever we need it, we could just replace a piece of the code with a call instead, making sure the local code remains the same size. Then create a new code segment at the end to receive those calls. In other words, put all of our new patches at the end of the code.

It does look, though, like there aren't many of these non-symbolic references lurking around because our code appears stable. We just have to play the game using every possible function, try it many, many times and see. But what I said above is probably the safest option, although I don't know in TASM syntax how to force the new code to be at the end.

Again, I'm not very familiar with TASM-specific syntax, but placing something to force paragraph alignment as you mention, Ilm, would definitely help too!

Quotealthough I don't know in TASM syntax how to force the new code to be at the end.

Again, I'm not very familiar with TASM-specific syntax, but placing something to force paragraph alignment as you mention, Ilm, would definitely help too!

not "segment byte" but "segment para" , but you need to check the map file for movws because currently the para alignment is manual done with alignment bytes directly added in front or end of segments

tlink.exe is called with a commandline parameter that orders segments in source occurence order, so just add a new segment at end, thats it

Quote from: llm on November 07, 2021, 08:04:49 PM
Its very easy, no idea what your struggeling with

I teach Git stuff at meetups and at work, and most people have some trouble with it. I am not surprised if Daniel doesn't find it very easy.

I would suggest starting from the command line, even if it looks more difficult. You can keep your graphical client open on the side to see what happens. Then start with a toy repository and some tutorial, e.g., this one on freecodecamp (https://www.freecodecamp.org/news/learn-the-basics-of-git-in-under-10-minutes-da548267cc91/).

Quote
Yes, the title is a clickbait. There is no way you can understand the basics of git technology in just 10 minutes. But you can get pretty close in about 25 minutes. And that is the purpose of this article.

Hey, guys!  I'm reading the whole post and I can't find (or maybe I stupidly skipped) the binary download for ReStunts with the needle colour mod. Do you guys have it somewhere?

Quote from: Cas on April 15, 2024, 07:44:40 PMHey, guys!  I'm reading the whole post and I can't find (or maybe I stupidly skipped) the binary download for ReStunts with the needle colour mod. Do you guys have it somewhere?

Hi Cas,

Check the attachment "SKIDMCGA.EXE" on the following post link:
http://forum.stunts.hu/index.php?topic=3810.msg82262#msg82262

Cheers.

Thanks, Zapper!  Yes, I was sure I had skipped it!  It had to be there. I've already obtained it from the CCC Stunts download, but I knew it had to be in the forum. Cheers!

Seeing this thread appear reminded me of an issue I saw. @Ryoma, would it be possible to change the needle colour in the Koenig Testarossa??
I'd love to test this car more, but the white needles on white dials make this difficult. Don't want to give you another job, but just thought I'd ask ;)

Quote from: Spoonboy on April 17, 2024, 11:17:39 AMSeeing this thread appear reminded me of an issue I saw. @Ryoma, would it be possible to change the needle colour in the Koenig Testarossa??
I'd love to test this car more, but the white needles on white dials make this difficult. Don't want to give you another job, but just thought I'd ask ;)

Its an easy fix, doesn't change the car. So I'm sure it can be done quickly.
But Ryoma often updates his cars, so maybe it's already done. Check out his mega for the latest updates.