GP2X Hw Accelerated Sdl

[yaustar]

Yes you can double buffer with this HW SDL.

On the choice of Libs, minimal lib is almost a list of memory registers so you would have to do everything yourself (image loading, blitting etc). SDL is a decent API and is fast enough for most uses.

 

[M-.-n]

Hey MR. paeryn,

I do have case where Posting SDL_EXPOSE never result of an event of that type coming into my main loop... have u any idea about it ? I've worked around one of the situation where it happens but I'm going to need to much hacking to prevent the other and I'm not very excited about that.

Any idea ?
Cheers,
M-.-n

 

[HexDump]

Another little question, that I think it should be easy to answer: I want to add SDL support to my cross engine (that nows produces code for win, psp). The engine used Doble buffer and it allocates 2 vram screens to do the hardware double buffer. Is there any way of doing this with SDL? I have seen that with the SDL_SetVideoMode, you can have Double buffer, But I don´t want SDL to control the surfaces, because I use an offset system for everyline (to speed up rendering) and all this is encapsulated in my own VRamPage class. So, Is there any posiblity of allocating 2 vram surfaces and make sdl use them for double buffer using hardware support? (flip, etc...). I mean somethink like:

frontbuffer= SDL_CreateRGBSurface(SDL_HWSURFACE,...);
backbuffer= SDL_CreateRGBSurface(SDL_HWSURFACE,...);

and then let know SDL this are the 2 buffers it should use for flipping.

This way I could have my VramPage class encapsulating a SDL_Surface and SDL will do its flipping with no prob.

Cheers,
Heump.

 

[Epicenter]

I'm using the newest version of this lib but I wonder if I am really using it right. I draw a LOT of image data to the screen per frame in my engine, most notably a lot of small sprites but even in areas with some BIG ones, e.g. full 320x240 background imagery e.g. for parallax scrolling, there is pretty much NO performance gain. Don't get me wrong, I'm not having trouble staying over 60 FPS even with very stressful situations in-game but I want to be above 120FPS at all times if I can, due to particulars in how the engine operates (That might make more sense when I put up some previews.) I can't really tell any difference switching between software and hardware surfaces.

Right now, I load things as such (let's say it's a BMP file to go in SurfaceA)
SDL_Surface *tempsurf;
tempsurf = SDL_Load ("gfx/lolsurfacea.bmp");
SurfaceA = SDL_DisplayFormat (tempsurf);
SDL_FreeSurface (tempsurf);

This is where my main screen surface is a hardware surface, and I believe this process should make the SurfaceA one as well. But, the performance benefit does not seem to be there for me. Also, color-keying removing a lot of transparent color pixels out of my surfaces each frame seems to be very slow still; slower than drawing another whole 320x240 image per frame. Is this normal or do you suspect something is wrong?

 

[paeryn]

Right, in order they were posted:
M-.-n,
Edit: From what I can gather, SDL_VIDEOEXPOSE is supposed to be posted by the video driver when an underlying window manager (or such) notifies SDL that the on-screen display has been altered outside of the application (like when a window is raised or lowered or you have a GL window.) None of these cases happen on the GP2X, and the only drivers that post such events are Quartz (which only uses it for coming out of sleep mode) and x11 (which posts when using GL based windows).
So basically you should never be posting it yourself, it's there for SDL to notify you that the screen needs re-drawing. As to why you're not seeing it in your event loop after you've posted it I don't know because there's absolutely no code outside those mentioned above that post expose events, and no code at all that acts on them.
Heump,
The current implementation of double buffering relies on having a surface that is twice as high as requested and flipping the start address of the bitmap between the top and halfway down. Also the screen bitmap is special in that it always resides at the start of the gfx memory and cannot be freed. {sings="Smooth Criminal"} ...Annie, are you OK
You OK
Are you OK, Annie
Annie, are you OK
You OK
Are you OK, Annie...{/sings}
It would be quite easy to allow you to use two arbitary surfaces, but there's no support for having the stride of a surface be anything other than what SDL decides is optimal for itself.
I've started on modifications to allow you to specify custom parameters for just this reason (I've got some ideas that require non-standard surfaces too ) but it may be a while before it's ready - as if all the other things going on around me aren't enough of a distraction I've just taken in a new kitten ^_^
Epicenter,
Why do you want such a high fps? I don't know about the new screen, but the original is only spec'ed up to 90Hz. LCD's don't work very well if you run them too fast and nor do TV's. Also the faster you run the screen the higher it's memory bandwidth usage which means the blitter gets less.
The only times the blitter doesn't work fast is if you try feeding it blits faster than it can process them, or there's not enough DMA bandwidth to satisfy it. The method you're using to get HW surfaces is the correct way, you're not SDL_Lock()ing either the screen or the blitted surfaces are you? Attempting to use the blitter with either surface Locked incurs a huge penalty.
Colour keying should, if anything, make the blit faster as it has one less memory write for each transparent pixel. As far as I'm aware there's no penalty for enabling it even if none of the pixels are masked out.
If you can send me your blitting code I'll see if I can spot what's causing SDL to go slow.
Oh, just in-case, when you refer to software surfaces are you just switching the screen to software because the screen is always created as a hardware surface.

 

