GP2X Hw Accelerated Sdl

[deadlychicken22]

...

​

I agree at I would like a n00bs guide.

​

Does this count?

​

Thanks, i'm folowing the directions right now.

EDIT:Would you please port perfect fit to the gp2x? I really liked it on the gp32, but I don't like to use my gp32 anymore because, besides having to carry around two handhelds, it is a nlu.

EDIT2:
well, i followed Flavor's instructions and HWSURFACE worked, but I am still getting some graphical problems (interlacing when moving, slight graphical abnormalities) when using SDL_DOUBLEBUF (which i was told would fix these). I just switched it to say this:

screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_HWSURFACE|SDL_DOUBLEBUF);

Is there anything I'm missing?

 

[paeryn]

well, i followed Flavor's instructions and HWSURFACE worked, but I am still getting some graphical problems (interlacing when moving, slight graphical abnormalities) when using SDL_DOUBLEBUF (which i was told would fix these). I just switched it to say this:

screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_HWSURFACE|SDL_DOUBLEBUF);

Is there anything I'm missing?

​

The interlacing artifacts are not solved yet. The MMSP2 is definately set up to not interlace when outputing to the LCD
I know about a couple of glitches, I'm working on them as I type. The blitter code doesn't handle SW->HW blits properly, it sometimes gets x-coord wrong, 8bpp blits were iffy... And there's some major memory corruption in graphics memory which I'm still trying to track down as I can't find a way of reliably triggering it.
Looks like no sleep for me tonight

Edit: Uploaded new version. Source tarball is .gz for this release as bzip2 is segfaulting on it , pre-compiled is still .bz2
source

Possible MMSP2 bug: reading MLC_STL_VSCH actually returns MLC_STL_VSCL.
Possible bug in leaving TV-out (firmware rev 1.2.1), going from interlaced to non-interlaced when display is on field=1 bottom 2 lines of LCD are wrong - NOSYMATVFLD & NOSYMATVLINE (bits 13 & 12) in DPC_VS_END are left on and shoulld be cleared.

 

[Flavor]

Would you please port perfect fit to the gp2x? I really liked it on the gp32, but I don't like to use my gp32 anymore because, besides having to carry around two handhelds, it is a nlu.

Are you talking to me? If so, I didn't do Perfect Fit. Though, I did do DynaMate which is rather similar.

 

[Flavor]

Edit: Uploaded new version.

I grabbed the binary version, and it here's how my game worked.

1) Selected the game from the menu.
2) Got black screen.
3) Goto 2.

 

[deadlychicken22]

Would you please port perfect fit to the gp2x? I really liked it on the gp32, but I don't like to use my gp32 anymore because, besides having to carry around two handhelds, it is a nlu.

Are you talking to me? If so, I didn't do Perfect Fit. Though, I did do DynaMate which is rather similar.

​

yeah, that's what i meant. I just noticed it in your avatar and remembered enjoying it on my gp32.

 

[paeryn]

I grabbed the binary version, and it here's how my game worked.

1) Selected the game from the menu.
2) Got black screen.
3) Goto 2.

​

Ohh.... Not good... Sorry! I probably copied a bad version - I was getting tired when I did it. I'll re-upload as soon as I can.

 

[telengard]

Hi everyone,

I have a (probably dumb) question. Is it possible to get a surface that will not be subject to stretching after setting the display size to be larger than the physical screen? I ask because the screen fitting works great for making larger size display surfaces fit on the gp2x's screen but my virtual keyboard is also subject to the strectching and no font I have come across looks that good. Removing lines from it makes the letters very hard to read. It is smaller than 320x240 so it can fit without being stretched. I guess what I'm looking to do is to blit the virtual keyboard as sort of an overlay unchanged. I haven't seen any way to do it so far.

Like I said, dumb question, probably not do-able, but I thought I'd ask.

paeryn, thanks a lot for your hard work!!

~telengard

 

[nickspoon]

Just blit the surface to an SDL_Rect?

 

[paeryn]

