Stunts Forum

Screenshot from 2025-01-27 01-25-05.png

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.

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!

Wow it looks great!!

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

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!

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:
for (si = 0x16; si >= 0; si--) {
this is the cycle on the 23 tiles. It fills various 23-wide vectors.

line 320-21
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".

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.

Quote from: HerrOtto on January 27, 2025, 03:16:04 AMI 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!  :D

Hello HerrOtto - what a great idea!

Quote from: Daniel3D on January 27, 2025, 09:59:02 AMWow. 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:

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.

Screenshot from 2025-01-28 03-03-52.png Screenshot from 2025-01-28 03-03-34.png

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!

The car doesn't move and...

Quotememory manager - BLOCK NOT FOUND at SEG=
 54f3

Quote from: Matei on January 28, 2025, 09:06:57 AMThe car doesn't move and...

Quotememory manager - BLOCK NOT FOUND at SEG=
 54f3

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

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

Quote from: HerrOtto on January 27, 2025, 11:17:58 PM* 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...)

So, I have mixed news:

* the glitches in the modded game happen because the engine can store only up to 400 polygons. I thought it would store the polygons of a single tile, draw them and then discard them. But no, it wants to store all polygons in the scene before drawing them, and with a 11x10 field of vision it's very easy to overflow the space
* when the space for the polygons is exhausted, the engine just stops drawing and shows only the objects rendered up to that point (technically, transformed_shape_op_helper returns 1, triggering the line `if (var_transformresult > 0) break;` in update_frame)
* and since the engine uses a painter's algorithm, when this happens only the farther objects will be drawn, while the nearest will be left invisible
* I have tried to extend the number of polygons by making the storage bigger (word_40ED6, polyinfoptrs) but if I do so the game crashes. I've spent many hours debugging this but still no success. The game gets stuck in the loop of get_a_poly_info (asm006), which suggests that my resizing damaged the structure of the linked list where the polygons are stored (word_40ED6). But it's hard to pinpoint the error.

---

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

I think it depends on:
1. whether we can successfully make more space of the new polygons
2. whether the memory is sufficient to store the whole track

Note that if the track is very simple (not many objects) this is actually possible right now. One just has to download my experimental code (https://github.com/AlbertoMarnetto/restunts , master branch), change TILES_TO_DRAW_WIDTH and TILES_TO_DRAW_DEPTH in frame.c (up to 30) and  adjust the end of dseg.asm 

---

I must give up my efforts for now. But I have some ideas:
1. find the bug in get_a_poly_info and make more space for the polygons (ideal solution)
2. if not possible, adjust the drawing routing so that it really draws one tile at a time, and then frees the memory
3. if not possible, adjust update_frame so that it automatically reduces the # of tiles if there are too many polygons

@Duplode if you can update the IDA database, here are the global names I changed in my code:

byte_3C09C --> detail_threshold_by_level
off_3C084 --> tiles_to_draw_offsets_tables
timertestflag2 --> detail_level
transformed_shape_op_helper2 --> projectiondata9_times_ratio
transformed_shape_op_helper3 --> is_facing_camera
transformed_shape_op_helper --> insert_newest_poly_in_word_40ED6
word_40ED6 --> poly_linked_list_40ED6

Hey, turns out that Plan 3 was easy to implement! This version in attachment is not perfect but seems playable. It tries to draw its 10x11 rectangle of tiles, if there are too many polygons it discards the whole scene and recalculates it with a narrower field. It is horribly inefficient – on a complex ZCT track you'll need a 486 :-) , or crank up your DOSBox cycles – but it is quite playable.

I'll try to devise better methods if I find the time. For now, hope you'll enjoy this version!

And here a small further improvement (better tile prioritization)

Unlike I tested it the first time, now I tried with other cars and most often it worked. A Pentium 4 at 3.4 GHz is of course not fast enough...

https://github.com/libsdl-org/sdl12-compat/

Btw, I have solved the engine to load any number of tiles (even all of them if you want), no graphical problems at all and it runs well even in the above conditions, but no one is interested... (Cas helped a little)

The view from ZCT275's high jump  8)

(https://i.imgur.com/ZxJ3Tqh.png)

Quote from: HerrOtto on January 29, 2025, 12:13:14 PM@Duplode if you can update the IDA database, here are the global names I changed in my code:

Not sure when I'll manage to get back to properly doing Restunts work (I'll try to make some time for that in the upcoming month!), but we'll surely want to keep such notes well-preserved. A cluster of pages in the Wiki (https://wiki.stunts.hu) could make sense...

This is my latest version, where I tried to do some minimal optimizations. It works well most of the time. Unfortunately, sometimes the tiles near the car still disappear, so it's not really ready for competitive use. I don't know what is the source of the problem but I'm running out of time, so I think this is the best I can do for now.

I investigated the possibility of extending the max # of polygons, but after a long debug session I had to find out that the bugs were due to the exhaustion of the memory (the stack would grow to the point of overwriting the globals – bad things ensued and it cost me a huge amount of time to find out the error). Extending the max polygons would still be possible, I think, if we managed to  allocate a dedicated memory segment for polyinfoptrs. But it would be a huge project and the success would not be guaranteed.

I'll be writing some documentation in the next days, meanwhile I'd appreciate your impressions about whether this version is of your liking.

We are making progress, pipsqueaks! I managed to find the source of the failures and obtained a version that, I daresay, plays very comfortably. I did not have much time to test it but run ZCT282 a couple of times and did not see the tiles around me disappearing.

I will open a thread in Stunts Modification Projects and leave this to the technical discussion. I still want to tune a couple of details, but this is already a version worth playing for pleasure and not only for testing. Let me know your impressions and, if you can, try to test with other tracks (I fiddled with some multi-tile code, so I wonder how the engine behaves with illusion tracks).

Note: the number no top left shows the number of tiles discarded when the scene is too complex. You may ignore it, but it's useful to me for debugging (and demonstrates a simple way to print arbitrary infos while playing)

Hey!  This is really great!  You can do a lot of progress in a little time!  I also tried (and gave up, in my case) to set up the toolchain in Linux, so Daniel3D has been doing the compiling and helping finding code, testing and analysing during my experiments, but this is a higher level than what we achieved.

I've been thinking, regarding Stunts mods, that more efficient results could be obtained by branching out the mod code and using a lightly modded Restunts as a hub. That way, we can write modes directly in separate files and a little piece of code connects them to Stunts and you can plug them and unplug them freely and independently. Same way, if you have access to all polygon data, you don't need to be limited by Stunts: you could write a simple renderer and redirect it. But anyway, it looks great to have it all in a DOS Stunts binary!

A non-important detail: in the first binaries you shared, I could add "/ssb" and it went on with SoundBlaster, but the latter ones always sound like PC Speaker. Is there a reason for it?

> A non-important detail: in the first binaries you shared, I could add "/ssb" and it went on with SoundBlaster, but the latter ones always sound like PC Speaker. Is there a reason for it?

Thanks for noticing that. The first binaries are the original Stunts executable where I hand edited the tiles; the others are instead built with the Restunts toolchain. As far as I understand, Restunts should support sound cards quite fine, so I'll investigate why it does not work.

Concerning your idea of combining mods: my plan is to commit general improvements (variable labeling and comments) to the main master branch and then compact the real mod in just one commit. This way one can combine it into any other mod via a `git cherry-pick` command.

> I also tried to set up the toolchain in Linux

Took me a lot but the solution is dead simple :-) Just

