Optimizing tilerendering

[Kingdom of Fish]

I'm curious if there are any simple optimizations to rendering tiles in SFML2 that you really need to know about.

I was thinking about caching parts of the screen in larger images instead of drawing each tile every frame. Is this even worth it? SFML2 seems to be pretty fast with tiles anyway and I would hate to hack together a bunch of code and figure out it was just a big waste of time and clever thinking.

[panithadrum]

It really depends on what number of tiles you are drawing in a frame. If you have it optimized to only draw what you see, I think that you don't need to do anything more.

You can always create some maps and check out their frame rate.

[PeterWelzien]

If you have it optimized to only draw what you see, I think that you don't need to do anything more.

Does SFML draw sprites that are completely off screen? Do I have to do my own frustum culling?

[Laurent]

I'm curious if there are any simple optimizations to rendering tiles in SFML2 that you really need to know about.

No, basically SFML already optimizes things a lot internally.
The only thing that *may* give better performances is to group sprites by image for drawing.

Does SFML draw sprites that are completely off screen? Do I have to do my own frustum culling?

Yes, SFML draws everything so if you don't want to draw off-screen entities you must filter them out manually.

[Gibgezr]

Interesting. I've coded a lot of 2d tile-based scrolling engines over the years, and no matter what the API, always found it best to implement the classic approach if I needed sub-tile (i.e pixel) scrolling:

1) Create an offscreen buffer that is two tiles wider/higher than the display area.
2) predraw the buffer ONCE, using the individual tiles
3)in the render loop, do one large blit, the size of the display, from the buffer, using scroll offsets to position the source rectangle for the blit.
4)if the player has scrolled more than one tile in any direction, update the offscreen buffer by resetting the scroll offsets and either:
 a) shuffling rows or columns of tiles on the offscreen buffer (blits with same source and destination that do not overlap), then drawing in the new row or column of tiles as individual tile blits, or
 b)do one large blit from the offscreen buffer to a second offscreen buffer, shifted by one row/column, that becomes the new offscreen buffer for our tilemap, and then fill in the new row/column with individual tile blits.

The benefit can be seen by supposing you have a 40x30 tile display: for many frames, your tiled background goes from 1200+ blits down to ONE blit, and even when the scrolling reaches the buffer edge and has to update ala #4, it goes down to either 33 or 43 blits for that one frame (using the ping=ponging offscreen buffers method, or 63 or 83 for the single buffer method). Yes, some of those blits are larger in area than the individual tile blits that make up updating a 1200+ blit screen, but in most APIs, doing one large blit is about the same speed as doing one small blit.

I can't imagine what optimizations SFML has that make the above not true anymore; can someone enlighten me? Now, I can see possibly in SFML 2 that Views might be used as part of the above 4 steps, but I don't see how that changes the steps. I'm quite willing to learn new tricks, though!

Also, something close to the above is beneficial even if you are doing whole-tile scrolling, but the offscreen buffer need not be any bigger than the intended display area, and it gets updated on every scroll. Still better than doing 1200 blits.

[vidjogamer]

Gibgezr thank you that is genius! I cant wait to get that implemented. =)

[l0calh05t]

why not use the wrapping texture capability of opengl? no need to "shuffle" all rows. just update a single row/column and your texcoords. should be even faster.

[Gibgezr]

why not use the wrapping texture capability of opengl? no need to "shuffle" all rows. just update a single row/column and your texcoords. should be even faster.

Not sure how to implement that, as adjusting texcoords adjusts the coords across the entire buffer...ahhh, I see, shift the texcoords, then update the rest of the buffer? How do I get access to the texcoords of an sfml sprite object?

For me personally, it wouldn't be worth the hassle writing that, especially if you are using sfml; the whole point of sfml for 2D graphics is to use sfml sprites and the nice, clean OO interfaces. If I was going to muck around with texcoords, I'd probably go straight to OpenGL and forgo sfml.

[l0calh05t]

why not use the wrapping texture capability of opengl? no need to "shuffle" all rows. just update a single row/column and your texcoords. should be even faster.

Not sure how to implement that, as adjusting texcoords adjusts the coords across the entire buffer...ahhh, I see, shift the texcoords, then update the rest of the buffer? How do I get access to the texcoords of an sfml sprite object?

For me personally, it wouldn't be worth the hassle writing that, especially if you are using sfml; the whole point of sfml for 2D graphics is to use sfml sprites and the nice, clean OO interfaces. If I was going to muck around with texcoords, I'd probably go straight to OpenGL and forgo sfml.

Dunno really, I use OpenGL directly most of the time anyways. I think Get/SetSubRect might be used for this, although it depends on which wrapping mode SFML uses.