I can confirm Zelda - Ocarina of Time crashes after you start.
notaz OSS plugin is nice, if the emulator is fullspeed - otherwise, it crackles
notaz OSS plugin is nice, if the emulator is fullspeed - otherwise, it crackles
Seriously, try Forsaken... I'm pretty sure it runs better than Mario64jumpman 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.
I'm gonna try it out now!PokeParadox said:Seriously, try Forsaken... I'm pretty sure it runs better than Mario64jumpman 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.
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: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.
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 .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
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 .wermy said:Quick! Someone test Goldeneye on the new version!
Viral18 said: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: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.
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).PokeParadox said:Quick question... how do we save to memory pak...?
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.Viral18 said: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).PokeParadox said:Quick question... how do we save to memory pak...?
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.notaz said:It's something to do with SDL overheads, getting rid of that does give noticeable improvement.
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.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 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.Hmm, would be handy to see how these regressions came to be, is all the developers involved using SVN?
Woops. My bad, i had to do this to test the golden eye multiplayer, and i forgot to remove it.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 ).
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.F-zero X, despite some texture problems, is fullspeed at 800mhz with Notaz' sound plugin.
framebuffer.width is set to window.width if framebuffer.enable=0. So it should fill the whole screen.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).
PokeParadox said: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.Viral18 said: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).PokeParadox said:Quick question... how do we save to memory pak...?
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: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.
XD That explains that one then.Adventus said:Woops. My bad, i had to do this to test the golden eye multiplayer, and i forgot to remove it.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 ).
Um... would there be an advantage in using fixed rather than floats in that case?Adventus said: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.F-zero X, despite some texture problems, is fullspeed at 800mhz with Notaz' sound plugin.
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.Um... would there be an advantage in using fixed rather than floats in that case?