Image Rotation, Sdl_gfx, Sprite Sheet, Or Opengl?

[YenningComity]

Hi, I am actually planning on making this game for the beagleboard, but hope to port to pandora (school project, making a full arcade game and cab)

I have hit a snag though. I am making an arena shmup and need to rotate my ships. The fastest is opengl, but if I understand correctly, I would have to implement all my graphics in opengl.

SDL does not natively handle image manipulation, but I can use SDL_gfx but it is slow. I could use it and store the rotated images in ram at the start of the level, but I am concerned this will eat up a lot of memory.

I could make sprite sheets, but this would be very, very time intensive. I am looking to have multiple ships that would be able to rotate 360 degrees. I am not sure how many degrees I can move with each input before it is no longer smooth.

What do you guys recommend?

 

[fishybawb]

The fastest is opengl, but if I understand correctly, I would have to implement all my graphics in opengl.

Doing all the graphics in OpenGL might not be all that difficult

 

[YenningComity]

It still will be much more complicated, but those tutorials are might helpful thanks for pointing them out mate.

 

[yosh64]

hey

Why don't ya just write ya own functions for drawing pixels? this is what I do . Just learn how to rotate the pixels and ya should be right to go, ya might wanna checkout the Sin & Cos: The Programmer's Pals! article.

Otherwise ya might wanna checkout allegro, I think it supports all those things, although ya might have to port it to the Pandora yaself if noone else is doing it.

But yea, drawing pixels to the screen can be darn slow, I mean when redrawing every pixel at really high resolutions, although this wouldn't be an issue on the pandora.

cyas

 

[fusion_power]

Hi, I am actually planning on making this game for the beagleboard, but hope to port to pandora (school project, making a full arcade game and cab)

I have hit a snag though. I am making an arena shmup and need to rotate my ships. The fastest is opengl, but if I understand correctly, I would have to implement all my graphics in opengl.

SDL does not natively handle image manipulation, but I can use SDL_gfx but it is slow. I could use it and store the rotated images in ram at the start of the level, but I am concerned this will eat up a lot of memory.

I could make sprite sheets, but this would be very, very time intensive. I am looking to have multiple ships that would be able to rotate 360 degrees. I am not sure how many degrees I can move with each input before it is no longer smooth.

What do you guys recommend?

I would design the Ship (and other Graphics) with Blender and render it in every needed position. So you have automaticly generated your sprite Sheets for rotation and other movements. This way you can use fast pre-rendered 2D animations instead of real-time calculated stuff.
I think this way you don't need opengel for your engine because everything is 2D.

 

[hobbyman II]

fusion power is right, any software rotation is going to be far slower than pre-drawn images,in any game I write I use as much pre calculation/rendering as possible, 32 images is a good number for smooth rotation, 64 if you want it really smooth, remember that rotating 1 degree at a time is going to result in a requirement for 360 fps if the ship is to rotate at a geriatric once per second, you can work out how many images you need just by dividing 360 degrees by your fps that tells you how many degrees you need per second for smooth once per second rotation

eg 60fps

360/60 = 3 << that's how many degrees you need to turn per frame to rotate once per sec

so to draw a new image every frame you just need 60 of them, for 2 revs per second you need 30, 3 revs=20 etc

 

[YenningComity]

For the sake of simplicity I want to just use sprite sheets. The gimp has an automated way for doing images, at least that is what I have been told.

The trouble is I do not know how much ram all these images will take up. If I have 20 different entities that can rotate and I do 64 images for smooth rotation, then I have 1280 images. My current setup calls for a 720p (1280 x 768) monitor. I have some concerns about running out of ram going this route.

P.S. I really want to use a beagleboard so it gives me an excuse to buy a pandora. On the other hand the 128mb of ram limitation is what makes it difficult. The arcade version will need to load everything into a ramdisk at boot, as to avoid load screens.

 

[Zoxc]

OpenVG or OpenGL ES is the way to go. OpenVG would probably be the easiest and you could easily accelerate other stuff too

 

[hobbyman II]

all images carried in memory for blitting (sprite use) will be raw, you might have loaded a JPG but once its in ram it will just effectively be a bitmap so you can work out how much memory it will use by the bitdepth (16-24-32?) of the screen....sooo..

for 16 bit colour

2 Bytes per pixel

so for a 32x32 image

1024x2=2048 (2K)

just over 500 images per mb, there are tricks you can use though if you think the memory usage is too high, one is to just use the first 90deg of the rotation rendered, then flip vertically or horizontally in software to get the rest, rotation is slow, but flipping is just drawing the image backwards and relatively fast in software.

another trick is to use a symmetrical ship with the nose/tail a unique colour you can swap over at 180 degrees, or use a flying saucer for the hero, you need to get inventive.

