Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I was working on J2ME games in the past, when draw a large backgroud, I always use the Carmack 2d scroll algorithm, keep a image buffer a little larger than device screen, draw the changed small tiles to this buffer, then draw the buffer to device screen. This can reduce the number of times to call drawImage().

Now we need to prepare for opengles 2D games for iphone and android. I am new about opengl, but i have try to read some engine code and keep learning opengl. There isn't much problem about 2d graphic system, except the tile buffer, there is no image buffer any more, so what size of the tile should i use? The screen size maybe 800*480, if i keep the 32*32 tile, i need to draw about 400 tiles per frame, will this be ok?

share|improve this question
add comment

2 Answers

When you are drawing using raw OpenGL ES, you will be drawing your tiles as pairs of triangles. Imagine one of your tiles, now draw a line from any corner to the opposite -- this is effectively what you will be doing. So for each tile, you will draw 2 triangles each frame. 400 tiles * 2 = 800 per frame, or 800 * 60 = 48,000 per second, which is a very small amount considering most modern phones can handle millions of triangles per second.

There are lots of optimizations you can make as well to avoid changing the current texture binding more often than you need to, and drawing multiple objects in one GL call. I'll be happy to elaborate if you want, but your original question seems concerned with performance, and I don't think you need to worry about that at all.

I have a font rendering system that renders each character in much the same way you would draw your tiles. I look up the coordinates of the particular character in a bitmap font file and draw it as a quad (two triangles in "GL_TRIANGLE_STRIP" mode.) For efficiency, I add all of the characters that I will draw into one large array and pass that to the GPU in one single command. I can render thousands of characters per frame, and that's being alpha blended on top of my game. This is all consistently done at 60 FPS. So I think you'll be just fine :)

share|improve this answer
    
Thanks a lot, maybe i shouldn't worry about the render performance, it is really good news, in J2ME games, this is always a big problem. –  mario May 19 '11 at 11:07
add comment

As stephelton says, OpenGL hardware is pretty fast, so maybe you don't need to worry too much about tiling and scrolling. Just re-draw everything each frame and see if it's fast enough.

Now, if you really want/need to do Carmack-style scrolling/buffering (in case your background is a complex scene with many bells and whistles), I suggest you look into Frame Buffer Objects (google for 'opengl fbo'), which allows you to render to memory (i.e. a texture). That texture (or a portion of it) can then be drawn pretty fast to the screen each frame, with "sprites" added on top.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.