Optimizing Random Generated Terrain Rendering for a Side Scrolling Game

Started by
2 comments, last by Emmet Cooper 10 years, 1 month ago

So we got started on making a sandbox game. All went well. We got our terrain generation classes working and rendering. It worked perfectly fine. But I'm looking for ways to optimize it. Apparently, the terrain generation code doesn't have the so-called "Batching" where the whole world is ,if I'm right, being rendered and handled by the core engine as a single data or entity. Each and every tile is being rendered individually in every game loop. Which is, in my opinion, is god awfully horrible. Unfortunately, we still haven't found a way to fix this. I'm not looking for exact codes to do this rather I'm looking for tips and techniques to achieve this. We're relatively new to game programming. I just thought that I needed to stress that part out.

Also, we're using "IDs" for each tile of that the terrain generation uses. At the meantime, we are using 6 IDs just to keep it simple. No liquids yet. The coders of the terrain generation used std::map for the tile/item ids of the game. Because, we're also hoping to include a mod support using lua in the near future. We're using SFML 2.1.

How can we improve this terrain generation bug? Can anyone give any tips, technique or maybe even just a starting point to how we can fix this?

Also, can anyone give us a starting point to how we can serialize the world so we can save it into a file(Save/Load) or for use with sqlite? We tried reading minetest's code. Unfortunately, we aren't really that good at reverse engineering an existing code. So we got a little confuse on the most part. Sorry if I may sound like a complete noob. I just wanted to get this issues done and fixed asap.

Thanks alot. :)

Advertisement

You may not NEED to optimize the code. Be sure that you do and measure the cost of your rendering function before you start tinkering with it. If you decide some optimizations are necessary, measure again after you're done to be sure you didn't make the problem worse! :)

You only see one screen's worth of stuff so rendering the entire world is a waste. Let's say you have X and Y coordinates for your player. You can calculate a rectangle of world coordinates that you should draw by drawing everything within 30 tiles of your player (or whatever number works for your game). Subtract 30 * tileWidth from player.x and add 30 * tileHeight to player.x to get your minX and maxX values. Do the same for your min/max Y's and then only draw the tiles and enemies that are within that range.

Here's a post that explains that idea in a little more detail, along with some other tricks for reducing texture swapping costs.

http://stackoverflow.com/questions/9877123/xna-culling-performance-issue

- Eck

EckTech Games - Games and Unity Assets I'm working on
Still Flying - My GameDev journal
The Shilwulf Dynasty - Campaign notes for my Rogue Trader RPG

As far as serialization goes, it's just a matter of coming up with a logical file format. Since you're using SFML, have a look at the tutorials for user data streams:

http://www.sfml-dev.org/tutorials/2.1/system-stream.php

If you're saving your "world" it could be as simple as outputting your x and y coordinates along with the tile id into a text file one line at a time.

Loading it would be just the opposite. You just create one tile for each line you read in, and add that to your world.

There should be PLENTY of tutorials online about file i/o for whatever language you want.

- Eck

EckTech Games - Games and Unity Assets I'm working on
Still Flying - My GameDev journal
The Shilwulf Dynasty - Campaign notes for my Rogue Trader RPG

You may not NEED to optimize the code. Be sure that you do and measure the cost of your rendering function before you start tinkering with it. If you decide some optimizations are necessary, measure again after you're done to be sure you didn't make the problem worse! smile.png

You only see one screen's worth of stuff so rendering the entire world is a waste. Let's say you have X and Y coordinates for your player. You can calculate a rectangle of world coordinates that you should draw by drawing everything within 30 tiles of your player (or whatever number works for your game). Subtract 30 * tileWidth from player.x and add 30 * tileHeight to player.x to get your minX and maxX values. Do the same for your min/max Y's and then only draw the tiles and enemies that are within that range.

Here's a post that explains that idea in a little more detail, along with some other tricks for reducing texture swapping costs.

http://stackoverflow.com/questions/9877123/xna-culling-performance-issue

- Eck

As far as serialization goes, it's just a matter of coming up with a logical file format. Since you're using SFML, have a look at the tutorials for user data streams:

http://www.sfml-dev.org/tutorials/2.1/system-stream.php

If you're saving your "world" it could be as simple as outputting your x and y coordinates along with the tile id into a text file one line at a time.

Loading it would be just the opposite. You just create one tile for each line you read in, and add that to your world.

There should be PLENTY of tutorials online about file i/o for whatever language you want.

- Eck


Thanks alot. :D This is a good start on fixing this issue. :) I will try and update if it's fixed. :D

This topic is closed to new replies.

Advertisement