Beta Mupen64Plus

[mhadf]

Well this is because Notaz's frontend is not a frontend, it's a part of his emulator (I believe, not actually looked at the source.), Whereas Picklelauncher is intended as a launcher for GUIless applications. It would require much more work for me to separate Notaz's GUI code from he emulator code (I find emulation code very scary to look at...) And this is simply time I do not have.
Picklelauncher took 2 evenings to get up and running and if I can remember how to make a multi-app PND I can make it so you can still run the mupen64plus GUI for config options.
Awesome!

Wouldn't a Zenity script give you a basic selector for picklelauncher or config?
Addin a jump straight to Picklelauncher option and you can just jump straight in too

 

[PokeParadox]

Ok, I have updated my Picklelauncher version to include Aventus's update
Also added and option to launch the Mupen64plus GUI or Picklelauncher.

http://projectinfinity.org.uk/lib/exe/fetch.php?media=pokeparadox:beta:mupen64.pnd

 

[Phawx]

@adventus @pokeparadox

Thank you guys! Adventus, it's good to see you back in some form.

 

[ozzyfreakdude]

Here's the new release: http://gles2n64.googlecode.com/files/mupen64plus-r1b5.pnd

I don't remember whats changed since last release (or BZ'z releases which are based on my own newer code). Somethings i did recently:
- added per game configuration: you can find a file "config/gles2n64rom.conf" which acts as an override for the settings in "gles2n64.conf", you should be able to figure it out... I've added some games i used for testing.
- added autoframeskip: not enabled by default. It only comes into effect when the FPS falls below the "target FPS". If its a PAL game the "target FPS" is multiplied by 5/6. You generally want to target FPS to be a few FPS below the actual FPS (ie i use 25 for 30 fps games).
- fixed zelda sun (well known problem)
- Banjo Tooie / Jet Force Gemini work (require "ignore offscreen rendering" to be enabled)
- other stuff i don't remember

Anyway there is a problem with some textures in zelda, not sure if its a combiner or texture issue. I'll look into it.

Awesome update! Auto-frameskip should make a large number of games playable now that weren't playable before.


That said, i tried Ocarina in this new release to see if it would get past the point it was freezing at, and it froze in the same manner. I looked in the new video plugin options, and a "zelda hack" option is added. I'm not sure what exactly it does, but I tried with it turning on (thinking that it might fix the triforce freeze) and it still froze.

