Release Emu EX Plus Alpha ported to the Pandora


The screen update is really irritating - random blocks about 1" on a side appearing usually when the screen updates. Happens both in the GBA and the Snes emulators, so it's likely a problem with the underlying GL renderer.

D.
 
The screen update is really irritating - random blocks about 1" on a side appearing usually when the screen updates. Happens both in the GBA and the Snes emulators, so it's likely a problem with the underlying GL renderer.


D.
Is that the mouse? The mouse is not hidden, and it may cause some artifacts :(
 
The last one of the serie is Saturn.emu, based on Yabause. But I have the (slow) bios screen splash, but cannot get ingame :( .

I put the PND here for anyone to test, but I won't put it on repo for now, it doesn't look right for now.

If someone can get ingame, please report (and grab a screenshot, so I can put nice ingame screenshot inside PND).

*EDIT*, Grab it on the repo.
 
Last edited by a moderator:
The screen update is really irritating - random blocks about 1" on a side appearing usually when the screen updates. Happens both in the GBA and the Snes emulators, so it's likely a problem with the underlying GL renderer.

D.
Is that the mouse? The mouse is not hidden, and it may cause some artifacts :(
No, those only happen in the UI and are forgiveable. These happen in game, and are quite distracting.

D.
 
The screen update is really irritating - random blocks about 1" on a side appearing usually when the screen updates. Happens both in the GBA and the Snes emulators, so it's likely a problem with the underlying GL renderer.


D.
Is that the mouse? The mouse is not hidden, and it may cause some artifacts :(
No, those only happen in the UI and are forgiveable. These happen in game, and are quite distracting.


D.
I don't have those kind of artefacts. What model of pandora (a CC if I remember correctly) and Firware/Driver do you use? I have to test a CC also (I have now 2 pandora, a Rebirth and a CC, that's good for testing, thanks to Linux-SWAT for selling me my 2nd pandy)...
 
The screen update is really irritating - random blocks about 1" on a side appearing usually when the screen updates. Happens both in the GBA and the Snes emulators, so it's likely a problem with the underlying GL renderer.
Is that the mouse? The mouse is not hidden, and it may cause some artifacts :(
No, those only happen in the UI and are forgiveable. These happen in game, and are quite distracting.
I don't have those kind of artefacts. What model of pandora (a CC if I remember correctly) and Firware/Driver do you use? I have to test a CC also (I have now 2 pandora, a Rebirth and a CC, that's good for testing, thanks to Linux-SWAT for selling me my 2nd pandy)...
CC Pandora, default graphic driver at present.

D.
 
I don't have those kind of artefacts. What model of pandora (a CC if I remember correctly) and Firware/Driver do you use? I have to test a CC also (I have now 2 pandora, a Rebirth and a CC, that's good for testing, thanks to Linux-SWAT for selling me my 2nd pandy)...
CC Pandora, default graphic driver at present.


D.
I have Snes9xEX running on a CC, no artefacts (playing SuperMario RPG). But my CC is upgraded. The drivers is default, but I have installed the "ipk" from Notaz that update the kernel.
 
Here is the diff
attachicon.gif
pandora.zip.

But I'm sorry that's hugly hacks, without proprer #ifdef :(

I wasn't sure on how to do that, and where to put defined at first... so I make it hugly. but it works  ;)
Thanks, I looked through the diff and there are a few issues I'd like to go over before I can include it in my Xlib code:

1. Why was XCreateWindow changed to XCreateSimpleWindow? It doesn't pass the event mask for window events (needs a call XSelectInput instead) so you won't get proper operation when the window is resized or a file is drag & dropped into it for example.

2. The full screen code is incorrect and only works because you called XMapWindow early and then XFlush. It can also cause the window to flash for a split second before the full-screen switch is complete. To fix this, you need to replace that whole block of code with the following:


Atom wmState = XInternAtom(dpy, "_NET_WM_STATE", False);
Atom wmFullscreen = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", False);
XChangeProperty(dpy, win, wmState, XA_ATOM, 32, PropModeReplace, (unsigned char *)&wmFullscreen, 1);
Then when the setupGLWindow function maps the window, it becomes full-screen directly. You should only use the XSendEvent full-screen method when the window is already mapped (i.e. the app is done launching).

3. What happened to the parameters for eglGetDisplay and eglCreateWindowSurface? Do the native Xlib types not work correctly when passed in on the Pandora?

confirmed the snesx port has stuttering sound at zero frameskip. why is that, since the other port we have on Pandora is usually full speed even at zero frameskip?
This is either caused by dropped frames (the 0 value currently needs real-time performance so you cannot miss any frames), or the audio rate not being fully tuned to the Pandora's screen refresh rate. If it's the latter, it's fixable by tweaking the output frequency in each emulator core. Currently the setting isn't editable but I'll add it to the Options menu in a future update.
 
Last edited by a moderator:
The last one of the serie is Saturn.emu, based on Yabause. But I have the (slow) bios screen splash, but cannot get ingame :( .

I put the PND here for anyone to test, but I won't put it on repo for now, it doesn't look right for now.

If someone can get ingame, please report (and grab a screenshot, so I can put nice ingame screenshot inside PND).
I am able to get ingame when I play Albert Odyssey and Lunar Magic School. They are very slow though.
 
Here is the diff
attachicon.gif
pandora.zip.

But I'm sorry that's hugly hacks, without proprer #ifdef :(

I wasn't sure on how to do that, and where to put defined at first... so I make it hugly. but it works  ;)
Thanks, I looked through the diff and there are a few issues I'd like to go over before I can include it in my Xlib code:

1. Why was XCreateWindow changed to XCreateSimpleWindow? It doesn't pass the event mask for window events (needs a call XSelectInput instead) so you won't get proper operation when the window is resized or a file is drag & dropped into it for example.

2. The full screen code is incorrect and only works because you called XMapWindow early and then XFlush. It can also cause the window to flash for a split second before the full-screen switch is complete. To fix this, you need to replace that whole block of code with the following:


Atom wmState = XInternAtom(dpy, "_NET_WM_STATE", False);
Atom wmFullscreen = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", False);
XChangeProperty(dpy, win, wmState, XA_ATOM, 32, PropModeReplace, (unsigned char *)&wmFullscreen, 1);
Then when the setupGLWindow function maps the window, it becomes full-screen directly. You should only use the XSendEvent full-screen method when the window is already mapped (i.e. the app is done launching).

3. What happened to the parameters for eglGetDisplay and eglCreateWindowSurface? Do the native Xlib types not work correctly when passed in on the Pandora?

>>confirmed the snesx port has stuttering sound at zero frameskip. why is that, since the other port we have on Pandora is usually full speed even at zero frameskip?
This is either caused by dropped frames (the 0 value currently needs real-time performance so you cannot miss any frames), or the audio rate not being fully tuned to the Pandora's screen refresh rate. If it's the latter, it's fixable by tweaking the output frequency in each emulator core. Currently the setting isn't editable but I'll add it to the Options menu in a future update.
I proceeded by trial and error...

For 1., Using my poor Fullscreen code, with the full XCreateWindow, I had no control on the app once launched. That's why I switched to the simple one. But, yes, there are drawbacks.

For 2., I'll try your code (and I assume I can also go back to full XCreateWindow also, maybe).

For 3, this is a trick to have rendering directely from FB, and also make it compatible with current beta video driver.

For Snes9xEX, the sn9x process is eating all cpu cycles, so the frameskip. I haven't looked at the code, but it doesn't seem able to do realtime emulation. But that sound strange, I overclock my Pandora to 1GHz, I have compile with full optim options, and "F-Zero" (for example) is not fullspeed on Frameskip 0. I'll probably take a look at some time.

I'll experiment the new Fullscreen tomorow and will report here. Thanks :)

The last one of the serie is Saturn.emu, based on Yabause. But I have the (slow) bios screen splash, but cannot get ingame :( .

I put the PND here for anyone to test, but I won't put it on repo for now, it doesn't look right for now.

If someone can get ingame, please report (and grab a screenshot, so I can put nice ingame screenshot inside PND).
I am able to get ingame when I play Albert Odyssey and Lunar Magic School. They are very slow though.

That's a good news ! :)

Can you get a screenshot, for the PND :) ?
 
Last edited by a moderator:
Played PCE.EMU...Blazing Lazers, Devil's Crush, and Dracula X (CD game) and all played flawlessly...thanks ptitSeb
 
Is this emu pandafe friendly? I mean does it work directly from command line? 
 
Here is the diff
attachicon.gif
pandora.zip.


But I'm sorry that's hugly hacks, without proprer #ifdef :(


I wasn't sure on how to do that, and where to put defined at first... so I make it hugly. but it works  ;)
 
Thanks, I looked through the diff and there are a few issues I'd like to go over before I can include it in my Xlib code:


1. Why was XCreateWindow changed to XCreateSimpleWindow? It doesn't pass the event mask for window events (needs a call XSelectInput instead) so you won't get proper operation when the window is resized or a file is drag & dropped into it for example.


2. The full screen code is incorrect and only works because you called XMapWindow early and then XFlush. It can also cause the window to flash for a split second before the full-screen switch is complete. To fix this, you need to replace that whole block of code with the following:


Atom wmState = XInternAtom(dpy, "_NET_WM_STATE", False);
Atom wmFullscreen = XInternAtom(dpy, "_NET_WM_STATE_FULLSCREEN", False);
XChangeProperty(dpy, win, wmState, XA_ATOM, 32, PropModeReplace, (unsigned char *)&wmFullscreen, 1);
Then when the setupGLWindow function maps the window, it becomes full-screen directly. You should only use the XSendEvent full-screen method when the window is already mapped (i.e. the app is done launching).

3. What happened to the parameters for eglGetDisplay and eglCreateWindowSurface? Do the native Xlib types not work correctly when passed in on the Pandora?


I proceeded by trial and error...


For 1., Using my poor Fullscreen code, with the full XCreateWindow, I had no control on the app once launched. That's why I switched to the simple one. But, yes, there are drawbacks.


For 2., I'll try your code (and I assume I can also go back to full XCreateWindow also, maybe).


For 3, this is a trick to have rendering directely from FB, and also make it compatible with current beta video driver.


I'll experiment the new Fullscreen tomorow and will report here. Thanks :)

Wahoo. It's working like a charm !!!


Here is the new diff:pandora.zip


I will make a build 03 of everything with this new code (sorry for the flood on the repo). Also, I will add a "$@" to the launch script, and I'll look at Snes9x to build in the PND both versions 1.43 & 1.53 (there is only 1.53 in build 02).


I will put Saturn.emu on the repo also..
 

Attachments

  • pandora.zip
    3.2 KB · Views: 404
Last edited by a moderator:
Ok, building the new "build 03"... They will appear one by one on the repo.

For Snes9x, I have both 1.53 (more compatible) & 1.43 (faster) in the PND. The compile optimizations make Snes9x more fluid !

Build 03

-----------

  • Better code for Fullscreen mode
  • More compile optimizations
 
 
Last edited by a moderator:
So, how well do these emu's work in comparison to the ones we already have in existing categories(SNES,Neo Geo Pocket, NES, Genis, ETC.)?

Chris
 
So, how well do these emu's work in comparison to the ones we already have in existing categories(SNES,Neo Geo Pocket, NES, Genis, ETC.)?

Chris
That's probably a very interesting Subject, you can start some comparison review, per machine, of the existing emulators for the Pandora, comparing side by side, feature, sound quality, video quality, accuracy, speed of emulation...
 
So, how well do these emu's work in comparison to the ones we already have in existing categories(SNES,Neo Geo Pocket, NES, Genis, ETC.)?

Chris
That's probably a very interesting Subject, you can start some comparison review, per machine, of the existing emulators for the Pandora, comparing side by side, feature, sound quality, video quality, accuracy, speed of emulation...
From what I know from using these with android, these have more features than on existing emulators. NES.emu has proper Zapper support, Snes9x has mouse and SuperScope support, and MSX.emu is much easier to set up.
 
Back
Top