Release SNES9X4P hardware scaled

[john4p]

Was always disappointed with the tiny area in which SNES9X4P displayed the gfx. Yes, it was very crisp - but I prefer to have the full height of the screen used (while keeping correct aspect ratio - so no ugly widestretch).


Thanks to notaz' new SDL release hardware scaling could easily be added just by modifying the startup-script (of the emulator's latest release) without altering the emulator's source code (which I couldn't find anyway).


Download the full ready-to-go package here: http://www.mediafire...9x6x5dw50170sib


Just extract the archive's contents to your SD card and start the emulator by executing run.sh (dunno how to make a PND - would be great if someone could do this).


In this release there is a standard setting (best for most games) plus 2 additional game specific settings.


If you start a game (via PickleLauncher) now a messagebox appears - press Return to use the "Standard" upscaling screen dimensions.


Press left and Return to select "Extra" to select one of the 2 game specific screen dimensions:


"SF2T" makes Street Fighter II Turbo fullscreen in battles which due to this game being letterboxed on standard 4:3 TVs still keeps its aspect ratio pretty much intact.


The 2nd setting "Batman Returns" lets you play that title at correct aspect ratio without black bars on top and bottom (it uses less lines than other SNES games hence this 2nd specific setting).


With access to the sourcecode this could be improved by removing the software integer pixel doubling (which isn't required anymore now that hardware scaling is available) and maybe providing an interface for custom screen dimensions.


You can easily use own screen dimensions already now just by modifying the script snes.sh.


Change the line:


export SDL_OMAP_BORDER_CUT=50,50,15,15


to your liking. The 1st number cuts x pixels from the left, the 2nd y pixels from the right, the 3rd n pixels from the top and the 4th number cuts m pixels from the bottom.

 

[Pickle]

With access to the sourcecode this could be improved by removing the software integer pixel doubling (which isn't required anymore now that hardware scaling is available) and maybe providing an interface for custom screen dimensions.

source is out there, if im remembering right there is a public git? out there that was originally used for the dingoo version. I know its out there though since i added scale2x support to it.

 

[Garrett]

Can someone please package up a .pnd of this asap


Cheers.

 

[NoeleyC]

Can someone please package up a .pnd of this asap


Cheers.

+1

 

[gruso]

Could this be integrated into the existing release, rather than create a fork?

 

[john4p]

source is out there, if im remembering right there is a public git? out there that was originally used for the dingoo version. I know its out there though since i added scale2x support to it.

I mean the sourcecode of the best Pandora build so far. Don't wanna create a fork either.

 

[ivanovic]

source is out there, if im remembering right there is a public git? out there that was originally used for the dingoo version. I know its out there though since i added scale2x support to it.

I mean the sourcecode of the best Pandora build so far. Don't wanna create a fork either.

THe sources are linked in the documentation. Just put the sdcard onto your pandora, open the documentation and see the link to the svn repo in which the sources are stored.

 

[Michoko]

Sounds awesome! Thank you John for your amazing work (something tells me there could be some nice potentials regarding Amiga emulation, right? )

 

[john4p]

The sources are linked in the documentation. Just put the sdcard onto your pandora, open the documentation and see the link to the svn repo in which the sources are stored.

Ah, great - thanks!


I'll have a look. Unless you want to add the custom hw scaling yourself (shouldn't be much work).

Thank you John for your amazing work

I didn't do any work here (just set 1 environment variable in the start script) - notaz implemented the zooming/cropping support to SDL.

something tells me there could be some nice potentials regarding Amiga emulation, right?

That's a fair assumption.

 

[ivanovic]

The sources are linked in the documentation. Just put the sdcard onto your pandora, open the documentation and see the link to the svn repo in which the sources are stored.

Ah, great - thanks!


I'll have a look. Unless you want to add the custom hw scaling yourself (shouldn't be much work).

