GU blit for snes9x

[crazyc]

This patch for uo_snes9x_002y11 changes the bilting code to use the GU. The upshot is stretching and (currently ugly) filtering can be done with no frame rate penalty. The patch also ports it to pspsdk and newlib.
http://home.wi.rr.com/crazyz/snes9x.diff
http://home.wi.rr.com/crazyz/snes9x.elf

Edit: new patch and binary

[mrbrown]

Great stuff! Have you gotten it to Y yet?

C'mon people we need more conversion of emulators and other apps to PSPSDK!

[zigzag]

Does it improve the frame rate over all though?

Is there a binary anywhere, too? :)

[crazyc]

Does it improve the frame rate over all though?

I haven't done any comparisons with an unpatched y11 so i don't know

Is there a binary anywhere, too? :)

I need to fix a few problems first.

[Orion_]

where did you get the Gu library ??

[Laurens]

You can get the latest hottest beta-code using SVN or TortoiseSVN (if you're on Windows) from the source repository at svn://svn.pspdev.org/psp/trunk/pspsdk/sdk/gu

[zigzag]

okay, thanks for your efforts!

[medafor]

does anyone have a compiled version we can test? after seeing what the pspsdk did for the neogeo cd emulator (60fps everygame with sound), i cant wait to play the snes. just seeing that you can resize the screen without any framerate loss is a major advancement already. pretty please can we have a sampler :)

[zigzag]

Where is this NeoGeo CD emu that uses GU?

[medafor]

http://www.pspupdates.com/2005/07/new-n ... r-psp.html

[inomine]

Any chance of an EBOOT.PBP? I can't seem to get it to pack.

Edit: In fact I can pack it but it crashes my V1.0 psp. I also can't seem to apply the patch to the y11 source.

Edit2: Looks like I'm not the only V1.0 owner having problems with it, but it does apparently work on V1.5. ector had some code from a while back that used to do the same, work on V1.5 crash on 1.0. I don't think he fully found what was wrong with it.

[wulfie]

anyone know where I can find an eboot of this? I'd LOVE to test it on my 1.5 ;)

[mrbrown]

In pgMain() in pg.c, after the sceDisplaySetMode() call, add a sceGuInit() call. This fixed it for me.

[mrbrown]

I've imported Y's 0.002y11 sources along with crazyc's GU patch into the pspware SVN repository. It only builds against PSPSDK head.

Do not spam the forums with a bunch of "where can I get it?" or "can I test it?". If you aren't capable of building it yourself, then you won't get anything useful out of what's currently there. Anyway, you'd be somewhat disappointed with the results - from my experimentation this runs slower than any of Y's recent releases (I was using y21 previously). There is no magical function that will instantly make SNES emulation full speed, but what crazyc has added is an excellent first step. There are several reasons why snes9x runs dog-slow on the PSP, and the bottlenecks are not limited to just blitting.

Make sure you repeat this on other sites as I will be filtering "me too" posts :).

/me heads to bed...

[subbie]

Hey I have a question.

What are the restrictions on resizing? Like can we let the user resize the image in any way or shape they desire on the lcd or is it limited to fix scales?

I am questioning because I might try moving my ngPsp project from the old method to this sdk.

[ector]

It's texture mapping, you can resize to any size or shape you want.

[deagle]

does anyone have a compiled version we can test?

I would like to get one because I don't know how to compile these sources (with gcc for x86?) the psp-gcc gives me an error :

C:\devkitpro\samples\sdk\gu>make
make: *** No targets. Stop.

[ooPo]

Code: Select all

/usr/local/pspdev/psp/sdk/samples/gu$ ls -la
total 0
drwxr-xr-x  8 root root 192 Jul  6 00:36 .
drwxr-xr-x  9 root root 224 Jul  6 23:39 ..
drwxr-xr-x  2 root root 216 Jul  7 16:22 blend
drwxr-xr-x  2 root root 208 Jul  7 16:22 blit
drwxr-xr-x  2 root root  96 Jul  7 16:22 clut
drwxr-xr-x  2 root root 120 Jul  7 16:22 cube
drwxr-xr-x  2 root root  96 Jul  7 16:22 lines
drwxr-xr-x  2 root root 120 Jul  7 16:22 sprite

You're not in a sample directory. There's no makefile. Pick a directory, go into it, then run make.

You were very close, though. :)

[Zeta]

Inside the snes directory first I used:

./autoconf
./configure
./make

but to make for psp I think you simply need to rename the Makefile.psp to Makefile and then make.
However I tried it on the psp and while it launches ok and the rom list appear I select the chronotrigger rom to play and the emulator crashes dumping the registers.

[Laurens]

I read elsewhere on the forum, you can do

Code: Select all

make -f Makefile.psp

should save quite a bit of renaming :)

[deagle]

Code: Select all

/usr/local/pspdev/psp/sdk/samples/gu$ ls -la
total 0
drwxr-xr-x  8 root root 192 Jul  6 00:36 .
drwxr-xr-x  9 root root 224 Jul  6 23:39 ..
drwxr-xr-x  2 root root 216 Jul  7 16:22 blend
drwxr-xr-x  2 root root 208 Jul  7 16:22 blit
drwxr-xr-x  2 root root  96 Jul  7 16:22 clut
drwxr-xr-x  2 root root 120 Jul  7 16:22 cube
drwxr-xr-x  2 root root  96 Jul  7 16:22 lines
drwxr-xr-x  2 root root 120 Jul  7 16:22 sprite

