Beta Mupen64Plus


I can confirm Zelda - Ocarina of Time crashes after you start.

notaz OSS plugin is nice, if the emulator is fullspeed - otherwise, it crackles :)
 
WOW, is it just me, or does Mario 64 run fullspeed with sound at 800 cpu setting?

This is Fucking AWESOME! Great work guys, the N64 looks so fab on the Pandora's screen. The very best I have personally seen it over the years. It has a little ghosting, but nothing that's a deal breaker.

I know Mario 64 is always the bench mark for N64 emulation, but it would be spectacular if more games can get to this level of quality with sound. I'm taking my Pandora to the Classic Gaming Expo in Las Veagas at the end of the month, and I think Mario 64 will be my show piece for sure. Really great work to all involved. Where's the donation link?

Chris
 
jumpman said:
I know Mario 64 is always the bench mark for N64 emulation, but it would be spectacular if more games can get to this level of quality with sound.
Seriously, try Forsaken... I'm pretty sure it runs better than Mario64 :eek:

EDIT: I tried it on 600MHz still fullspeed. I just faced a boss and then it had slowdown, but on normal levels it runs beautifully.
 
Last edited by a moderator:
PokeParadox said:
jumpman said:
I know Mario 64 is always the bench mark for N64 emulation, but it would be spectacular if more games can get to this level of quality with sound.
Seriously, try Forsaken... I'm pretty sure it runs better than Mario64 :eek:
I'm gonna try it out now!

Damn, why does the good stuff happen when I have work to do. :p

Chris
 
Last edited by a moderator:
Good work in the last version with framskip of 1 frame (Framskip of 2 in plugin setting) with sound at 500MHz in mario 64 seem to be full speed (some little crackling sound)
 
Hi guys

First thank you for this great emulator. I got my Pandora about a month ago and have almost only used this emu till now.

Most of the time I'm playing Zelda oot, the new pnd doesnt seem to work for be but the 2nd release is very playable at about 720. I am adult Link and almost in the Forest temple now. Unfortunately the emu crashes often while playing Oot. Does anyone know if there is a fix for that? That is the only thing holding me back from finishing the game. I also dont ink that is has to do something with OC as I can exit the emuwithout resetting and the system works like always.

Would be great if this issue can be resolved!!

Cheers
Flam
 
The most recent release was a major step back as far as Bomberman 64: Second Attack is concerned. The game used to display everything perfectly except for hud and text items ingame. Now the vatical logo doesn't show up, the text during the intro doesn't even appear, the Story, Versus, etc. menu doesn't even appear, the Planet Selection doesn't even appear, the save selection screen does not appear except for one element, and when you finally get in game, the HUD still is not there. -_-

However, for 1080, the game works great. However, I am more disappointed about Bomberman because it emulated with full sound at 750 MHz with only the very rare slowdown, whereas 1080 still doesn't have full sound even if you clock it to 850. If you could look into the Bomberman 64 issues, it would be greatly appreciated.

-God Ginrai
 
neogramps said:
Just tried out Ocarina of time Master Quest with the new version, using Notaz's audio plugin, and a frame render of 2 - it loads, and gets into menu, then when selecting a game file it crashes and flashed up an error about a memory error, and a possible invalid setting in a plugin.
Hmmm, very odd, I've been able to play OoT with pretty good results since rev3. Where abouts in the game's timeline was your save? Mine works fine loading to the first dungeon.

neogramps said:
Also, playing Mario Kart, it seems to double-up my button presses in the menu - so you can't select 1P time trials, because when you select it once, it takes you through to the next screen - not a deal breaker, but annoying. In game is awesome, sound is great, just a little slow down here and there (@750), but very playable
Yeah, that seems to have happened since this Rev for me too :s. Ah well, we can still play the first and last grand prix sets :p .

wermy said:
Quick! Someone test Goldeneye on the new version! :D
Tested it -not much better I'm afraid (fairly big slowdowns, especially in proximity to enemy NPC's), though the sound is a little better. I really hope Goldeneye becomes playable eventually :) .


I've tested my N64 games collection on this Rev, and have noticed the following changes:

  • Tonic trouble now doesn't freeze when you first save to mem pack, and is fully playable with sound at 800mhz (possibly less, though I like 800mhz). [Update: crashes on second level, or loading]
  • Perfect Dark seems to register the one controller as all 4, so if you go into multiplayer with simulants, you'll control 4 players and the screen splits (massive, massive slowdown :p ).
  • Banjo Kazooie, although the same speed as the last rev, now doesn't crash during flight, as it occasionally did. BK is so close to playable, but the sound gets too stuttery at parts still.
  • F-zero X, despite some texture problems, is fullspeed at 800mhz with Notaz' sound plugin.
  • Super Mario 64 is fullspeed with sound, even when clocked a little lower than usual :)
  • Super Smash bros. no longer crashes during battle, though is probably a little too slow to be playable just yet.

Will add more as I try them.
 
Last edited by a moderator:
Viral18 said:
neogramps said:
Just tried out Ocarina of time Master Quest with the new version, using Notaz's audio plugin, and a frame render of 2 - it loads, and gets into menu, then when selecting a game file it crashes and flashed up an error about a memory error, and a possible invalid setting in a plugin.
Hmmm, very odd, I've been able to play OoT with pretty good results since rev3. Where abouts in the game's timeline was your save? Mine works fine loading to the first dungeon.

That is odd, because I tested OoT after the comments here about it not working, and with a new save file, the game just black screens as soon as you choose to start the game. I got no crash or memory error.

-God Ginrai
 
