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
    Commented May 15, 2014 at 6:08

1 Answer 1

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\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .