Beta Mupen64Plus


Hey Adventus, would it be possible to add an inline menu to the emulator that could be pulled up during runtime by pressing the Pandora button? Something similar to the menu in Picodrive would be amazing. And you could always choose to exit the emulator from that menu.

-God Ginrai
 
http://jayfoxrox.pastebin.com/hS1vwRjU

this is an OpenGL.cpp which works with blight. It's pretty bad though and just a quick hack. The major aspect is that SDL is already initialized in mupen itself so you don't have to do it, only subsystems have to be initialized but even the VIDEO one exists before. I also renamed the WIN32 check to W for windowed because the other one didn't make any sense.
It doesn't work correctly though because blight expects you to press del to remove the existing configuration. While you can turn on sticky keys in the XFCE Accessibility settings, the DEL key is still not mapped (after 3 hotfixes..).
For fullscreen I'd recommend to either take the SDL fswindow if that works, otherwise just undecorate the existing one and reposition it and set it to topmost.


Adventus: There seems to be a new GPL violation, the sources with the new mousepad config launcher are still not online (and the conf file on google is also outdated).. not only breaks GPL but also slows down development. Furthermore I'd like to see a new makefile which is more linux / cross-platform friendly.

//Edit: Woops.. this was supposed to go into the dev corner. We should really get rid of those multiple topics with the same name imo.
Eh, I have a Pandora now by the way. It's a faulty one with a broken left nub (which can't be fixed by resetting it, hw problem probably, it's very strange. The X axis is mapped like this: "0% *travel* -100% *center* 0% *travel* +100%" rather than "-100% *travel* 0% *center* 0% *travel* +100%". Yup, this means the closer I get to the center the heavier the recognized movement becomes, then it jumps to 0 instantly, while another zero is at the very left edge of the nub.) [It was offered to me by ED and I agreed to it so I can finalize and release my things as my unit is still a month or so away. I'll hopefully get it replaced then]
 
JayFoxRox said:
//Edit: Woops.. this was supposed to go into the dev corner. We should really get rid of those multiple topics with the same name imo.

They are in separate forums, I hardly think that this should be a problem. Also, with the both of them now, they have started to serve their own purposes, with the DevCorner topic talking about development and the Beta Testing topic talking about tests, bugs, and requested features.

-God Ginrai
 
Last edited by a moderator:
How do I map the Pandora D-Pad to the N64 analog stick?
I'm not exactly sure how to include readmes in PNDs.... but heres what its says:
---------------------------------------------------------------------------------
MUPEN64PLUS Pandora, Release 1
---------------------------------------------------------------------------------

This is a Nintendo 64 emulator for the Open Pandora handheld. Mupen64plus is a
plugin based emulator, a plugin for graphics (gles2n64) and input (ppsp_input)
are provided.

---------------------------------------------------------------------------------
Installation
---------------------------------------------------------------------------------

1. place pnd in /pandora/desktop or /pandora/menu
2. execute pnd by clicking desktop icon or menu item
3. play

The first thing you probably want to do is goto Options->Configure->Rom Browser
and set the directory of your roms. Your roms should then show up in the main
window once it is finished searching (can take a little while).

---------------------------------------------------------------------------------
Default Input Plugin: PPSP_INPUT
---------------------------------------------------------------------------------

By default the controller is mapped:

+-------------------+-------------------+
| Pandora | N64 |
+-------------------+-------------------+
| Left Analog | Analog |
| Right Analog | C buttons |
| DPAD | DPAD |
| L | Z |
| R | R |
| B | A |
| X | B |
| START | Start |
| PANDORA BUTTON | Exit Emulator |
+---------------------------------------+

You can also remap the controls by going options->configure input. This will
start mousepad with the ppsp_input config file open. It is important that you
use the correct non-case sensitive syntax. The N64 Digital controls
can be mapped using the following sytax:

N64 <button>=<type> <name> {: <threshold>}

