I have run into a wall using SDL for graphics development. Currently, I setup my video mode to use 16 bits per pixel, and double buffering. I convert all of my input images to the display format to speed things up. Using Hardware or software memory for my video mode does not seem to make a difference in performance. Psp SDL does not seem to support creating SDL_Surfaces in video memory, so that is a moot point. Point being, I think I have the images and video mode setup such that it is rending things as fast as SDL will allow.
I draw my complete background to the screen each loop though. Then I draw my sprites atop it. So when I draw 1.25 or so full screen per loop, the game speed is great. When I draw 1.5 to 2 full screens of graphics per loop, the game speed decreases noticeably. My question is as follows:
Will I get a speed increase in blitting images to the screen if I use pspGL or even the sce GU functions to render my graphics? I have done some research, and it seems possible to apply your image data to a polygon as a texture, thus allowing you to draw 2D images using the GU functions. Would this be faster?
Bear in mind all I am doing right now is basically calling the SDL_BlitImage function. I pass it the image I want to draw, and the pointer to my display. Nothing fancy or overly tricky, but I figure the PSP should be able to handle at least 2 full frames of data being copied to the video buffer in 1 loop without slowing down. Would using 3D representations of my graphics and the GU help me accomplish this speed?
I assume I would just create the 3D representations of my graphics, and blit them to the video buffer using the SCE GU function. I am not currently doing rotations, scaling, or alpha blending. I do a little blitting with some images that use a transparent pixel color, but I don’t think that is really what’s slowing things down so much. Mostly I just do basic blitting to the back buffer. What do you think? Will I get a speed increase given this scenario?
Garak
2D/3D Graphics Speed
The fact is - in my opinion - SDL is really far from the way any system handles graphics. Then it's normal, optimizations are really hard to do.
In my opinion, if you really have speed problems, you should give up SDL or anything non-native (except if really optimized) and work directly with PSP hardware (what it's done for), or write yourself SDL-like functions that wraps to the PSP hardware, so that the transition is smooth. With a native interface, you will effectively gain a lot speed, especially in 2D.
I don't know what kind of gfx your game consists of, anyways, drawing a tilemap or a large sprite list with SDL is the best thing to kill completely your app speed.
And as you said, always use the same bit-depth for any image and the backbuffer. SDL implicitly does color conversion, which is already slow on a 3 GHz Pentium IV-based computer, so don't expect much of your 222 MHz PSP ^^ (however if you write yourself optimized color conversion, like 8-bit to 16-bit, it will run sweet).
In my opinion, if you really have speed problems, you should give up SDL or anything non-native (except if really optimized) and work directly with PSP hardware (what it's done for), or write yourself SDL-like functions that wraps to the PSP hardware, so that the transition is smooth. With a native interface, you will effectively gain a lot speed, especially in 2D.
I don't know what kind of gfx your game consists of, anyways, drawing a tilemap or a large sprite list with SDL is the best thing to kill completely your app speed.
And as you said, always use the same bit-depth for any image and the backbuffer. SDL implicitly does color conversion, which is already slow on a 3 GHz Pentium IV-based computer, so don't expect much of your 222 MHz PSP ^^ (however if you write yourself optimized color conversion, like 8-bit to 16-bit, it will run sweet).
Sorry for my bad english
Oldschool library for PSP - PC version released
Oldschool library for PSP - PC version released