I have a (probably dumb) question. Is it possible to get a surface that will not be subject to stretching after setting the display size to be larger than the physical screen? I ask because the screen fitting works great for making larger size display surfaces fit on the gp2x's screen but my virtual keyboard is also subject to the strectching and no font I have come across looks that good. Removing lines from it makes the letters very hard to read. It is smaller than 320x240 so it can fit without being stretched. I guess what I'm looking to do is to blit the virtual keyboard as sort of an overlay unchanged. I haven't seen any way to do it so far.

​

Not yet. As it stands, the scaling is transparent to SDL - it doesn't know that the LCD is scaling down the display. Getting the OSD up and running is high up on my list, but it may also be subject to scaling (can't remember off the top of my head.)
I want to get the current bugs fixed before I start adding the extra functionality, unfortunately I've got a lot of other things that people insist I do... I'm seriously considering unplugging my phone and skipping all these appointments, I really want to get this fixed - it's on my mind constantly and frustraiting me that I can't spend the time I need to sort it out. I'm really in the mood to work on it now, but I've got to go to bed 'cause I've got to be up and out by 10am

 

[telengard]

I have a (probably dumb) question. Is it possible to get a surface that will not be subject to stretching after setting the display size to be larger than the physical screen? I ask because the screen fitting works great for making larger size display surfaces fit on the gp2x's screen but my virtual keyboard is also subject to the strectching and no font I have come across looks that good. Removing lines from it makes the letters very hard to read. It is smaller than 320x240 so it can fit without being stretched. I guess what I'm looking to do is to blit the virtual keyboard as sort of an overlay unchanged. I haven't seen any way to do it so far.

​

Not yet. As it stands, the scaling is transparent to SDL - it doesn't know that the LCD is scaling down the display. Getting the OSD up and running is high up on my list, but it may also be subject to scaling (can't remember off the top of my head.)
I want to get the current bugs fixed before I start adding the extra functionality, unfortunately I've got a lot of other things that people insist I do... I'm seriously considering unplugging my phone and skipping all these appointments, I really want to get this fixed - it's on my mind constantly and frustraiting me that I can't spend the time I need to sort it out. I'm really in the mood to work on it now, but I've got to go to bed 'cause I've got to be up and out by 10am

​

Hi paeryn,

Don't stress out over it.

I go through the same thing w/ my project. Sometimes real life gets in the way of the fun stuff. There's no rush to get this stuff done. I really appreciate what you've been doing as I bet a lot of the people in this long thread do. I just did a release that supports one of my favorite systems thanks to your hard work!

~telengard

 

[paeryn]

I go through the same thing w/ my project. Sometimes real life gets in the way of the fun stuff. There's no rush to get this stuff done. I really appreciate what you've been doing as I bet a lot of the people in this long thread do. I just did a release that supports one of my favorite systems thanks to your hard work!

​

Cheers! This is what I miss in Real Life, none of my friends / family understand computers and when I tell them what I'm doing all I get is an "ohhh, that's nice" with a glazed look on their face.
And absolutely nobody understands that I prefer to code at night and sleep in the day.
The source download is back to .bz2 format - Don't know what went wrong with bzip2 last night but it worked fine just now... Maybe my PC was overheating.
There seems to be a bug in 8bpp colourkeying - my test is working half the time, might be a problem with mapping RGB colour back into a palette number.

 

[telengard]

I go through the same thing w/ my project. Sometimes real life gets in the way of the fun stuff. There's no rush to get this stuff done. I really appreciate what you've been doing as I bet a lot of the people in this long thread do. I just did a release that supports one of my favorite systems thanks to your hard work!

​

Cheers! This is what I miss in Real Life, none of my friends / family understand computers and when I tell them what I'm doing all I get is an "ohhh, that's nice" with a glazed look on their face.
And absolutely nobody understands that I prefer to code at night and sleep in the day.
The source download is back to .bz2 format - Don't know what went wrong with bzip2 last night but it worked fine just now... Maybe my PC was overheating.
There seems to be a bug in 8bpp colourkeying - my test is working half the time, might be a problem with mapping RGB colour back into a palette number.

​

Hehe, I can totally relate to the 'glazed look' thing. I showed my fiancee when I got TI 99/4A emulation up and going and was very excited. I got a little ho-hum kinda "that's nice". Oh well, we can't all be 8 bit geeks I guess.

~telengard

 

[miq01]

And absolutely nobody understands that I prefer to code at night and sleep in the day.

I do understand it. That's the way I like it too.

 

[Epicenter]

Partaining to the 5MB hardware surface limit-- in what format are these surfaces? e.g. if I were to want to use a 20kb PNG file as a hardware surface-- should I assume it's going to be converted into a very large bitmap-like format and stored in VRAM? If so, I imagine I won't be able to fit very much there-- and storing anything like a big, long scrolling background is going to be totally out of the question. I'd have to just put smaller things like character and bullet/effect sprites there.

What happens to surfaces past that 5MB Limit-- are they stored in main system RAM and used as software surfaces on their own or do I need to allocate these resources carefully, defining hardware surfaces separately from software ones to avoid exceeding that limit? Are you allowing for the use of up to 8MB (incl. the VRAM normally used for overlays) just yet or is that planned for in the future?

Also, are SDL_GFX functions like rotozoom yet supported? Sorry for all the questions. Thanks.

 

[paeryn]

Partaining to the 5MB hardware surface limit-- in what format are these surfaces? e.g. if I were to want to use a 20kb PNG file as a hardware surface-- should I assume it's going to be converted into a very large bitmap-like format and stored in VRAM? If so, I imagine I won't be able to fit very much there-- and storing anything like a big, long scrolling background is going to be totally out of the question. I'd have to just put smaller things like character and bullet/effect sprites there.

What happens to surfaces past that 5MB Limit-- are they stored in main system RAM and used as software surfaces on their own or do I need to allocate these resources carefully, defining hardware surfaces separately from software ones to avoid exceeding that limit? Are you allowing for the use of up to 8MB (incl. the VRAM normally used for overlays) just yet or is that planned for in the future?

Also, are SDL_GFX functions like rotozoom yet supported? Sorry for all the questions. Thanks.

​

It's raw bitmap data held in either 8bpp or 16bpp depending on what you request the video mode to be in.
Once you've used up the memory any attempt to allocate HWSURFACEs will fail and you'll have to either free some surfaces or allocate them as SWSURFACEs. At some point I'll add a function to reorganize HWSURFACEs so that after you've freed some it'll move all the free space to the end.
The next 3MB after the 5 I've taken is used for 3x 1MB video surfaces so I should be able to extend into there. I'm not sure what area of memory is taken for the audio buffers at the moment. The main problem is that this upper 32MB isn't managed by Linux, the drivers all use there own hard-coded memory regions.
I'll allocate more of the upper memory as I can when I find out what areas are (relatively) safe to trash.
Rotozoom does software rotation/zooming of one surface to another doesn't it? As long as it's in C(++) it should work without any problems.

 

[pepone]

Partaining to the 5MB hardware surface limit-- in what format are these surfaces? e.g. if I were to want to use a 20kb PNG file as a hardware surface-- should I assume it's going to be converted into a very large bitmap-like format and stored in VRAM? If so, I imagine I won't be able to fit very much there-- and storing anything like a big, long scrolling background is going to be totally out of the question. I'd have to just put smaller things like character and bullet/effect sprites there.

What happens to surfaces past that 5MB Limit-- are they stored in main system RAM and used as software surfaces on their own or do I need to allocate these resources carefully, defining hardware surfaces separately from software ones to avoid exceeding that limit? Are you allowing for the use of up to 8MB (incl. the VRAM normally used for overlays) just yet or is that planned for in the future?

Also, are SDL_GFX functions like rotozoom yet supported? Sorry for all the questions. Thanks.

​

