Thursday, 22 May 2014

Update #001: Map Editor bugfixes, begun implementing resizeable entities

I ended up tackling a few really notorious bugs which plagued my map editor. The first of which was actually causing my map files to corrupt at random. It turned out the elements of the std::vector which housed my loaded worlds were needlessly swapping positions, resulting in invalid iterators being accessed.

I also went back and optimized how often entity sprites reloaded themselves. It was something I was planning on redoing for a while now. Tomorrow I plan to being implementing resizable entities. Rather than simply rescaling the size of the sprite (which resulted in a blurred/distorted final appearance), these entities will copy certain rects from a larger source texture, tiling them appropriately within the sprite itself.

I have spent the last few days reworking my worlds such that the larger ones are divided into evenly-sized segments. Here's a very simple example of what I mean:

Let's assume the following grid represents our entire world:

The simplest way of loading this world into our game would be to load it all directly into memory at once. This was what we were doing for the most part, and there is nothing inherently wrong with this technique as long as the world itself wasn't too large. However, we are projecting that our game will consist of worlds as big as 50,000 tiles by 50,000 tiles, and loading 2.5 × 109 tiles at once would be rather silly. Therefore, we have opted to divide our larger maps into several smaller, equally-sized segments.

Not quite as daunting now! With our world divided up as such, we are able to only load the relevant segments of the map; said segments being the ones that are visible by the camera. In order to guarantee a smooth transition between world segments, we would need at least 4 chunks loaded at a time assuming our camera size is smaller than the size of a segment. Consider below:

The red rectangle represents our camera position and size, and the purple area represents what is currently loaded into memory (including what the red area covers). Everything within the camera's view is being drawn every frame. We load these relevant tiles in a spiral, starting as close as possible to the camera's centre.

We can see how imperative it is that our first 6 tiles load before the game itself begins. Afterwards, we can have the spiral load the remaining purple tiles on a second execution thread and the game can begin!

No comments:

Post a Comment