PDA

View Full Version : super smash bros glide exception


filenotfound
10th April 2013, 06:08 PM
Well when trying to open super smash bros after the n64 logo, it stops and glide64 plugin pops up and error message:

Glide64 exception
The GFX plugin caused an exception and has been disabled. Would you like to turn it back on?

If you click yes, the game never seems to render video at all. and clicking no ofcourse just pauses the emulation (unpausing just does the same result as clicking yes).


The game loads fine with jabos plugin, but doesnt on glide64 (final). And i want to use glide for loading an HD texture pack.
It seems rice 6.1.4 is really buggy after loading the texture pack of the game.


The game loaded fine with glide64 (final) with the texture pack in 1.6


EDIT: problem solved by using these settings in rdb
Linking=0
SMM-Cache=1
SMM-FUNC=1
SMM-PI DMA=1
SMM-Protect=0
SMM-TLB=1
http://forum.pj64-emu.com/showthread.php?t=3601

since when i tried pokemon, i got the same issue and figured it would likely stem from the root cause.

HatCat
10th April 2013, 09:55 PM
(moderated post)

We will have to all avoid editing things like certain links or image URLs into our posts until we have been around long enough for it to not raise suspicion to the forum.

HatCat
10th April 2013, 10:11 PM
Well when trying to open super smash bros after the n64 logo, it stops and glide64 plugin pops up and error message:

Glide64 exception
The GFX plugin caused an exception and has been disabled. Would you like to turn it back on?

If you click yes, the game never seems to render video at all. and clicking no ofcourse just pauses the emulation (unpausing just does the same result as clicking yes).


The game loads fine with jabos plugin, but doesnt on glide64 (final). And i want to use glide for loading an HD texture pack.
It seems rice 6.1.4 is really buggy after loading the texture pack of the game.


The game loaded fine with glide64 (final) with the texture pack in 1.6


"GFX plugin exception" generally implies that the graphics simulation has to stop. I never click Yes anymore personally; you may as well just close pj64 every time that error would pop up.

Fortunately it almost never does when I disable any crazy-ass codes I have turned on.

In your case, basic Cache/Check Memory & Cache settings from like, pj 1.6, were insufficient and caused an unaligned DMA request which got sent to in this case Glide64 thus attempting to simulate the DMA transaction incorrectly.
Better self-modifying controls like what you set in the RDB or an interpreter setting fixed it on the CPU's side.

I'm not sure if Jabo's plugins are more resilient to those gfx exceptions, can't remember.
They would have loaded the HD hi-res texture paks if there was a way to port them.

squall_leonhart
11th April 2013, 04:06 PM
the exception in this case ise caused by the wrong rdb settings for the game

Start Changed should be used instead of Protect Memory

this works for 1.6 as well (Nekokabu rdb already sets this)

HatCat
11th April 2013, 05:47 PM
Umm except there isn't a "Start Changed" setting on 1.6? :/

None
Cache
Check Memory & Cache

^ those 3 settings all crash the game at a bad DMA address sent to the RCP

Check Memory Advance
Change Memory & Cache
Protect Memory

^ fully played 100% through Super Smash Bros. using those 3 settings while testing my RSP interpreter

squall_leonhart
11th April 2013, 05:53 PM
Change Memory and Cache is the equivalent of Start changed.

Glide64 does not recieve an exception with this setting.

Jabo's ignores it.

HatCat
11th April 2013, 06:16 PM
How do you tell?
Is it apparent when a HLE gfx plugin encounters an exception while simulating the ucode but manages to safely ignore it?


Honestly, I think I preferred the former name.

"Start changed" etc. in 1.7/2.0 self-modifying code names sound so unscientific, unliteral, caveman-ish...made me think you boot the game with changed self-modifying code but do nothing after that?

squall_leonhart
11th April 2013, 08:18 PM
Jabo's has a JIT exception handler

thats the only reason it isn't affected by the invalid data.


Cache - Clear the address of code on a cache write
PI DMA - Clear the code if it is replace via a dma from the rom
Start Changed - When executing a block check if the first 4 instructions are the same, clear if different.
TLB Unmapped - if the virtual address is unmapped from rdram then flush those blocks
Protect Memory - Change the 4k block where any code is written to read only, writing to that block will generate an execption, the emu picks that exception up, flushes the code if any write to the block