Request: Add the option to toggle TLB normally or per-game.

[retrobenny]

Sure,Paper Mario uses it and Super Smash Bros. also actually uses it to display error info,but many games don't appear to fully utilize it,as many lack error screens with info,most games being the Rareware games.

Having the option to NOT use it would decrease freezing/hanging in games,for example, Banjo-Tooie and DK64 have moments where the game will freeze wihen using TLB but won't freeze if its disabled.

Even though the reasons are not entirely from normal game-play,but with many certain Gameshark codes.
Particularly,the Split-up Anywhere code for Banjo-Tooie and the DK Bongos Actor/Image Mod on DK64 when Rambi is used.

B-T: Splitting up from anywhere will freeze with TLB in use if the distance is even slightly too far,but with TLB disabled,it allows it to continue running regardless of distance.

DK64: Spawning Rambi with the DK Bongos freezes upon instrument playing with TLB in use,but with it disabled,Rambi spawns using the Orange Glowing Special action in a stiff animation,and you are free to bounce on him for fun with some neat side-effects.

Without the option to turn TLB off,a lot of extra fun that can be had with codes is ruined by freezing as a result of an error triggered by TLB itself.
And possibly other problems occur such as SM64 hacks and other game hacks/mods will likely freeze with TLB and run fine when its disabled. It might be part of that issue I encountered with Glide64 and an SM64 hack freezing randomly in a level and also the Peach's Christmas Invitation hack's freeze upon trying to enter the first course due to heavily custom ASM hacks it has.

Though this last one is probably not even caused by using TLB,sometimes compatibility is better than pure accuracy,especially if it could be made optional to extend the possibilities for more things to work at decreased accuracy for only those unique cases.

[retrobenny]

I have seen proof of better performance by at least 30VI/s faster if TLB is disabled with my test on Banjo-Tooie within PJ64 so it would likely boost performance if Mupen64Plus had this option available.
So an option to disable it would be good for getting better performance on Android at the cost of some accuracy but with the added compatibility for more of the really entertaining GS codes as a bonus.

My recent codes for object spawn mods partially fail if TLB is enabled because of some dumb issue disallowing it to work when swapping eggs with other non-egg objects which works fine if TLB is disabled.
Its hilarious to lay eggs with spawn mods because you cab literally "shoot" out enemies and NPCs instead of eggs,my favorite being a very cold caveman.

[loganmc10]

I'm personally against these kinds of changes. You already have Project64, which is a little less focused on strict emulation accuracy and allows things like disabling TLB or overclocking. We have made good progress in the last year in removing hacks and game specific settings.

You'd get better performance by only drawing half the screen as well, but it wouldn't be accurate emulation. I don't think disabling a key part of the CPU emulation to increase speed or make GS codes work that wouldn't work on a real console is a good idea.

[AmbientMalice]

I have to agree that a hack that doesn't work on real hardware is a bad hack. As an emulator becomes more accurate, it is natural that certain hacks no longer work. Eventually a lot of those Mario 64 hacks won't work anymore, for example.

[retrobenny]

Well,what are you using so that some games can even run with TLB enabled...hacks!
Its like what is being done to make GoldenEye work with it enabled along with some other games also getting special hacks because they won't boot or function all that well with TLB enabled.

What's wrong with giving the users an option to have games run less slow on weak hardware like Android devices,especially games that have no real reason for TLB to be enabled?
And 30VI/s is a large difference when you have to put up with how slow things get when on GLideN64.

[AmbientMalice]

Its like what is being done to make GoldenEye work with it enabled along with some other games also getting special hacks because they won't boot or function all that well with TLB enabled.

In theory, those hacks will eventually be removed as the emulator improves.

especially games that have no real reason for TLB to be enabled?

IMO, it's extremely unwise to disable major system features just because there are no known side effects. Stuff like Project 64's 32 bit mode, for example, is a really bad idea. There's no knowing what obscure problems it is causing.

That said, I think there's something to be said for leaving the option of disabling certain features and burying them in a cfg file somewhere. But having as few per-game settings as possible is ideal.

[retrobenny]

I actually helped zilmar for a 32bit engine issue (if even only a little) because of an error on Interpreter that doesn't happen on recompiler which was also preventing me from attempting to find and create ASM hacks for some games. I found proper 60fps for Toy Story 2 but Zurg is too evasively fast unless you fight him in normal 30fps,I need a command for ANDI to read the specific level map after hopefully finding the Map ID address in order to make the code work seamlessly with everything else.

