Walls in endor space stage reactor chase not rendered right

[belegdol]

Hello,
In the endor space stage of swtrilgy the reactor walls are dark with the default 3d engine. With -legacy3d things are rendered properly. I tried to attach a save state but it appears to large for the forum software to handle.
ETA: I also have a save state right before the end of darth vader duel, it might be useful according to viewtopic.php?f=3&t=1206&p=15919&hilit=swtrilgy+endor#p15919:
https://www.dropbox.com/s/wyv2urf8xlzrr ... y.st3?dl=0 - duel end
https://www.dropbox.com/s/ilvovdp0pt5id ... y.st4?dl=0 - in the tunnel

[Ian]

The renderer I think is working properly, but the inputs to it aren't. The shading values are effected by jtag, and maybe they are patched out in the ROM.
I don't know someone should check this

[Bart]

I think I've checked it before and determined that the patched-out JTAG code was not being executed before stages. I wonder if JTAG controls shading at all or whether we were fooled by a false correlation and, in fact, something else controls this setting? For example, could there be a bit we overlooked in the culling nodes or the viewport?

When I get back home tonight I will try again just in case. Would be helpful if someone could produce a save state at the Endor forest boss (the AT-AT walker) just before the final Death Star space battle begins. Reason being that if JTAG is being used to control the shading, it is very likely being set somewhere *in between* stages, so a save state produced just before the tunnel sequence or at the start of the Endor space battle would actually be already too late.

[belegdol]

The uploaded save state is from the end of Darth Vader duel, before the Endor space battle starts. Let me know if this is early enough, I made a bunch of savestates during my last playthrough so I might be able to generate an earlier one relatively easily.

[Bart]

Yes that is perfect. But unfortunately, I don't see any of the patched-out JTAG code being triggered. I'll have to dig deeper at some point but I do recall looking for JTAG and register writes once before and not finding anything.

By the way, the Death Star surface sequences look really broken on my RTX 2060. Has anyone seen this before? Is this a known issue? Almost all the surface geometry is white (see attached photo).

[belegdol]

I did not see that on my last playthrough (RTX 2070, Linux).

[Ian]

Not seen the white error
Maybe drivers failed to compile?
Also check viewport parameters for any NaN light values?

[rokfpoewrkcpoqwkcp]

I just built r835 in GCC with an up to date msys2 environment to find I also get the white planet surface.
I checked with my last build, r834 built a couple of weeks ago, that also suffers white/missing textures.

I reinstalled Visual Studio 2019 community with the relevant libraries, and that build works fine, the planet surface is back.

I had ditched VS in favour of GCC, only to re-download and install it all again a few months later. A bit of a pain in the ass

It is looking like a compile problem though.


EDIT.
After further tinkering, it seems to be that darned "Rules.inc" file causing problems again. I should of known.
Changing back to "OPT = -O3" brings back the planet surface textures.

EDIT 2.
BTW
If the source code does get reverted back to "-O3", while you're there, can we also revert to using a capital 'S' in "OUTFILE = supermodel".
I find the small case 's' downright disrespectful to Supermodel.

[belegdol]

I have realised that these old save states no longer work with current svn. Here are the updated ones in case someone wants to pick this issue up:

• duel end: https://www.dropbox.com/s/ua5ii8b3ttpu5 ... y.st8?dl=0
• reactor tunnel: https://www.dropbox.com/s/7sma9rcm96uhu ... y.st1?dl=0

[rokfpoewrkcpoqwkcp]

Did the walls only ever render because of a hack in New3D.cpp?

Hack:
https://sourceforge.net/p/model3emu/code/736/tree//trunk/Src/Graphics/New3D/New3D.cpp#l30
https://sourceforge.net/p/model3emu/code/736/tree//trunk/Src/Graphics/New3D/New3D.cpp#l1666


Harry changed the Games.xml JTAG patches in r737, so he could remove the hack.

commit 737:
https://sourceforge.net/p/model3emu/code/737/#diff-1


Spindizzi re-enabled some of the patches so the lever feedback would work in update r832.

commit 832:
https://sourceforge.net/p/model3emu/code/832/#diff-1


He didn't bring back the hack.
Was this just an oversight by Spindizzi or an active decision?

You can still hack the SetSignedShade() for both swtrilgy & swtrilgya. It seems to work. Both games look good to me on play through.