I have found some interesting GS codes for N64 games that are global,but at different locations per game.
They can be exploited to even make shader stutters not happen (GLideN64 without storage) and also make load times non-existant.
Also at the cost of desynced audio in some spots of games,like Super Smash Bros. 64 on the intro.
The codes I found are called "Half Frames" but can be used at extreme levels.
The way the codes work,is that they overcompensate the game speed,which is technically running at a thousand VI/s and 1 real fps according to 1964 testing,and as a result,it magnifies the loading speeds including how fast shaders are used,thus making shaders no longer stutter since they are oddly loaded extremely fast.
Internally,it is running at a fraction of 1fps or a fraction of 1DL/s.
First,the Super Smash Bros. code which makes loading non-existant!
8003D553 007F
8003D583 007F
Set to an extreme value for the most instant loading speed possible as seen on Mupen64Plus AE using GLideN64. (2.0 variant at least)
Here is one for Paper Mario (U) which is the most obvious one that stutters,because it happens during an action command for the first time at boot,and lasts almost an entire second.
80095973 0020
800959A3 0020
Using 20 makes it stronger while being more cpu intensive,works best on Mupen64Plus AE with Audio sync disabled.
The PJ64 emulator either has its own stuttering issue,or my computer sucks so much that it can't benefit from it because it still gets stutters with the code on,even with Rice as the plugin.
PJ64 needs audio synced in the audio plugin and "Limit FPS" disabled in order to work right.
That's good about Mupen64Plus AE since I need cheats mainly for Dolphin on Android to hopefully get rid of the stuttering.
I am incapable of serching for it myself for various reasons including crappy hardware obsoleted by later versions of Dolphin and very limited debug features compared to PJ64's memory viewer and memory search.
Now,the request,I was hoping someone could debug what these codes do on N64 emulation so they can find an equivalent code for a few games primarily Super Smash Bros. Brawl,and give info on how to find it for other games if possible.
The Metroid Prime series may greatly benefit from this if codes were found for them.
The most common value in 32bits on N64 RDRAM is 0x00190001 but sometimes will be different.
Curious if Paper Mario in N64 virtual console stutters on Dolphin,and if a port of the code actually makes it no longer stutter.
You won't get rid of Dolphin's shader stuttering by altering the game's timing.
I would like to see it attempted at least since it works on N64 emulation.
One issue though,it requires certain conditions depending on audio latency.
Mupen64Plus AE with 128 as the latency still gets stuttering with 20 as the value,but setting that value to 7F makes it not stutter again at the cost of even more of a performance intensive drain.
I know Dolphin's audio sounds painful when games lag enough,meaning latency must be set really low.
The Audio is actually quite similar to Mupen64Plus AE in the fact that faster and slower emulation speeds change the pitch.
(also the fact they are both OpenSLES)
I still wonder why neither have an option to dynamically shift the pitch when games run slowly to avoid the crackling.
That alone can add entertaining audio quirks on slow framerates.
(02-02-2016, 09:31 AM)retroben Wrote: [ -> ]I would like to see it attempted at least since it works on N64 emulation.
It would be a waste of time since there's well clear and defined reasons to why this won't work (hint: shader compilation is not done by Dolphin). Also, N64 != GC/Wii in almost all possible ways, so that's not a good point...
That's the point,the emulators are not doing the shader work,the plugins are.
Like GLideN64,the OpenGL ES backend has the shader compiler within it.
And like native loading of the game itself,there is a way to greatly decrease load times with a cheat/patch in the Gamecube/Wii equivalent of RDRAM and most likely also an address that can be modified to get a similar result of non-existant or at least super fast load times and minimal-to-no shader stutters.
It may likely be two values of 01 by default for 60VI/s,early in the boot cycle and if both are changed to 02 it would run at 30VI/s with audio synced and still run at 60VI/s with no audio sync.
If only we knew what Gamecube/Wii memories looked like in comparison to N64 memory.
No memory viewer in Dolphin,and inaccessable to me in newer builds if one was added,unless a great deal of work was done to add memory viewing on Android,which is highly unlikely.
If there is a few results of 0x0000020D in any Gamecube or Wii game,then that would show some similarity.
Changing the correct one to a really low value,would make the played game run with dropping frames much like the example of Brawl with a low underclock in a 4 player Metal Heavy Curry Fast match in Special Brawl.
Or pick a game that notoriously drops frames for some reason and set the correct address to a higher value to smooth out frame drops.
Last questions for now,would it even be possible to overclock the shader compilation part,even though it could greatly decrease performance?
Can a shader interpreter be made and worked on until it gets to a really fast performance?
Err... okay, I'm not a developer but I can (try to) reply to some statements here (take with a grain of salt):
(02-02-2016, 11:58 AM)retroben Wrote: [ -> ]That's the point,the emulators are not doing the shader work,the plugins are.
Dolphin doesn't use plugins anymore (since Dolphin 2.0 if I'm not wrong -- in other words, for a looooooooong time). All GFX/DSP/CPU emulation code is baked directly in the emulator and many parts are shared too. And about who does the work, Dolphin is responsible for generating the shader's code, but it's not Dolphin who compiles it, it's the GPU drivers that are responsible for compiling the shader code Dolphin generates...
(02-02-2016, 11:58 AM)retroben Wrote: [ -> ]Like GLideN64,the OpenGL ES backend has the shader compiler within it.
And like native loading of the game itself,there is a way to greatly decrease load times with a cheat/patch in the Gamecube/Wii equivalent of RDRAM and most likely also an address that can be modified to get a similar result of non-existant or at least super fast load times and minimal-to-no shader stutters.
I may be wrong here but the N64 have a much more simpler GPU and I bet many of the features it can pull off can be emulated directly with equivalent PC instructions on many PC GPUs, probably not using shaders at all or using veeeery simple and small shader code that can be compiled ahead-of-time. Dolphin, on the other side, has to emulate a GPU with many fancy tricks that can't be emulated directly, thus, requiring complex shaders that take time to compile (and as I said above, it's the GPU drivers who performs it, not Dolphin). Even worse, Dolphin can't "predict" how the shader will look like until the game actually uses that effect and thus, you get the stuttering (ubershaders are the solution to at least alliviate this, search for the related PRs in GitHub if you want to take a look).
About that part of using codes in the "Gamecube/Wii equivalent of RDRAM to skip load times", well, I'll leave that to a dev answer you since it involves some technical details I'm not familiar with it but it sounds (and probably is) plainly wrong. If such "magic" codes that reduces and even skips load times could be created without leaving things broken I bet you the game developers would have baked them directly in the games they produced for GC/Wii to have more horsepower available to use in other things...
(02-02-2016, 11:58 AM)retroben Wrote: [ -> ]It may likely be two values of 01 by default for 60VI/s,early in the boot cycle and if both are changed to 02 it would run at 30VI/s with audio synced and still run at 60VI/s with no audio sync.
If only we knew what Gamecube/Wii memories looked like in comparison to N64 memory.
No memory viewer in Dolphin,and inaccessable to me in newer builds if one was added,unless a great deal of work was done to add memory viewing on Android,which is highly unlikely.
If there is a few results of 0x0000020D in any Gamecube or Wii game,then that would show some similarity.
Changing the correct one to a really low value,would make the played game run with dropping frames much like the example of Brawl with a low underclock in a 4 player Metal Heavy Curry Fast match in Special Brawl.
Or pick a game that notoriously drops frames for some reason and set the correct address to a higher value to smooth out frame drops.
I'm not even sure on what you're searching here. In PC version you can run Dolphin.exe -d from a CLI to have access to some debugging tools, if that helps...
(02-02-2016, 11:58 AM)retroben Wrote: [ -> ]Last questions for now,would it even be possible to overclock the shader compilation part,even though it could greatly decrease performance?
Can a shader interpreter be made and worked on until it gets to a really fast performance?
No. Also, shaders are already generated in a common and native language the GPU drivers can interpret directly so I'm not sure on what you're trying to ask here by proposing a shader "Interpreter" (there's no emulation involved in shaders at all once the emulator generates it). Regarding shader stuttering issues in Dolphin, what would alleviate that is an ubershader approach (and luckly, phire is already working on a proof of concept, with very promising results in current state).
To finish, remember that you're comparing emulators of a much simpler and less powerful system (N64) that nowadays can run above fullspeed in almost any potato PC or <insert random mobile device here> with Dolphin, the one emulating two complex systems way more powerful than an N64 and that can bring even high-end i7s to their knees (depending of the settings and the games being emulated). This fact alone is also a good answer of why some tricks that increase speed on N64 aren't applicable here...
Thanks.
So the general idea is to make the shader part more powerful than the emulated system's original shader to counteract in a way that overlaps the stuttering range so it will no longer stutter?
This idea,since the performance on hard drives is the main cause of stuttering,would fix stuttering in the form of a workaround.
Would beefing up the emulated CPU (not overclocking,but enhancing the other processing stats and throughput) also be part of this ubershader creation,or would it also help in any other conditions?
The same question about the emulated GPU if the stats can be enhanced including how shaders are passed from point A to pint B and the such.
Just brainstorming in case it might transpire to great ideas.
Edit: Reading a few topics,and about using ubershaders with a normal shader to both compile new ones in uber while displaying cached ones in the normal shader sounds like a nice idea.
So instead of stuttering,it runs like normal but will take a performance hit instead whenever the uber shader/s compile new stuff but with the hit only lasting for the duration of compiling in uber shader/s which I would assume is a small fraction of the normal shader compilation length.
(02-02-2016, 06:44 PM)retroben Wrote: [ -> ]So the general idea is to make the shader part more powerful than the emulated system's original shader to counteract in a way that overlaps the stuttering range so it will no longer stutter?
What you're saying doesn't make much sense.
(02-02-2016, 06:44 PM)retroben Wrote: [ -> ]This idea,since the performance on hard drives is the main cause of stuttering,would fix stuttering in the form of a workaround.
No, the performance of hard drives is not the main cause of stuttering.
(02-02-2016, 06:44 PM)retroben Wrote: [ -> ]Would beefing up the emulated CPU (not overclocking,but enhancing the other processing stats and throughput) also be part of this ubershader creation,or would it also help in any other conditions?
That's actually what the "overclock" option does. It doesn't alter the clock rate of the CPU, it alters how many instructions it can run per clock cycle. This had nothing to do with ubershaders. Beefing the CPU up will just make games harder to emulate, but on the other hand, it can increase the framerate on variable framerate games that didn't run at a full 50/60 fps originally.
(02-02-2016, 06:44 PM)retroben Wrote: [ -> ]The same question about the emulated GPU if the stats can be enhanced including how shaders are passed from point A to pint B and the such.
For more information about "if the stats can be enhanced":
https://forums.dolphin-emu.org/Thread-ov...-gpu-clock
I don't understand what you mean by "how shaders are passed from point A to pint B and the such".
(02-02-2016, 06:44 PM)retroben Wrote: [ -> ]Edit: Reading a few topics,and about using ubershaders with a normal shader to both compile new ones in uber while displaying cached ones in the normal shader sounds like a nice idea.
So instead of stuttering,it runs like normal but will take a performance hit instead whenever the uber shader/s compile new stuff but with the hit only lasting for the duration of compiling in uber shader/s which I would assume is a small fraction of the normal shader compilation length.
Yep, that's a decent summary of ubershaders. (The ubershaders don't compile other shaders, though – they are just used while other shaders are being complied by the GPU driver. Also, the shader compilation time won't be "a small fraction of the normal shader compilation length" – they'll take as long to compile but won't make the game stutter like they did in the past.)
(02-02-2016, 06:44 PM)retroben Wrote: [ -> ]So the general idea is to make the shader part more powerful than the emulated system's original shader to counteract in a way that overlaps the stuttering range so it will no longer stutter?
The Wii/GC (and probably N64) doesn't have shaders, since they are fixed pipe (not sure about the N64, also might be wrong). The reason Dolphin generates shaders is because of the Graphics backend (OpenGL 3+ wants atleast a fragment (and a vertex?) shader), speed and more control over the things happening. (I read somewhere about accurate depth-test using shaders)
As told, the shaders are "written" in memory, but the video drivers compiles it for their graphics card. So dolphin can't change anything, since something else compiles it.
With that, it doesn't make sense to have a shader compiler in a OpenGL ES backend, because the software doesn't know the language the GPU is speaking, only the graphics drivers.
(02-02-2016, 06:44 PM)retroben Wrote: [ -> ]Edit: Reading a few topics,and about using ubershaders with a normal shader to both compile new ones in uber while displaying cached ones in the normal shader sounds like a nice idea.
So instead of stuttering,it runs like normal but will take a performance hit instead whenever the uber shader/s compile new stuff but with the hit only lasting for the duration of compiling in uber shader/s which I would assume is a small fraction of the normal shader compilation length.
AFAIK, ubershaders is like a shader that includes all of the states that Dolphin would generate a shader for, so Dolphin uses the ubershader, compiling only done once, and somehow (unifroms?) gives the current state to the shader to emulate.
Some (or all, or none) information might be and is wrong, as they are just from reading and common sense (for me).