[Epicenter]

I'd like >100FPS whenever possible as I utilize very, very fast image scrolling at times, and jumping >3px per frame seems to cause the movement to feel very choppy and nauseating. So, I try to stay at 2px/frame or lower scrollrate-- and at 100 FPS that allows up to 200px/sec scrollrates with excellent smoothness. Also, I always like to have the absolute maximum of headroom I can for adding potentially stressful bits to the same task later .. room to grow.

It's not really 'slow', I just can't seem to find the benfit most of the time. Although I can't really see any performance gain from the MMU hack, which really seems like it should be there-- as all access to the memory allocated as 'VRAM' should be in the upper 32mb (16mb build)-- which that code accelerates ARM920T access to. Yet, no gains. Peculiar, huh?

 

[Gadget]

Hi paeryn, Just wondering where I can get the latest source code from... tracked back a few pages until I found a link, but I think it was for the non-FW2.0 version (with flickering).... anways... want to compile it on my new Slackware DevBox, but can't find the source code. Thanks in advance.

I have had this problem as well. Does anyone have a copy of the lib for FW Version 2.0?

Thanks

 

[gfoot]

I just got the source via Subversion using the link paeryn posted - I had to modify it slightly though, see below. Maybe this is the link you already found anyway though.

gfoot@glost ~/gp2x/open2x$ svn checkout https://svn.sourceforge.net/svnroot/open2x/trunk/libs/SDL-1.2.9 libs/SDL-1.2.9

i.e. add "trunk" in the middle of the path - I also added a target directory at the end, not sure if it's necessary though.

 

[sparr]

Just wanted to cross-post here, SDL_WarpMouse still doesnt work for me in the latest SVN (as of two days ago). I edit it to always use ...PrivateMouseMotion instead of ...WarpCursor (sorry for imprecise names, dont have the source in front of me right now) and it then works, but I lose some of the nicer features of WarpCursor.

 

[Zenzuke]

I'd like >100FPS whenever possible as I utilize very, very fast image scrolling at times, and jumping >3px per frame seems to cause the movement to feel very choppy and nauseating. So, I try to stay at 2px/frame or lower scrollrate-- ...