Still could go for that speed boost though,even if the option is global but the games that use TLB whole-heartedly that otherwise won't run at all with it disabled will have TLB forced enabled regardless of the global setting.

Then if not having an option to disable TLB,can there instead be an option that is either per-game or a global setting that bypasses the freezing triggered by TLB Exceptions for simple stuff like my egg object mod not being able to spawn non-egg objects because TLB disagrees with it?
Having the option for a modded TLB would be better than disabling it and may allow the choice for boosted performance because of disabling the thing that even checks for errors and other stuff.
(Object ID type mismatch cseggnormal."filetype",halting R4300i "game is frozen with audio playing instead of added fun working at its fullest")
Switching blue eggs with fire/ice/grenade eggs works with TLB Enabled but other objects only spawn with TLB disabled while the game will freeze with music playing when TLB is enabled with the attempt of spawning those objects in place of eggs.
However the Gold Feather object mod allows Enemies,NPCs,and many other objects to appear with TLB enabled.

I would like to re-iterate something I mentioned somewhere a long while back.
Roughly,the definition of emulator is something that interprets something else equally or better than the original thing does.

Sure N64 emulation is still filled with holes for several games that don't work and many others with varied issues,but in the context of doing things better than hardware,we have up-scaled resolutions,enhancement shaders,overclocking for better fps (1964 then PJ64 while Mupen currently lacks it) without timing issues,custom HD texture packs,save states for games that don't break and emus that don't crash at any point (ignore SM64's working on-console save state mod,or debug it to improve emulator save state compatibility to fix the crash-prone issue),and possibly a few other things I didn't think of or even know about!

[loganmc10]

The problem is with the GS code, not the emulator. If you have a cheat code that doesn't work without hacking up the emulator, then you have a bad code. We shouldn't be modifying emulators to work with things that would never work on a real console, that's not an enhancement.

The speed thing has merit, except that the CPU is hardly ever the bottleneck when using an HLE graphics plugin. I don't think we are in the position where we need to fill the emulator with all kinds of speed hacks, people are able to play these games on relatively modest Android phones, the limit usually revolves around the device's GPU and the graphics plugin, not the emulator core.

[retrobenny]

Technically the codes work in variable ways,but freeze way too often from TLB from even the slightest irregularity.
There is even non-cheat freezes like the glitch on Banjo-Tooie from touching fire as Talon Torpedo Kazooie within the same room you learn Talon Torpedo in. I even have videos proving it.

With TLB;

https://drive.google.com/open?id=0B1nr_75cEfQOYTd5dFphU2h0SEU

Without TLB;

https://drive.google.com/open?id=0B1nr_75cEfQOaDJBTFE0TEtQbmc

Bonus Guide (reaching the area on foot);

https://drive.google.com/open?id=0B1nr_75cEfQOaFR4Njd4MkVTekE

The Android device I have uses a superb GPU and is lacking on CPU power,so the change would indeed boost performance on that front. It could be made exclusive for Android if you want to keep this rubbish out of the main master branch.
What's the point of the Android port if nobody can get consistently full speeds in more scenarios and the stronger hardware can't reach full speed with GLideN64 in most cases?
The Glide64 plugin on Android is a mess on at least other Android devices that lack Desktop GL access for proper rendering,thanks to fzurita for the addition for full GL support.
Mupen64Plus AE via FZ Edition has excellent base-speed performance but that doesn't help enough for GLideN64 when not even legacy blending can run at decent speeds for some games on 1080P scale. And good luck even getting half speed on modern blending at even forced 1x Native because it has a devastating impact on performance regardless of resolution where that extra 30VI/s would indeed be helpful.
One thing you might not think about,some people either avoid Windows (10) outright while others can't access any Windows or Linux on decent hardware to run PJ64 normally or with the few ways of running Windows programs on Linux systems through Wine or other methods.

