Smoke and Explosions in GoldenEye and Perfect Dark Reduce Framerate To Slideshow

[deuxsonic]

A separate issue I've been having playing GoldenEye and Perfect Dark is that despite how well they perform most of the time in 1964 with GLideN64, walking into smoke or explosions instantly drops the framerate to an unplayable state. It reminds me of the Medusa effect bug from DOOM because as long as either are still in view the situation either has to be waited out for both to disappear or if you can, turning away so that they are no longer being viewed. Has anyone else experienced this with these games? It seems strange for those 2 effects to be the only things that can slow the game down to an unplayable state.

[dankcushions]

that sounds like accurate emulation to me :)

[retrobenny]

Try zooming into a fire torch in Mayahem Temple's treasure room tunnels,and it may slow to a crawl on higher resolution and with one of the 60fps code choices.

Improved 60fps D207913F 0000 8007913F 0001 81125D10 3C88 81125D12 8889 80125D19 0088 80125D1D 0088 D0127633 0005 8003F4F2 0002 D2127633 0005 8003F4F2 000D Softlocks in cut-scenes still occur,original code combats them but makes the game run at a faster pace.

And here that code is...

Ultra 60fps Hack D207913F 0000 8007913F 0001 81125D10 3CA4 81125D12 8889 80125D19 00A4 80125D1D 00A4 D0127633 0005 8003F4F2 0002 D2127633 0005 8003F4F2 000D

I bet if I were to use this newer code on Android with the accurate blending,it would run even worser than before and make the Shield TV get really hot.

[deuxsonic]

No question it's probably hitting the nail squarely on the head, but it makes me wonder why Rare couldn't come up with a better-performing solution for these 2 effects... I would take half resolution or quarter resolution smoke and explosions if it meant avoiding the performance hit (everything else is good though.)

[deuxsonic]

Will those codes work with GoldenEye/Perfect Dark? You mentioned a different game.

[retrobenny]

Forgot to mention the codes are for Banjo-Tooie,my bad. Its another game that can severely lag on GLideN64,mainly with the 60fps code enabled.

DK64 also has a laggy moment when fighting the Crystal Caves Armydillo rematch and the smoke effects come out,but maybe that was with some glitch codes to manipulate the animation to keep him smokey and getting closer to zoom in on the effects.

The lead cause of this is shader rendering on the modern blending which has a much heavier impact on processing Mhz/Ghz.

[gonetz]

@deuxsonic could you give me a save state to check? Preferably right before the smoke that I do few steps and see that slowdown.

[deuxsonic]

So during the explosion or right as a bunch are starting or just with the smoke left?

On Sun, Mar 19, 2017 at 9:24 AM, Sergey Lipskiy notifications@github.com wrote:

@deuxsonic https://github.com/deuxsonic could you give me a save state to check? Preferably right before the smoke that I do few steps and see that slowdown.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gonetz/GLideN64/issues/1381#issuecomment-287616479, or mute the thread https://github.com/notifications/unsubscribe-auth/AHTtPYw_NStJ_K5Kz7V0jV-ShSS5kdjVks5rnSyQgaJpZM4MBYoB .

[gonetz]

Any moment, from which the problem can be easily reproduced.

[deuxsonic]

The easiest I can think of is simply walking into a proximity mine in Perfect Dark multiplayer. The next 10+ seconds are a slide show.

http://www.mediafire.com/file/j3mgo91ryb61j3b/pd_explosion.sav

Here is a save state taken in 1964 with the current WIP GLideN64 DLL in the midst of a system-killing explosion.

[Jj0YzL5nvJ]

Is just like @dankcushions commented. In the real hardware you experience frame drops and lag in massive explosions, smoke screens and shooting many times to a wall when you are too close. You have to allow "frame skipping" in the emulator plugin. You can mitigate the effects a bit using 8MB (Expansion Pak) instead of 4MB (Jumper Pak) in case of GoldenEye. In Perfect Dark, deactivating the Hi-Res mode... in the emulator does not see the effect anyway.