In that extreme case I would pre-process the image to appear motion blurred. Some perfectly sharp object moving at those speeds (moreso if it's small) is going to appear jumpy if it was not originally created with this extreme speed in mind, even at 200 fps.

 

[Drag]

For this one game I'm doing, I don't use any of the blitting features of sdl, I just manually do everything pixel-by-pixel. Even though this SDL is hardware accelerated, would there be a significant speed increase if I just wrote everything directly to the framebuffer, instead of using surfaces?

 

[paeryn]

For this one game I'm doing, I don't use any of the blitting features of sdl, I just manually do everything pixel-by-pixel. Even though this SDL is hardware accelerated, would there be a significant speed increase if I just wrote everything directly to the framebuffer, instead of using surfaces?

If you're using squidge's MMU thingy to enable caching of upper memory then you'll get a bit of speed increase - to all intents and purposes the display surface is a regular HWSURFACE so you'd save on the blit.
If you're not using the MMU thing then you'd be better off creating one SWSURFACE and do all your pixel-level stuff on that and blit it to the display when you've finished the frame as HWSURFACES are slower to read/write to than SW.

 

[paxl13]

A general quesiton of SDL.

If I'm currently writing a TileMap Engine/Routine. I need to load my Tiles onto a surface and then bilt upon what I need to do...

So, Can somone explain me to do a IMG_Load("...") to a HWSurface... Also, Why can't I get rid of the Cursor in the screen event after having called
SDL_ShowCursor(0);

Also, can somone explain me what is the best between SW and HW surface, also, do SWsurf are in the linux memory and HW one in the 32 upper megs ??

Thank for yours answers

 

[Gadget]

A general quesiton of SDL.

If I'm currently writing a TileMap Engine/Routine. I need to load my Tiles onto a surface and then bilt upon what I need to do...

So, Can somone explain me to do a IMG_Load("...") to a HWSurface... Also, Why can't I get rid of the Cursor in the screen event after having called
SDL_ShowCursor(0);

Also, can somone explain me what is the best between SW and HW surface, also, do SWsurf are in the linux memory and HW one in the 32 upper megs ??

Thank for yours answers

Hey,

To sort your cursor out:-

Run SDL_ShowCursor(0); after the init of SDL:-

SDL_Init(SDL_INIT_JOYSTICK | SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_TIMER);
	screen = SDL_SetVideoMode( 320, 240, 16, SDL_SWSURFACE | SDL_DOUBLEBUF);

	SDL_Surface *tempSurface = SDL_CreateRGBSurface(SDL_SWSURFACE, 320, 240, 16, 0, 0, 0, 0);
	clear = SDL_DisplayFormat(tempSurface);
	SDL_FreeSurface(tempSurface);

	SDL_Surface *tempSurface1 = SDL_CreateRGBSurface(SDL_SWSURFACE, 320, 60, 16, 0, 0, 0, 0);
	TempScroll = SDL_DisplayFormat(tempSurface1);
	SDL_FreeSurface(tempSurface1);
	SDL_SetColorKey(TempScroll, SDL_SRCCOLORKEY, SDL_MapRGB(TempScroll->format, 0, 0, 0) );

	#ifdef Windows
		SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 0,0,0));
	#else
		ClearScreen((short unsigned*)screen->pixels);
	#endif

	SDL_WM_SetCaption( WINDOW_TITLE, 0 );
	SDL_JoystickOpen(0);

	SDL_ShowCursor(SDL_DISABLE);

This is how you load onto a HW surface:-

	SDL_Surface* TempSurface1 = SDL_LoadImage (or whatever it's called, I forget as I don't use it)
	SDL_Surface* TheSurface = SDL_DisplayFormat(TempSurface1);
	SDL_FreeSurface(TempSurface1);
	TempSurface1 = NULL;

HW surfaces are faster for blitting, but slower for per pixel manipulation. There do seem to be issues relating to VBlank timing and the HW SDL. I have never got it working 100% on my MKII (get occasional tears)

I always assumed the HW surfaces must be loaded into the upper 32Mb, as far as I know there isn't anywhere else to load them to, ie. no dedicated Video RAM as such. Someone please tell me if I am wrong =D

 

[paxl13]

I love those forum ! .. Thank for the answer

paxl

 

[Mudi]

One quick question... is the version of SDL on the Open2X svn the 16MB version or the old 5MB version? If it is the old, where can I get the 16MB version sources?

 

[paeryn]

One quick question... is the version of SDL on the Open2X svn the 16MB version or the old 5MB version? If it is the old, where can I get the 16MB version sources?

Erm, still the 5MB. I'm really sorry, haven't been programming for ages. I'll try and finish the memory manager off and update the SVN as soon as I can. And it'll be 21MB (at least), the bit that needs writing is to allow access to all the upper memory (99% done) and user configuration of which memory ranges SDL is/isn't allowed to use (0% done.) Plus it really needs some user-readable stats on memory usage.

 

