The Elite Forum
The Big Three Plus One => GoldenEye 007 => Topic started by: Trihook on June 07, 2017, 08:57:50 am
-
Hello speedrunners!
This is my first post. A few days ago I got more interested in goldeneye speedrunning, and while I'm not home yet so I can't dig up
my n64 to see if it works yet, I watched a few streams of GE on twitch, and generally read up on it. After I saw the amount of
insane effort that goes into some of these speedruns and the number of hours people actually spent grinding for that elusive
RNG combination that will give them that 1 second better time on records that are sometimes years old, I decided to see if I
can do something to help. Since the community is very old, I am not sure if some of this has been already said, but I don't
think my efforts are deconstructive in any sense so I'll just go and list my findings.
A note before I begin tho. Most of these findings are informed wild ass guesses, so take them with a grain of salt. Because
there is no released source code of the game, there is no actual way to prove these WAGs are actually true. On the other hand,
I've been playing games since I could reach the controls, and have been involved in creating games, I
think most of these WAGs should be true.
So, after researching a bit about the speedruns, I noticed that all the best lines and strats have been found, and in the end
it came more or less to RNG and lag managment. There is, ofc, the player skill itself as the largest factor, but that's not
anything I can help with, so it is not in the scope of this post.
With these two factors in mind, researching the RNG leads me to believe that there is no humanly possible way to control it to
get the desired outcomes without making a TAS. Without decompiling the game, which is out of my skill reach, I can only make a
few guesses. Lag management is much more easier and will be the focus of this post.
RNG:
RNG (random number generator) is usually used in computer games to get random numbers for purposes of deciding variables, so
the game doesn't look as artificial as it is. A bit of randomness simulates how things in nature are usually all unique to a
point. Older generation hardware sometimes used hardware chips to generate these numbers, but as hardware became more powerful
it is usually relegated to generating a random number by code only. Since N64 doesn't have any hardware RNG afaik, I guess
RARE coded their own as is the accepted practice. Reading up on it, it seems that random numbers were generated by the CPU in
the microcode. Nintendo released their own microcode to game developers so they can make games, but the fact is that RARE did
develop their own microcode to replace the Nintendos one for better performance for some of their later games. Seeing how GE
was released early in the N64s life I am not sure if they used Nintendos microcode or their own. All that is known is that
super mario 64 has a bit of an unoptimized RNG code that uses a few more cpu cylces than it sould. Seeing how SM64 is a launch
title made by Nintendo itself, it is reasonable to assume it uses this microcode. Therefore, it's all speculation at this
point on what RNG method was used in GE. One thing to note is that without a battery powered clock, the code usually relies on
itself by using math formulas to get random numbers that are seeded when the console powers on. Some games use the clock to
seed their random numbers. In effect, if GE uses only math formulas, the potential to predict the RNG is much better if one
replicates exact inputs frame perfectly. This is usually above human possibility so I cannot see a way to force the RNG to
give specific results without making a TAS. As far as it links to lag management, RNG is usually very easy on the CPU, but
seeing how the nintendos code is a bit unoptimized, there is a very small possibility it can overtax the CPU if a lot of these
numbers are generated in a very short amount of time. Overtaxing the CPU generates lag ingame.
The amount of RNG that the player can make the CPU generate is not very high in Goldeneye so it comes down to generating it at
specific times to push the CPU into overload. To do this, one would need super psychic powers to predict when this situation
is possible so it is probably of no use of trying to train oneself to do this. Even if one somehow managed to master RNG
techniques that pertain to lag, the increase of actual runs would be like half a percent once in about a million runs.
RNG manipulation to get better numbers is possible by resetting the console and is in the scope of human possibilities, but is
still very hard. If we assume the game generates the same random numbers after the console powers on, there is a possibility
there are chains of numbers that are good for the player, and by playing the game while these chains are running it is possible
to get specific random numbers. The way to do it is obviously to be very precise with timings after the console is turned on.
I find is very unlikely one can rely on this, but it is still in the domain of human achievement.
Lag:
Before we start, I would like to explain where the grains of salt are, and the WAGs that are used to theorize this.
I will be using an emulator in wireframe mode to be able to see when certain areas of the game are loaded and what is rendered
on screen at any given time. I don't really know if the emulator replicates the N64 at 100% accuracy, but comparing the actual
videos of speedruns and what I see in wireframe mode it does seem to be reasonably accurate. The actual rendering process is
not known, but some general 3d rendering algorithms are more or less generally used in all 3d rendering, so I am pretty
confident in my assumptions of what the N64 is rendering each frame. This is mostly pertains to "culling" or "scissoring" as
it is named in 3d rendering. Culling means that polygons that are not on screen are not rendered, so angling the camera to see
as less of the scene as possible will make the N64 not lag as much. The actual lag occurs only if the processors are taxed
beyond their abilities. To avoid desynchronizing the game, the machine will pause the screen so the processors can catch up to
what is happening. This is is known as dropping frames and makes the game run slower.
The N64 is a multi threaded console in a way, and according to this
http://n64.icequake.net/doc/n64intro/kantan/step2/index1.html
it is clearly obvious that one thread of the game code can make the other one not run. In actual gameplay this means that on
some laggy frames your controls are unresponsive, for instance, not being to able shoot while the CPU is overtaxed and the
game lags.
The lag in game is usually generated by 2 things, either the GPU is rendering too many polygons so the framerate drops, or the
game is loading data from the cartridge beyond the scope of the data transfer bus, so the console is waiting for the data to
transfer before it can resume computing the actual game.
Using a N64 emulator, I was able to turn on wireframe mode and I took some screenshots of the DAM level to show what renders
and what loads at which points of the level. This is possible for all levels in the game, but I felt it is too much work to be
done by me so I will just run through the DAM level for now.
Please keep in mind I am only going through the level geometry to spot specific lag potential, and I am not counting anything
other than that the game can use to generate lag (explosions, bullets, guard animations, sounds and so on). I checked the
screen modes in the game and tested them out, and the normal, widescreen and cinema modes pertain to the FOV (field of view)
the game uses to decide how much of the screen it will render. The normal view has the smallest angle, so I'll use that as a
measurement point because I think it will produce the least amount of lag. This is a highly debatable point, as I am
concentrating on reducing the horizontal view angle, while the cinema and widescreen modes do extend it horizontally but
reduce it vertically. Depending on the level geometry setup different modes could potentially be better.
Starting in the DAM area
(https://s1.postimg.org/9poo8of33/Screen_Shot_06-07-17_at_12.51_PM.png)
(https://s17.postimg.org/w9ohral73/Screen_Shot_06-07-17_at_12.51_PM_001.png)
most players will start by looking down to reduce lag. This removes most of the first area from the viewing angle (FOV) so the GPU has less to render, decreasing the chance of overtaxing it. Based on the screenshots, looking up actualyl renders less. Keep in mind that lag happens when the machine is overtaxed, so the handful more polygons rendered by looking down probably are not enough to generate lag.
(https://s4.postimg.org/xv2yfie4t/Screen_Shot_06-07-17_at_12.52_PM.png)
(https://s2.postimg.org/wm4i47jvd/Screen_Shot_06-07-17_at_12.52_PM_001.png)
(https://s4.postimg.org/j0ed1c4jx/Screen_Shot_06-07-17_at_12.53_PM.png)
(https://s11.postimg.org/492ceuv4j/Screen_Shot_06-07-17_at_12.53_PM_001.png)
As seen this SS and by running around the level, the tunnel area is loaded together with the first area. It is not rendered
because of culling, but at this specific point, probably due to the mountain polygons not lining up perfectly a part of the tunnel area is rendered.
(https://s2.postimg.org/nlzwk0nrt/Screen_Shot_06-07-17_at_12.58_PM.png)
While it might not be obvious at a glance, most 3D rendering does not calculate each polygon separately to see if it supposed
to be rendered on screen, but clumps them into segments, and renders the whole segment if any of it is visible on screen, To
reduce calculation errors, there is a variable number that renders them a bit before they are actually visible on screen, so
they render just "around the corner" as I would put it. To determine what polygon occludes which one is CPU intensive to a
point, so most games just render everything possibly visible form back to front. This means the visible tunnel area is rendered
(taking up cpu cycles) but you can't see it because the mountain is rendered after it, more or less completely obscuring it.
This point is where the gate are is loaded:
(https://s11.postimg.org/hreao9dlf/Screen_Shot_06-07-17_at_12.55_PM_001.png)
(https://s23.postimg.org/deii87mjv/Screen_Shot_06-07-17_at_12.55_PM_002.png)
Please note that the N64 data transfer bus is not really all that fast, and some articles on the internet mention this as a choke-point for the system. Loading up a new area is a potential lag generation point. On top of that, if you are trying to affect guards in the area ahead, the area in question must be loaded for this to work.
Moving a bit ahead we can see at which point the area behind the gate is loaded into the memory:
(https://s13.postimg.org/xrogj64lz/Screen_Shot_06-07-17_at_12.55_PM_003.png)
The dam area mountains is loaded just beyond the second gate:
(https://s30.postimg.org/9aqhnrz7l/Screen_Shot_06-07-17_at_01.01_PM.png)
(https://s22.postimg.org/4uftj4q9t/Screen_Shot_06-07-17_at_01.01_PM_001.png)
Interesting to note is that the guard captain is rendered because a small piece of his body is possibly viewable from the gate area:
(https://s12.postimg.org/ysiowh8bx/Screen_Shot_06-07-17_at_01.00_PM.png)
The locked gate is loaded in after you cross a line that extends from the alarm gate towards bond in these SS:
(https://s13.postimg.org/6wef49nmf/Screen_Shot_06-07-17_at_01.02_PM.png)
(https://s1.postimg.org/a84a4dcsv/Screen_Shot_06-07-17_at_01.02_PM_001.png)
The guard towers on the dam are loaded into the memory after you cross the gate near the first alarm:
(https://s29.postimg.org/vt9o3jzcn/Screen_Shot_06-07-17_at_01.04_PM.png)
(https://s23.postimg.org/3xxafbs2z/Screen_Shot_06-07-17_at_01.04_PM_001.png)
The area before the dam is unloaded from the memory (freeing up some cpu cycles) around the first guard tower:
(https://s4.postimg.org/mzchmwr2l/Screen_Shot_06-07-17_at_01.06_PM_001.png)
(https://s21.postimg.org/998ufue5z/Screen_Shot_06-07-17_at_01.06_PM.png)
The crates on the dock area are loaded bit by bit as you walk towards the second guard tower:
(https://s12.postimg.org/4ewnl6qgd/Screen_Shot_06-07-17_at_01.08_PM.png)
(https://s14.postimg.org/q3y7mk55d/Screen_Shot_06-07-17_at_01.09_PM.png)
(https://s11.postimg.org/jn12zf2fn/Screen_Shot_06-07-17_at_01.09_PM_001.png)
The interior of the guard tower renders when you step closer to the mahole:
(https://s9.postimg.org/5g1hhzpv3/Screen_Shot_06-07-17_at_01.10_PM.png)
(https://s12.postimg.org/5wi3wqv71/Screen_Shot_06-07-17_at_01.10_PM_001.png)
and it stays rendered if you break the window:
(https://s11.postimg.org/6mpc2zfv7/Screen_Shot_06-07-17_at_01.10_PM_002.png)
Walking inside the first guard tower shows us that the dam itself is still rendered at the first turn of the stairs:
(https://s1.postimg.org/hsbvmdxfz/Screen_Shot_06-07-17_at_01.11_PM.png)
not rendered near the second turn:
(https://s2.postimg.org/5a4ikr74p/Screen_Shot_06-07-17_at_01.11_PM_001.png)
and completely unloaded from the memory when you descend to the floor below:
(https://s14.postimg.org/srwuoecy9/Screen_Shot_06-07-17_at_01.12_PM.png)
The computer room is in the memory while bond is in the underground tunnel near the boxes:
(https://s3.postimg.org/wuzshhdb7/Screen_Shot_06-07-17_at_01.15_PM.png)
I am not sure when it actually loads, because it is not possible to see because of the culling, but I found that glitch spot that proves it is loaded at some point in the tunnel.
The computer room guards will react to shots behind the closed door:
(https://s11.postimg.org/lwp7a6bdf/Screen_Shot_06-07-17_at_01.17_PM.png)
testing it out, I found that the guard will not react to single shots, but will react to multiple shots, or single shots that are fired soon enough one after another. It seems to be a function that evaluates the sound generated through firing (that adds multiple shots to the overall volume but decays over time) and the distance to the guard.
This concludes the possible lag generation spots for the dam level.
Moving around I observed that looking down while walking the dam does render the area of the dam itself and the parts of the canyon below bond, so looking up should produce a better FPS as it renders less (just the railing, top of the mountains and the sky)
If you are interested in exploring this one or other levels in wireframe mode to find lag generation points, you can download project64 ( http://www.pj64-emu.com/ ), download the ROM image of the game (which is probably legal if you own a cartridge), adjust the advanced graphical options of the rendering plugin and have a go at it.
N64 usually filters all it's textures so they look nicer, because the texture memory is pretty small (2kilobytes) This makes most n64 game textures look blurry compared to games of today. PS1 does not have this and you can clearly see sharp pixels on textures in ps1 games. Some n64 games also use anti-aliasing which makes polygons that are angled have less jagged edges on the screen by blurring the edge pixels. All these effects cost GPU cycles and can overload the GPU so it starts to drop the framerate. Wireframe mode does not render any textures so it is much easier on the GPU. There are ways of entering wireframe mode in Goldeneye. There are 3 ways but 2 of them will probably be rejected by the community because you have to use a gameshark, or a flash cart. Interestingly, RARE themselves put this option into GE but never published it. There is a sequence of button presses that enables it but I couldn't get it to work on an emulator with my current control scheme. Maybe I was not fast enough in inputing them or the emulator forces textures always, I don't know. If it actually works on a real N64, running the game in wireframe mode can potentially make runs much less laggy.
The codes are listed here:
http://goldeneye.wikia.com/wiki/Button_Codes
and the one for the wireframe mode is:
R+C down
L+R+D down
L+D right
R+C up
L+R+C right
R+D up
L+D down
L+D right
R+C left
R+C up
This code should be entered while playing a level, and the wiki indicates it can be reversed by inputing the code again. I can't get it to work so I don't really know if it is a wireframe mode or something else. The legality of speedruns made in this mode is not the point of the post, so if someone manages to make it work or speedruns it like that for less lag, (s)he should check with the community if those runs would be accepted as they are.
Completely unrelated to lag, yesterday someone was running runway and using R-Lean (Arlene =D ) to throw nades very far. Experimenting with it a bit, I found out that you can climb non fenced stairs with it quicker (on guardtowers) and tried to think thorugh the implications of it. What Arlene does is that it moves the bond in the strafing direction with a significant speedboost for about one step before it stops him completely. When R is released, the bond returns to the position he was when R was first pressed. While strafing, tapping the R button will give you a speedboost, but it will stop you after a step, kill your acceleration and return you to the first postion when released. This does sound impractical for speedruns, but using it to enter an end level zone (jumping from the dam for instance) everything but the boost is not in play. It could be used to enter end level zones quicker with some practice.
Returning a bit to the N64 hardware, I found out that sound is generated with the help of the main CPU so turning off music and/or sfx will make less demands on the machine. I'm not sure how much of this is practical because some runs might rely on sound cues.
-
k
-
tl;dr
(https://i.imgur.com/oC9jE1U.png)
-
Welcome!
-
The button code is for 'Line Mode' which is not useful at all. It just takes what is usually drawn and makes it really obnoxiously white.
Usage of wireframe mode on emulator (i think gameshark also has it?) to find lag reduction strats tho is pretty cool.
-
Really interesting first post, I think you could be a great addition to the community and I think these kind of topics/posts are great information that will be helpful in finding better strats and to continue improving upon what we already have :)
Welcome!
-
Really interesting first post, I think you could be a great addition to the community and I think these kind of topics/posts are great information that will be helpful in finding better strats and to continue improving upon what we already have :)
Welcome!
Lol not
-
Lol not
It taught me more about lag management than you ever have
-
Lol not
It taught me more about lag management than you ever have
Lag management doesn't need to be taught. It needs to be felt.
-
Such a nice and warm welcome this person gets. Pfff
-
So the line mode is actually some kind of an internal N64 hack. I was really hoping it was a wireframe mode. Ah, well, can't have it all.
I thought aobut the line mode tho, and to pull off something like that the game would have to replace every texture with a white one, or just hack the function that draws the textures so every pixel becomes white. I don't know what RARE used here, and there are numerous ways of doing it. Some of them might be less laggy, but finding actual proof for that would need serious test time.
There still might be a way to get the wireframe mode running on an unmodded cart but it would need a dedicated coder to find it.
As seen on this page
http://doc.kodewerx.org/hacking_n64.html#activators_button
it is possible to fiddle with the memory by just using the gamepad if I understood it correctly.
Goldeneye obviously has this possibility as there are button codes for it on the wiki. The only question is if there is a wireframe mode that can be activated by this method. Taking a broader view, if you can manipulate the game mem via button codes, you can prolly do a lot of other stuff, and some of it might be outright cheating.
I also found this video on YT:
https://www.youtube.com/watch?v=Reaz4aKYci8
which shows some guy managing to have a free look camera in game. Reading up on it, it seems that he is running goldeneye in Dolphin (a wii/gamecube emu) as a ported game for the wii. Ofc, this might be sucky and the port might not be accurate, but a free camera be really helpful to see the levels more clearly, especially concerning seeing stuff behind culled areas. I tried my best, but I couldn't get the emu working with the rom of the ported game, prolly due to incompatibilities of the regions involved. If the port isn't drastically changing the original code the loadpoints for areas and stuff like that might work exactly as they do on the N64.
There is a possibility of adding a free camera to a N64 emu, but so far, no rendering plugins have it. Maybe a plugin coder could be persuaded to help, or the emu can be hacked with a simple cheat app that changes values in the memory at runtime if one could find the variables that control the camera position. I am not a coder myself, tho I do understand the basic principles involved, so this level of skill is out of my reach. I will look further into it, maybe something can be done.
-
So, to shortly recap the topic:
The N64 can lag at specific points on the level, especially when it's not just loading new areas, but other stuff is happening at the same, i.e. explosions, sounds, changing weapons, rendering too much at once, etc.
For the Dam level, here are the specific lines when you have the most potential for lag:
(https://i.imgur.com/9GFhpQO.png)
Crossing this line will load up the gate area. Trying to affect the gate before crossing this line will prolly yield no results whatsoever.My suspicion is that the function that checks if the gate button is pressed does not update every frame, but every few frames, so getting a good gate depends on hitting the cycle just right to press the button when the function is checking for it. If you miss it, it will only start opening the gate the next time it updates.
(https://i.imgur.com/XWyoei6.png)
This loads up the dam area mountains, but since there is nothing people want to affect there, it's just a potential lag line.
(https://i.imgur.com/2w8C5fO.png)
This is where the dam area loads, but the guard towers and guards only load when you cross the first alarm gate.
(https://i.imgur.com/SnVUvvo.png)
This line denotes when the lock and the gate load up. Many runs cross this line when shooting the first alarm. Some of them lag on it, potentially dropping frames and not being able to shoot.
(https://i.imgur.com/KWtb0ob.png)
This line denotes when the interior of the guard tower loads. Shooting out the window will make it load faster and stay in the memory for longer. There is a small possibility that shooting out the window earlier reduces lag when shooting at the alarm after opening the guard tower door.
Also, from what I can figure out, looking down on the dam is ill advised, especially looking to the side where the docks are.
-
Sick images and finds dude
-
DECENT POST. <3
-
Completely unrelated to lag, yesterday someone was running runway and using R-Lean (Arlene =D ) to throw nades very far. Experimenting with it a bit, I found out that you can climb non fenced stairs with it quicker (on guardtowers) and tried to think thorugh the implications of it. What Arlene does is that it moves the bond in the strafing direction with a significant speedboost for about one step before it stops him completely. When R is released, the bond returns to the position he was when R was first pressed. While strafing, tapping the R button will give you a speedboost, but it will stop you after a step, kill your acceleration and return you to the first postion when released. This does sound impractical for speedruns, but using it to enter an end level zone (jumping from the dam for instance) everything but the boost is not in play. It could be used to enter end level zones quicker with some practice.
Clarifying this does not save much time:
Yes iirc Henrik said it saves 3 1/60ths of a second if done very well, 1 if done less well and below that you've kinda screwed up (my words not his). I tested it briefly during my facility TAS and thought it could save 4/60ths in a TAS setting. Note that 3-4 /60ths is usually 1 frame in GE, so this is very much a frame perfect trick.
I think it's just not done because it's too risky. Even if you think your run is going to be .00 by the music or whatever you might be better of hedging that it's actually .98 than trying the trick.
Via Whiteted at https://forums.the-elite.net/index.php?topic=19414.msg471319#msg471319
-
Lol not
It taught me more about lag management than you ever have
So much negativity - You were being nice and welcoming someone new with some inherent new information on lag for others who may also be new to the forums yet someone took the time to respond poorly....Nothing really changes here - Continue being gracious for new people coming to the boards and posting on their time especially that is adding beneficial information regardless of the non sense replies
So, to shortly recap the topic:
The N64 can lag at specific points on the level, especially when it's not just loading new areas, but other stuff is happening at the same, i.e. explosions, sounds, changing weapons, rendering too much at once, etc.
For the Dam level, here are the specific lines when you have the most potential for lag:
(https://i.imgur.com/9GFhpQO.png)
Crossing this line will load up the gate area. Trying to affect the gate before crossing this line will prolly yield no results whatsoever.My suspicion is that the function that checks if the gate button is pressed does not update every frame, but every few frames, so getting a good gate depends on hitting the cycle just right to press the button when the function is checking for it. If you miss it, it will only start opening the gate the next time it updates.
(https://i.imgur.com/XWyoei6.png)
This loads up the dam area mountains, but since there is nothing people want to affect there, it's just a potential lag line.
(https://i.imgur.com/2w8C5fO.png)
This is where the dam area loads, but the guard towers and guards only load when you cross the first alarm gate.
(https://i.imgur.com/SnVUvvo.png)
This line denotes when the lock and the gate load up. Many runs cross this line when shooting the first alarm. Some of them lag on it, potentially dropping frames and not being able to shoot.
(https://i.imgur.com/KWtb0ob.png)
This line denotes when the interior of the guard tower loads. Shooting out the window will make it load faster and stay in the memory for longer. There is a small possibility that shooting out the window earlier reduces lag when shooting at the alarm after opening the guard tower door.
Also, from what I can figure out, looking down on the dam is ill advised, especially looking to the side where the docks are.
This last photo Trihook is actually why you'll witness some players look up at the sky during the segment of A SA or OOA runs so they aren't loading things on the barges or just unnecessary objects that create lag
The gate trigger photo I believe there is a few topics that talk about that red line and how it activates the code for the gate however its great that you're finding the same results
Those red load/lag lines that get activated are informative - Its possible some of the other techies with this game will chime in to compliment your studies of the lag - Welcome to the forums as well some interesting information that some of us old or new haven't seen so appreciate you sharing your findings/research