Beta Mupen64Plus


Snowboard Kids 1 and 2 is still broken (was working in the old April build), which is a shame as I always enjoyed the multiplayer of that.

Otherwise new release has definitely seen improvements. And fortunately us N900 users aren't experiencing save issues or anything of the likes as we have a perfectly working blight_input :p
 
Adventus said:
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.

If the result is really a raw integer offset then the precision into a 4KB texture memory can only be so high... I don't know exactly what texture formats and sizes N64 supports, going to assume full non-square and 1bpp and go with the worst case of 32768x1 textures. That's still only 15 bits. I fully expect some actual sub-texel precision too, but not more than the 9 remaining bits a float's 24-bits of effective precision gives you. So it doesn't seem like this should be giving you a problem. If there's a problem from fixed point it's going to be due to internal matrix transformation operations, where you could lose precision at the bottom of 32-bit multiplies, or even worse, where the game is actually relying on losing range intermediately. In that case going to the same format for fixed point transforms would help.

What's the nature of the graphical errors exactly?
 
Last edited by a moderator:
Exophase said:
If the result is really a raw integer offset then the precision into a 4KB texture memory can only be so high... I don't know exactly what texture formats and sizes N64 supports, going to assume full non-square and 1bpp and go with the worst case of 32768x1 textures. That's still only 15 bits. I fully expect some actual sub-texel precision too, but not more than the 9 remaining bits a float's 24-bits of effective precision gives you. So it doesn't seem like this should be giving you a problem. If there's a problem from fixed point it's going to be due to internal matrix transformation operations, where you could lose precision at the bottom of 32-bit multiplies, or even worse, where the game is actually relying on losing range intermediately. In that case going to the same format for fixed point transforms would help.
Currently the texture coordinate transformations are performed by the vertex shader, so fixed point is not really an option there. The only reason i decided not to do it on the CPU is that a texture coordinate could feasibly be shared between two different textures (requiring a different transform), so they would need to be recalculated (this would further complicate the tribuffer optimisation i did aswell). Here's what it looks like:

vTexCoord0 = (aTexCoord0 * (uTexScale[0] * uCacheShiftScale[0]) + (uCacheOffset[0] - uTexOffset[0])) * uCacheScale[0];

Originally the texture coordinates are in 10.5 fixed point format. There are 4 bit textures. The maximum texture width is 1024 (max height is 256). uCacheScale = (1/texture width), uCacheOffset is set to +0.5 (which might be the problem... this is how gln64 does it), uCacheShiftScale = 2^-5 to 2^10. I'm using mediump for the texture coordinates at the moment but changing it doesn't seem to fix the problem.

What's the nature of the graphical errors exactly?
Pretty sure its a wrapping error, sometimes the texcoord=0.0 when it should be 1.0, it flickers a bit though in between 0.0 and 1.0. Its a very rare problem, fzero X is the only one which i know exhibits it.
 
Last edited by a moderator:
I agree that the texel center offset might be the problem. You should check out what MESS does for reference.
 
Adventus said:
What's the nature of the graphical errors exactly?
Pretty sure its a wrapping error, sometimes the texcoord=0.0 when it should be 1.0, it flickers a bit though in between 0.0 and 1.0. Its a very rare problem, fzero X is the only one which i know exhibits it.

Check out Turok: Dinosaur Hunter. The characters have the textures mapped wrong ;) and most of the environment seems to tile the textures too often, like they're scaled down in the mapping (not texture size)
 
Last edited by a moderator:
Adventus said:
framebuffer.width is set to window.width if framebuffer.enable=0. So it should fill the whole screen.
True, sorry, I overlooked the X11 backend. Thanks!
 