where:
+-----------+-------------------------------------------------------------------+
| <type> | possible <name> |
+-----------+-------------------------------------------------------------------+
|ANALOG | LEFT UP, LEFT DOWN, LEFT RIGHT, LEFT LEFT, RIGHT UP, RIGHT DOWN, |
| | RIGHT RIGHT, RIGHT LEFT |
|BUTTON | UP, DOWN, LEFT, RIGHT, DPAD UP, DPAD DOWN, DPAD LEFT, DPAD RIGHT, |
| | L, R, START, SELECT, MENU |
|KBOARD | A-Z, 0-9, F1-F12, ENTER, LEFTSHIFT, ENTER, SPACE, COMMA, DOT, |
| | BACKSPACE, ESC, MINUS, EQUAL, TAB, LEFTBRACE, RIGHT BRACE, |
| | SEMICOLON, APOSTROPHE, GRAVE, BACKSLASH, SLASH |
+-----------+-------------------------------------------------------------------+

If <type> is ANALOG you should also specify a threshold between 0 and 127. When the
analog is pushed past the threshold the button is pressed. The N64 analog can only
be mapped to three possible configurations at the moment.

N64 ANALOG = <type name> {: <velocity>}

where:
<type name>=ANALOG LEFT | ANALOG RIGHT | BUTTON DPAD

If BUTTON DPAD is specified you can supply an additional argument which
describes the rate at which the N64 analog responds to the DPAD being pressed.

ie. N64 ANALOG=BUTTON DPAD : 25.0

This would set the velocity to 25 (the default value). The last option is the
pandora analog controllers calibration curve. The curve desribes what value is
outputted as the left and right analogs are pressed. The syntax is:

CALIB <analog>[n]=<value>

where <analog>=LEFT | RIGHT, 0 <= n <= 3 and <value> is the c[n] value in the
below formula:

out=in*c[0] + in*in*c[1]+in*in*in*c[2]+in*in*in*in*c[3]

A linear mapping would set c = {1,0,0,0} this is not used by default because
the N64 Analog has far more travel than the Pandora's making them too sensitive,
by default a half linear half quadratic is used c={0.5,0.5,0,0}. This effect is
applied before any button mapping takes place.

---------------------------------------------------------------------------------
Default Graphics Plugin: GLES2N64
---------------------------------------------------------------------------------

.... TBC

---------------------------------------------------------------------------------
Source Code
---------------------------------------------------------------------------------

Parts of this release is based on GPL source code. The source code can be found
at the follwing addresses:

- dynarec/mupen64plus: http://bunnitude.com/ari64/mupen64plus-arm-20100627.tar.gz
- gles2n64: http://code.google.com/p/gles2n64/
- ppsp_input: http://code.google.com/p/ppsp-input/
So if you want to use the DPAD just set: "N64 ANALOG=BUTTON DPAD : 25.0"

Adventus: There seems to be a new GPL violation, the sources with the new mousepad config launcher are still not online (and the conf file on google is also outdated).. not only breaks GPL but also slows down development. Furthermore I'd like to see a new makefile which is more linux / cross-platform friendly.
Its up now. You don't have to convince me. I'm not using SDL video anymore, its only there from when i was developing on PC + OGLES2 emulator.... maybe i should be using the mupen window though....
 
After playing the latest release, is it me, or does the new release seem to have more "jaggies"?

Lines in Mario64 (trees, the castle etc) dont seem as smooth
 
Adventus said:
Adventus: There seems to be a new GPL violation, the sources with the new mousepad config launcher are still not online (and the conf file on google is also outdated).. not only breaks GPL but also slows down development. Furthermore I'd like to see a new makefile which is more linux / cross-platform friendly.
Its up now. You don't have to convince me. I'm not using SDL video anymore, its only there from when i was developing on PC + OGLES2 emulator.... maybe i should be using the mupen window though....

Yes, I know, the version which was on code.google didn't even have the config option for fullscreen / windowed mode, but it was all hardcoded. This is how I noticed the GPL violation first (because a binary I have does have the option + it opens mousepad when clicking the configure button).