Personally I would prefer it done "right". This means doing it via sourcecode changes. It might also be worth a try to do the "normal" upscaling in hardware. So when switching the render mode via the menu, the emulator would switch to a different resolution and use scaling in hardware to either "not scale", scale to "keep aspect ratio" or "scale to fullscreen". The basic changes required would probably be the following:


1) Gather a list of possible resolutions (on the rom side) as well as "what should be used when displaying". This basically means as "source" the following:


* 256x224 (NTSC - LowRes)


* 256x239 (PAL - LowRes, might require using 240px vertically!)


* 512x448 (NTSC - HiRes)


* 512x478 (PAL - HiRes)


* 320x240 ("Overlay Menu" of the emulator)


The general problem here is that it seems possible that games (like Secret of Mana) switch the mode used depending on the situation (not 100% sure though!) which can make things significantly more interesting...


Thinking about the resulting resolutions when displaying I can think of the following:


* Render the stuff into a 800x480 buffer (like it is done at the moment).


* Render the 256x* into a 320x240 buffer and let the hardware scale it up to 640x480 (so keeping the aspect ratio and adding some black borders).


* Render the 256x* into a 256x* buffer and let the scaling to 512x480 be done by the hardware, resulting in no black borders at the top and bottom.


* Do that stuff for some select "wide version", too.


2) Switch to the correct render mode. This means that we set the resolution of the SDL pane which should not be done too often, so possibly only when switching the render mode in the menu (have a look at the button and menu mapping stuff where the switching is implemented), here you'd have to add changing the SDL display resolution and make sure that hardware scaling is set correctly.


3) Create the additional modes for selection in the menu, since several new ones would be required.


4) Adjust the code for the rendering into the panes, according to the modes set. Some sane splitting will likely be required here to make sure that not too much overhead is added, since this selection has to be done for every frame displayed.


This should basically list the stuff that is required regarding the code changes. All code that you have to modify is in "unix/" (the lang used for most stuff is C, though since the compiler used is a C++ compiler, you might want to use some C++ like I did for the preferences). Most stuff is even inside "#ifdef PANDORA" blocks. To build a binary for yourself simply edit Makefile.pandora to list the correct path to your crosscompiler. Afterwards call


"make -f Makefile.pandora" to create the plain snes9x binary or "make -f Makefiles.pandora pnd" to directly create a pnd. If you need to do some packaging changes, have a look at the folder "pandora/", especially at "pandora/pnd/". There you will have to at least add the library you want packaged. Currently the packaging happens running "svn export", so to get new files into the pnd, you have to "svn add" the files.


Feel free to ask questions in #openpandora on irc.freenode.net. I am not sure which of these things I'll be able to do myself (time constraints...). For some stuff you might want to ask notaz, too. You'll likely have to set some things using setenv, since the lib relies on some env variables.

 

[john4p]

Thanks for the elaborate reply and build instructions.


Yeah, the auto detection of possible resolutions would be nice to have, but I'm just going to add the possibility to change the hardware scaling manually.


Also there are games which run at a certain resolution - say 256x224 pixels - yet they still draw black lines on top and bottom so in reality the displayed gfx are really only e.g. 256x200 pixels. These games benefit especially by manually set screen dimensions.


Also the correct aspect ratio may differ from user to user: some prefer 8:7 (square pixels), some 4:3 (like the games would appear on TVs).


Still some games just look too "thin" at 8:7 aspect ratio while others look too "fat" at 4:3. For some games some ratio in between like 8:6.5 (16:13) looks best. That can be easily done with custom scaling, too.


The only thing needed to change the scaling is to re-set the environment variable SDL_OMAP_BORDER_CUT and call SDL_SetVideoMode.


Btw., just tried out Scale2x* with the hardware scaling combined which looks amazing (and is fast) so I won't remove the software pixel doubling.


(*push SPACE to bring up the emulator gui where you can select it, push (X) to leave the gui)

 