Last edited by a moderator:
PokeParadox said:
Quick question... how do we save to memory pak...?
Well surely that's specific to the game. In tonic trouble you can only save to mem pack, so it just acts as saving on a normal game. Though I just tested loading from mem pack, and that seems to crash it :\ I haven't tried the mem pack saves in other games yet though (Perfect Dark also has the option I believe).
 
Last edited by a moderator:
Viral18 said:
PokeParadox said:
Quick question... how do we save to memory pak...?
Well surely that's specific to the game. In tonic trouble you can only save to mem pack, so it just acts as saving on a normal game. Though I just tested loading from mem pack, and that seems to crash it :\ I haven't tried the mem pack saves in other games yet though (Perfect Dark also has the option I believe).
Haha... I have an N64... I mean how do we have the emulator save to mempak... because my Mupen64 here doesn't seem to be saving if it's mempak saves.
 
Last edited by a moderator:
notaz said:
It's something to do with SDL overheads, getting rid of that does give noticeable improvement.
I have also noticed that jttl's tends to call SDL_Delay from time to time, at least with its default configuration. On my N900 this causes stuttering even when CPU is +50% idle.

Seems that its synchronization algorithm is fairly broken; there's a newer one in Mupen64Plus 2.0.
EDIT: Oh, and a bugreport ( http://code.google.com/p/mupen64plus/issues/detail?id=228 ).
 
Last edited by a moderator:
That is odd, because I tested OoT after the comments here about it not working, and with a new save file, the game just black screens as soon as you choose to start the game. I got no crash or memory error.
I tested OOT before i release it. It seems the (v1.0)(U)(!) version throws a segfault, the (U)(v1.2)(!) and (E)(GC)(!) versions work fine though. I've been trying to track down this memory problem for awhile now, its very fishy. When Orkin made Direct64 (which is based on gln64) he mentioned a texture cache memory problem, but he never released the sourcecode to Direct64. When i enable IA textures it segfaults all the Zelda's within a glDrawArrays call, strangely i can fix it by not uploading textures on the first display list. I thought i might be passing bad data when i was loading textures, but i checked it and it seems fine. The fact that using IA textures makes it occur is even more strange, the amount of code between using them and converting to RGBA textures is very minimal.

Hmm, would be handy to see how these regressions came to be, is all the developers involved using SVN?
I am the only one who's touched the graphics plugin, so all regressions are probably my fault. You can see the changes in the gles2n64 SVN. Ari64 does not use an SVN that i'm aware of, but his code is more likely to either not work or work perfectly. Writing the graphics plugin is much more take a guess, see that it works for a few games... then leave it up to you guys to show how broken it is. I only recently found some official documentation.

Perfect Dark seems to register the one controller as all 4, so if you go into multiplayer with simulants, you'll control 4 players and the screen splits (massive, massive slowdown ).
Woops. My bad, i had to do this to test the golden eye multiplayer, and i forgot to remove it.

F-zero X, despite some texture problems, is fullspeed at 800mhz with Notaz' sound plugin.
The texture coordinate problem is well known, the original gln64 has it aswell. I think its because the original N64 did its coord transforms using fixed point and now we're using floats.

A slight gles2n64 question: shouldn't 800x480 be the default framebuffer.width/height now that viewport scaling is the default (instead of offscreen framebuffer)?

OGL.scaleX is calculated from framebuffer.width (400 by default) which causes the viewport to fill only a quarter of the display.

(I don't have a Pandora so I can't test it there).
framebuffer.width is set to window.width if framebuffer.enable=0. So it should fill the whole screen.
 
PokeParadox said:
Viral18 said:
PokeParadox said:
Quick question... how do we save to memory pak...?
Well surely that's specific to the game. In tonic trouble you can only save to mem pack, so it just acts as saving on a normal game. Though I just tested loading from mem pack, and that seems to crash it :\ I haven't tried the mem pack saves in other games yet though (Perfect Dark also has the option I believe).
Haha... I have an N64... I mean how do we have the emulator save to mempak... because my Mupen64 here doesn't seem to be saving if it's mempak saves.

Ah sorry, totally misunderstood the context :p . I think most games don't seem to correctly save to mem pack yet, of the ones i've tried, only Tonic Trouble seems to have actually saved it, though it crashes on load, so it must have corrupted or something :s. Has the mempack been properly implemented yet, out of interest?


[Edit:
Adventus said:
I tested OOT before i release it. It seems the (v1.0)(U)(!) version throws a segfault, the (U)(v1.2)(!) and (E)(GC)(!) versions work fine though.
That explains that, I use the (E)(GC)(!) version -are save files swappable between versions, as if they are the people that are experiencing crashes could swap over to a working version?

Adventus said:
Perfect Dark seems to register the one controller as all 4, so if you go into multiplayer with simulants, you'll control 4 players and the screen splits (massive, massive slowdown ).
Woops. My bad, i had to do this to test the golden eye multiplayer, and i forgot to remove it.
XD That explains that one then.
Thanks for all the hard work, Mupen64plus is getting better and better with every release.]
 
Last edited by a moderator:
Adventus said:
F-zero X, despite some texture problems, is fullspeed at 800mhz with Notaz' sound plugin.
The texture coordinate problem is well known, the original gln64 has it aswell. I think its because the original N64 did its coord transforms using fixed point and now we're using floats.
Um... would there be an advantage in using fixed rather than floats in that case?
 
Last edited by a moderator:
Um... would there be an advantage in using fixed rather than floats in that case?
No i don't think so, OGL maps textures coords from 0.0 to 1.0 no matter the dimensions of the texture. On the N64, the texture coord maps to a raw integer offset in TMEM.
 
Back
Top