New mod: extended line of sight

[HerrOtto]

You cannot view this attachment.

Hi guys! I wanted to present you a Stunts mod I'm working on, which allows to see much farther objects.

The task is harder than I thought, but I can show you the easy version, which extends the line of sight to 8 tiles by sacrificing the lateral vision. The effect is not bad; as you can see from the attached screenshot it allows to see the first ramp from the starting line in the default track. Unfortunately it also shows the slalom road on top of the hill, which should be hidden. But I think it's still quite pleasant and should allow nice screenshots if one chooses the right track and point of view.

The mod is attached to this post. Let me know what you think of it.


Now the technical explanation, for which I'm much indebted to the Restunts project.
The game only draws 23 tiles: the one where the car is standing, the two immediately left and right of the driver, and a 5x4 rectangle in front of him. I rearranged the tiles in a narrower but longer configuration.

Code Select Expand

Legend:
$ : car (heading south)
O : drawn tile

Original:        Modded:

 O$O                O$O
OOOOO               OOO
OOOOO               OOO
OOOOO               OOO
OOOOO               OOO
                    OOO
                    OOO
                     O
                     O

The goal is obviously to convince the engine to draw more than 23 tiles, but this is much harder than reorganizing them, so it might take a lot of effort and the success is not guaranteed. I hope to come back with good news in future!

[alanrotoi]

Wow it looks great!!

[Duplode]

Welcome, @HerrOtto ! That's a very nice mod indeed. The long line of sight reminds me a bit of @Cas ' renderer, though of course this one is directly playable right now!

The clarification about the 23 drawn tiles is itself very interesting. If you have any notes or code about it that you'd like to share, that would be great 

[Cas]

Hi, HerrOtto!  This is indeed very good!  I think it can be done by taking a look at the assembly code. To draw more, you'll need to add more code, so the rest of the code will move forward and that will cause some artifacts, but this can be calibrated to align the paragraphs. I had this when working with Daniel3D for the colour needle mod. To have a more open view would enhance the experience a lot. Great work!

[HerrOtto]

Thanks for the nice words! Here a further improvement, where all objects are drawn using the high-detail model (the normal version uses a lower-detail model for far objects).


> The clarification about the 23 drawn tiles is itself very interesting. If you have any notes or code about it that you'd like to share, that would be great 

I intend to write some detailed doc when I have time. However, for a quick look, have a look at frame.c in Restunts:

line 309:

Code Select Expand