[fusion_power]

I know the SNES had a very weird Pixel Aspect Ratio. But I also know that this usualy was displayed in normal 4:3 on the screen so I think the "correct" Aspect Ratio would be 4:3 for displaying the image on the Pandora Screen. For example 640x480 without borders. If the scaling can produce a clean and fluid image in this size, I'm already happy. ^^


Of course there still can be other options in, if people want the "Pixel Perfect" scaling. maybe this is even faster because of "clean" doubling Pixels than stretching everything in 4:3.

 

[skeezix]

I wouldn't drop any of the code, since its all good and working Just add additional blitters and perhaps dynamicly list them -- ie: if in software mode, show this set, otherwise this set. Its laid out like that pretyt easily in the code.. I added an enum IIRC for blitter-operations or something, and the user just picks the desired one from the menu, and away it goes. So adding more shouldn't be too hard.. code chanegs only in a couple of places.


Its all kept in a svn by SiEnCE; I kicked off the pandora port, then I think Ivanovic pollished it up and fixed a bunch of bugs, and then WizStan added some more blit modes, and Pickle did some blit modes, and ED did some packaging to add pickle-launcher and so on, and I think others have been in there;. now its your turn, I think we're all busied up, so have at


jeff

 

[john4p]

For example 640x480 without borders. If the scaling can produce a clean and fluid image in this size, I'm already happy. ^^

The standard mode of the above release does that already. Just try it.

I wouldn't drop any of the code, since its all good and working Just add additional blitters and perhaps dynamicly list them -- ie: if in software mode, show this set, otherwise this set. Its laid out like that pretyt easily in the code.. I added an enum IIRC for blitter-operations or something, and the user just picks the desired one from the menu, and away it goes. So adding more shouldn't be too hard.. code chanegs only in a couple of places.

Okay, thanks for the info. I won't remove any functionality.

Its all kept in a svn by SiEnCE; I kicked off the pandora port, then I think Ivanovic pollished it up and fixed a bunch of bugs, and then WizStan added some more blit modes, and Pickle did some blit modes, and ED did some packaging to add pickle-launcher and so on, and I think others have been in there;. now its your turn, I think we're all busied up, so have at

Nice. True community project.

 

[john4p]

Downloaded the latest TortoiseSVN and tried to check out the url as described in the documentation.


Doesn't work: "no repository found in: ...".


The repo browser says: can't connect to host.


How can I obtain the sources?

 

[skeezix]

Off the top of my head (and its been months), that doesn't strike me as the domain I was using to pull from, but I don't have my VM or dev-linux-box handy. Someone confirm?


jeff

 

[ivanovic]

You are missing an 'o' in dingoo.


SiENcE asked me explicitly not to publish the complete url on some server, since his machine is likely not to be able to handle high(er) load. It would be nice if you could edit the URL out of your post.

 

[john4p]

Thanks for the quick replies.


Currently at work now where with the correct url tortoisesvn still can't find the host ('unknown hostname'). But maybe the network here is just too restrictive (I've set the proxy correct). Will try again after work.


edit: Great, with a standard internet connection (no proxy) the svn checkout worked now.

 

[john4p]

Tried building this directly on Pandora. A few minutes in this error occured:

/usr/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../crt1.o: In function `_start':
init.c.text+0x2c): undefined reference to `__libc_csu_fini'


init.c.text+0x34): undefined reference to `__libc_csu_init'


unix/svga.o: In function `S9xInitDisplay':


svga.cpp.text+0x98): undefined reference to `atexit'


collect2: ld returned 1 exit status


make: *** [snes9x] Error 1

Am I missing some library?


Halp please!

 

[ivanovic]

What crosscompiler setup are you using? Maybe it would help if you joined IRC (#openpandora on irc.freenode.net) and we discussed stuff in there. I know for sure that with the crosscompiler setup I created (the script based installer) it does work over here.