notaz
Certified Guru
If aspect saving and and exit lag are the only problems, I could probably take a look at those.
Is Snes9x4P likely to see any updates?
- Thread starter Haze
- Start date
AFAIR the exit lag happened sometime when we updated the firmware.
SNESFAN
Retro game fanatic
Notaz to the rescue again... We need like 10 notazes
To the clone-a-matic!
To the clone-a-matic!
Orion4874
Mega GP Mania
This is more of a technical question than a request for notaz but would it be possible to incorporate MSU-1 support into Snes9x4P? I realize that only a couple projects even use it but the only other emu that supports it is bsnes which has never been ported to a portable console as far as I know. Here's byuu's development page on it, http://byuu.org/snes/msu1/development
Gausen
Member
Snes9x4P is really fast, specially when using HW scaling (haven't noticed any slowdown with those). Compatibility is also excellent.
I don't now if this is of any help, but this sdl version builds fine with latest codeblocks (just needed to include unistd.h in some files to support stuff like usleep). The gtk version fits ok in the pandora screen and the audio quality is really good (uses byuu's apu), but it is slow (lots of frameskipping). Had a system crash trying the pal version of DKC and brawl brothers was a flickering and jumping experience but maybe this can be useful in someway.
I don't now if this is of any help, but this sdl version builds fine with latest codeblocks (just needed to include unistd.h in some files to support stuff like usleep). The gtk version fits ok in the pandora screen and the audio quality is really good (uses byuu's apu), but it is slow (lots of frameskipping). Had a system crash trying the pal version of DKC and brawl brothers was a flickering and jumping experience but maybe this can be useful in someway.
mjohansson
Supporter
- Joined
- Feb 10, 2011
- Messages
- 409
Were can I find the source? Id like to have a look at it.
Edit: Is the source Gausen linked to the emu we currently use? It dosnt use GLES?
Edit 2: Nevermind, looked at the Jaguar source, I understand now, the emu draws pixels to a surface and then draws only two polygons and render the surface on them as a texture. So theres nothing to do to speed that process up.
Edit: Is the source Gausen linked to the emu we currently use? It dosnt use GLES?
Edit 2: Nevermind, looked at the Jaguar source, I understand now, the emu draws pixels to a surface and then draws only two polygons and render the surface on them as a texture. So theres nothing to do to speed that process up.
Last edited by a moderator:
mjohansson
Supporter
- Joined
- Feb 10, 2011
- Messages
- 409
But my 600mhz Pandora only slows down when it have transparent graphics on the screen, isnt there a way to let GLES handle that? Instead of drawing all graphics to a surface hmmm I dont know how old consoles work, what you would want is for every sprite and every background to be drawned individually as polygons by GLES, that would deal with transparencys and CPU wouldnt have extra work or am I talking crazyness?
mjohansson
Supporter
- Joined
- Feb 10, 2011
- Messages
- 409
Do old consoles read a frame directly from cart instead of storing all frames for an animation in ram? Well if the emu can find image data it should be able to store frames as textures for use in polygon rendering.
The new one actually renders on the Pandora?
I know it had issues with ARM, that's why it was never used for the Pandora.
Gausen
Member
Yes. I can make a crappy pnd if you want. It would be slow, glitchy and might crash your system, but audio is very good.
Gausen
Member
I don't really know. For what I have read in this boards about other emus, the use of GLES/openGL in the pandora for rendering "frames" would be slow. Work is comparable to constantly loading textures.
ivanovic
Active Member
- Joined
- Aug 4, 2006
- Messages
- 784
Most of the problems many of you see with some games slowing down like hell or playing in wrong speed is due to this emu being based on an ancient snes9x version. The problem is that later version had a rework in their audio system which makes sound close to perfect for stronger machines, sadly it significantly increases performance requirements so won't work nicely for the pandora.
I was already doing some experimenting with notaz libsdl back in the day and this is actually used for the hw scaling mods.
ED is correct that the delay when exiting the emulator itself back to the menu was introduced during some pandora system upgrade. But I have no idea when exactly that was and which prog exactly is responsible for this.
The aspect ratio saving was implemented by me this way because there were basically two groups of people. One group saying "I want one value for all roms" and the others saying "I want to define it on a per game level". I agreed more with the last group so that is what I did.
Everybody is free to improve on the current version of snes9x. It is fairly easy to build using a git checkout from github. Readme.txt states what you should do for building, should be enough of an explanation to allow you directly building a nice pnd. And no, this version of the emulator makes no use of OpenGL ES, just plain copy operations directly into the framebuffer.
I was already doing some experimenting with notaz libsdl back in the day and this is actually used for the hw scaling mods.
ED is correct that the delay when exiting the emulator itself back to the menu was introduced during some pandora system upgrade. But I have no idea when exactly that was and which prog exactly is responsible for this.
The aspect ratio saving was implemented by me this way because there were basically two groups of people. One group saying "I want one value for all roms" and the others saying "I want to define it on a per game level". I agreed more with the last group so that is what I did.
Everybody is free to improve on the current version of snes9x. It is fairly easy to build using a git checkout from github. Readme.txt states what you should do for building, should be enough of an explanation to allow you directly building a nice pnd. And no, this version of the emulator makes no use of OpenGL ES, just plain copy operations directly into the framebuffer.
ptitSeb
Serial Porter
The SNes9x v1.53 is clearly slower than v1.43 ! But sound is better sometimes. You should use old version as much as possible, and use newer only when necessary (I found Super StarWars for example sounds good only on v1.53, but many games runs and sound perfect even on 1.43)
Similar threads
