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

[axdoom]

GE isn't completely CPU bound. One reason it runs so fast on the iQue is the different type of memory that's used. (SDRAM instead of RDRAM)

There's a bunch of .f constants in the source code that are stored in the 21990 section instead of being embedded in the code. The developers surely didn't know about that there is a performance penalty for using them. When such float constant is used in the code, the CPU has to fetch it from memory if it's not already in the cache which incurs an additional delay.

It's estimated that despite being 3x faster (in clock rate) than a 30 Mhz intel 486 processor, the N64 is actually the same speed because of the RAM latency. This means you could probably run GE on the PS1's CPU just fine because the N64's CPU is idle most of the time since it's waiting after the memory.

I'd like you to expand on this:

> Gameplay is almost exclusively a singleton. Pretty much anything gameplay-related is in a single massive thread, probably because Hollis's background was arcade. Normally you'd spin your explosions, smoke, TV screens, etc. into lower-priority threads instead of waiting for them to evaluate alongside all the objects, characters, etc. Something going off the path network can make the game unplayable until it gets back on (like frames per minute territory). Smoke and the random-select TV screen script have noticeable impact.

Introducing more threads would likely not improve performance. Having a thread for each of these things will result in more context switching and likely trouble controlling how many time these update during every game frame. I'd like you to elaborate. I haven't seen that in any other N64 game.

In my opinion, the developers did a great job optimizing the game by reducing the amount of computation for things that are offscreen. There are a few things they could have done better, for example by using the RSP/RDP's hardware feature to eliminate geometry using a bounding box (G_CULLDL), but they are doing that on the CPU.

I've made attempts at optimizing the game such as by having the AI sleep more, avoiding useless execution of the AI action blocks, but I only saw minor improvements. I've made other attempts, such as using a lookup table like PD for how many bytes a command must jump over to reach the next command. I saw a 3x improvement in this function, but in general it didn't have an impact on the framerate.

I noticed naive algorithms. I have yet to improve them. For example, the guards' line of sight algorithm will populate a list of props to test for collision for all the props in all the rooms which the LoS traverses, then test all of these props to find the closest LoS blocker. This is really bad and is why the storage room on Archives is split into a bunch of little rooms, else this area would get super laggy when many guards get in there.

There are also other improvements to be had, for example in the computation of quaternions. PD devs have rewritten one or more of these functions into asm to reduce memory reads/writes and make them faster. I'm hoping to be able to reuse some of Kaze's asm quaternion functions in GE when his 60 FPS SM64 mod gets released because he really knows the N64's architecture and I know this is as best as we'll be able to get. Quaternions are the real bottleneck that cause the framerate to tank when guards are on the screen.

There is no silver bullet, but I think that with all of these improvements, I'll be able to improve GE's minimum framerate by 5 frames. Most of the improvements that will significantly impact the framerate won't improve CPU usage, they'll reduce the RAM's usage.

Still, as you said, room loading is slow. The developers even limited the number of rooms that can be loaded in a single frame. But if I have the sort the rendering commands in the engine when a room loads instead of the editor doing it at export, it's going to be even slower, hence why I ask if anyone has considered doing this in the editor. I don't agree with the assertion that "Evaluating current room first pretty much makes the walls vs floor/ceiling thing moot" for complex rooms. The walls (or "polygon at the edges") of these rooms are very likely to occlude more level geometry. Sometimes portals are not used properly, or are not used at all because of the difficulty (in a room full of pillars for example).

[zoinkity]

The PS1's CPU is 32bit with a reduced instruction set plus it has no FPU and its own stack of memory access problems. Integer movement does not suffice for this type of game because you very quickly run out of precision to steal for your fixed point math. Take that up with the devs who worked on Robotron, they struggled to get that running on PSX largely because of memory access bottlenecks and no FPU. 64bit ints also make 32bit math faster. The ability to use a *mult* + MFHI for fast division to push everything flush to ground are what GE/PD, the Duke Nukems, and at least a few Turoks are built on. Magic number mult is incredibly common across all titles, especially when you run the risk of certain common small numbers occurring (1/3 in f32).


