Flowchart of the menus

[Daniel3D]

Ok,

Since we (me for sure) know that the entire code is readable in assembly and creates a almost bit by bit copy of the game when reassembled we know everything is there. And i have seen calls to the various menu's.

I would like to make a flow of the menu parts that are connected and place the relevant pieces of code here.
One post per piece of code with notes and findings.

My hope is to build knowledge about the workings and maybe find a way to either hijack a button for our own purpose or add a button.
Since this part was written in c, i think it should be possible to add something and still have a working game after reassembly.

- Daniel.

[Daniel3D]

The place to start would be the Main menu i think.

https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asmorig/seg000.asm#lines-496

Code Select Expand


_show_menu:
    mov     ax, 2
    push    ax
    call    ensure_file_exists
    add     sp, 2
    cmp     is_audioloaded, 0
    jnz     short loc_10467
    mov     ax, offset aSlct; "SLCT"
    push    ax
    mov     ax, offset aSkidms_0; "skidms"
    push    ax
    mov     ax, offset aSkidslct; "skidslct"
    push    ax              ; char *
    call    file_load_audiores
    add     sp, 6
loc_10467:
    push    cs
    call near ptr run_menu
    cbw
    cmp     ax, 0FFFFh
    jnz     short loc_10474
    jmp     _prepare_intro
loc_10474:
    or      ax, ax
    jnz     short loc_1047B
    jmp     _do_game0
loc_1047B:
    cmp     ax, 1
    jnz     short loc_10483
    jmp     _do_car_menu
loc_10483:
    cmp     ax, 2
    jnz     short _do_show_menu
    jmp     _do_opp_menu
_do_show_menu:
    cmp     ax, 3
    jnz     short loc_10493
    jmp     _tracks_menu0
loc_10493:
    cmp     ax, 4
    jnz     short loc_1049B
    jmp     _do_option_menu
loc_1049B:
    jmp     short _show_menu
    nop


I see several references:
_do_game0              ; the Lets drive! button.
_do_car_menu          ; Car selection menu
_do_opp_menu         ; opponent selection
_tracks_menu0         ; track selection
do_option_menu       ; the options menu

ALso i See
_prepare_intro      ;i think that holds the timer that runs the replay if you wait to long.

[Daniel3D]

This is the piece of _prepare_intro.

]https://bitbucket.org/dreadnaut/restunts/src/master/src/restunts/asmorig/seg000.asm#lines-461[url][/url]

Code Select Expand


_prepare_intro:
    call    audio_unload
_do_intro0:
    sub     si, si
_do_intro:
    mov     ax, 2
    push    ax
    call    ensure_file_exists
    add     sp, 2
    or      si, si
    jz      short loc_1042D
    mov     ax, offset g_path_buf
    push    ax              ; char *
    mov     ax, offset a_trk; ".trk"
    push    ax              ; int
    mov     ax, offset gameconfig.game_trackname
    push    ax
    mov     ax, offset byte_3B80C
    push    ax              ; char *
    call    file_build_path
    add     sp, 8
    push    word ptr td14_elem_map_main+2
    push    word ptr td14_elem_map_main
    mov     ax, offset g_path_buf
    push    ax
    call    file_read_fatal
    add     sp, 6
loc_1042D:
    mov     idle_expired, 0
    push    cs
    call near ptr run_intro_looped
    mov     di, ax
    cmp     di, 1Bh
    jnz     short _show_menu
    jmp     _ask_dos


Don't understand everything, but this seems to contain a timer and replay loading.

@CAS.. as a proof of concept. Just to see if it can work without having to program a lot.
Can you add a button and add the trigger for the Idle replay to it?
(maybe in the new format by making the existing ones 3px smaller so you can make a 15x15 button at the end)

[Cas]

Uhm... I would have to read the code in detail and very well concentrated to be able to actually modify a routine. Adding a button would require structural changes that I can't understand right now because I haven't analysed how the code is distributed. Removing a button is more feasible. The thing is that the coordinates of the button areas appear to be in a different memory region instead of within the function and this region has a certain size. If I change that size, I don't know how the code will react. So I'd be forced to completely replace the main menu function to do that if I want to avoid modifying that memory region. I better read more before doing that.

[Daniel3D]

I don't think that changing the size will break the game.
Because it was written in c but influences everything.
But that is why I want to test this.
Make a small change and create an offset. Recompile the game and see if it is broken.

Because i can´t program. the way i managed to make stuff was by first braking it a dozen times.
But solutions i got working were effective but not something a developer would make,
(using  basic, windows commandline and powershell instructions in about 60 lines of code)

And you are right about the code. It's not the complete picture. I'm missing the connection between the button coordinates and the the functions. unless you see them somewere.

[Cas]

I wouldn't recommend trial-and-error or code that you don't understand well. The thing is that many bugs are not evident when present. If you make a change that produces a bug and you don't understand the code, it may happen that everything seems to work fine, so you continue to work, but one day, something fails and by that time, you've made so many changes that you no longer know which of your changes is causing the bug. To modify a routine, you have to really understand how the routine works. If understanding the routine is too complex and you want to have something else, then the best thing to do is to completely replace the routine with a brand new one that you fully understand. It seems like more work, but in the long run, it saves time and suffering.

Anyway, we're talking about the main menu, the simplest routine in the program. I'm confident that we can get to fully understand it. If I had more time, I'd already be deep in it.

I have not been reading the routine, but I imagine 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. It won't be very easy to spot without reading the whole main loop. Again, I'm not currently reading the code. I'm speaking from my mind. I'm at work!

[Daniel3D]

Based on what I understand in the code and what I experience in the game, I see three main segments, one sub-segment.
Segement:

• The intro of the game (intro music)
• the Menu's, including the selection screens and the track editor. (continues music)
• The race engine
• opponent win/lose screen and high score

The menu's with opponent selector, car selection, track selection/editor and options all seem to be related to each other.
I am not sure if it is feasible to cut out just the main menu. We may have to replace all menu's, or it may be easier to do so.

That will create an offset in the assembly coded part (game engine) and before we even attempt this I would like to know if something breaks if we create a offset.

We need to know:

• How car, track and opponent selection is stored.
• How we can change those variables.
• How options are stored
• How we can change the options variables
• If there are unused options that may function on better machines.

[Cas]

Track, current car and other information like that is reasonably well documented, I mean, like where in memory it is stored and in which format, in the wiki and forum. I don't remember exactly where, but I have read some of that.

But yes, there are variables for sure that have not been identified for what they are in the code, so careful attention should be put to potential global variables being accessed from the main menu function or perhaps variables being shared (exported) to other functions. Other than that, I imagine (but don't know if it's really so... I should read the code with time) that replacing the whole function is more feasible than modifying it selectively.