GP2X Help With Image Format


Shikaku

ROFL THE WORD PENIS IS HILARIOUS!
Joined
Jan 11, 2006
Messages
2,839
Location
USA... I feel lonely, not that many people from US
Website
Visit site
I'm thinking about starting a game.

However, I have a slight dilemma on what would be the best image format to use and blitting/sprite drawing method for what I want to do with this game. What I am working with and what I want to be able to do with it is thus: the main sprites that move around and do things will be very limited in color palette size, but numerous in frames (thousands), and are required to be able to change its palette colors on the fly. I am thinking about using SDL because of the cross compatability and ease of use, but it might be too slow for the GP2X...

I'm not sure what else I would need to explain, since I have never coded a game.

Thanks in advance!

Edit: crap wrong forums *smacks head*
 
You do not need to use ASM to draw sprites on the GP2X, the ASM you refer to is probably not for the ARM9 either. And it needs to be specific to the GP2X graphics hardware to work properly anyway.

For maximum speed you will want to utilize the Gp2X's 2D blitter for accelerated drawing functionality, accelerated color keying (transparent color application), accelerated filling, etc. I use SDL and Paeryn's "HWSDL" (hardware accelerated SDL) designed for the GP2X, and it works superbly. Even with an enormous amount of sprites and large images onscreen I have yet to encounter a speed problem.

It's all about writing efficient code; SDL is not slow if you use it effectively. Problem is, a lot of homebrew games for the GP2X appear to have been written very inefficiently in SDL, and run quite slowly, giving a very poor impression of what the GP2X can REALLY do with its hardware and SDL.

That said, I use PNG. Widest compatibility, a nice array of supported features such as alpha channels, very small.
 
My preferred image format is raw R5G6B5 that I just block read direct into memory, and then I can use the blitter on it immediately. All my image processing is done off-line before the GP2X even gets a look at it.
 
That's all well and good if you don't have that much in the way of raw graphics content, as it will eat up tons of disk space like that. I prefer to use PNG and then convert it to the display format during a loading sequence before doing anything demanding.
 
Epicenter posted on May 25 2006 at 12:05 AM said:
It's all about writing efficient code; SDL is not slow if you use it effectively. Problem is, a lot of homebrew games for the GP2X appear to have been written very inefficiently in SDL, and run quite slowly, giving a very poor impression of what the GP2X can REALLY do with its hardware and SDL.


its not so much about writing effcient code.. well, obviously it is, but its not that people are being lazy. Its just not having a proper understanding of how sdl, the gp2x sdl particulary, works. I mean I just learned earlier thanks to paeryns tip off that when I load an image it becomes a software surface and not a hardware one. That knowledge has made a HUGE difference in the way I write some of my code. It wasnt that I wrote bad code before - all my stuff was fine for the pc and other sdk's (darksdk, dx, opengl, etc) - it just wasnt the "right" code for this implementation of sdl (and in most cases, sdl in general)

What we need is a set of DETAILED articles and tutorials, in the wiki or whatever, explaining all the ins-and-outs that people need to know. At the moment if you search you may find "to do task A, write this code" but its very rare to find "to do task A, write this code. We do it like this because ... " and that makes it very easy to trip up when you are writing your code based on past, now false, presumptions :p
 
Last edited by a moderator:
Back
Top