A x3 to x5 speed boost from RAM alone? At least put some of the blame on both CPUs being upclocked...
Among GE's debug features is a framerate counter (displayed as Hz). The Hz counter resides within the VI update function, basically counting misses when the next frame isn't ready. So, interested in what it's waiting on set a few counters at points like before and after object evaluation; at the start and end of the guard list (meaning can't get specific impact of particular AI steps for each sadly); after script blocks like smoke, explosions, screens, etc.; when the RSP task is sent and completes; basically all the major points in the mainloop that are easily evaluatable (or already had some useless debug things already there). Even in nominal situations GE wasn't making it through the mainloop to the point where it waits for VI to hand itself back. There was always a blown frame before it shoved out a display list. The most notable exception is the RSP struggling to finish the intro logos; luster is a heavy computation but nothing else is really happening.


The point of context switching is you don't need to evaluate to the end for superficials like smoke that generate a large number of computation-heavy sprites but serves no direct gameplay purpose. Threads or thread-like context handlers are used for this. Doubutsu no Mori spins them off for most interactives, something that ultimately screwed up the translation. The usual implementation for rotors is adding a context handler. (Physically attaching it to player physics is an exception to the rule a couple high-profile 1st party titles did.)


GE's problem isn't a low FPS, it's an inconsistent one. Replay desyncs are the most obvious victim. Here's a few optimizations that would help even it out:
1) TLB-loaded code is read into a buffer before being mapped to random TLB entries. That's normal and fine. However, it random-selects one of the buffers when doing so, causing code to be swapped in and out more frequently than needed. That's pointless, because the three blocks of ASM (menus, gameplay, and speccy) all fit in their entirety within the buffer. Do them incremental.
2) Pre-expand image DLs instead of generating them at runtime, cutting out the repeated copy commands and a lot of overhead. Largely a matter of using a different form when writing them. With a fixed size would also make it trivial to manage allocated memory more efficiently.
3) Set allocations to load entire stages into memory--something PD already does. It's usually the default when the 7 or 8MB patches are in use; even with 4MB the MP exclusive stages should all fit comfortably iirc. Not needing to reload them makes for more consistent play.
4) Evaluation of impacts on objects in NTSC versions reparses the object to pull the surface impacted (plus all steps from there). The reparsing is unnecessary and was revised in PAL to work like walls.
5) Dynamically-generated objects (and sprite-like objects like detail imgs) in NTSC versions do not properly test if they exist before handling. Nothing like running a bunch of collisions-against-room-surfaces tests you don't need. Again corrected in PAL, with the added bonus of explosions continuing until complete because of the opposite case: things aren't removed before evaluation either.
6) An additional atmospheric fog layer was removed in PAL. Has anyone noticed? That's why the fog tables were so much shorter.
7) Don't flip-flop between float modes or use doubles when unnecessary. How accurate does the watch really need to be? MP counters (alive, holding flag, etc.) can be integers.
8) All the other buggy bits of code or hanging chads: lookup tables of values that are all identical (like in MP weapon generation, preload, fair number of menus); completely unused or forced conditionals; improper/multiple load/expansion of 1st person weapons, especially in multiplayer (also source of a mirroring glitch); counters for things removed or unused; multiple sets of player location data for different purposes, not all updated at the same time or predictably (3rd person location != 1st person location != 1st person viewport != position when evaluating some collisions); when a player dies stop recalculating the viewport position for their head on the ground, if not after a certain frame then at least when the screen goes black; or removing all the debug text generation that runs even when the debugger isn't on. Granted those are fixed buffers so you aren't getting anything out of it, but it can't hurt and literally just NOPs jumps.
9) There are obvious advantages to simplified pathfinding networks and not subdividing the sides of clipping triangles unless absolutely necessary. These are used for common search algos. The original stages are pretty decent in this regard, not certain the rules can be automated though.
10) Dare say, updating the underlying microcode to f3dex2 so, at the very least, when it does finish building a DL it spits it out faster.

Which portals are set wrong?

[axdoom]

zoinkity wrote:

So, interested in what it's waiting on set a few counters at points like before and after object evaluation; at the start and end of the guard list (meaning can't get specific impact of particular AI steps for each sadly); after script blocks like smoke, explosions, screens, etc.; when the RSP task is sent and completes; basically all the major points in the mainloop that are easily evaluatable (or already had some useless debug things already there). Even in nominal situations GE wasn't making it through the mainloop to the point where it waits for VI to hand itself back. There was always a blown frame before it shoved out a display list. The most notable exception is the RSP struggling to finish the intro logos; luster is a heavy computation but nothing else is really happening.

I'd like to do that, I don't know what the counter points represent and if they're still there already set at these locations, but that's something I could implement easily (by counting CPU cycles) to get an idea of how much time the game spends processing different things. I already did something like that to figure out which AI commands cause the most lag (yes, I have a benchmark of all 250+ of them)

zoinkity wrote:

Here's a few optimizations that would help even it out: 2) Pre-expand image DLs instead of generating them at runtime, cutting out the repeated copy commands and a lot of overhead. Largely a matter of using a different form when writing them. With a fixed size would also make it trivial to manage allocated memory more efficiently. 4) Evaluation of impacts on objects in NTSC versions reparses the object to pull the surface impacted (plus all steps from there). The reparsing is unnecessary and was revised in PAL to work like walls. 5) Dynamically-generated objects (and sprite-like objects like detail imgs) in NTSC versions do not properly test if they exist before handling. Nothing like running a bunch of collisions-against-room-surfaces tests you don't need. Again corrected in PAL, with the added bonus of explosions continuing until complete because of the opposite case: things aren't removed before evaluation either. 6) An additional atmospheric fog layer was removed in PAL. Has anyone noticed? That's why the fog tables were so much shorter. 8) improper/multiple load/expansion of 1st person weapons, especially in multiplayer (also source of a mirroring glitch);

If you can share the addresses of these bugs/changes, I can backport those fixes to NTSC. All I need to know is the addresses to those functions and I can figure out the rest by myself.

Is there even a noticeable difference caused by 6? (in appearance and in performance)

zoinkity wrote:

Which portals are set wrong?

Here's an example: https://i.imgur.com/sAH7bJ3.png

These screenshots were taken with the z-buffer off. Whatever is shown on the screen is what was drawn last.

Walls in red should always be drawn first because they have the potential to create occlusion in the room. These rooms would need to be subdivided even more to reduce overdraw, so portals should be added where I drew thin orange lines. The walls in red make the room non-convex and the editor should use an heuristic to put them at the start of the display list so they are rendered first. If they are rendered first in those screenshots, it's because of luck.

[zoinkity]

So the complaint isn't that existing portals are wrong, but that you want to subdivide rooms. Slicing up buildings all over Depot wouldn't be a bad idea, one of the worst offenders and can blackout 1P if you move too quickly. Has a bunch of unused detail rooms too. (chemical storage containers?) Not sure if it was that one or Silo that caused the initial release rejection from Nintendo after a crash, but last minute one of the allocations was increased and without testing the game resubmitted.

Not just the convex portion of the walls but the flats on that side of the main area would need priority as well. If that player is in the room along a wall, those can occlude the narrow portion of one entry wall. Linearity is a trap. If both ends are convex, knowing which end is the normal travel direction would be best but that's also outside knowledge. User-flagged surfaces would be easiest there.

21990 is largely globals and you're only using globals because they're a programming convenience. Plenty of common embeddable things like pi and its multiples can go.
There's a bunch for screen formatting and menu layout that are awfully convenient, not just to standardize layout changes during development but to simplify resolution changes two builds later. If you inline those please try to do it in a way that doesn't make it terribly confusing when somebody ports the 640i mod to source.

PAL details were from a project like 15 years ago. Can check the floppies to see if anything's left from the PAL disassemblies. Somebody here might even have the documents for all I know. Remembering those points because at least two made it into a patch, one didn't, and couldn't successfully convince anyone bugfixes should be backported from J & P.

Is point of this to remove the Z buffer entirely?


Wait...how do you not have any of the room DLs for reference?

Sorting after-the-fact might be the better option if there are multiple rules involved, allowing custom rule orders for different rooms or omitting certain tests if a weird post-modern shape or every single surface is a different texture. (Orb-shaped rooms? Macrotexturing?) In fact, not sure the editor differentiates walls, floors, and ceilings (when those things exist). Can use first point of tangent change for a floor so long as no stairs. User flagged/painted surfaces maybe.

[Sogun]

axdoom wrote:

zoinkity wrote: Which portals are set wrong? Here's an example: https://i.imgur.com/sAH7bJ3.png These screenshots were taken with the z-buffer off. Whatever is shown on the screen is what was drawn last. Walls in red should always be drawn first because they have the potential to create occlusion in the room. These rooms would need to be subdivided even more to reduce overdraw, so portals should be added where I drew thin orange lines. The walls in red make the room non-convex and the editor should use an heuristic to put them at the start of the display list so they are rendered first. If they are rendered first in those screenshots, it's because of luck.

The third screenshot is 'BODEGA' from Goldfinger 64 which I modelled a long time ago. It was the first custom level I made and back then the knowledge about what affected performance was very scarce. Flashcarts weren't that common when we started the mod, so if it ran decently on emulator it was ok for us. Later during development we tried to make the levels more original hardware friendly, but many of them were already too big.

The problem with BODEGA is that I ran out of portals and rooms. I reached the limit on both categories and couldn't subdivide the level more. It was very ambitious for a first level. I wanted it to be interesting so people would like it a lot and continue playing the rest of the mod. But I think in the end the general opinion is that it wasn't that great, heh. I wanted to have all the sets that appear in the movie, connect them in a realistic way, thus expanding the level, and also make an area that would work as a multiplayer map and would only be accesible in the hardest difficulty.

Overdraw was something I was unfamiliar with back then. I though that the N64 would process all polygons that were facing away from the camera or that were outside the screen in a different way that the ones that are shown in the final image and wouldn't impact performance that much. A couple of years ago I made some benchmarks in real hardware and realized that it's like every triangle in a room lags performance almost the same way, like it's beeing fully rendered even outside the camera view. But if those triangles are on a different room and that room isn't loaded, they don't lag the gameplay at all. So subdividing the level in very small chunks would be ideal. Too bad that we can have only 199 portals and 148 rooms in a GE level. The limit is higher for PD (I don't know the exact number of rooms or portals) but the engine works differently and once a room is loaded it's processed in some way even when it should be unloaded, lowering performance. Hopefully we can get the best of both worlds someday.

Sorry for the offtopic.

[zoinkity]

That seemed pretty on-topic though?
Maybe the other surprise was when one of the Goldfinger stages was so large you could "see" the actual edge of the world (+-0x7FFF) and that would crash on console. If stages didn't require scaling because of the integer problem a good chunk of floating point and matrix math could be trashed.

Didn't find the PAL documents, but did find an old email from the early attempts at co-op that addressed the mirrored 1st-person weapon issue with multiplayers. Past self was pretty certain it's because the "current Bond" player data pointer walks between each player (as opposed to the unique guardIDs). Not certain that's the actual cause, sure odd if it is.
Anyway, when you collect doubles the 1st-person model is loaded again and a function will walk through manually mirroring it. That screws up only in multiplayer. Fatal on console but ran in the crummy emus of the time.


There is a larger backup on LTO tapes but it takes a bit of hardware finagling to hook up the drive. Anything related to released patches should be on there. Well, should have time to do that in a few days.

[axdoom]

zoinkity wrote:

So the complaint isn't that existing portals are wrong, but that you want to subdivide rooms. Slicing up buildings all over Depot wouldn't be a bad idea, one of the worst offenders and can blackout 1P if you move too quickly. Has a bunch of unused detail rooms too. (chemical storage containers?) Not sure if it was that one or Silo that caused the initial release rejection from Nintendo after a crash, but last minute one of the allocations was increased and without testing the game resubmitted. Not just the convex portion of the walls but the flats on that side of the main area would need priority as well. If that player is in the room along a wall, those can occlude the narrow portion of one entry wall. Linearity is a trap. If both ends are convex, knowing which end is the normal travel direction would be best but that's also outside knowledge. User-flagged surfaces would be easiest there.

