Ways on Keeping My Game From Eating RAM

[ModShop]

Look at xerzi's last post, I'm willing to bet that your calls to push_back in the tile loading loop are causing at least some lag. Re-size the vector to the desired size before the loading loop, then just access the current tile using the bracket operator.

[N36fSL3A]

Alright.

(You were right, now it takes less than a second.)

[Disch]

FredBill30 wrote:

Yes. [Debug build]

Then any measurement of time is meaningless.

You should run this with optimizations on to see if it really is an issue or not.

So yeah... get rid of the font loading (what does that have to do with a map anyway?) and do an optimized build test... and I'm sure this will fly.

Look at xerzi's last post, I'm willing to bet that your calls to push_back in the tile loading loop are causing at least some lag.

While I agree that a reserve/resize is a good move, I sincerely doubt it's doing any harm in terms of performance... at least currently.

I've found that vector implementations are pretty good at overshooting the amount of allocated memory they need to anticipate further growth.

Not to mention it's only growing to 50x50, which is practically nothing. Even if it had to reallocate 10 times (unlikely), and with 64-bit pointers... that'd be less than 50*50*10*8 = 200K of memory movement. Even in a debug build moving that little memory doesn't take very long.

I still really think the culprit (if any) is that font loader.

[N36fSL3A]

I changed it to simply just get the font from my resource manager. Since you posted this a few seconds from my help asking for what I'm doing with loading my clips, I'm just going to repost it here.

Can you guys help with trying to figure out this code?