The thing with the mupen window is that mupen sets an event filter on the created window to grab the input which is then forwarded to the plugins after checking the mupen hotkeys alt+enter etc.
(In an old version it was main/main.c:875 ("SDL_SetEventFilter(sdl_event_filter);") and the related callback at main/main.c:675 ("static int sdl_event_filter( const SDL_Event *event )")
 
Last edited by a moderator:
After playing the latest release, is it me, or does the new release seem to have more "jaggies"?
Its being rendered at a lower resolution, to get what it looked like before set "framebuffer enable=0" in the gles2n64 config file.
Yes, I know, the version which was on code.google didn't even have the config option for fullscreen / windowed mode, but it was all hardcoded. This is how I noticed the GPL violation first (because a binary I have does have the option + it opens mousepad when clicking the configure button).
Technically i don't think its a GPL violation, the original gln64 was never released with a licence :) .... I've just wacked a licence on it, its all rather dodgy. Thats why it cannot be included in the new mupen64plus, however a plugin called Arachnoid which is basically gln64 rewritten in C++ was given permission by the original gln64 author to release under GPL. I am considering porting across my changes.... though the original gln64 is much easier to modify. The best outcome would be if the original author of gln64 turned up, others have tried to contact him but to no avail.

Anyway it doesn't matter, now that i know people are actually looking at the SVN I'll update it more frequently.

Also another game that works well is Rocket: Robot on wheels, pretty cool games aswell.

EDIT: And in other news, i've rewritten the frame skip code. It now works much better, games like 1080 are now playable with frameskip and it should work better in general. It turns out alot of games submit multiple display lists per frame.
 
Just wanted to drop in to say you guys are flamin' legends. And heroes for us N900 owners. After a recompile of your source we now have a fully functioning N64 emu with blight input plugin working wonderful. Just managed to get accelerometer and PS3 controller support going, so am over the moon.

Keep doing what your doing!

Adventus said:
Anyway it doesn't matter, now that i know people are actually looking at the SVN I'll update it more frequently.

That would be very much appreciated for us over at Maemo. I'm not sure, fully, how its happening... as I've just been the one designated to set up the tarball with needed configs and write the guides for the noobs... but I'm almost certain they are building from the SVN.

On to some questions, up until last night we've been running the March release with early April gles plugin, but have just had the latest compiled. He found the latest to have some issues and went on to post this, Best use his words over mine:

javispedro said:
Oh, wow. Seems that there's a regression in today's gles2n64, cause I got yesterday's (revision 16) and now there is a noticeable speed bump (mario64 bowser's battle demo gets + ~5fps).

Also with today's I get graphical corruption in zelda textures.
Source: http://talk.maemo.org/showpost.php?p=740342&postcount=129

So whats being used in the current official build? and is it more stable/faster than either of these revisions? I'm way out of my depth here... but hoping I'm making enough sense to get some tips.

Beyond that my questions are probably much the same as others on this thread.. so I'll read back.
 
Last edited by a moderator:
IzzehO said:
So whats being used in the current official build? and is it more stable/faster than either of these revisions? I'm way out of my depth here... but hoping I'm making enough sense to get some tips.
The newest revision (r20) i just uploaded today to the gles2n64 SVN is probably the best, it should fix the issues some games have with frameskip. It probably also fixes the texture problems I introduced yesterday.... I needed to convert I/IA textures to RGBA, but i don't fully understand why (i think its because the IA texture's RGBA =(I,0,0,A) in the fragment shader). Dynarec wise the best is the one I most recently linked to in the previous posts.

With some of the nice overclocks you guys are able to manage it'll probably run better than the pandora. :)
 
Last edited by a moderator:
Adventus said:
With some of the nice overclocks you guys are able to manage it'll probably run better than the pandora. :)

Awesome, I've passed on the message. As for the overclock.. it'll probably just be enough to balance out that is isn't designed for the N900 in mind. Surprised no one is pushing it on the Pandora as much as on the N900.

Once again, ya's are awesome.. keep it up. And if its not too much trouble, get OGLES working for PSX for us as well :p
 