for (si = 0x16; si >= 0; si--) {
this is the cycle on the 23 tiles. It fills various 23-wide vectors.

line 320-21

Code Select Expand

var_pos2lookup = var_50[si * 3] + var_pos2adjust;
var_poslookup = var_50[si * 3 + 1] + var_posadjust;
The naming is not great, but var_50 points to the table containing the offsets of the tiles. It's a 23-long array, each element of which has 3 bytes:
* x offset of the tile to draw, wrt the tile where the camera is standing
* z offset of the tile to draw, wrt the tile where the camera is standing
* detail threshold (0 = draw always, 1 = only if detail is MEDIUM or FULL, 2 = only if detail is FULL)

z is the vertical axis in the track editor. I think the axis naming in restunts is not perfect, but I'll stick with the naming for now.

There are 8 tables of this kind (indexed at off_3C084), but each is just a rotation or mirror of the basic layout shown in my first post. Which table is used depends on the car's heading. To patch the data, I looked up off_3C084 (asmorig/dseg.asm:3697), saw where the location of the 8 tables was (unk_3BE9A, etc.), looked up some of the contents, searched for the corresponding bytes in the exe and changed the entries.

I have the impression that the code could work better if I sorted the tiles in the tables to be ordered by distance from the car, but the time was a little short and the task tedious enough... definitely something to do when I extend the engine.

 
> To draw more, you'll need to add more code, so the rest of the code will move forward

Yes, my point is that it's not a thing one can do by just editing the .exe, one must compile the project. Took me a while to set up the toolchain in my Linux system. Also, there are a lot of static arrays to resize, and forgetting one of them would be "unpleasant".

[Daniel3D]

Wow. That is an impressive modification. Enlarging the tables should be possible. I can recompile the source and CAS and Duplode have quite a bit of skill in either coding assembly or understanding the code.
If you like the four of us work together, we can investigate this opportunity thoroughly.

[Duplode]

I intend to write some detailed doc when I have time. However, for a quick look, have a look at frame.c in Restunts:

Thanks for the useful notes!

On the axes, z corresponds to the vertical axis on the track grid because y is (almost?) everywhere the height axis (even in various places where it isn't relevant to whatever is been done). In any case, there certainly are quite a few confusing names across the current Restunts code! 

[Frieshansen]

Hello HerrOtto - what a great idea!

[HerrOtto]

Wow. That is an impressive modification. Enlarging the tables should be possible. I can recompile the source and CAS and Duplode have quite a bit of skill in either coding assembly or understanding the code.
If you like the four of us work together, we can investigate this opportunity thoroughly.

Thanks, I'd be glad to work with you guys! Here are some notes:
* I managed to set up the build toolchain. It's a Frankenstein thing (Linux calling Windows calling Dosbox) but it works.
* Have a look at my fork of restunts: https://github.com/AlbertoMarnetto/restunts/tree/master/src/restunts/c
* I have renamed some generic/imprecise variables in frame.c; you can compare it with frame-original.c which is a copy the version in upstream (take commit 0c16bd9 ; I kept the same line numbers so it should be easy to diff). Check if you agree with the new names.
* The renames of the global variables must be performed on the asm code too. I could do it easily with a search-and-replace but it is my understanding that the asm files are somehow generated by IDA Pro, so the clean thing to do would be to update the IDA database. Do you know how the process works?
* We must check which arrays must be expanded. These are those I found, but a second or third pass in the code would be great:

Code Select Expand

currenttransshape
trkObjectList (EDIT: nope)
transformedshape_zarray[];
transformedshape_indices[];
transformedshape_arg2array[];
* I found is that I think the 3D rendering is made by the function "transformed_shape_op" (frame.c, line 1018) and the tile vectors are not used afterwards. If this is correct, it's good news because such function only receives one object at a time, so it should not be affected by the resizing of the tile vectors. I was fearing that there could be  many derived containers to resize (e.g. a list of geometric primitives to render); if it's not the case the modification could be faster than I thought.

I'm trying now to see how much I can progress.

[HerrOtto]

You cannot view this attachment. You cannot view this attachment.

Well, getting some results was faster than expected! Here is a version with a field of vision of 11 (width) x 10 (depth).

The exe is attached, you can find the source here: https://github.com/AlbertoMarnetto/restunts/commit/dd1be91e2b3a1078745d97de7b31b91445482536  (current master)

Unfortunately the rendering is glitchy, take ZCT282 and you'll see track items disappearing. Even on the default track, if you take the left branch, the final loop and bridge will disappear as you try to enter them. I have a hope that I know where the glitch lies: I could not enlarge the arrays in dseg.asm (adding bytes to the arrays makes the game crash), so I had to create local copies in frame.c . Maybe some subroutine like transformed_shape_add_for_sort expects the values to be in the former place and glitches out. If someone wants to try to enlarge the arrays in dseg.asm, or has some tips, I'd be very grateful!

[Matei]

The car doesn't move and...

memory manager - BLOCK NOT FOUND at SEG=
 54f3

[HerrOtto]

The car doesn't move and...

memory manager - BLOCK NOT FOUND at SEG=
 54f3

Sorry, I had attached the wrong executable. Now it should be fixed.

[alanrotoi]

Is it possible to make visible all the track instead of few tiles?

[Duplode]

* The renames of the global variables must be performed on the asm code too. I could do it easily with a search-and-replace but it is my understanding that the asm files are somehow generated by IDA Pro, so the clean thing to do would be to update the IDA database. Do you know how the process works?

Yup, the originally intended workflow involved alternating between analysis and porting through IDA scripts to keep everything in sync. The process is outlined in the Restunts readme.

(I'm not actually experienced with that workflow, as back in the day I did a fair amount of code reading and note-taking, but no porting. I keep meaning to rectify that, but couldn't get to sit down and focus on it yet...)