As developers kept adding more features, the game ended up using all the extra memory on the debug consoles.[30] As a result, the game became too big to fit into the Nintendo 64's 4MB of random-access memory (RAM).[30] The developers soon realised that they were not able to optimise it and decided to make use of the Nintendo 64 Expansion Pak, which increases the Nintendo 64's RAM from 4MB to 8MB of contiguous main memory, to support most of the features in the game.[30] After playing the release version of the game, Hollis was impressed by the comprehensive range of multiplayer options, which he described as "a vast array of features I never planned".[31] Doak, however, remarked that "GoldenEye pretty much exhausted the performance of the machine. It was hard to push it further. Perfect Dark had some good ideas but was dog slow."[41]

https://en.wikipedia.org/wiki/Perfect_Dark

[deuxsonic]

I'm not sure where frame-skipping is in the emulator. It is version 0.8.5 of 1964 that has been customized for GE and PD.

http://www.shootersforever.com/forums_message_boards/viewtopic.php?t=7045&start=0&postdays=0&postorder=asc&highlight=

8 MB is already in-use and high-res mode is not active.

[theboy181]

If you over lock the emulator and the FPS are still dropping it's the plugin. Have you tested this with other plugs?

The game will dip in performance during these intense explosions but 2cycle mode needs optimizations.

[deuxsonic]

I have, and the other plug-ins are either wildly off on their accuracy (the Direct3D plug-ins) or just slow constantly (glide64). GLideN64 happens to both perform well and be very accurate. It just seems like explosions and smoke when nearby and in-view cause it to grind to a halt.

[oddMLan]

Can you try with Mupen64plus with legacy blending enabled?

[deuxsonic]

http://www.mediafire.com/file/rvrwg8x3jfnd2ei/test2.sav

Here is another save state from GoldenEye with the game paused after explosives set off. The problem is that the explosions hastily finish during the pause, so after only the smoke remains, which has some of the slowness but not like it would in an explosion.

[retrobenny]

Got a code to test even though it doesn't reflect the way this issue happens,this code works on CF=1 and only at 30fps because it crashes when using the 60fps code or when removing lag via VI Refresh Rate boosting.

Banjo-Kazooie (U) (V1.0)

Water Droplet Benchmark 813796E0 3A76

Get to floor 3 in Grunty's Lair (waterfall near the TTC lobby entrance) and there will be tons of water droplets falling from the ceiling,try to get the lowest framerate you can get on a CounterFactor of 1 or CountPerOp of 1 using unlimited fps or fast forward. I stood next to the waterfall near the pipes and set the closest camera view then faced the droplets.

On Glide64 I get 75fps down to 60fps at its lowest,and on GLideN64 I get 42fps with it rendering to my 960x720 output on all "fewest game issues" settings. Take note this was the 2.0 public release of GLideN64 and not the latest commit updates.

This code is not in the same way the lag I experienced via Android in Banjo-Tooie on the 60fps code when zooming in on the torch fire within Mayahem Temple Chief Bloatazin's chamber (top floor) quite a long while back when not in legacy blending mode.

Hope all of this can help in some way.

EDIT: Larger scale benchmark code to try,I get a mere 13fps on Glide64 and am afraid to try GLideN64 to see how much slower it is.

B-K (U) 1.0

Ultimate Water Droplet Benchmark 81275C92 0C4E 80359CD7 008E 803796E1 0036 Uses partial lagfix code to remove frame-drops,spawns several images of Clanker rapidly to bring actual performance to a crawl while somehow not overloading the game.

[deuxsonic]

Upgraded my graphics card, which does actually improve explosion/smoke performance to where there's no framerate hit most of the time unless it's particularly large. Those explosions and smoke take some serious computing power it seems.

[loganmc10]

I remember lots of cases playing multiplayer GoldenEye on a real N64 back in the day, and large explosions would bring the system to a crawl. Accurate emulation I suppose lol

[deuxsonic]

I believe it. There are occasional very short hitches despite caching shaders helping it out somewhat.