I used to post help in another programming forum and the most constant complaint was something like, "my game goes fast enough when testing, but when I put in all 3000 aliens it slows to a crawl", the point is not to have a game with 3000 aliens in it, what you need is one where the same 30 aliens keep popping up 100 times during the level, far less stress on the system, it`s same with all games programming, games are all smoke and mirrors, it just has to LOOK like a huge raft of smoothly attacking aliens or whatever.

 

[YenningComity]

Thank you for the input. I hadn't thought of flipping images. The question I have though is how big the performance hit for doing that is as opposed to using a sprite sheet? My preliminary design doc is calling for 10 enemies on screen at anyone time *there will be more, but not in the cameras view*.

My goal right now is working out my design document. Reading and playing around with tutorials. Over Christmas break I will be putting a one stage prototype together, and will then take it to the school's gaming club to beta test it and tell me how much it sucks. Once I get it to a point they like I will be planning out the engine and what not.

Has anyone tried the OpenVG Tiger demo? It is slow as snot. Reading through there documentation it seems like it isn't ready for the prime time yet.

 

[multiplex]

It sounds like you're worrying about nothing. I suspect that

1. The CPU will be plenty fast enough to rotate a couple dozen sprites each frame with a reasonable algorithm, and
2. there will be plenty memory to store the sprites pre-rotated.

As long as your code is reasonably modular, I think you'd get much more done if you just wrote it whichever way is easiest, and deal with performance problems by profiling them when you get them. Even switching to OpenGL later shouldn't be too hard if you take care not to litter your code with direct drawing calls.

If you do want to exploit the hardware as much as possible, using a OpenGL based sprite engine is the way to go (Or possibly OpenVG, which I don't know much about.). I'm not sure what you mean by having to do all your graphics in OpenGL. It is possible to do, say, the main menu in normal SDL or whatever, and just switch to OpenGL in the main game. It should also be fairly simple to overlay any other type of text and graphics you have by drawing them on a texture and rendering them just as normal sprites.

 

[senquack]

IIRC, from looking at the source code a while ago, the rotozoomer in SDL_gfx uses floating point. That would be your problem. A simple conversion to integer math and lookup tables would fix this completely, as would pre-rendered sequences of the rotated sprites.

 

[Quiest]

I used to rotate the image at loading and store them in memory.
Depends on how big your images are and how many, but don't think
it will matter that much...

 

[yosh64]

hey

I thought the Pandora supported floating point numbers?

cyas

 

[kevcal]

The allegro rotate is very fast - uses fixed point...
Be nice if someone with a pandora ported allegro... especially if they then ported allegro-gl.

 

[sindbad]

I thought the Pandora supported floating point numbers?
It does. It has a decently fast fpu (VFlite i think) for backwards compatibility and ease of use and a monster of a pipelined fpu called NEON, which requires some reworking of code.

 

[YenningComity]

As far as I know the only thinking lacking floating point on pandora is the GPU as OpenGL ES only uses Fix Point.

Why this is a concern to me is if my game is 50mb in size, then I have 128MB of ram - 50MB or in other words 78MB. I have no idea as to how large the game will be because it will depend on how many people I can attract on campus to do sound, music, art, etc for this project. So right now I am looking at worst case scenarios.

 

[skeezix]

50mb? Most assets will be 'on disk' (SD, etc) and not in RAM.

ie: When you load up a level, load up the needed assets (audio, sprite sheets, level maps, etc) and when level ends, unload that stuff. (Or wiser, when the next level is loading unmload the no-longer-needed things and load up the now-needed things, this saves reloading things you previously loaded.)

ie: You coudl have 3GB of music on SD, and who cars? You only need a few MB of it in RAM at a time.

Likewise with sprites .. you don't need to load all of them, just the ones you need for this level (or could load more in as you go..)

Its all ab out trade offs -- if you can get away with pre-rendering it all, you throw memory at it; if you can't prerender or don't want to you throw CPU at it during runtime. Its up to you, your target system specs, etc. You might be able to code both really, as this is all in the loader-preparation phase of the game, not the real meat of it.. so you could use #ifdef (say) to have sprite-sheet-load, or have a load-and-calculate-rotations-before-level-begins mode, or even a calculate-as-level-runs mode.

The pandora will be fast, so you might be able to get it in real time, depending on the size of sprites and scene complexity. (Parallax layers? really big sprites?)

If you're talking 32x32 sprites and a few dozen, don't sweat it!

On much wimpier machines I've had a hundred rotated sprites all moving, eith _Script_ AI's running on each, at 30fps.

jeff

 

[Xmas]

As far as I know the only thinking lacking floating point on pandora is the GPU as OpenGL ES only uses Fix Point.

No, only OpenGL ES 1.x Common Lite profile is limited to fixed point data. The GPU in Pandora is perfectly capable of handling floating point data (and float is in fact preferable over 16.16 fixed point).

 

[fusion_power]

I'm sure, the 128MB RAM of the Pandora are more than enough for a nice 2D Sprite-Based Game. How much RAM had the MegaDrive or the SNES? (unfair, I know ^_^ )
I'm not sure how much work this would be but AFAIK you can reduce the Memory-usage by using 8-Bit Graphics...or even more if your graphics are all converted into pure code...but I don't know too much about this kind of stuff. ^^"""""