0
\$\begingroup\$

I'm working on the base engine of my game right now, specifically converting a text file into a level on-screen. As a 2D platformer, each level has an array of rectangles that can be drawn to the screen. Obviously I don't want to draw all these bad boys to the screen every frame, as that would slow everything down. I've thought up two solutions to this problem myself:

  • Draw these rects to a separate texture (I'm using SDL2, by the way) and paint a specific portion to the screen every frame

  • Choose which rects to draw every frame based on the player's position by checking collision between every rect and an imaginary moving "chunk"

My question: Which of these two processes, if either, would be less of a burden to the cpu? If neither seem reasonable, what other alternatives are there?

\$\endgroup\$
1
  • \$\begingroup\$ You should only draw what the camera can see. Everything else would be a waste of time. Basically, any rects within the camera x + camera width and within the camera y + camera height should be drawn. \$\endgroup\$
    – TorbenC
    May 15 '14 at 6:08
1
\$\begingroup\$

I found that with plain SDL2, even using the accelerated renderer, that redrawing all the tiles every frame was a huge bottleneck. I would suggest drawing as much as you can to a static texture that you then draw using the camera's clipping rectangle. Now, I was drawing around 3600 tiles per frame (8x8 tiles at 640x360) on a relatively low-powered laptop, so your use case may not be a problem.

The best solution would probably be to dip into OpenGL and store all the tiles in a vertex buffer (or a grid of vertex buffers) and draw those instead. Advantage being that it would save memory and you wouldn't be constricted to using basically only one tile layer per texture.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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