Last edited by a moderator:
Zelda no longer works after I load a save file :(
But mario 64 is really fast now o_O
 
HackModford said:
Zelda no longer works after I load a save file :(
But mario 64 is really fast now o_O
Yeah, I've tried every differant version that was suggested, and I'm having the same problem with each one.

Agreed, Mario is near perfect now. It looks so beautiful on the pandora screen, and the controls rock also.

Chris
 
Last edited by a moderator:
Adventus said:
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.
Does OpenGL ES not have anything equivalent to GL_TEXTURE_RECTANGLE_ARB?
 
Last edited by a moderator:
Is it just me or did the nubs get super-sensitive again?

There was a version where they worked real nice. Now if I move the nubs 1/2 millimeter it is almost full speed. Is there a setting somewhere or something?
 
Does OpenGL ES not have anything equivalent to GL_TEXTURE_RECTANGLE_ARB?
Not that I'm aware of. I tried removing the 0.5 offset, had no effect.

DaveC said:
Is it just me or did the nubs get super-sensitive again?

There was a version where they worked real nice. Now if I move the nubs 1/2 millimeter it is almost full speed. Is there a setting somewhere or something?
It shouldn't be super sensitive, unless I've broken something. You can change the calibration by going to options->input settings, at the bottom is the left and right calibration. By default its f(x) = 0.5*x+0.5*x*x, lowering the values should give a decrease in sensitivity. Typically you want them to sum to one.
 
Last edited by a moderator:
There are 2 different releases of OoT (not counting different regions or different ROM versions), the normal one (Rom title: THE LEGEND OF ZELDA) and the High Society hacked version (Zelda 64 HS'98), the hacked version was buggy for me when I played it in Project 64, but everyone having different results with OoT might just have different releases of the ROM.
 
Zelda loads fine for me in beta 3, too.

But r1 beta 2 (with notaz' sound-plugin) is still better for OoT because the sound doesn't crackle.

With deactivated framebuffer you can play OoT in high resolution* (4x the N64's resolution of this game) with mostly stable sound at frame skip=2 (@850MHz, r1 beta 2).


* playing without framebuffer in 640x480 is just as fast as playing with framebuffer in 320x240 - only that 640x480 looks incredibly detailed
 
Revision 21 appears to create some serious graphical issues in 1080 Snowboarding. Every second or third race, half way through it'll suddenly stop showing textures and just show a yellow grid. Then on map change it'll have artifacts and other ugly things happen.

Went back to Revision 20 with same save and ROM and am not receiving these issues at all.
 
IzzehO said:
Revision 21 appears to create some serious graphical issues in 1080 Snowboarding. Every second or third race, half way through it'll suddenly stop showing textures and just show a yellow grid. Then on map change it'll have artifacts and other ugly things happen.

Went back to Revision 20 with same save and ROM and am not receiving these issues at all.
Yeah just looked into this, its strange isn't it. I've fixed it (I beat Normal Mode without too many glitches occuring anyway) and uploaded a new revision.

What causes it is when it fails to allocate indices it returns 0xffffffff then when this occurs it get cast as a signed int... so it becomes -1, and in memory the -1 index is mapped to where i hold all the config information, which is then overwritten with junk. This causes fog to be enabled in the fragment shaders, but because it wasn't enabled when the vertex shader was compiled I get a shader link error. The reason it failed to find a mapping is that even after flushing the buffer the remaining indices were mapped very sparsely, like ---X---X---X, so it couldn't find a 4 element block to perform the __VEC4_OPT optimisation on. To fix it i just made it undo the mapping when this occurs.
 
Last edited by a moderator:
Adventus said:
What causes it is when it fails to allocate indices it returns 0xffffffff then when this occurs it get cast as a signed int... so it becomes -1, and in memory the -1 index is mapped to where i hold all the config information, which is then overwritten with junk. This causes fog to be enabled in the fragment shaders, but because it wasn't enabled when the vertex shader was compiled I get a shader link error. The reason it failed to find a mapping is that even after flushing the buffer the remaining indices were mapped very sparsely, like ---X---X---X, so it couldn't find a 4 element block to perform the __VEC4_OPT optimisation on. To fix it i just made it undo the mapping when this occurs.

I understood about half the words you use here... but if it works now I'm happy :p Can anyone beat Expert Mode... I keep losing to the Ice Man :(

Anything else cool in the works to be fixed?
 
Last edited by a moderator:
Adventus said:
IzzehO said:
Revision 21 appears to create some serious graphical issues in 1080 Snowboarding. Every second or third race, half way through it'll suddenly stop showing textures and just show a yellow grid. Then on map change it'll have artifacts and other ugly things happen.

Went back to Revision 20 with same save and ROM and am not receiving these issues at all.
Yeah just looked into this, its strange isn't it. I've fixed it (I beat Normal Mode without too many glitches occuring anyway) and uploaded a new revision.
Where is this uploaded too?
 
Last edited by a moderator:
I just tried Mickey's Raceway and I get the input plugin controlling all 4 controllers. As a result I end up in multiplayer mode each time...
The good news is that the split screen does seem to display correctly...
 
I uploaded a version that fixes 1080 snowboarding and the input plugin here: http://gles2n64.googlecode.com/files/mupen64plus-r1b3-fixed.pnd
 
Adventus said:
I uploaded a version that fixes 1080 snowboarding and the input plugin here: http://gles2n64.googlecode.com/files/mupen64plus-r1b3-fixed.pnd

?_? What was wrong in 1080?

-God Ginrai
 
Last edited by a moderator:
Back
Top