notaz
Certified Guru
I suppose I should hold off merging the diffs to PCSX for a while? Or is this not a regression?Ari64 said:
Last edited by a moderator:
Beta Mupen64Plus
- Thread starter Pickle
- Start date
64-bit signed multiply is broken. It's not a regression and doesn't affect PCSX.notaz said:
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:
fusion_power
Advanced Member
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.
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.
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.
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.
Blue Protoman
Well-Known Member
- Joined
- Mar 6, 2010
- Messages
- 4,117
You can lower the sensitivity for Mupen exclusively. I did.
http://code.google.com/p/mupen64plus/issues/detail?id=280chris_r said:
It never worked in the original glN64. I don't know what's wrong.chris_r said:
Same... It somewhat works with rice, but it's glitchy.chris_r said:
Last edited by a moderator:
fusion_power
Advanced Member
How can I do this? Controller config of Mupen maybe? There are some values but I have no clue which one is for sensitivity. ^^Blue Protoman said:
Last edited by a moderator:
Blue Protoman
Well-Known Member
- Joined
- Mar 6, 2010
- Messages
- 4,117
They should be identified by name. Go to the Input plugin's settings.
Esn
(:";
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:fusion_power said:
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:
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.
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:
- Joined
- Dec 8, 2005
- Messages
- 6,603
- Age
- 40
- Location
- UK
- Website
- pokeparadox.itch.io
- WEBSITE
- https://github.com/pokeparadox
- YOUTUBE
- pokeparadox
To be honest... I haven't yet found the golden settings... You definitely have to experiment and even then, you may have to tweak on a per game basis. The default setting feels very wrong.
Blue Protoman
Well-Known Member
- Joined
- Mar 6, 2010
- Messages
- 4,117
I did .3 or .35 for each, worked fine for me.
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.
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.
fusion_power
Advanced Member
Emulation of an N64 on a Touchscreen Device with Touchscreen Controls is completely wrong, IMHO.MooTheKow said:
Last edited by a moderator:
sebt3
homebrew player (P. & C.)
May be the part "I dont care if this make me illegal, I'll keep the source for myself"MooTheKow said:
Last edited by a moderator:
Pickle
Mega GP Mania
sebt3 said:
There is a link to source code.
Last edited by a moderator:
sebt3
homebrew player (P. & C.)
I need to learn to read...Pickle said:
Well in fact it's in the middle, cristal clear
/me run ashamed
Last edited by a moderator:
Pickle
Mega GP Mania
sebt3 said:
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!
Last edited by a moderator:
Schnatterplatsch
Well-Known Member
- Joined
- Feb 8, 2009
- Messages
- 1,086
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?
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?
Similar threads