I can't seem to figure out how I'm loading the tile clips (They're just rectangles) from my image.

	Clips[0].x = 0;
	Clips[0].y = 0;

	Clips[1].x = 0;
	Clips[1].y = TILE_H;

	Clips[2].x = 0;
	Clips[2].y = TILE_H * 2;

	Clips[3].x = 0;
	Clips[3].y = TILE_H * 3;

	Clips[4].x = 0;
	Clips[4].y = TILE_H * 4;

	Clips[5].x = 0;
	Clips[5].y = TILE_H * 5;

	Clips[6].x = 0;
	Clips[6].y = TILE_H * 6;

	Clips[7].x = 0;
	Clips[7].y = TILE_H * 7;

	Clips[8].x = 0;
	Clips[8].y = TILE_H * 8;

	Clips[9].x = 0;
	Clips[9].y = TILE_H * 9;

	Clips[10].x = 0;
	Clips[10].y = TILE_H * 10;

	Clips[11].x = 0;
	Clips[11].y = TILE_H * 11;

	Clips[12].x = TILE_W * 2;
	Clips[12].y = 0;

	Clips[13].x = TILE_W * 2;
	Clips[13].y = TILE_H;

	Clips[14].x = TILE_W * 2;
	Clips[14].y = TILE_H * 2;

	Clips[15].x = TILE_W * 2;
	Clips[15].y = TILE_H * 3;

	Clips[16].x = TILE_W * 2;
	Clips[16].y = TILE_H * 4;

	Clips[17].x = TILE_W * 2;
	Clips[17].y = TILE_H * 5;

	Clips[18] = Clips[t_stonewall];
	Clips[19] = Clips[t_stonewall2];

	for(int t = 0; t < TILETYPES; t++)
	{
		Clips[t].w = TILE_W;
		Clips[t].h = TILE_H;
	}

The image:
http://prntscr.com/1dg9yh


Thanks for any future help.

[naraku9333]

Fredbill30 wrote:

I can't seem to figure out how I'm loading the tile clips (They're just rectangles) from my image.

It looks like you are setting the top left corner of the rects to the corresponding coords of the texture. How do you not know what you did?

[o1vk4iN6]

@ Disch

Using vs2012 std::vector capacity changed 21 times...

On gcc it did 13...

http://ideone.com/SLmQ2h

[N36fSL3A]

No, I mean I don't know my pattern of loading them. I'm trying to load 'em all in a for loop without having to re-write my maps and ID's of the tiles.

[Disch]

Using vs2012 std::vector capacity changed 21 times...

It's still probably around 200K or less because that 200K figure was assuming it copied the full 50x50 every time... which it wouldn't.

But the real zinger here probably isn't the moving of the memory, but rather is the allocation.

Anyway I agree he should be doing a reserve(). I was just pointing out that the reserve wouldn't solve the problem he was seeing. Though it's probably moot anyway. =P

[N36fSL3A]

Can someone help me with creating a good clip loading method?

[Disch]

In my experience, basic 2D grid maps are usually done like this:

A map may consist of multiple layers -- but no fewer than 1 layer (multiple layers can allow for parallax scrolling effects, or overlays drawn above the player)

Each layer has at least 2 things: an assigned "tileset", and a 2D grid of tile indexes.

Each tileset is assigned a graphic/texture, as well as any interactive properties of the tiles it contains (ie: is the tile open space or a wall?)


Implementation-wise, I've found it's easiest to load up the tileset into a vector of individual Tile properties. Then the map layers contain a simulated 2D array of pointers to tiles within that tileset vector. The pitfall with this is that the pointers have to stay valid throughout the lifetime of the map, which means the Tiles themselves cannot move in memory... and the Tileset must remain alive for as long as any layers are using them.

The "clip" as you call them can be specified in the tileset information if you need it to be fancy... or if not, you can just have the tile index itself double as the graphic location.

For example, if your graphic has 10 tiles per row.... then tile 0 would be the upper left corner of the graphic, tile 1 would be to its right, etc. Tile 10 would be the left-most graphic on the 2nd row from the top, etc.

Tiles do not need to contain a X,Y coordinate for where they are on the map, as that information is already inferred by their position in the map's 2D array.


Pseudo code:

struct Tile
{
    int graphicX;
    int graphicY;
    static const int width = ...;
    static const int height = ...;

    bool isWall;
    //... any other properties you want tiles to have go here
};

class Tileset
{
    std::vector<Tile>  tiles;

    void loadTileset(...)
    {
        //...
        for(int i = 0; ...each tile in file...; ++i)
        {
            Tile t;
            t.graphicX = (i % tiles_per_row) * Tile::width;
            t.graphicY = (i / tiles_per_row) * Tile::height;

            //... load other properties from the tileset here

            tiles.push_back(t);
        }
    }

    // remove move/copy ctors and assignment operators to prevent this class from moving
    //   around, as that will cause the pointers to go bad.
};

class MapLayer
{
    int width;
    int height;
    std::vector<const Tile*>    tiles;

    void load(const Tileset& tileset)
    {
        for( ... each tile in the layer ... )
        {
            i = read_a_tile_index_from_the_file;
            tiles.push_back( tileset.getTile( i ) ); // where 'getTile' returns a pointer to the tile
        }
    }
};

class Map
{
    std::vector<MapLayer> layers;
    std::vector< std::unique_ptr<Tileset> > tilesets;
        // The tileset allocated dynamically so it doesn't move around in memory

    //...
};

Take from that what you what

[N36fSL3A]

What I meant was is there a good method of loading tileset clips from the image.

I already was going to implement layers once I was done finding a good way of automatically getting clips.

[Disch]

Yeah I kind of went over that. Take a look at the "loadTileset" pseudo code.

[N36fSL3A]

I know, but I'm trying to figure out what the hell I did with my Clip loading wall of code. From there I could make a for loop.

[o1vk4iN6]

Your clip loading can just be put into a for loop like in Disch's code...

        for(int i = 0; ...each tile in file...; ++i)
        {
            Tile t;
            t.graphicX = (i % tiles_per_row) * Tile::width;
            t.graphicY = (i / tiles_per_row) * Tile::height;

            //... load other properties from the tileset here

            tiles.push_back(t);
        }

You are asking for help with your Clip loading code but you aren't actually asking a question or saying what's wrong with it.

[Lachlan Easton]

In your clip code it looks like you're assuming the image is twelve tiles high (though your image looks like there should be six), and then you skip the second column. I agree with xerzi, what exactly is the problem?

[N36fSL3A]

I'm trying to figure this out aswell, the code works but I'm clueless on how this actually works. Can someone help me with a for loop?

I'm most likely gonna have to rewrite the clip code.

The problem is when I try to make a for loop to load possible clips, it gives the tile the wrong clip and I end up with the stone walls with the grass graphic and the top layer stone walls as the top portion of an open door graphic.

[o1vk4iN6]

Well you are loading your tiles from top to bottom and left to right. Disch's is loading tiles from left to right and top to bottom. Row major and column major ordering.

for(int t = 0; t < TILETYPES; ++t)
{
    Clips[t].x = (t / tiles_per_column) * tile_width;
    Clips[t].y = (t % tiles_per_column) * tile_height;
    Clips[t].w = tile_width;
    Clips[t].h = tile_height; // these should probably just be constants defined in Clip or something
}

[Lachlan Easton]

Could you show one of these horrible for loop? Not because I have a fetish but to point out where you went wrong.

[N36fSL3A]

	for(int t = 0; t < TILETYPES; t++)
	{
		if(t == 18) {t++;}
		if(t == 19) {t++;}

		// Set clip values
		Clips[t].x = _x;
		Clips[t].y = _y;
		Clips[t].w = TILE_W;
		Clips[t].h = TILE_H;

		// Move the coords accordingly
		_y += TILE_H;
		// If we go too far down...
		if(_y > Res.TileSet_IMG->h)
		{
			// go back to the top
			_y = 0;

			// Move over one
			_x += TILE_W;
		}
	}

I'm most likely gonna have to end up redoing the whole tile ID thingy.

Then, after that I'll work on adding 5 layers to my map system, then after that I guess I'll have to write my Map Editor. (All this comes after a binary map is put into the picture)

[Lachlan Easton]

Well xerzi's got you covered, but in any case what's up with the two if statements?