No need for the user to flag stuff. You can use heuristics based on the position of the polygons in the rooms or something more accurate like a BSP (Binary space partitioning) to subdivide rooms and find out which polygons are most likely to occlude others and sort them that way. That's basically what Quake 1 did to have no overdraw because it was a performance killer back then. Similarly to the N64, they had a problem with the slow ISA/PCI bus PCs had back then. Sending pixel data to the GPU was slow, so you needed to avoid writing a pixel twice. The BSP made it so there was no overdraw. The game didn't need a z-buffer because of this.

I don't want to traverse a BSP tree on the N64 because this data structure is slow on the N64. It's not cache friendly. It's best to do it when compiling the level, so the display list polygons are pre-sorted. It sure won't be as perfect as Quake which has no overdraw, but it will help on every level where the rooms are not optimally divided. Plus, since this will be done in the editor, every mod will benefit from it.

zoinkity wrote:

PAL details were from a project like 15 years ago. Can check the floppies to see if anything's left from the PAL disassemblies. Somebody here might even have the documents for all I know. Remembering those points because at least two made it into a patch, one didn't, and couldn't successfully convince anyone bugfixes should be backported from J & P.

I found one difference between PAL and NTSC at 7F0446B8. It matches what you were describing in the way it processes vertex data on objects, but it only involves objects like Door and Tanks which are moving and is used for collision detection. So checks are added before calling the more expansive algorithms, I don't know if this really improves the game's performance and all. I doubt it improves the framerate when driving a tank very much. This function doesn't get called much at all except in that case. Is the PAL version of streets or runway considered better by speedrunners? I don't think so.

zoinkity wrote:

Is point of this to remove the Z buffer entirely? Wait...how do you not have any of the room DLs for reference? Sorting after-the-fact might be the better option if there are multiple rules involved, allowing custom rule orders for different rooms or omitting certain tests if a weird post-modern shape or every single surface is a different texture. (Orb-shaped rooms? Macrotexturing?) In fact, not sure the editor differentiates walls, floors, and ceilings (when those things exist). Can use first point of tangent change for a floor so long as no stairs. User flagged/painted surfaces maybe.

You can differentiate walls, floors, etc. via their normal. This is not meant to remove the Z buffer, it's an heuristic, it only has to be good enough for 90% of cases.

[axdoom]

Sorry for double posting. Quoting two posts is not made intuitive on this platform.

zoinkity wrote:

That seemed pretty on-topic though? Maybe the other surprise was when one of the Goldfinger stages was so large you could "see" the actual edge of the world (+-0x7FFF) and that would crash on console. If stages didn't require scaling because of the integer problem a good chunk of floating point and matrix math could be trashed.

If scaling is enacted on the level, it should be done when the level is loading, it shouldn't be scaled repeatedly when the level is running and being rendered because the geometry is static so it makes no sense to do it like this. They probably already do it at level load, but I keep that in mind when examining the code in case I see anything suspicious. Matrix math and quaternions are slow. It's plausible that they are scaling rooms each time they're loaded though.

zoinkity wrote:

That seemed pretty on-topic though? Didn't find the PAL documents, but did find an old email from the early attempts at co-op that addressed the mirrored 1st-person weapon issue with multiplayers. Past self was pretty certain it's because the "current Bond" player data pointer walks between each player (as opposed to the unique guardIDs). Not certain that's the actual cause, sure odd if it is. Anyway, when you collect doubles the 1st-person model is loaded again and a function will walk through manually mirroring it. That screws up only in multiplayer. Fatal on console but ran in the crummy emus of the time.

Double weapons is not supported at all in MP. The memory for the second weapon never gets allocated IIRC. I don't know how they achieved it in the coop mod or any mod that lets you hold two weapons in MP. My understanding is that it will crash.

Here's how weapon loading works: When you press A and the game needs to load a weapon, it DMAs the compressed model from ROM to RAM and loads the weapon's textures. The textures are cached for the rest of the level, but you still get lag spikes when pressing A to change weapons again because loading the model is the most expansive thing.

zoinkity wrote:

Anything related to released patches should be on there. Well, should have time to do that in a few days.

Thanks. Anything that helps optimizing the game will greatly benefit everyone.

[HackBond]