* install Wine (but I guess you already have it)
* mount the restunts dir as drive S using winecfg
* in the Linux console type wineconsole cmd* in the resulting Wine console type (mind the inverted slashes and the lack of tab completion):
s:
cd src\restunts
..\..\tools\setpath

And then just type make every time you want to build your changes.

I made some tiny modifications to the build files in my branch but it should work also with the version currently in master. If not, let me know, I can send you the diff I used (basically just suppressed all the pop up windows)

Investigated: it's a bug in Restunts, will submit a fix for that. Good catch!

Quote from: HerrNove on January 31, 2025, 08:44:41 PM* install Wine (but I guess you already have it)

Wine!! I had pretty much forgotten it existed, and so had overlooked the possibility. I'm definitely trying this later! (While I have a Windows install around, switching systems just for running the toolchain is a bit of a hassle.)

Oh, I do have Wine installed now because I needed it to compile the Windows port of Pretty Garage, but I normally don't use it for anything else. I could try this.

My idea is to actually circumvent the tool chain completely by making a single base mod. Then the actual hub I was mentioning would be an external assembly binary that would load the mods and the mods themselves could also be written in something more comfortable, such as Flat Assembler, so no need to touch the main code any more and mods could be plugged and unplugged hot, without recompilation. But what you're doing is more like the original spirit of the Restunts project, I think.

I'm also planning to make a mod to report the car coordinates and other data to a file during the game loop in every frame and then pick this up with my engine and send it to a small server, so that we can play live in network and actually see other pipsqueaks. Shouldn't be very hard. Only thing I don't have is something to draw wheels, ha, ha.

Audio fixed and mod baptised :) I opened a thread in the Mods section: https://forum.stunts.hu/index.php?topic=4404.0

But we can further discuss here about the more technical points. Your plan seems very interesting, I have not the skills to implement it myself but I'm totally willing to make my plugin compatible with your hot-plug framework when you when you find the time to create the infrastructure.

nice project  :o

Quote from: HerrNove on January 27, 2025, 11:17:58 PM* 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?

i helped starting the restunts project (but mainly driven by users clvn/dstien) - i wrote the drvcombiner tool in the src folder

IDA process is: changing the names in IDA + running the src/idc/anders.idc script from IDA - that generates the complete asm code

problem with IDA is: we used the commercial version of IDA in the beginning and everyone needs to have the same IDA version user with older or freeware versions are not able to open the IDA file

