Beta Snes9X4D4P - Another New Build, Now With Hi Res And New Rom Picker

[skeezix]

Latest builds are: http://repo.openpandora.org/?page=detail&app=snes9x4p_ivanovic


EDIT: See later in the thread for newer downloads with some newer bits; Secret of Mana, a new picker, etc, are supported.

Not yet uploading to the dl.openhandhelds and app-store until we sort out this SRAM saves issue. Not had time to look into that myself, but hopefully SiENcE or myself can take a peek soon.

This is a continuation of earlier betas floating around rolled up into one.

A note on overclocking for now -- theres no ASM CPU cores or blitters in here yet, so I'd suggest overcloing to 666 or more to keep things sensible most of the time; myself, I run at 800 all the time, but its up to each person to decide w2hat they wish to do re: overclocking. I'll be adding hw scaler soon, which will speed things up a bit, and I'll look into ASM CPU cores in a few days, which would dramatically speed things up.

- defaults to no-frameskip (60/1 mode instead of Auto);
- attempts to switch between 50/60 hz as necessary
- attempts to do vsync (to avoid tearing)
- the spacebar menu has a scaling-mode switcher in it
- currently supports 1->2x2 and 1->3x2 (unsmoothed) scalers
- screen should center better for 2x2 scaled modes; ahh, the little things

Do people want a tiny old 1:1 scaler?

I'm planning on adding 2x2 and 3x2 smoothed hardware scaling soon.

Do people care about things like 'fullscreen with aspect constrained and smoothed' type scalers?

NOTE: This one seems ot have some SRAM bug; I've not had much free time in the last month or two, so I've not worked over that side of things; if you want SRAM saves to work, the current official build in appstore and dl.openhandhelds should work fine.

Get it here:
http://www.codejedi....4p_20100719.pnd -- out of date now; the project is in multiple peoples hands now

jeff

 

[Prometheus]

Agh, right when my Pandora's away! This will be the first thing I try when I get it back.

By the way, I keep forgetting to mention this, but I've had some strange behaviour with games that can save, in the original 32KHz-audio build (which is the one I've been using). Oftentimes, it will appear to save, but when I go to load it again it will only have the previous save, as if I hadn't saved when I last played. My cards are formatted as ext2, and the usual OS updates are applied. (One game it happens with a lot is Rockman & Forte, if you want any examples.)

 

[skeezix]

I'm not much of a SNES person and not a huge collection (I've ripped my own carts, but barely played many of them -- can you guys nail down what the SRAM save issue appears to be doing, to help me and SiENcE investigate it?

ie: what works, what does not work, regarding saves?

I just fired up SMW and it seems to have defaulted to the last SMB I played (SMB3), so that would suggest SRAM save does work (at least sometimes.)

EDIT: I just made a city in Sim City, hit Save, quit the emu (using spacebar menu), then fired it up again, and hit Restore City and it worked fine.

jeff

And note .. AFAIK, the last official build had no problems with SRAM saves, right?

 

[EvilDragon]