Last edited by a moderator:
Beetle Adventure Racing looks nice, runs pretty smooth but slow, and it crashes during a race. It crashed when my car touched the side rail near the starting point on the first track.

It's a fun little game!

Also tried Body Harvest, seems to be missing graphics for the intro/menus but when in the game its playable but slow.

I consider Body Harvest to be the prototype open world game Rockstar games were experimenting with at the time, even go into vehicles and the aiming system is very GTA3 :)

FIFA 99 crashes when you try to go past the main menus and into a game, or when editing a player/team.
 
IzzehO said:
Adventus said:
With some of the nice overclocks you guys are able to manage it'll probably run better than the pandora. :)

Awesome, I've passed on the message. As for the overclock.. it'll probably just be enough to balance out that is isn't designed for the N900 in mind. Surprised no one is pushing it on the Pandora as much as on the N900.

Once again, ya's are awesome.. keep it up. And if its not too much trouble, get OGLES working for PSX for us as well :p

What do you mean by pushing? I want N64 to be better and better, but I believe that if I bother the devs too much they will become less productive. ;) As for OGLES for PSX, Tinnus is working on that right now.

EDIT: Btw, Adventus, I found a strange input plugin glitch. In Bomberman 64: Second Attack, after a while of playing, the Analog stick will not be read right. (I will only be able to move up and down :) Luckily, that game also takes dpad input, so I can still continue, but it's strange because the nub works fine still even after that happens. (When I exit the emulator it works as normal in the OS, and I booted up the emu again with Mario 64, and the nub input worked fine there as well) This has only happened to me with Bomberman 64: Second Attack. However, the only games I have played as long as I did Bomberman before this bug happened would be SM64, Quest 64, OoT, and Bomberman. And Bomberman is the only one I have had this bug with.

-God Ginrai
 
Last edited by a moderator:
MDave, can you post your games in the compatibility thread?
people will see the results there, and then they'll go on the spreadsheet for everyone else to see too.
 
Hi, hydro thunder is getting closer to running ingamewith the last release, originally it froze as the race was about to start, it now gets about 2 secs into the race! It's not much but it's another step, all textures, polys etc look fine, so not sure what the major thing to get this running and staying running!
 
God Ginrai said:
IzzehO said:
Adventus said:
With some of the nice overclocks you guys are able to manage it'll probably run better than the pandora. :)

Awesome, I've passed on the message. As for the overclock.. it'll probably just be enough to balance out that is isn't designed for the N900 in mind. Surprised no one is pushing it on the Pandora as much as on the N900.

Once again, ya's are awesome.. keep it up. And if its not too much trouble, get OGLES working for PSX for us as well :p

What do you mean by pushing? I want N64 to be better and better, but I believe that if I bother the devs too much they will become less productive. ;) As for OGLES for PSX, Tinnus is working on that right now.

-God Ginrai

Pushing the overclock like we are on the N900. Got a lot of people running at 1.1GHz, I'm at 950MHz. As for PSX... thats awesome.. can't wait to steal it :p The current dev for N900 has gotten married and moved to Spain.. so we've run out of developers :p

Anyhow, on topic... has much progressed been made with getting sound to work reasonable? Is this planned? I ask only if you guys actually have decent sound (we don't).

Also Rev20 is working fantastic... thanks again Adventus - it does create some weird colours on Mario64 but nothing in the gameplay.
 
Last edited by a moderator:
IzzehO said:
God Ginrai said:
IzzehO said:
Adventus said:
With some of the nice overclocks you guys are able to manage it'll probably run better than the pandora. :)

Awesome, I've passed on the message. As for the overclock.. it'll probably just be enough to balance out that is isn't designed for the N900 in mind. Surprised no one is pushing it on the Pandora as much as on the N900.

Once again, ya's are awesome.. keep it up. And if its not too much trouble, get OGLES working for PSX for us as well :p

What do you mean by pushing? I want N64 to be better and better, but I believe that if I bother the devs too much they will become less productive. ;) As for OGLES for PSX, Tinnus is working on that right now.

