New mod: extended line of sight

[Matei]

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...

[HerrNove]

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 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.

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.

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

Doesn'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.

[Matei]

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%...

[Duplode]

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

(Cross-quoting from the other thread:)

I 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, 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 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. The initial two executables you have posted, with the narrow line of sight, don't have them.

[HerrNove]

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.

[HerrNove]

Other Restunts mods with unchanged physics, like the 1.1 M1.1 available from CCC 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
 

[Duplode]

I wonder if building the game under Linux+Wine is introducing subtle differences.

That's definitely worth checking!

If 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. While I can make it public or grant you access, given that the future of Bitbucket doesn't look too rosy 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. 

[HerrNove]

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.

[Cas]

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.

[HerrNove]

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

[llm]

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

[llm]

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.

thats a hard one,

* 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

* 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

[HerrNove]

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.

You cannot view this attachment.

[Duplode]

* 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.

[HerrNove]

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!