I don't know if it's something I've updated recently or what but I am crashing whenever I open the visual editor after opening a setup from GE.
So far I have opened Aztec and Bunker I and it crashes after loading the Visual Editor.
I did try an empty Silo and that was fine.
I added a couple guards, guns, pads and a few objects and they were fine too. Model Editor visual editor is fine too.
I am not sure if the Editor outputs any logs else I would share those too.
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[SubDrag]

Is this happening to anyone else?

[HackBond]

SubDrag wrote:

Is this happening to anyone else?

Not that I am aware of. Just me. I'm not sure of the cause either so I'm not sure what could be done to solve this.

EDIT to avoid a double post:
I tried booting into a minimal safe mode configuration and running the Editor,
opened a setup from the Editor folder and the visual editor and as soon as I interact with it by clicking, the editor closes itself.

EDIT once again
Completely replaced the Editor folder, updated to latest beta and it is suddenly fixed. Sorry for wasting your time.
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[HackBond]

I figured this is worth a seperate post.

I can recreate the crash with this reinstalled version. Enabling "Check Action Block Syntax on Output" in Preferences crashes the editor for me upon interacting with the Visual Editor.
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[SubDrag]

That helped - something off with syntax checks. Guess no one, myself included, has that on. Should be fixed in latest beta.

[HackBond]

SubDrag wrote:

That helped - something off with syntax checks. Guess no one, myself included, has that on. Should be fixed in latest beta.

Thanks, problem fixed. I can interact with the visual editor again and the button for checking syntax works fine too.
_________________
Also known as Spyster or Nyxem
[Youtube]

[Decoy] Antenna | Control | Silo | Escape

[zoinkity]

Finally pulled something off the LTO drive. Bonus points because had to do a backup and archive just to have enough room to load the TAR off of it. Being all linear and stuff, you can't exactly search one directly.

Anyway, it was utterly underwhelming. The vast majority was irrelevant. The full reference for 0x1F850 appears lost, and if anyone else has a copy that would be much appreciated.

Only useful things were from the patch development.
.: Remote mine timer fix, part of a broader management of dynamic objects :.
To stagger explosions requires modifying the function that generates an explosion, smoke, and foley effect at a given location to return a boolean based on if it did anything. Basically, they now know if something was skipped.
In PAL that starts at 7F09B790, with the main loop starting at 7F09B7FC. Note every caller also wound up getting edited to use the flag.

Remote mines ignore timers, but as a side-effect timers that get set to -1 when unexploded (over cap, thrown too many, etc.) don't get removed properly and can be detonated (and/or redetonated) by player 1. Only player 1.
The fix from the patch was to ignore when time is -1, but otherwise check the ownership flags when detonating and set the timer to 0. That was just a convenient way to handle it in a precompiled binary though, so really should use PAL's implementation.
In PAL, the code for when players detonate theirs is at 7F044084, part of the explosive object handler starting at 7F043E34. There's individual handlers for different types of objects (ammo clips, boxes, plastique, bombcase, etc.)

Didn't note the address of the general removal function for dynamic objects, but that's one of the tables parsed in these so can't be that hard to find. There was a difference with glass on lights, not quite sure if it was more than the structure changing though.


.: PAL skies :.
Don't have details, just noted a few functions. The format would have been in the 1F850 doc.
7F0B9E34 copy fog values to current sky
7F0B99F8 copies a longer-form sky (from first table)
7F0B9DA0 copies a short-form sky (from second table)


.: Default text bank :.
Forgot this was a feature in PAL. The editor applies this fix secretly.
Any stage that lacks its own text bank will loop endlessly. Don't know what the PAL equivalent was, but in NTSC the "else" case was handled by returning Bunker I's text bank (0x1E) on account of that being the default stage.

Rooms are loaded, not levels. That's Perfect Dark. The clipping is integer based but 3D stuff is scaled to get around the limits of signed shorts. You can change the scale during play for immediate effect. At high scale factors doors at angles clear in peculiar ways.

There's only 1 or 2 player count tests preventing doubles in MP. There should be one wrapping the test for the "left" flag (7F08C40C?). Anyway, if you can't allocate into the block you want it will allocate into bank 6 instead.

The editor already uses normals to autogenerate clipping from models. It requires significant human intervention to remove all the false positives.