GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion

[axdoom]

I've got some of these changes as part of Operation MonkeyWrench patches.

- Remote Mine Fix: Forces remote mines to test for a stopped timer. This prevents detonation of standalone objects and re-detonation of undeleted mines.
- Staggered explosions Fix: Inhibits removal of explosives when the explosion cap is reached. These will detonate at the next available opportunity.
- Default Text Bank Fix: Any stage lacking a specific text bank will loop endlessly. The default is Citadel which is invalid, this changes the default to Bunker I's text bank.

The Default Text Bank Fix is applied automatically to a any mod by the editor.

[axdoom]

Hi,

I created a new setup for Caverns. It crashes on real hardware but not on emulator.

I imported the Setup file into my modified GE engine which has the crash screen enabled and it shows that there is a floating point exception occurring. The exception sets some extra CPU flags (FPCSR: flush denom to zero, condition bit, unimplemented operation, invalid operation, overflow, inexact operation, round to nearest).

The function where it crashes is 7F0B0688, when the game is subtracting the 1st parameter of that function from the 8th one. I don't have the exact address around, but it crashes on this instruction:

Code:

46 04 52 01     sub.S      S f8,f10,f4

We've been speculating that the cause of the exception is a "denormal" float, also known as "subnormal". The N64 hardware doesn't handle them and won't generate them because the VR4300 designers decided not to support them, so the result of the speculation was that only external tools can generate those floats (such as the setup editor).

Intel processors support them but the N64 doesn't. Does the Setup Editor encode denormal/subnormal floats into its setup files? This is possibly the cause of the crash.

Test map: https://files.fm/u/7c6d2psesu

Pick Caverns MP. Test with 2 players. I didn't adjust the mem values, so if you go higher, it will likely crash for other reasons.

[axdoom]

More infos about denormalized floats: https://en.wikipedia.org/wiki/Subnormal_number

The answer to this post explains how they are represented.

There is an GH issue asking for the option to disable them in .Net, but it's not supported. Instead, the post at the bottom of the thread explains how to normalize a float in C#.

https://github.com/dotnet/runtime/issues/16018#issuecomment-1222843445

You might need this code to implement the fix.

[SubDrag]

Not normally. You must have something off in setup. Backup setup, delete objects and test until it works to figure out. Probably an object or preset not over clipping or other small issue.

[Wreck]

Just a quick comb through, these are some things I noticed...

Start Pad 0005 used twice
Traditionally Flag Token is first weapon (but shouldn't hurt)
A door has In Air Upside-Down flag on?

Only the last one might have any kind of possible impact. None of the pads needed relinking, at least, so your glass should be correct. Also, the eyelid doors are not really used to close portals. The iris do that. The shape doesn't suit it.

[zoinkity]

Exporting just the setup uncompressed makes it easier to browse the binary. ("Save Setup Uncompressed" in the file menu.)

There's a pretty solid 1:1 correspondence between what you type into the editor and what you get out. To output a denormalized value or something like -inf you'd need to type it in yourself. That function lies past preset expansion though so it should have been fatal sooner. Expansion is just the original value multiplied by stage scale and can be previewed in the editor's "presets/pads" dialog.
Indirectly though? Presets are multiplied by stage scale, then objects' local positions are derived from those and, depending on settings, may automatically drop flush to clipping (which has a randomizer involved, so really a range). Certain object types have other local values for depth, etc. that are adapted from the position data as well. Not impossible, but clearly an edge case.

Like Wreck said, it's much more likely you used a combination of object settings and/or invalid locations that caused an error. They're the two most common errors after all. Displaying an object inside out or placing a preset outside of clipping's bounds can be fatal depending on type & flags (especially an 0x2710 type). Inverting the dimensions of a door was only fatal from certain directions iirc... Some types of door motion can cause math errors if they move way out of bounds after activation.

tl;dr: most errors are solved by checking object settings and not using a scale of 100000000000000000000000.


Also, Ares would probably want a bug report if denormalized floats aren't tripping errors in their emu. Pretty sure they implemented that.


MP flag items don't have to be the first entry. You can even have more than one, as silly as that is. Good practice though, they're easy to forget otherwise.

[axdoom]

It was either the same spawn used twice that caused the issue (very likely) or two unused pads (not likely).

I created an utility to parse floats and find if they're denormalized. I pasted the list generated from the Edit Presets menu which comes out as hex and there was no denormalized float in there. Still weird that I got this exception on console. Once I improve my crash screen to properly parse the stack, I'll have better stack trace which will offer me a better understanding of the issue.

Ares crashed on Linux when loading the unfixed setup, but didn't on Windows, which is weird.

[zoinkity]

Just remove objects until it stops happening. That's your offender.

It's faster, easier, and requires less work to get a result than walking through a stack trace.