Is Snes9x4P likely to see any updates?


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
 
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.
 
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.
 
Last edited by a moderator:
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?
The source for snes9x4p is here. The other link posted is for an sdl port of the version 1.53. This sdl version has support for openGL, but not in the test build I made (configured using --without-opengl).
 
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?
 
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.
 
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?
 The source for snes9x4p is here. The other link posted is for an sdl port of the version 1.53. This sdl version has support for openGL, but not in the test build I made (configured using --without-opengl).
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.
 
I am kind of surprised that this version of Snes9X runs as well as it does. Weren't there GP2x SNES emus (pocketsnes) that ran much, much faster?
 
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?
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.
 
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.
 
The snes9x in the PtitSeb PND should be more recent if I'm not wrong, but I find it still slower than this
 
He even explained why. Please read ivanovics post again.


Morw recent sometimes != faster.
 
Last edited by a moderator:
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)
 
Back
Top