Has anybody other than sterling and bzfrank gotten it to work? And has renegadechic gotten it to work yet? I find it extremely strange that it works for some people under hotfix 5 (assuming that bzfrank himself used the workaround that he posted, and that he's running hotfix 5 himself) by just running it in windowed mode, but not for others.

The answer probably lies in figuring out the difference between bzfrank's setup (I'm assuming that he's running hotfix 5), sterling's setup on hotfix 4, and everybody else's on hotfix 5 (mine, renegadechic, and whoever else is having the issue that might not be posting in this thread).

For the record, I'm running the (first) pnd installer release of hotfix 5 and I have the codec pack (from the pnd installer) installed. I run mupen64 at 850mhz, but when I set the cpu speed down to 600mhz and to 500mhz, it behaves in much the same way. If anybody needs any more information, just name it - I just don't know what more to provide at this point.

What I find interesting - and likely related - is that Majora's mask freezes in much the same way. When you start a game, it's supposed to flash a few screens of text before showing any graphics. It starts out showing the first screen of text - "In the land of Hyrule, there echoes a legend. A legend held dearly by the royal family that tells of a boy..." - and then when that text goes blank, the system hard-freezes. Considering that they're both zelda games and they both hard freeze in cutscenes, these two crashes are very likely related. The most interesting thing about it, though, is that it freezes at that point when running at 850mhz and at 600mhz, but it doesn't freeze at 500mhz. However, Ocarina freezes even at 500mhz. Can anybody else replicate this with Majora's mask?

 

[bzfrank]

Anyway there is a problem with some textures in zelda, not sure if its a combiner or texture issue. I'll look into it.

This effect happens when the texture buffer is too small.

Did you merge in my code? Gameplay feels slower in LOZ:OOT now?

 

[Adventus]

That said, i tried Ocarina in this new release to see if it would get past the point it was freezing at, and it froze in the same manner. I looked in the new video plugin options, and a "zelda hack" option is added. I'm not sure what exactly it does, but I tried with it turning on (thinking that it might fix the triforce freeze) and it still froze.

If you could provide me with the rom and save file (it should be in pandora/appdata/mupen64plus-r1/config/save or something and have the same name as the rom name showed in GUI) I could look into it. I could at least tell you which UCODE command is causing the crash (if its not a dynarec issue). In the mean time i suggest you get past that point in the x86 version of mupen64plus then copy the save files over (they should be compatible). The zelda hack just fixes the sun texture.

I have noticed some strange behaviour in the GLES2 driver. Sometimes it will freeze for a couple of seconds, return to normal, then freeze again until it eventually crashes. I know its occurring within the glDraw* calls (I've measured it). I think its actually writing to SD Card during the freeze.

This effect happens when the texture buffer is too small.

Do you mean the static buffers that are used for conversion? I've changed them back to malloc-ing every time. I'm pretty sure my old texture cache code works (which i've ported to the new version), so i should be able to figure out whats wrong.

Did you merge in my code? Gameplay feels slower in LOZ:OOT now?

I didn't directly copy any of your code, but i did do some of the changes i could see in it (fast CRC, texture hashmap). Does the depthbuffer hashmap really help?

 

[ozzyfreakdude]

Adventus - check your PMs

 

[bzfrank]

That said, i tried Ocarina in this new release to see if it would get past the point it was freezing at, and it froze in the same manner. I looked in

This effect happens when the texture buffer is too small.

Do you mean the static buffers that are used for conversion? I've changed them back to malloc-ing every time. I'm pretty sure my old texture cache code works (which i've ported to the new version), so i should be able to figure out whats wrong.

Did you merge in my code? Gameplay feels slower in LOZ:OOT now?

I didn't directly copy any of your code, but i did do some of the changes i could see in it (fast CRC, texture hashmap). Does the depthbuffer hashmap really help?

It depends - if more than 3 DBs are used and they are constantly shuffled its faster. Thats what my synthetic benchmark did say - don't know if this is a real world scenario for DBs though. But I was doing it for the Texture cache and I thought that it would not hurt for DepthBuffers also.

I would still use a static buffer for the textures and swap buffer, even if it is only 128k it helps a lot. Just malloc/free everything above that limit. Malloc can be slow sometimes and I still have the itching feeling that deep down inside the emulator messes with the heap a bit so the less allocations go on the better (gles2n64 seems rather clean, I checked everything so far for r22). Maybe it would be a good idea to valgrind mupen someday.

BTW Which mupen version did you use for your build, it looks different to ARIs Feb 2011 release?

 

[bzfrank]

The answer probably lies in figuring out the difference between bzfrank's setup (I'm assuming that he's running hotfix 5), sterling's setup on hotfix 4, and everybody else's on hotfix 5 (mine, renegadechic, and whoever else is having the issue that might not be posting in this thread).

Stock HF5, nothing changed. It worked right that first time I tried the windowed emulator. To be sure I tried a second time, worked too (At 600 Mhz both times)...

 

[bzfrank]

And I did a shutdown right before each run so the gfx driver has a clean system to work with... don't know if this changed things though.

 

[Adventus]

I would still use a static buffer for the textures and swap buffer, even if it is only 128k it helps a lot. Just malloc/free everything above that limit. Malloc can be slow sometimes and I still have the itching feeling that deep down inside the emulator messes with the heap a bit so the less allocations go on the better (gles2n64 seems rather clean, I checked everything so far for r22). Maybe it would be a good idea to valgrind mupen someday.

I would be surprised if it helps alot. They are only used when a texture is not already in the texture cache which is fairly uncommon (beyond the first few frames of a scene) since the cache is so large. You can benchmark the texturecache hits/misses per frame by defining TEXTURECACHE_TEST. Anyway, If it makes it more stable its definitely worth it. There should be a pretty set in stone upper limit on its size (since there only so much texture memory on the N64), thats why i was surprised when you said making it larger fixed these issues (I may have just miscalculated).

BTW Which mupen version did you use for your build, it looks different to ARIs Feb 2011 release?

Yeah, i have a few modifications i make to the source to make the GUI a bit nicer, etc. Currently i just copy them directly over Ari64's source. If anyone wants the source PM me.

@ozzyfreakdude Thanks

 

[bzfrank]

I just had tried to walk the castle ground in LOZ:OOT but it almost everytime hard freezes in the cut scene. I always got to the princess but when she tells her story in the cut scene... bang, deep freeze. Only a hard reset could revive the Pandora. 600 Mhz, 700 Mhz does not matter - not always at the same spot though (and not when the Triforce appears, usually it happends in the castle ground itself but during the cut scene). Thats with the older Mupen version from Ari64 and with your newer one (tried both). Pretty much the same as the freeze at the triforce cutscene and similar to the one in LOZ:MM when opening a saved game.

BTW Much nicer GUI!

 

[God Ginrai]

Is Adventus' latest release using Notaz's most recent sound plugin? I'm hearing that speaker-popping sound when running OoT again. :/

EDIT: Also getting it in SM64, just not nearly as much.

-God Ginrai

 

[EvilDragon]

Is Adventus' latest release using Notaz's most recent sound plugin? I'm hearing that speaker-popping sound when running OoT again. :/

EDIT: Also getting it in SM64, just not nearly as much.

-God Ginrai

It is there, but with this release, sound is much worse... it seems like the new GLES plugin has some sync issues with the sound.
There also seem to be other bugs, Mario Kart freezes pretty often for a couple of seconds for me... it might be connected to notaz sound plugin somehow, as it always freezes when something happens (i.e. if I bump into a car, grab an extra weapon, etc.), which causes a sound to be played.

 

[God Ginrai]

Is Adventus' latest release using Notaz's most recent sound plugin? I'm hearing that speaker-popping sound when running OoT again. :/

EDIT: Also getting it in SM64, just not nearly as much.

-God Ginrai

It is there, but with this release, sound is much worse... it seems like the new GLES plugin has some sync issues with the sound.
There also seem to be other bugs, Mario Kart freezes pretty often for a couple of seconds for me... it might be connected to notaz sound plugin somehow, as it always freezes when something happens (i.e. if I bump into a car, grab an extra weapon, etc.), which causes a sound to be played.

Well, I remember notaz's first attempt at the sound plugin had this problem, and then he fixed it with another release. I was wondering if it was possible that Adventus released this with notaz's first release of the plugin and not the later release.

EDIT: Another thing to note: There was no conf file for the sound plugin when I checked my directory, while with my older version of Mupen64plus with the working sound plugin that I used did have a conf file. This might also suggest that this release is using Notaz's first release.

-God Ginrai

 

[bzfrank]

Got something working here that seems to prevent the hard freezes during gameplay. Need to check further though...

 

[notaz]

Just for reference, my latest source (and binary) is here:
http://notaz.gp2x.de/releases/misc/mupen64plus_notaz_audio_r2.zip

 

[God Ginrai]

Just for reference, my latest source (and binary) is here:
http://notaz.gp2x.de/releases/misc/mupen64plus_notaz_audio_r2.zip

Thanks, that pretty much confirms that Adventus is using the old version. The version in the most recent release is listed as notaz audio r1.

-God Ginrai

 

[Blue Protoman]

Does this mean that I'll have to download ANOTHER Mupen PND? I've downloaded some new revision of it three times in as many days.

 

[jonjandran]

Does this mean that I'll have to download ANOTHER Mupen PND? I've downloaded some new revision of it three times in as many days.

Just wait a few days and download the latest IF you need to. If its not something new that you need or want then why worry about it.