[joyrider]

Hi,

i just got my tv out cable and was testing it with my games that are using your libs. For some reason part of the screen is cut off. It's on the right side it seems that there like 30 or so pixels that missing. (due to the scalar perhaps ?) I've tried everything on my pc program that i use but it seems the image is given like thise from the gp2x (since moving the picture to the left doesn't affect it). Also when i quit my game the tv out briefly shows the correct screen size before returning to the menu. Is this a known issue ? is there a way around it ? cause i only bought the tv out cable to create video's of my gp2x games on the pc.

Also am i supposed to add certain code to my games for it to work correctly ? i didn't use any special code and just ran the game on tv out without modifications.

Here's a screen taken using fbgrab from the frame buffer when running in tv out, it shows the screen correctly

this screen shows what i see on my 2 tv's & pc as u can see i already tried moving the picture to the left without result and composite / svideo makes no change (black border)

the physical screen size is 720x288

btw thanks for ure hardwork already i donated (5 euro) to you since i've used your libaries in all my four games

 

[efegea]

I have a problem with the libs compiled from SVN.

I use this function that flips the sprites

SDL_Surface* flip(SDL_Surface *src){
	SDL_Surface *temp;
	Uint32 rmask, gmask, bmask, amask;

#if SDL_BYTEORDER == SDL_BIG_ENDIAN
	rmask = 0xff000000;
	gmask = 0x00ff0000;
	bmask = 0x0000ff00;
	amask = 0x000000ff;
#else
	rmask = 0x000000ff;
	gmask = 0x0000ff00;
	bmask = 0x00ff0000;
	amask = 0xff000000;
#endif
	temp = SDL_CreateRGBSurface(SDL_HWSURFACE, src->w, src->h, SCREEN_DEPTH, rmask, gmask, bmask, 0);
	int i;
	
	for(i=0;i<src->w;i++){
		SDL_Rect srcRect = { src->w-i-1, 0, 1, src->h };
		SDL_Rect dstRect = { i, 0, 0, 0 };
		SDL_BlitSurface(src,&srcRect,temp,&dstRect);
	}
	return temp;
	SDL_FreeSurface(temp);temp=0;
	
}

But the sprites flipped by this function, but not all, get the transparency (the colorkey) corrupted. On the pc works without problems.

 

[GP2X_Coder]

I have a problem with the libs compiled from SVN.

I use this function that flips the sprites

SDL_Surface* flip(SDL_Surface *src){
	SDL_Surface *temp;
	Uint32 rmask, gmask, bmask, amask;

#if SDL_BYTEORDER == SDL_BIG_ENDIAN
	rmask = 0xff000000;
	gmask = 0x00ff0000;
	bmask = 0x0000ff00;
	amask = 0x000000ff;
#else
	rmask = 0x000000ff;
	gmask = 0x0000ff00;
	bmask = 0x00ff0000;
	amask = 0xff000000;
#endif
	temp = SDL_CreateRGBSurface(SDL_HWSURFACE, src->w, src->h, SCREEN_DEPTH, rmask, gmask, bmask, 0);
	int i;
	
	for(i=0;i<src->w;i++){
		SDL_Rect srcRect = { src->w-i-1, 0, 1, src->h };
		SDL_Rect dstRect = { i, 0, 0, 0 };
		SDL_BlitSurface(src,&srcRect,temp,&dstRect);
	}
	return temp;
	SDL_FreeSurface(temp);temp=0;
	
}

But the sprites flipped by this function, but not all, get the transparency (the colorkey) corrupted. On the pc works without problems.

There is an internal bug with SDL_CreateRGBSurface that only changes the color key pixel values the fastest way to fix this it to find out what the new color is that SDL_CreateRGBSurface change the color key to and just reset it with SDL_SetColorKey. Hope this helps out. I just took of screen shot of my image after it was flipped and got the new value buy viewing it in photoshop and reset the values that way works perfect.