You're not in a sample directory. There's no makefile. Pick a directory, go into it, then run make.

You were very close, though. :)

I'm not so stupid :p

I created a makefile from another and the compilation starts but it gives me an error I cannot understand..

compiling c callbackFin.c
In file included from guInternal.h:12,
from callbackFin.c:9:
pspgu.h:12:22: psptypes.h: No such file or directory
In file included from guInternal.h:12,
from callbackFin.c:9:
pspgu.h:456: error: parse error before '*' token
pspgu.h:460: error: parse error before '*' token
pspgu.h:547: error: parse error before '*' token
pspgu.h:736: error: parse error before '*' token
pspgu.h:738: error: parse error before '*' token
make: *** [callbackFin.o] Error 1

the files are all present, even psptypes.h

[inomine]

Grab latest sdk/toolchain script from SVN, compile them and then retry SNES9x, the usual problem is that they are out of date.

[Andon]

crazyc, I wanted to thank you for your patch.

I'm working on including it in uo_Snes9x 0.02y11J3a6 right now. There are a couple of issues that need to be resolved first, but I should have it working and ready for release soon.

y added software bilinear filtering to his newer releases, but it's incredibly slow. It'll be great to offload the task to the GPU using texture filtering, games should actually run at a playable framerate with bilinear filtering :)

1x mode will use a nearest neighbor filter, but I'll give Fit/4:3/2x Width/Full the option of bilinear filtering.

[inomine]

I'm working on including it in uo_Snes9x 0.02y11J3a6 right now.

Why not just get SVN commit access and work on it in there? That way everyone can contribute in the long run. While the choice is of course yours I just think this will save a lot of duplication (there is already quite a bit between the different versions of the Snes emu)

[Andon]

I'm working on including it in uo_Snes9x 0.02y11J3a6 right now.

Why not just get SVN commit access and work on it in there? That way everyone can contribute in the long run. While the choice is of course yours I just think this will save a lot of duplication (there is already quite a bit between the different versions of the Snes emu)

Yes, that sounds like a good idea... I'm not too familiar with SVN unfortunately, I've used CVS a lot. I know they're similar, so it won't be too difficult to learn.

We should probably officially unofficially branch the codebase. Since y isn't releasing the source code for anything newer than y11, just drop the y11[j3[aX]] stuff in favor of a new name (perhaps a snapshot date version scheme).

I'll finish up on 0.02y11J3a6 and then work on merging it with the SVN project.


BTW, what's with the undefined reference to entry symbol _start error with psp-ld? I read somewhere that it might be because I had older toolchain files, so I wiped /usr/local/pspdev/ and rebuilt the toolchain, but I still get the linker error. I went ahead and changed main to _start to fix the problem, but that's a stupid way of fixing it, I think :) Should I just modify the linker script to use main as the entry point, or am I doing something wrong?

[mrbrown]

You should be using psp-gcc to link, not psp-ld.

[Andon]

You should be using psp-gcc to link, not psp-ld.

I am using psp-gcc... But it invokes psp-ld, and that's what spits the warning out.

Using the Makefile from SVN, the error goes away. So I'm guessing one of the additional psp libs it links with contains the _start symbol and that's what makes the call to main? That would make sense, allowing one to use their own startup.s, or the PSP SDK...


Anyway, I've got all of the code from 0.02y11J3a5 integrated with the PSP SDK port from SVN. I had to change the makefile, however, because it linked with newlib's libc and its fopen/fread/fwrite is slower than molases going uphill in winter. Instead, I removed -lc and replaced it with -lpsplibc, whose fread/fwrite use sceIoRead and sceIoWrite and are MUCH faster :) Unfortunately, atoi seems to be absent from psplibc, so I borrowed the stub function from the old psplib.cpp.

I disabled the GU blit code by default, because it's still not working properly. I suspect the RGB macro will have to be changed to compensate for the extra green bit when rendering to a texture, since we're using a 16-bit 565 pixel format now (it was previously 15-bit 555). The alternative would be to use a 16-bit 555(+1 alpha) format, but I don't know for certain if that requires or enables alpha testing. You can enable the GU blit code by uncommenting a line in the Makefile... I'll try to retool the code so it's possible to select the blit method at runtime, instead of at compile time.

I'll try to familiarize myself with GU... I was lead developer for an OpenGL 3D engine for 3 years in my previous job, so I have a lot to offer on the GPU end of things. There are a lot of potential GPU optimizations in Snes9x, most importantly, rewriting the transparency code to use hardware stencil/alpha testing and blending.

Using the PSP SDK functions instead of the psplib.cpp stubs has a slight negative impact on the performance of the application. I can't pinpoint exactly which ones are to blame, unfortunately, because I can't get profiling to work in any PSP apps :-\

Mrbrown, is there anything additional I should be doing to get the PSP toolchain to work with profiling? Perhaps a different ./configure option when building gcc and its libs?

Also, would it be possible for me to get SVN commit access for the Snes9x project in pspware? We might as well fork the project and work from the 0.02y11J3a6 codebase since y isn't releasing new code. I'd love to use a shorter version number too :)

[Warren]

For SVN write access you need to talk to Oobles or Neovanglist in #pspdev on irc.freenode.net r you could probably send either of them a PM on the forums.

[mrbrown]

He's already got SVN access :).