i always wanted to change the assembler from Turbo Assembler to UASM or WASM and using a recent linker like WLINK or ULINK - so multi/cross platform builds are esier doable - but never found the time

Definitely, the greatest advancement in modding of the actual code for a long time. Will deserve a Wiki article.

How did you do about paragraph alignment?  When I worked with Daniel3D on the needle colour mod, we had to test several times and add padding NOPs to prevent glitches.

Doesn't modding the actual code matter if nothing is left of it? The advancement doesn't get any greater than that and the cars also move properly now...

Quote from: llm on February 01, 2025, 03:10:00 PMproblem with IDA is: we used the commercial version of IDA in the beginning and everyone needs to have the same IDA version user with older or freeware versions are not able to open the IDA file

I am a beginner with Ghidra and not so willing to (pirate and) learn a different debugger, so I will be pragmatical: after I cleanup the code I will submit my labelings made with search-and-replace. This will put the .asms out of sync with the IDA database, but one can always adjust that at a later time.

Quote from: Cas on February 01, 2025, 05:46:00 PMHow did you do about paragraph alignment?  When I worked with Daniel3D on the needle colour mod, we had to test several times and add padding NOPs to prevent glitches.

Thankfully I only changed C code (apart for the variables declarations), so the linker took care of everything :-)

Quote from: Matei on February 01, 2025, 09:34:33 PMDoesn't modding the actual code matter if nothing is left of it?

I'm not sure if I interpret this sentence correctly, but my mod changes maybe 0.1% of the game code, so there is actually a lot left.

The correct interpretation:

https://matei.one/idxscr.html

https://sourceforge.net/projects/simple3d/

There's also a little movie at the second address. Anyway, the program that you chose seems pretty hard to change if you only got to 0.1%...

Awesome, @HerrNove -- the 1.0 mod looks lovely in-game!

(Cross-quoting from the other thread:)

Quote from: HerrNove on February 01, 2025, 10:57:37 AMI have only changed the rendering code, the physics should be exactly to same. However, I noticed that my replays made with the Zakstunts 2025 version tend to de-sync, so I don't recommend using this version to produce competitive runs (also, the extended LOS could be considered a cheat). The replays made with other Restunts-based mods should play fine.

That's an interesting situation. My first guess was that the replay incompatibility would be something similar to unstable replays (https://wiki.stunts.hu/wiki/Unstable_replays), which seem to happen due to the graphical layer somehow interfering with the execution of the physics in the game loop given a fast enough processor (emulated or otherwise). However, with your executable there is no divergence between the fast-forward timeline and the normal playback one (I'm using the terminology from the Wiki article here), so the effect here seems to be something else. A few other things I have noticed:

• The de-syncing can be pretty subtle. A Default lap I drove with the mod only becomes obviously different by the long bridge when replayed on plain BB 1991.
• Other Restunts mods with unchanged physics, like the 1.1 M1.1 available from CCC (https://ccc.mystunts.net/) are replay-compatible with plain BB 1991, and de-sync in the same way relative to SuperSight 1.0.
• There are a few subtle differences in menu behaviour with SuperSight 1.0: the screen transitions feel a little slower, and the arrow keys don't work when entering text in dialogs (only backspace does).
• These differences seem to have started with the first 11 x 10 executable from this reply (https://forum.stunts.hu/index.php?msg=96456). The initial two executables you have posted, with the narrow line of sight, don't have them.

Hm, this might hint to the fact that I am still using too much memory and the stack is overwriting some global variables, albeit in a non fatal way. Definitely something to look into.

Quote from: Duplode on February 02, 2025, 03:31:32 PMOther Restunts mods with unchanged physics, like the 1.1 M1.1 available from CCC (https://ccc.mystunts.net/) are replay-compatible with plain BB 1991, and de-sync in the same way relative to SuperSight 1.0.[/li][/list]

Now this is interesting, because if I build Restunts from the master branch, it still desyncs my replay made with the Zakstunts edition. I wonder if building the game under Linux+Wine is introducing subtle differences.

If you have the time, would you help me with a cross-check?
* if you use a pure Windows platform, try to build my mod (https://github.com/AlbertoMarnetto/restunts/tree/supersight – use commit 1e81d6b i.e. the current head) there and check if the replay desyncs in the same way
* provide me a link to the source code of your branch (if public), and maybe your replay so that we have a common reference; I'll build it on my machine and check whether it de-syncs
 

Quote from: HerrNove on February 02, 2025, 09:54:40 PMI wonder if building the game under Linux+Wine is introducing subtle differences.

That's definitely worth checking!

Quote from: HerrNove on February 02, 2025, 09:54:40 PMIf you have the time, would you help me with a cross-check?

Sure! I should be able to do it either tomorrow or on Tuesday. I'll build your mod on Windows and redo the tests.

On repositories: I currently have a private fork on Bitbucket, which I used some time ago for working on the DAF Museum mod (https://forum.stunts.hu/index.php?topic=4152.0). While I can make it public or grant you access, given that the future of Bitbucket doesn't look too rosy (https://www.atlassian.com/blog/it-teams/important-changes-coming-to-bitbucket-clouds-free-plan) I'm thinking of bringing it over to GitHub anyway.

For the moment, I have attached the Default replay I mentioned, driven on SuperSight. You'll notice that I went a little too slowly onto the bridge, and failed to get powergear. When replayed on plain BB 1991, the Indy instead gets powergear on the ramp, and so the car misses the corner after the bridge and loses its way. 

Since I got the attention of the experts, let's try to squeeze some of their knowledge...

Last weekend I wasted a couple of hours by trying to alleviate the memory problems of my program. My plan was
* modify dseg.asm create an extra data segment, called fseg
* move the big containers for the runtime graphics data (polyinfoptr and co.) there
* add an `assume fs:fseg` directive so that the linker can keep using 16-bit pointers. Put some assembly at program start to load the FS register with the fseg segment address

The plan failed, but I think it's because I am not expert enough in assembly programming. In particular, when I put in a C file the assembly fragment to set FS, the Borland compiler complained that FS is not a valid name (this despite me adding the -3 option, that should compile for 386 processors). The linker also complained about "fixup errors"; changing the model to `huge` alleviated that but I think this is wrong since we should be able to keep working with 16-bit pointers.

Ideas are welcome.

Uhm... I'm comfortable with assembler, but not used to combining it with high level code. Compilers can do very different things from one another. Even Turbo Assembler is actually more like a high level language and I get lost in the directives. What I can tell you is that the 386 did have FS and GS, so it should be fine.

So, here I have pushed my fixes for vanilla Restunts:

https://github.com/AlbertoMarnetto/restunts/tree/master/

I would have opened a CR in dreadnaut's repo, but dreadnaut seems busy and in his repo there is a 3-year-old CR still waiting to be merged, so I'll use my repo for the meanwhile. I'll be happy to transfer the project to Duplode's profile or some other active member's.

Anyway, I made various fixes to the master branch, fixing and improving the makefiles. They are still not perfect, e.g. the .asm dependencies do not include the .inc files, but the build process works.

https://github.com/AlbertoMarnetto/restunts/tree/master/

The branch includes meaningful labelings for many variables, and extensive commentary in the tile rendering routine:

https://github.com/AlbertoMarnetto/restunts/blob/master/src/restunts/c/frame.c

Moreover, I have cleaned up the SuperSight branch. Today's version adds correct processing for the illusion tiles (so that now the hidden elements appear only when the car is driving on them, like in the vanilla game) and minor fixes. Still unpublished since now that we have a working version I don't want to spam the forum with each minor patch, but feel free to build and try it.

https://github.com/AlbertoMarnetto/restunts/tree/supersight

Quote from: HerrNove on February 02, 2025, 03:07:42 PM

Quote from: llm on February 01, 2025, 03:10:00 PMproblem with IDA is: we used the commercial version of IDA in the beginning and everyone needs to have the same IDA version user with older or freeware versions are not able to open the IDA file

I am a beginner with Ghidra and not so willing to (pirate and) learn a different debugger, so I will be pragmatical: after I cleanup the code I will submit my labelings made with search-and-replace. This will put the .asms out of sync with the IDA database, but one can always adjust that at a later time.

Ghidras support for 16bit DOS segmen/offset stuff etc. is in a very early stage and often buggy

and i think there is no one on this forum who can currently change the IDB besides me :) - maybe dstien is around, clvn is not active for a long time

Quote from: HerrNove on February 03, 2025, 02:19:37 PMSince I got the attention of the experts, let's try to squeeze some of their knowledge...

Last weekend I wasted a couple of hours by trying to alleviate the memory problems of my program. My plan was
* modify dseg.asm create an extra data segment, called fseg
* move the big containers for the runtime graphics data (polyinfoptr and co.) there
* add an `assume fs:fseg` directive so that the linker can keep using 16-bit pointers. Put some assembly at program start to load the FS register with the fseg segment address

The plan failed, but I think it's because I am not expert enough in assembly programming. In particular, when I put in a C file the assembly fragment to set FS, the Borland compiler complained that FS is not a valid name (this despite me adding the -3 option, that should compile for 386 processors). The linker also complained about "fixup errors"; changing the model to `huge` alleviated that but I think this is wrong since we should be able to keep working with 16-bit pointers.

Ideas are welcome.

thats a hard one,

Quote* modify dseg.asm create an extra data segment, called fseg

that should work if its at the very end - or before stack with some fixes for the stack start

Quote* move the big containers for the runtime graphics data (polyinfoptr and co.) there

1. works only if there are no non-symbolic offsets in the assembler(or C) refering to this data
2. the other (non yours) polyinfoptr and co. using code needs to use then fs instead of ds (or whatever register is use at that point to the segment)

big pain-point with restunts for me was always - there are offsets in the code that are non-symbolic

I think I must give up for now. I managed to switch to 386 mode, create the new segment and put its offset in FS. The game builds but the graphics are horribly mangled, as if even the address of the video buffer had been corrupted. The game also records stray keyboard inputs. It's annoying because it's clear from the image that the 3D rendering algorithm is working, even after some of its data have been moved to the far segment, so it's really a case of some hidden offset that should be adjusted.

I tried to put the new segment before everything, between stack and data, just before endseg and after endseg. I also tried adding an empty segment to work as padding. None of these options worked.

The game appears to work if I only add new variables in the segment and only refer them from the C code. If this is really the case (I only tried with one 2-byte variable) it would at least allow me to produce new mods on top of SuperSight. But my original goal, to put the graphic data in the new segment and break free from the limit of 400 polygons, seems for now unattainable.

Screenshot from 2025-02-05 14-22-03.png

Quote from: HerrNove on February 02, 2025, 09:54:40 PM* if you use a pure Windows platform, try to build my mod (https://github.com/AlbertoMarnetto/restunts/tree/supersight – use commit 1e81d6b i.e. the current head) there and check if the replay desyncs in the same way

I couldn't get to it yesterday (it was a long day...), but now I've just done a few tests on Windows. SSTWIN.RPL and SSTWAU.RPL were driven with your mod (latest from GitHub, built on Windows), and they de-sync on plain BB 1991... but so does RSCWIN.RPL, which was driven on base Restunts built with make restunts! Furthermore, the base make restunts build also has the keyboard arrows issue.

It appears, then, that the issues affect Restunts builds with ported code (make restunts) generally, rather than just your mod or the Wine build process. The Restunts builds we had been using elsewhere (Mod 1.0, Mod 1.1, DAF Museum) were based on asmorig/make restunts-original instead. That's good news in that the issues aren't side effects of your mod, even if that also means there will be future work in debugging the ported code.

Oh, that's interesting news! One could probably run a git bisect and find out the culprit. Unfortunately I have no time for that right now but it's good to know that I didn't make the situation worse :-)

Thanks for your research!

On second thought, this replay issue seems pretty important. First because I want that SuperSight is able to be used with 35 years worth of past replays, second (and more important!) because if replays desync it means that the repldump version in master is broken.

I was able to determine that the fault happens somewhere in update_car_speed. I cannot find where the conversion from assembly to C introduced a discrepancy wrt the original Stunts, but simply replacing the function with its original asm version solves the issue. I'll publish a fixed Restunts and a fixed SuperSight soon.

OK, I published the fixed version in the other thread! Now the vanilla replays play correctly – and, as expected, your files recorded with the Restunts builds with ported code desync. But I fixed Restunts master too, so from now on, if we take my fixed version as base, we should not have this problem anymore: the replays of BB Stunts and future Restunts versions will be compatible; the replays made with older Restunts will stay broken but I think this is not particularly worrying.

It's great that you managed to stabilise it!  Can you compile the colour needle mod into this modded binary? Here are the details on how it works:

https://wiki.stunts.hu/wiki/Needle_colour_mod

I think we should sync to discuss how we could implement plugins for mods. We could join forces there.

Quote from: HerrNove on February 07, 2025, 08:42:32 AMI was able to determine that the fault happens somewhere in update_car_speed. I cannot find where the conversion from assembly to C introduced a discrepancy wrt the original Stunts, but simply replacing the function with its original asm version solves the issue.

Good move! My guess is that the porting bug in update_car_speed is something like a subtle truncation discrepancy. I'll investigate that at some point in the coming week.

Quote from: Cas on February 07, 2025, 06:19:18 PMCan you compile the colour needle mod into this modded binary? Here are the details on how it works:

I believe the mods are currently separate because the needle mod was done on asmorig, while SuperSight was done on the ported code. That said, as long as the code touched by the two mods doesn't overlap (and I think it doesn't) it should be straightforward for us to compile a bespoke binary combining the two -- that's the same kind of thing HerrNove has done to avoid runniing into the de-syncing bug.

Needle color added as the Oxia cockpit shows. I could not find a nice car with different colors, but tried the GTON used in the needle thread and the needles appeared one gray and one white, so I think the patching was successful.

One thing I found out is that Restunts crashes (out of memory) if I select the Diablo. None of the other cars has the problem, but it's annoying.

I do not release yet this version in the modification thread because I want to keep that thread relatively clean and not spam everyone. I'll test this version for some time, then I'll publish it. But you can already test it.

Screenshot from 2025-02-07 23-38-02.png

I think that you could use the Ferrari F40 (ZF40) since it has use of almost the limit of vertices/faces allowed by game's engine. I also suggest to check stability of this developments with a race with opponent using an high detailed car.

I congratulate you for your job on getting such improvements! Very nice  ;)

I'm getting a crash with the Hexa too!  I also notice I have to use more cycles in DOSBox for this binary than from the original, but that's fine.

Great that you were able to compile it with the needle colour mod!  Thanks!

@Duplode - Yes, this is a different part of the code and it's just a very small change.

I've just tested this and it looks great!  Improving the draw distance of Stunts is something that I've always wanted, but didn't think was possible. :D

During my test, I made the following interesting observations:

• As mentioned, selecting the Baronetti HEXA or Lamborghini Diablo VT crashes the game with a "reservememory" error.
• However, giving an opponent either of the above cars works fine.
• As per @Zapper's suggestion, selecting the Ferrari F40 and also giving it to an opponent works fine.
• Selecting the Caterham Super Seven JPE works fine, but giving it to an opponent crashes the game with an "unhandled primitive type 5" error.

Thanks for the research!

Quote from: KyLiE on February 08, 2025, 04:08:29 AM

• As mentioned, selecting the Baronetti HEXA or Lamborghini Diablo VT crashes the game with a "reservememory" error.
• However, giving an opponent either of the above cars works fine.

This makes sense. The allocation fails because the game does not find space for the .VSH file, which I think is the graphics of the cockpit.

Quote from: KyLiE on February 08, 2025, 04:08:29 AM

• Selecting the Caterham Super Seven JPE works fine, but giving it to an opponent crashes the game with an "unhandled primitive type 5" error.

This is a problem in Restunts that has only reimplemented 99% of the Stunts code.

So in general, I think most of these problems can be fixed by porting my mod to work with the original assembly and not with the Restunts-rewritten versions. And so...

...I have done just that! This version seems to work well, runs all cars, debugs do not desync. But I made it in haste, so please test it!

EDIT: removed, see below.

Screenshot from 2025-02-08 14-15-28.png

I had forgotten to reapply the needle color fix, so here a small update, which could also be the final one for this project if no errors arise. Enjoy Herr Otto and Herr Nove racing on their Caterhams, with black speed needles and no crashes!

Screenshot from 2025-02-08 14-51-00.png

Quote from: HerrNove on February 08, 2025, 02:20:12 PM...I have done just that! This version seems to work well, runs all cars, debugs do not desync. But I made it in haste, so please test it!

EDIT: removed, see below.

Screenshot from 2025-02-08 14-15-28.png
[/quote

Quote from: HerrNove on February 08, 2025, 02:20:12 PM...I have done just that! This version seems to work well, runs all cars, debugs do not desync. But I made it in haste, so please test it!

EDIT: removed, see below.

Screenshot from 2025-02-08 14-15-28.png

Is this an edited image or

Quote from: HerrNove on February 08, 2025, 02:20:12 PM...I have done just that! This version seems to work well, runs all cars, debugs do not desync. But I made it in haste, so please test it!

EDIT: removed, see below.

Screenshot from 2025-02-08 14-15-28.png

Quote from: HerrNove on February 08, 2025, 02:20:12 PM...I have done just that! This version seems to work well, runs all cars, debugs do not desync. But I made it in haste, so please test it!

EDIT: removed, see below.

Screenshot from 2025-02-08 14-15-28.png

Is this an edited image or the farsight effect makes the clock move from its place or it is a replay?

It's a replay. In live racing the clock is where it should be.

Screenshot from 2025-02-09 17-59-25.png

I don't have much to add but that this is an excellent mod @HerrNove! 8)

One thing I am wondering about is if there is a way to make the game render illusion elements earlier. If so, that would greatly increase the track-building possibilities without the (for some pipsqueaks) annoying side effect. Perhaps your next project?  ???

Excellent!  I'm testing it now. It works great. It is, of course, a little more demanding as it draws more polygons, but it's just a few Ctrl+F12 clicks and it's perfect.

Quote from: HerrNove on February 02, 2025, 09:54:40 PM* provide me a link to the source code of your branch (if public), and maybe your replay so that we have a common reference;

I said earlier that my fork on Bitbucket was private. Embarrassingly, it turns out I was wrong about that  :o I must have mixed it up in my head with some of the other private Stunts-related repos I have there. Anyway, this is the fork: https://bitbucket.org/duplode/restunts . I think the only branch not available from elsewhere is the "siluro" one, which has the tweaks for the DAF Museum edition. (Also, I still plan to move this away from Bitbucket...)

You know, this mod project is like a 4X game. You would like to save and exit, but you keep thinking "just one more thing...". So, here the newly-baked SuperSight. The final-final-for-real-this-time (lol) version.

I have spent a lot of time and attempts to try to raise the limit of 400 primitives, and I've finally made it! The gain is not immense, but it had become a matter of principle for me. Now the game can display about 480-500 primitives, which means that complex scenes will be rendered more fully. You can check how many polygons are being rendered, as well as other infos, by pressing F5.

For future researchers only: the new limit is given by the memory buffer allocated to the primitives: it is 10400 bytes big and the primitives are up to 26 bytes big, with an observed average of 21.5. I tried increasing the buffer but the game tends to crash at about 11000-11200 bytes, leading me to think that other unknown buffers in the game are being overrun. I think we are hitting the point of diminishing returns, so I stopped here.

Quote from: Argammon on February 09, 2025, 08:13:49 PMOne thing I am wondering about is if there is a way to make the game render illusion elements earlier. If so, that would greatly increase the track-building possibilities without the (for some pipsqueaks) annoying side effect. Perhaps your next project?

Oh, I thought illusion tiles were a deliberate effect of the track designers :D Restunts made them visible (the "hiding code" was defective) and I made them hidden again as part of my fixes. So removing the invisibility effect is as simple as removing the fix. But you know what, to accommodate each taste I have made the option configurable: the engine by default will behave as the original Stunts, but pressing F6 will toggle the visibility of illusion elements.

And if pressing F6 every time is too annoying, open the file with a binary editor, search for the string "ZakS" and change the second 00 byte following it into a 01.

Quote from: Cas on February 09, 2025, 10:05:43 PMExcellent!  I'm testing it now. It works great. It is, of course, a little more demanding as it draws more polygons, but it's just a few Ctrl+F12 clicks and it's perfect.

When playing this mod I highly recommend tuning DOSBox's CPU as follows:

[cpu]
core=dynamic
cputype=auto
cycles=max
I'm playing with these settings and the mod is running very fluid. Granted, I have a good PC but nothing extraordinary (AMD Ryzen 7 5700U).

You've done some excellent work on this!  I've been testing it again and I noticed a small issue.  When you enable the debug information, the text on the opponent evaluation screen changes to light blue.  It's still readable, but I wanted to know if it's possible to change the colour and position of the debug information so that it doesn't blend in with the sky and interfere with the clock.

Quote from: HerrNove on February 10, 2025, 12:20:25 AMI have spent a lot of time and attempts to try to raise the limit of 400 primitives, and I've finally made it! The gain is not immense, but it had become a matter of principle for me. Now the game can display about 480-500 primitives, which means that complex scenes will be rendered more fully. You can check how many polygons are being rendered, as well as other infos, by pressing F5.

Very good! The degradation mechanism (https://github.com/AlbertoMarnetto/restunts/commit/61164d0028cf7fea78b44496b17dacf5f76cae78) is an interesting way to try and find a balance between the competing needs of the mod. I have done a few quick tests with detail-heavy cars like Zapper's F40 and Ryoma's Jaguar XJ220, and so far I haven't gotten a crash with this latest build.

(And speaking of tests, I drove a few laps on In Your Eyes (https://www.raceforkicks.com/index.php?page=race&race=2023-04), and it looks gorgeous with the mod  :) )

Quote from: HerrNove on February 10, 2025, 12:20:25 AMOh, I thought illusion tiles were a deliberate effect of the track designers :D

That's an interesting point  :D While sometimes illusion elements are added for the visual effects (Krys TOFF, for instance, would often use them in the way), in other cases they are mainly used to manipulate track continuity and physics. A memorable example that comes to mind is the half-loop in ZCT274 (https://zak.stunts.hu/tracks/ZCT274) -- @Argammon might tell us how much of each of those two alternatives applied there  ;)

Then of course there are the quirks of the original rendering, with some illusion elements only appearing as you land on them, missing parts of multi-tile elements being drawn anyway, and so forth. While in the base Restunts port we'd ideally have an exact, "bug-for-bug" reproduction of the original, a mod can of course adopt whatever makes more sense for its purposes.

Quote from: HerrNove on February 10, 2025, 12:20:25 AMI'm playing with these settings and the mod is running very fluid. Granted, I have a good PC but nothing extraordinary (AMD Ryzen 7 5700U).

On my old laptop (i5-7200U), I'm trying the mod with fixed 60000 cycles on DOSBox Staging (a configuration I've been testing lately for separate reasons), and it runs well enough.

Very impressive, it plays well at 22000 cycles, but the game always freezes on track ZCT037 after a few turns...

Well spotted. The crash seems to happen when exiting ZCT037 (https://zak.stunts.hu/tracks/ZCT037)'s first banked corner -- maybe because of all the 46-primitive boats that come in sight rather suddenly?

Guys, first of all I want to thank all of you for your help in testing this mod and for the useful infos!

Now, I have no idea about what was causing the freeze. All I can say is this: I have made some changes that, in my opinion, should have no impact on the bug, but after making them I cannot make the program freeze on ZCT037 any more, nor on other tracks. I am not claiming that the problem is fixed, but after trying for 20 minutes with different cars/opponents, on 037 and other tracks, and rotating the camera in all possible manners, Stunts continued to run happily.

I tried a thing that led almost always to crashes before (increasing the memory buffer for primitives to 13K and running up to the first bridge on 4:00am), and this time everything went well, no freezes in 5 attempts.

So here's to you a new build, which seems to be more stable for mysterious reasons and can draw a little more primitives as added perk (560 possible in richly decorated points like the town center of 4:00am). Increasing the memory for 3D objects reduces the resources for other things like car models and cockpits, so it's stil to be tested whether 13K is a good compromise. But I tried it by giving myself and my opponent the demanding Hexa, and it ran fine. Looking forward to your reports.

Quote from: KyLiE on February 10, 2025, 12:48:31 PMI've been testing it again and I noticed a small issue.  When you enable the debug information, the text on the opponent evaluation screen changes to light blue.

Skid speaking with pastel colors is not a small issue! This is now fixed, and the debug infos are now white (turning to yellow/red when the 3D engine is under load).

For my personal reference, the proof that something has changed: yesterday's and today's version showing exactly the same frame from the replay in attachment. The old version froze at this point, the other works fine.

After 48 hours without bug reports, I'm going to nominate my last version as the official release! I'll produce some documentation about it too. Enjoy!

 8)

Quote from: HerrNove on February 13, 2025, 11:43:54 AMAfter 48 hours without bug reports, I'm going to nominate my last version as the official release!

Thanks for the last update!  I'm continuing to test this for potential inclusion in my Stunts Windows installer.  I will let you know if I come across any significant issues.

A teaser about my upcoming writeup about the making of SuperSight. I will produce a long essay for my blog and publish the useful information here in the wiki too.

Thanks to KyLiE for the ongoing testing, I am always available to fix issues as they appear.

Screenshot from 2025-02-16 22-59-42.png

Looking good and very detailed! :)

Fix issues? Increase the resolution and the speed; I'm currently using one if these:

https://www.linux-netbook.com/asus-eee-pc-r011px/

"Processor: 1.66 GHz Intel Atom N455"

It's very good, I bought it in 2011 (practically new), but I can't increase the cycles in DosBOX to more than 10000.

The first part of the writeup is online!

https://marnetto.net/2025/02/20/broderbund-stunts-1

Quote from: HerrNove on February 20, 2025, 02:36:28 AMThe first part of the writeup is online!

https://marnetto.net/2025/02/20/broderbund-stunts-1

What a great writeup, thank you! It's also a useful read for people getting to know Restunts -- I have added a link to it to the Restunts Wiki article. Looking forward to part 2 already!

P.S.: I also enjoyed finding out about the other "DSI" (https://marnetto.net/2024/11/20/tweaking-stunt-island). Gotta try it out, too!

Quote from: Duplode on February 20, 2025, 03:33:04 PMP.S.: I also enjoyed finding out about the other "DSI" (https://marnetto.net/2024/11/20/tweaking-stunt-island). Gotta try it out, too!

I am not above cheap marketing tactics, and my inclusion of multiple links to my other magnum opus might have been not totally innocent ;)

Jokes apart, Stunt Island has a lot in common with Stunts. The big difference is the lack of a present-day active community. I guess that Stunts' much easier editor and its competitive nature helped to keep a sufficient number of people interested for 35 years.

I've finally had the time to try the mod on 4:00am from beginning to end and yes, there are point in the track when lots of things show on the screen at the same time and the mod barely slows down if at all. Of course it does requires more cycles, but very comfortable still. I made the track to be very full of scenery, but had never seen it that rich before :)

This is a very impressive achievement but I think it shows the track about as "rich" as my version. You can increase the viewing distance if you want. The car moves properly too, not like in the original game...

So, @Matei , here goes a general point. Broadly speaking, there are at least two kinds of Stunts-related projects, with rather different aims:

• On the one hand, Stunts might be a source of inspiration, and possibly of game assets as well, to a new racing game, created according to the author's own vision. That's a valid and worthwhile goal.
• On the other hand, Stunts itself might be reverse engineered and modded, be it for the technical challenge, for documenting the original game (perhaps even with an eye towards remixing it with other projects), or for the sake of compatibility with a 35-year history of playing, racing and modding. That's also a valid and worthwhile goal.

These are different high-level goals, and "solving" one of them won't "solve" the other. And that's okay! Progress in one front can still spur progress in the other, and projects of different kinds can cross-pollinate just fine. Comparing projects of different kinds as if they were trying to achieve the same thing, though, leads to an apples-and-oranges situation.

And now, back to our regularly scheduled programming.

Quote from: Duplode on February 20, 2025, 03:33:04 PMI have added a link to it to the Restunts Wiki article. Looking forward to part 2 already!

Speaking of the Wiki, I was going to create an initial version of the SuperSight article to cover the red link, but it turns out you've already done that (https://wiki.stunts.hu/wiki/SuperSight) 👍

Thank you for calling the laws of physics "my own vision". A lot of people do that.

@HerrNove, it's great to see that you've gone to the trouble of documenting the development of this.  Part 1 was a very interesting read!

I enjoyed reading it as well. Makes me think I've never actually written about my programming in prose. Wish I had done it with Bliss.

Thanks for the comments! Writing these articles takes time, so it's refreshing to hear that they are read by someone. But I also partly write for myself, forcing myself to translate my hasty notes into normal language so that I can reuse my discoveries in future.

It's a really good thing to do. I like writing and documenting. I've written several Wiki articles, for example. I'll sure follow your example on my next project... when I have the time