Until HF4 is released, do NOT clock exactly to 650 Mhz. Due to some small error in the algorithm, setting CPU Speed to 650 sets it to -1 MHz (whatever the OMAP does then... but it's slow).

So use 651 or 649 or something completely different - but not 650

 

[WizardStan]

Do people care about things like 'fullscreen with aspect constrained and smoothed' type scalers?

I actually really do like the look of the hq2x scalar for a lot of games. Any chance of that happening?

 

[EvilDragon]

I still want phosphor2x

 

[skeezix]

Do people care about things like 'fullscreen with aspect constrained and smoothed' type scalers?

I actually really do like the look of the hq2x scalar for a lot of games. Any chance of that happening?

Is that scale2x, for instance? Find me the source for the software-scaler and shoudl be easy to add.

(In essence with this latest build, theres a enum/array which lists scaler-mode-code and a callback to perform it, and the menu cycles through available valid-tagged options; it'd be pretty easy to add another scaler mode.. just an enum value, array entry to detail and name that mode, and the code to read the SNES buffer and spit it out to Pandora buffer.)

I saw phosphor2x awhile back, seemed pretty clever; point me to the source, piece of cake to add now I'm still time tight a little, but not too bad of late.

jeff

 

[MonkeyChops]

your awesome skeezix, I'll try this out tonight and report any bugs

I too need to send mine back but I may never do it, I keep coming up with reasons to not do it, this is another one

SRAM saves are save states, right? I hope you find time to fix that as its essential to the game I'm into right now, namely Super Mario World 3 Island of Mystery, its impossible w/o save state but oddly addictive.

I really liked your 3x2 version, I will probably exclusively use that setting. I'm not picky about the 1:1 thing or the constrained aspect ratio fullscreen.

 

[skeezix]

3x2 fills the screen, but just creeps me out with how far horizontal motion is relative to vertical; throws off my sense of balance 2x2 scale seems pretty slick, but we'll see how it goes with some hw scaler options.

SRAM saves are normal SNES in-game type saves (not emu doing a 'snapshot of the system' type save.)

But then, I'm not really well versed on what the problem is; from my limited testing it worked fine

jeff

 

[sebt3]

I actually really do like the look of the hq2x scalar for a lot of games. Any chance of that happening?

Is that scale2x, for instance? Find me the source for the software-scaler and shoudl be easy to add.

h2qx is way smarter than scale2x :
http://code.google.c.../hq2x.cpp?r=248

EDIT : Original source : http://code.google.com/p/hqx/downloads/list

 

[Prometheus]

can you guys nail down what the SRAM save issue appears to be doing, to help me and SiENcE investigate it?

ie: what works, what does not work, regarding saves?

As soon as I get my Pandora back I'll be trying to chip in with this.

And note .. AFAIK, the last official build had no problems with SRAM saves, right?

The last official build is the build where I'm encountering the issue I described.

 

[Tom`]

I saw phosphor2x awhile back, seemed pretty clever; point me to the source, piece of cake to add now I'm still time tight a little, but not too bad of late.
jeff

The only code that I could find:

uniform sampler2D rubyTexture;
uniform vec2 rubyInputSize;
uniform vec2 rubyOutputSize;
uniform vec2 rubyTextureSize;

#define TEX2D(c) texture2D(rubyTexture,(c))
#define PI 3.141592653589
#define phase 0.0
#define gamma 2.5

void main()
{
   vec2 xy = gl_TexCoord[0].xy;

   vec2 one          = 1.0/rubyTextureSize;
   xy = xy + vec2(0.0 , -0.5 * (phase + (1-phase) * rubyInputSize.y/rubyOutputSize.y) * one.y);

   vec2 uv_ratio     = fract(xy*rubyTextureSize);

   vec4 col, col2;

   vec4 coeffs = vec4(1.0 + uv_ratio.x, uv_ratio.x, 1.0 - uv_ratio.x, 2.0 - uv_ratio.x);
   coeffs = (sin(PI * coeffs) * sin(PI * coeffs / 2.0)) / (coeffs * coeffs);
   coeffs = coeffs / (coeffs.x+coeffs.y+coeffs.z+coeffs.w);

   col  = clamp(coeffs.x * TEX2D(xy + vec2(-one.x,0.0)) + coeffs.y * TEX2D(xy) + coeffs.z * TEX2D(xy + vec2(one.x, 0.0)) + coeffs.w * TEX2D(xy + vec2(2 * one.x, 0.0)),0.0,1.0);
   col2 = clamp(coeffs.x * TEX2D(xy + vec2(-one.x,one.y)) + coeffs.y * TEX2D(xy + vec2(0.0, one.y)) + coeffs.z * TEX2D(xy + one) + coeffs.w * TEX2D(xy + vec2(2 * one.x, one.y)),0.0,1.0);
   col = pow(col, gamma);
   col2 = pow(col2, gamma);

   vec4 wid = 0.2 + 0.4 * pow(col, 2.0);
   vec4 weights = uv_ratio.y/wid;
   weights = 0.51*exp(-weights*weights)/wid;
   wid = 0.2 + 0.4 * pow(col2,2.0);
   vec4 weights2 = (1.0-uv_ratio.y)/wid;
   weights2 = 0.51*exp(-weights2*weights2)/wid;

   gl_FragColor = pow(col * weights + col2 * weights2, 1.0/2.2);
}

It scales horizontally using a Lanczos filter and then vertically by giving the beam a Gaussian profile. Vertical blending is done in a linear color space. I've included a fair amount of bloom, but that can be adjusted.

 

[cosam]

I'm planning on adding 2x2 and 3x2 smoothed hardware scaling soon.

Do people care about things like 'fullscreen with aspect constrained and smoothed' type scalers?

How are you doing the hardware scaling? I'd be curious to see what an actual 4:3 fullscreen mode looked like...

 

[WizardStan]

h2qx is way smarter than scale2x :
http://code.google.com/p/snes9x-gtk/source/browse/branches/merge/filter/hq2x.cpp?r=248

That's the one. Not only smart, but fast. It has some room for improvement (specifically in how the tolerance of what is "near" is calculated) but on the whole it provides a very organic scaling: smoothing without blurring.

 

[urjaman]

h2qx is way smarter than scale2x :
http://code.google.com/p/snes9x-gtk/source/browse/branches/merge/filter/hq2x.cpp?r=248

That's the one. Not only smart, but fast. It has some room for improvement (specifically in how the tolerance of what is "near" is calculated) but on the whole it provides a very organic scaling: smoothing without blurring.

Just dropping by to add +1 for hq2x, its very nice

 

[chaosmage]

Until HF4 is released, do NOT clock exactly to 650 Mhz. Due to some small error in the algorithm, setting CPU Speed to 650 sets it to -1 MHz (whatever the OMAP does then... but it's slow).

So use 651 or 649 or something completely different - but not 650

Yeek. I assume that the slider doesn't change the actual speed until you click on OK, right? Otherwise this is bad mojo...

Are there any other speeds we should avoid because of a similar issue?

 

[MDave]

PLEASE get sound interpolation in! Some games sound absolutely dreadful without it

 

[skeezix]

PLEASE get sound interpolation in! Some games sound absolutely dreadful without it

Any examples? I'm not not emu level coding per se, just doing the port of SiENcE's port of snes9x, so post and hopefulyl he'll be about and take a look.

My hands are full enough that getting into snes9x actual emu coding is too much I'm afraid.

jeff

 

[SNESFAN]

hello... haven't posted in a while, been in the process of moving to another state, anyway, just wanted to stop in to request some stuff if it's not already there (snes emu was #1 reason I wanted a pandora)

I don't have my Pandora yet, but I'm expecting it soon (1st day preorderer) so I don't know if it already has this support or not, but what I would hopefully like to see is:

-full screen stretched mode (top to bottom, left to right)
-full stretched mode(top to bottom only)

also zsnes has filters that can be applied such as 2xsai and super 2xsai, super eagle etc.... is there any possible way these can find their way into this emu? it makes games look a little smoother when stretched all to hell like that.

you would be my favorite person ever if you could implement this

 

[skeezix]

Well, 3x2 scale fills most of the screen without being too weird, but it is a little over-wide imho; 2x2 scaling is a pretty good compromise (letterboxing, with padding at left/right to center it.) Adding smoothers will come soon (ie: bilinear from the hardware, plus stuff like scale2x, hq2x, phosphor2x etc in software modes.) The code I laid in for this version makes that sort of addition pretty easy. I'm thinking of adding some things like aspect-correct scale-up with clipping to the extra bits so it fills the screen, etc; so yeah, I think your answer is 'yes'

The emu is quite playable already (mostly thanks to SiENcE and the snes9x team), and it runs great on pandora. I think you'll be pleased

jeff