I myself still have limited access to Windows in a less restricted way now,and would like to have better performance on Android OPTIONALLY along with more cheats also OPTIONALLY working.
Aside from keeping standards for accuracy,emulators benefit from a robust amount of customization.
For example,its surprising to see that even CEN64 runs into trouble where it can't boot some games.
ParaLLEl is the other highly accurate emulator but I don't know whether or not it boots whatever game that failed to boot.
And BizHawk is nightmarishly slow on my Nvidia GPU but not with the Intel and as you would guess,that emulation combo is not available on Android while ParaLLEl has issues via RetroArch along with their Mupen cores,but also,RetroArch has terrible bugs/limitations on Android because of input issues and outright lacking N64 cheat support so its not possible to use the working 60fps codes on their faster normal Mupen cores either.
(Mickey's Speedway USA,most of Mario Kart 64,Diddy Kong Racing,and many of Iguana Games' stuff with some not even having released codes due to being told :( to refrain from releasing them)

[loganmc10]

We are just going back and forth saying the same thing. I'm just expressing my opinion, I don't even have write access to this project. If you can find a dev to do the work and merge it more power to you, I just don't think it's worthwhile

[AmbientMalice]

Mupen64Plus AE via FZ Edition has excellent base-speed performance but that doesn't help enough for GLideN64 when not even legacy blending can run at decent speeds for some games on 1080P scale.

That's a GPU issue, though. These devices are primarily bottlenecked by their GPU. Even the best Android device GPUs generally aren't very good.

[retrobenny]

Well,yeah,proper emulation as priority is expected as the primary objective though falls short on downstream for Android if any increase of accuracy causes a loss of performance with no way to negate that loss.
The few instances I know TLB is needed is GoldenEye and I know Conker uses if memory jumps into the actual ROM data in order to execute several functions outside of the RDRAM range itself but other games like Banjo-Tooie and DK64 don't seem to be doing these kinds of RDRAM->ROM jumps at a glimpse.
I have been able to run both of those games without seeing any issues caused by disabling TLB.
And if TLB doesn't even relate to those jumps,then that would mean even less games would need it much at all other than to provide accuracy to match more closely to what hardware does which honestly is kinda hard when the TLB is pretty messy in its current state and might be less accurate because of those issues and required hacks for some games to even use it at all without immediately running into issues.

In my case,with a Shield TV and its beastly GPU,the inferior CPU is the main bottleneck,especially according to developers of Dolphin Emulator and overclocking the CPU and GPU would help performance (GPU also grossly under-clocked despite performing its duty great anyway) but I am stuck with the high risk of bricking the device to get root access in order to apply overclocking on either temporary or permanent methods.
I would believe it if someone said they got faster performance on another Android device with a decent GPU and a more equipped CPU,even if their device was hooked to a TV in 1080P and also using 1080P up-scaling on the emulator.

Android Oreo has some promising results in performance gains so maybe that will help a bit if compatibility with apps doesn't cause ironic nasty issues.
Still wouldn't make more of the entertaining codes work.

Another thing,both PJ64 and standard Mupen64Plus are NOT used for proper speedruns or TAS recordings to post on TASVideos[DOT]org as BizHawk was suggested to be the most accurate choice that has TAS support.
BizHawk seems to hold the slowest of Mupen cores so it must be heavily accurate,even with Intel GPU running it better,it still struggles to run at an exceptionally good performance when trying to get decent graphic rendering at something larger than 1x Native but smaller than 1080P for average visual quality..
PJ64 just runs too well on Windows for anyone to even bother using any other N64 emulator when they are mainly looking for what can run fast enough with the most visual enhancements on anything that ins't a GTX1060-1080 Intel i5/i7 4.5Ghz leviathan or the AMD equivalent since their processors are getting crazy beastly but have the benefit of being more cost effective in some scenarios.

I have been waiting for something that can run Windows x86 32bit programs and maybe also 64bit programs on ARM Android devices at really good speeds.
There already is a few things that exist with that capability but the only available one named ExaGear is a paid app that is not supported by the device so it can't be installed for that very (DUMB) reason if I even purchase it.
I implore anyone who can use ExaGear (if they already purchased it) to see if PJ64 works on it with any version,I expect newer versions to not work for good reasons but older versions might work.

[loganmc10]

If you have a Shield TV then you know that if you use mupen64plus FZ, and use GLideN64 at native res, legacy blending enabled, it will run pretty much every game at full speed. If you have issues with higher resolutions, or with other GLideN64 options, those are issues with GLideN64, not mupen64plus-core. The CPU is sufficient to emulate the game as-is when using the dynarec and HLE graphics.

By the way, BizHawk is just using an old version of mupen64plus, it is not any more accurate, I'm not sure why it would be slow though, I've never used it.

[retrobenny]

One way of how it works is that if anything makes core performance faster normally,its very likely to cause better performance on other much slower plugin setups as well,meaning one could displace enough of a speed boost to sustain nearly full speed in more situations than before.
So the goal would be to get everything that can further boost core performance while reducing CPU usage on all parts to achieve much higher minimum fps speeds.
If GLideN64 could get substantial Sync mode optimizations,it would be VERY possible that it could exponentially increase performance of the Asynchronous color buffer mode which would even get to the point of being faster than disabling color buffer altogether and would make modern blending mode more manageable in performance so it could actually be used conventionally.

Or if legacy blending would get some love,it could at least render as much as Glide64 but with better performance with improved optimizations (and no middle-man wrappers) to avoid overhead and bottleneck issues.
I want this mode for PJ64 so I can find codes with the best performance because it seems to outperform every other plugin as it does in BizHawk's Mupen on Nvidia when set up just right.
I would get so much performance that it would even rival recompiler speeds on other plugins and never dip below 60VI/s in most cases.

The primary concern represented in this issue was getting more codes working for entertainment purposes on recompiler but performance boosts are also the additional concern in general and so 60fps codes can run better with less slowdowns with that 30VI/s+ increase in speed.
If anyone wants it to not be tarnished they can enjoy 5fps on Pure Interpreter with TLB also enabled even though Interpreter seems to natively run TLB functions without even requiring the option to be enabled because the same freezes happen on Interpreter from its accuracy.

If you didn't watch the videos showcasing the difference of TLB enabled/disabled for one of the non GS code scenarios,I would appreciate it if you'd watch them.
And a fact; There is an action designed exclusively for Talon Torpedo Kazooie to take damage from elements like that,so it was intentional for it to be possible to get fire damaged while in that specific form but its original programming has some sort of flaw ending in disaster.
The Jiggy Collection Dance from B-K is also oddly still intact but is very buggy to invoke unlike the leftover 10 Jiggies/Note Door Dance. Just thought this would be an interesting detail to share.

[retrobenny]

A really good example is if I ever find a 60fps (that works properly) or other enhancement-based code like widescreen fixes or (if lucky) some other draw-distance/no culling mods for any game that doesn't work with TLB enabled or Interpreter,this would be a good reason to have it possible to toggle TLB usage. So far its not an issue while Mupen even runs some games better than PJ64 with 60fps codes like Mickey Speedway USA never crashing except when on PJ64,but you never know.

[AmbientMalice]

A really good example is if I ever find a 60fps (that works properly) or other enhancement-based code like widescreen fixes or (if lucky) some other draw-distance/no culling mods for any game that doesn't work with TLB enabled or Interpreter

Such a code would be an inherently bad code, though. If it doesn't work on real hardware, it's bad.

[retrobenny]

The whole point is to have the ability to use said enhancement or 60fps on emulation.
Of course the hardware has NO way of using 60fps hacks because it lags too hard and the real hardware overclocking runs too fast while emulation overclocking runs okay with proper timings wihen using 60fps codes which is why Mupen would benefit with this feature too for the few games that can reach full speed on even Android like Mickey.
The 60fps code for Mickey's Speedway USA would actually never reach 60fps on console because it can't even make it to 60fps in most scenarios and doesn't use fractions of fps to achieve speeds greater than 30fps either.
So there is no reason for that 60fps code to "work" on console because of the performance causing the cap to hit 30fps and slower anyway.
But if it is possible force it to stay on 60fps pacing then it would be a very slow experience.

But I want to run bad hacks of SM64 and other broken stuff.
Sega Genesis emulators have options to turn off a host of errors so hacks can run on them perfectly and also for avoiding the Sonic 1 error of scrolling down the screen in a roll when in Labyrinth Zone regardless of original game or one of the many hacks that didn't patch it. (this error is most likely HSync instabilities from the water)

I just recently tested Conker's Bad Fur Day with TLB disabled and it immediately runs into errors.
New PJ64 has some harder to explain errors while the 1.7 leak only gives me a non-mapped space error then closes the game.
Neither Tooie or DK64 ever run into these errors with TLB disabled,and I have been through most of the entire game's stuff (no excessive use of the multiplayer stuff) for both of these without ever running into issues.
I will edit in my results with other games like GoldenEye soon.

[AmbientMalice]

Of course the hardware has NO way of using 60fps hacks because it lags too hard and the real hardware overclocking runs too fast while emulation overclocking runs okay with proper timings wihen using 60fps codes

Which is actually potentially a problem. The current implementation of COUNT is extremely wrong, and something will need to be done about it if some games are ever to work correctly. The hack should change the framerate cap from 30 to 60fps on real hardware. Doesn't matter if the game runs at 60fps properly.

But I want to run bad hacks of SM64 and other broken stuff.

Then you risk ending up with a compromised emulator like ZSNES. As N64 emulation improves, a lot of Mario 64 rom hacks and the like simply aren't going to work anymore. A lot of them don't work on Angrylion's/GLideN64, for example. And that's not something you can just "turn off" like TLB.

It's better for emulators to pressure the hacking community into writing code that actually works on real hardware, IMO. People writing hacks and cheats that aren't hardware compatible causes no end of problems.

I will edit in my results with other games like GoldenEye soon.

As mentioned earlier, GE is a tricky case because it's using a hack that really should be removed down the road. There are a number of hacks that only exist because people cared more about playing popular games than developing accurate emulation way back in the day.

[retrobenny]

GoldenEye doesn't boot with TLB off and stays at 100% R4300i usage.
A handful of other games also ran fine with TLB unchecked.
I have yet to try and see what happens with TLB disabled and using Interpreter.

There is no way to run some mods on actual console when it comes to using over-sized RDRAM expansion mods for 12MB or greater sizes unless you would invest into some expensive or hard to acquire physical mods.

And what if suddenly a flood of issues came in saying X cheat code doesn't work in Mupen but works in PJ64 when disabling TLB?
It hasn't happened but it could randomly occur and actually be worse than the small case of TLB disabled makes (very few) games not work that do work with it enabled.
This type of issue post would get easily answered with "then keep TLB enabled for those games" and briefly solved by that answer,or better yet,some patchwork could be made to force those few games to use TLB regardless of the setting whether its global or per-game.
The idea of per-game would be easier if its defaulted to enabled,meaning one could change any individual game's setting just like other settings within that game's generated ini/cfg file to disabled for the ones that don't run into issues.

In passion,I really can't stand seeing a lot of my hilarious corruption codes not working on Android when they work perfectly fine on Windows which has the primary version of PJ64 to access with a super easy way to use cheats comfortably.
Some of the codes that fail can partially work at some values of the varied effects but other values fail to work.

Oddly enough,the instrument corruption/mod on Banjo-Tooie which has the water style instruments not working on Mupen Android but PJ64 is capable of accessing the sounds and play fun remixes of water-less area themes like Jinjo Village.

This code...

Banjo-Tooie (U)

Music Instruments Mod
81024888 3405
8102488A 0042
Water styled music.

This code actually works with TLB enabled,so something is throwing it for a loop when using Mupen in this scenario where it either ends up muted or crashes directly at one point before the sound can be heard for the water styled instrument on land,possibly sound emulation accuracy being too strict.
I also tried Azimer's XA2 Audio 0.70 WIP 6 and the code works there as well.
Edit: The code also worked on Interpreter with PJ64 and TLB still enabled.

Corruption codes are easily the BEST ones for the pure comedy and entertainment values.
Most corruption codes are ended much sooner when TLB is involved dropping the fun factor considerably,particularly Vinesauce streamed ones because of the TLB responding to the coding that is incorrect behavior,stopping the fun very early on.
Obviously any corruption and corruption code is definitely a bad code because it corrupts things for amusement at the heavy risk of crashing/hanging/freezing things.

I wonder,what if I can hack TLB usage stats via RDRAM to disable/limit it in each game so the freezes can be avoided on any emulator?
If so,I need to figure out how to pull this off and I am curious if it would work on console to bypass simple freezes caused by "bad" codes.
Also,cheats are harder to pull off in general on an actual N64 console because games like DK64 dislike Gameshark itself when even using good codes for basic stuff found in static address locations and clean ASM changes that don't go into the "bad" territory.
I think some games probably are completely incompatible with a Gameshark/Action Replay/Codebreaker meaning they won't boot no matter what the condition is.

[retrobenny]

New test results for that music code on accurate settings.

The code on PJ64 even works in LLE with a newer version of Angrylion and with Hatcat's Static Interpreter RSP plugin.
Someone please suggest the most accurate over-all set of plugins that work in PJ64 unless these are already the most accurate then I can get to testing that combination to see the results.