-God Ginrai

Pushing the overclock like we are on the N900. Got a lot of people running at 1.1GHz, I'm at 950MHz. As for PSX... thats awesome.. can't wait to steal it :p The current dev for N900 has gotten married and moved to Spain.. so we've run out of developers :p

Anyhow, on topic... has much progressed been made with getting sound to work reasonable? Is this planned? I ask only if you guys actually have decent sound (we don't).

Also Rev20 is working fantastic... thanks again Adventus - it does create some weird colours on Mario64 but nothing in the gameplay.

Ah. We overclock, but with our current voltage settings, we can't overclock higher than 900. (Most of us can only go up to 850 or 875 stably)

As for the sound: For us, it works fine in some games (like Mario64), works fine at times and jumpy at times in some games (like OoT), and is jumpy all the time in some games. I'm not really sure why.

-God Ginrai
 
Last edited by a moderator:
Also Rev20 is working fantastic... thanks again Adventus - it does create some weird colours on Mario64 but nothing in the gameplay.
Can you describe where you see these weird colours? I can only test my changes on a few games and theres a lot of voodoo to HLE-ing the N64 graphics.

Ah. We overclock, but with our current voltage settings, we can't overclock higher than 900. (Most of us can only go up to 850 or 875 stably)
Yeah my devboard could do ~900mhz stable, but my prototype can only do around 825mhz.... on mupen64plus anyway. You can tell that using NEON decreases the overclocking capabilities. When it begins to glitch you get polygons being transformed wrong (which is where the NEON code is). I wonder if the fact that the NEON code is not extremely dense (its usually only run over <20 vertices at a time) is why people seem to report higher stable overclocks with mupen than psx4all.

Anyhow, on topic... has much progressed been made with getting sound to work reasonable? Is this planned? I ask only if you guys actually have decent sound (we don't).
I haven't looked into the sound yet. The plugin is pretty simple it just passes the samples to SDL, so its performance largely depends on how optimised memcpy / memmove and SDL_Audio is.
 
IzzehO said:
Pushing the overclock like we are on the N900. Got a lot of people running at 1.1GHz, I'm at 950MHz. As for PSX... thats awesome.. can't wait to steal it :p The current dev for N900 has gotten married and moved to Spain.. so we've run out of developers :p

Anyhow, on topic... has much progressed been made with getting sound to work reasonable? Is this planned? I ask only if you guys actually have decent sound (we don't).
No, the sound on the Pandora is very stuttery. That is something that I hope can be improved with the Pandora hardware limits. The stuttering really detracts from games and playing with no sound is even worse.
 
Last edited by a moderator:
DaveC said:
IzzehO said:
Pushing the overclock like we are on the N900. Got a lot of people running at 1.1GHz, I'm at 950MHz. As for PSX... thats awesome.. can't wait to steal it :p The current dev for N900 has gotten married and moved to Spain.. so we've run out of developers :p

Anyhow, on topic... has much progressed been made with getting sound to work reasonable? Is this planned? I ask only if you guys actually have decent sound (we don't).
No, the sound on the Pandora is very stuttery. That is something that I hope can be improved with the Pandora hardware limits. The stuttering really detracts from games and playing with no sound is even worse.

That really depends on the game. In SM64 and Bomberman 64: Second Attack, I get virtually no stutter at 750 MHz. (Except I have gotten it during 2 cutscenes in Bomberman, OCing more should probably fix that)

-God Ginrai
 
Last edited by a moderator:
Adventus said:
Also Rev20 is working fantastic... thanks again Adventus - it does create some weird colours on Mario64 but nothing in the gameplay.
Can you describe where you see these weird colours? I can only test my changes on a few games and theres a lot of voodoo to HLE-ing the N64 graphics.

I can't seem to replicate it all of a sudden, it was on the loading screens a white and cream sort of shakey imaged showed up. In other news 1080 snowboarding now works fantastically as do several others. Even Tony Hawks is running much faster (even with the trippy messed up textures :p).
 
Last edited by a moderator:
Back
Top