Beta Mupen64Plus


Ari64 said:
Bramrash said:
Donkey Kong makes a noise at the start then crashes back to desktop, not sure if thats an improvement or not. It seems like RARE games have improved in general so I thought i'd try it.
I can confirm this is a dynarec bug.
I suppose I should hold off merging the diffs to PCSX for a while? Or is this not a regression?
 
Last edited by a moderator:
notaz said:
Ari64 said:
Bramrash said:
Donkey Kong makes a noise at the start then crashes back to desktop, not sure if thats an improvement or not. It seems like RARE games have improved in general so I thought i'd try it.
I can confirm this is a dynarec bug.
I suppose I should hold off merging the diffs to PCSX for a while? Or is this not a regression?
64-bit signed multiply is broken. It's not a regression and doesn't affect PCSX.

The loop preload bug and the dirty flag bug do affect PCSX, so you want those. Plus you probably want the liveness analysis and register allocation stuff for a small speedup.
 
Last edited by a moderator:
So, after testing Starfox 64 /Lylat Wars I can say that it is pretty hard to play with the Pandora Nubs. If there is one Game that I've played to death onto the original N64 then it is Starfox. ^^ So I would say I'm not that bad in this game. But aiming with the only 2mm of travel of the Nubs is more or less luck, no way to really "hardcore" play it onto the Pandora. Maybe I have to adjust nub sensivity but I don't want to alter this system wide because of only one game. Maybe this could be adjusted per menu if Mupen supports ingame menu some day.
But you still can play it on the easy route, not bad for beginners. However, even Starfox is far away from Full Speed, maybe I lower the resolution to squeeze out some more FPS. Or I try more OC but I don't want to melt my Pandora. :D
I still searching for a option to get rid of this annoying frame around the Screen when playing in 4:3. (640x480). Full Screen stretched is fine and really full screen, no border/frame around the image.

Yesterday I also tested GoldenEye and well... I better skip this game at the moment, besides graphic glitches (infinity effect in the sky) it is of course very slow, but this also was onto the PC and other N64 emus the case, even with the great Project64, same for Perfect Dark.
 
chris_r said:
Blast Corps just plays the first two logos really fast and then crashes to the menu.
http://code.google.com/p/mupen64plus/issues/detail?id=280

chris_r said:
Gauntlet Legends just shows a black screen.
It never worked in the original glN64. I don't know what's wrong.

chris_r said:
Glover does too, but returns to the menu after a few seconds.
Same... It somewhat works with rice, but it's glitchy.
 
Last edited by a moderator:
Blue Protoman said:
You can lower the sensitivity for Mupen exclusively. I did.
How can I do this? Controller config of Mupen maybe? There are some values but I have no clue which one is for sensitivity. ^^
 
Last edited by a moderator:
So after testing the updates a bit, let me hear your thoughts about the new frameskip code. Better or worse than the old way? Is the default configuration ok so far or were changes needed? If you did game specific changes let me know too.
 
fusion_power said:
Blue Protoman said:
You can lower the sensitivity for Mupen exclusively. I did.
How can I do this? Controller config of Mupen maybe? There are some values but I have no clue which one is for sensitivity. ^^
It was explained earlier in the thread on page 36. But to be honest, I never managed to get a sensitivity level for the nubs that I was really comfortable with; they always seemed to be too sensitive. Here is the info, quoted, in case anyone figures it out:

PokeParadox said:
Well you've found the correct thing... I also don't really understand what the explanation is, but...
Code:
CALIB LEFT[0]= high value x
CALIB LEFT[1]=high value y
CALIB LEFT[2]=low value x
CALIB LEFT[3]=low value y
CALIB RIGHT[0]=high value x
CALIB RIGHT[1]=high value y
CALIB RIGHT[2]=low value x
CALIB RIGHT[3]=low value y

This simplification makes some sense to me... values on a 0 to 1 scale. I realised my config is on my SD. e.g.
Code:
CALIB LEFT[0]=0.500000
CALIB LEFT[1]=0.500000
CALIB LEFT[2]=0.100000
CALIB LEFT[3]=0.100000
CALIB RIGHT[0]=0.500000
CALIB RIGHT[1]=0.500000
CALIB RIGHT[2]=0.100000
CALIB RIGHT[3]=0.100000

But of course, experimentation is key, so good luck! ;)


PokeParadox said:
Fishbong said:
Yes i have been wondering about this too. theoretically, if you enter a higher value for CALIB LEFT[0] and CALIB LEFT[1], you'd have to push the nubs further for the emulator to interpret them as "analog stick pushed all the way", but in practice this seems to make no difference. Or am i wrong? I just can't get MArio to walk slowly, so i keep waking up those Piranha Plants...
Actually you want to adjust the low values lower, to have more range... I don't 100% get it, but the lower values are not a deadzone. Just changing it to 0.1 from the default 0.2 improved things for me... try those values and then work from there!


Whynodd said:
Hey guys,

maybe this small modification idea before or instead the cubic io-curve could help with nub precision near the deadzone (yes, the nubs have a deadzone) without losing precision on the other end.

graphp.gif

Edit: This io-cuve is the exact opposite to what the nubs do. I wrote a small nubtester app to visualize the nubs behaviour and noticed that they have a deadzone and near their deadzone, they are more sensitive. So this type of io-curve corrects that behaviour.

More about that here in an old post by me:
http://www.gp32x.de/board/index.php?/topic/55762-dxx-rebirth-1-and-2/page__view__findpost__p__904486
 
Last edited by a moderator:
I'm not sure, but I think there's something odd going on with the input plugin. For example, when I use something like

0
0
.5
.5

for the values and move the nub around, I notice that in the corners, it doesn't give the full input. I'd expect that the full up position would give [0, 255] while the full up-right corner would give [255, 255]. Instead it's more like [0, 255] and [150, 150].

Does that make sense? Is it supposed to behave like that?

It's like the nub's output is being mapped onto a circle whereas I assume it should really be mapped onto a square.
 
those bastards, at least credit was given where credit is due
http://forums.precentral.net/hp-touchpad-homebrew/297966-n64-emulator-first-release.html
 
Pickle said:
sebt3 said:
MooTheKow said:
What did they do wrong?
May be the part "I dont care if this make me illegal, I'll keep the source for myself"

There is a link to source code.
I need to learn to read...

Well in fact it's in the middle, cristal clear


/me run ashamed
 
Last edited by a moderator:
sebt3 said:
Pickle said:
sebt3 said:
MooTheKow said:
What did they do wrong?
May be the part "I dont care if this make me illegal, I'll keep the source for myself"

There is a link to source code.
I need to learn to read...

Well in fact it's in the middle, cristal clear


/me run ashamed

let me correct you then: hhum hrmgh How dare they give credit! How can they ethically decide to give this away for FREE! The gall to provide a link to the source code! Blahhhh!
:p
 
Last edited by a moderator:
Ahem.

I must be doing something really wrong here... I played some Mupen the first time for a while(using the default config) and found that 0.0.4 gfx-plugin being way smoother than 0.0.5, tried Mario64 and FZeroX.

That cannot be right, I guess, can it? What settings do I have to change in the config to get the power out of 0.0.5?
 
Back
Top