GP2X Hw Accelerated Sdl

[Drag]

My linker keeps complaining about Semaphores and Threads whenever I try to compile:

arm-linux-g++.exe main.o  -o "GP2Xtest.exe" -L"C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib" -lSDL -s  

C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_syssem.o): In function `SDL_CreateSemaphore':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_syssem.c:103: undefined reference to `sem_init'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_syssem.o): In function `SDL_DestroySemaphore':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_syssem.c:129: undefined reference to `sem_destroy'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_syssem.o): In function `SDL_SemTryWait':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_syssem.c:144: undefined reference to `sem_trywait'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_syssem.o): In function `SDL_SemWait':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_syssem.c:165: undefined reference to `sem_wait'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_syssem.o): In function `SDL_SemValue':

/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_syssem.c:209: undefined reference to `sem_getvalue'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_syssem.o): In function `SDL_SemPost':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_syssem.c:230: undefined reference to `sem_post'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_sysmutex.o): In function `SDL_CreateMutex':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_sysmutex.c:72: undefined reference to `pthread_mutexattr_init'
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_sysmutex.c:77: undefined reference to `pthread_mutexattr_setkind_np'

C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_systhread.o): In function `SDL_SYS_CreateThread':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_systhread.c:99: undefined reference to `pthread_create'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_systhread.o): In function `SDL_SYS_SetupThread':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_systhread.c:117: undefined reference to `pthread_sigmask'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_systhread.o): In function `SDL_SYS_WaitThread':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_systhread.c:136: undefined reference to `pthread_join'
C:/Program Files/Dev-Cpp/gp2x/devkitGP2X/lib\libSDL.a(SDL_systhread.o): In function `SDL_SYS_KillThread':
/home/darius/gp2x/sdl/libs-gp2x/SDL/src/thread/SDL_systhread.c:142: undefined reference to `pthread_cancel'

make.exe: *** [GP2Xtest.exe] Error 1

Whenever I use the precompiled LIBs that paeryn posted.

When I use the ones that came with the devkit that's on the gp2x wiki, it compiles fine. Am I doing something wrong? I really would like to use the HW acceleration.

 

[paeryn]

My linker keeps complaining about Semaphores and Threads whenever I try to compile:

​

You need to add -lpthread

 

[Drag]

That made it work, thank you very much.

 

[cowai]

Ok, I should not be here.. I'm not a devver.. But this "Hw Accelerated Sdl"-- what is it?
Can I install it in my gp2x and get a faster/better gp2x right away? Will it improve all games using sdl? Or just the new ones with implemented "Hw Accelerated Sdl"?


Sorry for English guys.. I am a Norwegian..

 

[Ravnos]

No, you won't get a faster anything until devs use the newer SDL libs in their games. This work provides a possibility for better performance out of new games and emus, but the existing ones will need to be recompiled to take advantage of this.

As for what hw accelerated SDL is, basically there's hardware in the GP2X that can be used to perform some of the things SDL does, and so the SDL libs have been modified to take advantage of this. This takes some of the load off the main processor(s) which should generally speed things up a bit. If you're not a dev or a potential dev, then none of this is really much concern to you, though, so don't worry your pretty little head and enjoy the fruits of all this labour.

 

[cowai]

I'm a potensial dev. I really want to start develop. But I don't know anything...

On topic: Can I install the file without hurting/changing my gp2x, so I can still play games that I play know?
= Can I just install this one for the future, or should I wait?

 

[luteijn]

On topic: Can I install the file without hurting/changing my gp2x, so I can still play games that I play know?

​

The question doesn't really make sense. It is not needed for you to install this stuff on the gp2x; (most) existing stuff wouldn't use it (as it is generally statically linked with the older routines). Any new stuff that does use it will (generally) come pre-linked with these new routines.

To use these new routines, you'd copy them to your development platform, where you link them to newly developed programs.

Pieter (also just starting with development for gp2x).

--
http://luteijn.xs4all.nl/html/luteijn.html#gp2x

 

[Drag]

Basically, I think that means that instead of having to install libraries and the game uses the libraries that are installed, the game will come with the libraries built into the gpe. The bad side to this is that games will have larger filesizes, but since we're not using 16mb sd cards... (RIIIIGHT?? )

Edit: also, my game is working fine with this updated library. And by that, I mean I'm able to see, hear, and have input to my game. The only problem is that when I turned on my sound synthesizer, it makes the game run slowly, and I'm not quite sure why. I'm using SDL_OpenAudio, so I'm not just playing WAV files or something, I'm actually generating squarewaves and stuff that's being output. The strange thing is if I increase the buffer size (the synth routine runs longer, but is called less frequently), the game speeds back up, but the sound has horrible latency (sound effects take up to 1 second to start playing). If I decrease the buffer size (routine is called more frequently, but runs for less time), the game slows down, but latency is improved.

I'd really like to fix this, but I don't know how. For one thing, I don't know what format the GP2X's audio is supposed to be in, so I don't know if SDL has to do some converting. I also don't know if there's any kind of HW acceleration for the audio. Oh well, at least it's WORKING.

Edit 2: Which is more optimal, SWSURFACE, or HWSURFACE?

 

[paeryn]

Basically, I think that means that instead of having to install libraries and the game uses the libraries that are installed, the game will come with the libraries built into the gpe. The bad side to this is that games will have larger filesizes, but since we're not using 16mb sd cards... (RIIIIGHT?? )

Edit: also, my game is working fine with this updated library. And by that, I mean I'm able to see, hear, and have input to my game. The only problem is that when I turned on my sound synthesizer, it makes the game run slowly, and I'm not quite sure why. I'm using SDL_OpenAudio, so I'm not just playing WAV files or something, I'm actually generating squarewaves and stuff that's being output. The strange thing is if I increase the buffer size (the synth routine runs longer, but is called less frequently), the game speeds back up, but the sound has horrible latency (sound effects take up to 1 second to start playing). If I decrease the buffer size (routine is called more frequently, but runs for less time), the game slows down, but latency is improved.

I'd really like to fix this, but I don't know how. For one thing, I don't know what format the GP2X's audio is supposed to be in, so I don't know if SDL has to do some converting. I also don't know if there's any kind of HW acceleration for the audio. Oh well, at least it's WORKING.

Edit 2: Which is more optimal, SWSURFACE, or HWSURFACE?

​

If you're using my version you may get some speed up with HW. HW is faster as it can do the blit whilst the CPU is doing other stuff, but there are still times when it doesn't play nicely. Downside is that you're limited to 5MB of HW surfaces. If I'm to play nicely with what linux is expecting the next 3 MB of memory are reserved for video overlays. Since I'm already taking liberties with it that can be freed for use to give us 8MB. The display is always 16-bit as SDL relys on /dev/fb which only returns 16-bit surfaces, SDL converts 8-bit to 16-bit when updating the screen, I'll have an 8-bit version out soon (just a case of more ignoring what /dev/fb says - which I already do half the time.)
I'm trying to figure out just how the blitter is intergrated, the gph code doesn't seem use it at all (unless the 920 uses it,which I doubt). I've got some code that works half the time and other times ignores certain blits totally - the docs are too vague in parts. Only thing I can certainly say is DON'T write to HW surfaces directly if you can help it - put images in them and then let SDL deal with them, CPU access to them is definately slower than to SW surfaces.
As for audio, it's AC97 spec. I'm not much of a sound person so it's low on my to-do list (read: leaving to someone else), but everything runs off the same memory bus, so the more you ask the hardware to do, the more you risk audio/graphics stealing memory access from the processor. Hopefully you can time things so the the CPU runs from it's cache, every system has its own sweet spots.

 

[paeryn]

If anyone wants to test, I think I've got 8-bit surfaces working with acceleration. It's a bit of a bodge but seems to be working. The dummy blit has changed too so hopefully it shouldn't cause corruption any more.
Only blits between same depths I think, don't know if the hardware will do 8bit -> 16bit on the fly.

Pre-compiled here, source will be available later.

 

[miq01]

Wow... This thing rocks! Thanks a lot, Paeryn.

I've recompiled Tilematch using your libs and it now it works at 160 FPS (before, it was 45 FPS). Tilematch draws 64 30x30 tiles on screen plus fonts (not SDL_ttf but homemade ones).

Besides, now I'm working on a space shooter that draws directly to buffer instead of blitting images and the speed is 730 FPS (46 FPS before!!!).

 

[codeninja]

Wow... This thing rocks! Thanks a lot, Paeryn.

I've recompiled Tilematch using your libs and it now it works at 160 FPS (before, it was 45 FPS). Tilematch draws 64 30x30 tiles on screen plus fonts (not SDL_ttf but homemade ones).

Besides, now I'm working on a space shooter that draws directly to buffer instead of blitting images and the speed is 730 FPS (46 FPS before!!!).

​

mig01, could you PLEASE re-compile your tile_match and release it for US? I can't wait til playing tile_match at solid 60fps! Also, is tile_match using your DaveC adaptation of control input? Those two will make the game truely excellent.

 

[Trip]

Besides, now I'm working on a space shooter that draws directly to buffer instead of blitting images and the speed is 730 FPS (46 FPS before!!!).

Jeez that's one hell of an increase.
Nice work all.
I can't wait to see the emulators etc. in action with this.

 

[miq01]

mig01, could you PLEASE re-compile your tile_match and release it for US? I can't wait til playing tile_match at solid 60fps! Also, is tile_match using your DaveC adaptation of control input? Those two will make the game truely excellent.

Hi Codeninja. I'm working on a few improvements. I'll probably release a new version that uses Paeryn SDL libs soon. BTW, my nickname is miQ01, not miG01 (since it appears underlined in this board, it is hard to figure out if it's a 'q' or a 'g').

Jeez that's one hell of an increase.
Nice work all.
I can't wait to see the emulators etc. in action with this.

I don't know why this huge increase in speed happens. Probably because all it does inside the main loop is calling SDL_FillRect (filling the screen entirely) and then drawing a small number (don't know, maybe 500 out of 320x240=76800) of pixels. So Paeryn will tell us better, but I don't expect this amount of speed boost on emulators at all.

 

[codeninja]

Hi Codeninja. I'm working on a few improvements. I'll probably release a new version that uses Paeryn SDL libs soon. BTW, my nickname is miQ01, not miG01 (since it appears underlined in this board, it is hard to figure out if it's a 'q' or a 'g').

​

I'm truely sorry, Miq01. I won't make that mistake again. I'll be waiting for your newer and even better tile_match while playing your currently released tile_match.

 

[paeryn]

I don't know why this huge increase in speed happens. Probably because all it does inside the main loop is calling SDL_FillRect (filling the screen entirely) and then drawing a small number (don't know, maybe 500 out of 320x240=76800) of pixels. So Paeryn will tell us better, but I don't expect this amount of speed boost on emulators at all.

​

I've just uploaded a newer version, a bugfix in my dummy_blit (this thing is causing me headaches) that could cause lock-ups.
FillRect is now accelerated in both 16 & 8 bits, doing a full screen fill will be much quicker, especially if you don't write to the buffer for a bit. All that time spent filling 76800 pixels isn't done by the CPU anymore, all it has to do is fill a few registers.

Hardware surfaces are only faster if you use them properly. Always lock them before writing directly to them. And writing directly to a hardware surface is slower than writing to a software surface.

 

[Squidge]

Yup, don't forget any memory >32mb is out of Linux's grasp, so has the default attributes of no caching whatsoever. It is also the only memory that can be blitted, as it's physical rather than virtual and is guaranteed not to be cached.

I'm not sure whether creating a kernel module that allows to change the attributes of memory would be any use. I'm thinking whether or not changing the memory attributes to cached, and then ensuring to drain the cache before doing blitter ops would make any difference as to the speed.

 

[JyCet]

paeryn, the hardware acceleration with your sdl lib is really impressive !!

Look this plasma demo test (start to quit the demo, the long black sceen is bormal ):
Plasma test software blit (original SDL)
Plasma test hardware blit (paeryn SDL)

Thank you a lot and all contributors !!

 

[no_skill]

if you add the hw scaler please use the "de-facto" "default" "SDL API" for "scaling": sdl_rotozoom (should be in sdl_gfx now)

 

[DJWillis]

if you add the hw scaler please use the "de-facto" "default" "SDL API" for "scaling": sdl_rotozoom (should be in sdl_gfx now)

​

Well there goes my plan of using it to just support 640*480, 800*600 etc. surfaces and down scaling on the fly .