It's raw bitmap data held in either 8bpp or 16bpp depending on what you request the video mode to be in.
Once you've used up the memory any attempt to allocate HWSURFACEs will fail and you'll have to either free some surfaces or allocate them as SWSURFACEs. At some point I'll add a function to reorganize HWSURFACEs so that after you've freed some it'll move all the free space to the end.
The next 3MB after the 5 I've taken is used for 3x 1MB video surfaces so I should be able to extend into there. I'm not sure what area of memory is taken for the audio buffers at the moment. The main problem is that this upper 32MB isn't managed by Linux, the drivers all use there own hard-coded memory regions.
I'll allocate more of the upper memory as I can when I find out what areas are (relatively) safe to trash.
Rotozoom does software rotation/zooming of one surface to another doesn't it? As long as it's in C(++) it should work without any problems.

​

Hi
I now use your SDL with gngeo, and it work pretty well. It even give a little boost (not too much, nearly 5fps, but I didn't hope more )
I would like to know: Is there a way to know wich part of the upper memory is used? Because I also use some part of it with gngeo, and I don't want to trash something

 

[Mudi]

It's raw bitmap data held in either 8bpp or 16bpp depending on what you request the video mode to be in.
Once you've used up the memory any attempt to allocate HWSURFACEs will fail and you'll have to either free some surfaces or allocate them as SWSURFACEs. At some point I'll add a function to reorganize HWSURFACEs so that after you've freed some it'll move all the free space to the end.
The next 3MB after the 5 I've taken is used for 3x 1MB video surfaces so I should be able to extend into there. I'm not sure what area of memory is taken for the audio buffers at the moment. The main problem is that this upper 32MB isn't managed by Linux, the drivers all use there own hard-coded memory regions.
I'll allocate more of the upper memory as I can when I find out what areas are (relatively) safe to trash.
Rotozoom does software rotation/zooming of one surface to another doesn't it? As long as it's in C(++) it should work without any problems.

​

Hey look it's rotozoom
http://www.ferzkopp.net/Software/SDL_rotozoom/
And a C demo that can compile to GP32 and can probably be ported to GP2X easily
http://chui.dcemu.co.uk/rotozoom.c.html

 

[ooPo]

This package is deprecated - please use the compatible SDL_gfx library referenced on the Software Page.

SDL_gfx has been available in my toolchain script for a while now and works nicely, although slow, on the gp2x.

 

[paeryn]

I would like to know: Is there a way to know wich part of the upper memory is used? Because I also use some part of it with gngeo, and I don't want to trash something

​

Currently it allocates 0x3101000 - 0x3600FFF which is the area that fbcon expects to have. I think the 4K below this was intended to hold the palette, the code for the frame buffer just says it allocates 1 page + 2.5M, it doesn't specify what that 1st page is for and it doesn't use it. I might just try right now...
I think the 1st 1Mb (0x2000000-0x20FFFFF) is intended to hold the 940's code (and vector tables?)
Then there's the areas needed for audio and USB, although I've not looked to see which areas these take.
You are aware that the upper memory is slow to access aren't you? If you're using it to hold often-used data then you'll be taking quite a performance hit. I think squidge clocked it at 65% the speed of normal malloc'ed memory.

 

[KaosOverride]

Hi Paeryn, I would like to thank you because of the great work you are doing with this SDL for GP2x It has been very usefull for some programs I have made for GP2x

I'm now working on CaPriCe for Gp2x and have some "trouble" trying to speed up the emulator... It uses 2 surfaces instead of doublebuffer, but the CPC's are clocked to 50hz so 50 frames is the max. I have recoded to use double buffer and the emu gets 30FPS because the VBL at 60hz...

Declaring both surfaces as HWSURFACE may work at similar speed to one double buffer but without the 60FPS lock? Then, maybe I don't need to recode the doublebuffer...

If I want to remove the 60FPS lock, is just remove the "do {} while VBL "'s from the source?

If just the use of two surfaces declared in hardware is enought...

Anyway, thank you very much for the hardware SDL!!!