Oh God so many tiles!

[spirit bomb!]

This is a subject that I believe many people on these forums have experience with...

Suppose I have a tile based game. And suppose the character can move, but he really stays in the same spot on the screen, as the entire world moves in the opposite direction he is running in (Kinda like the space ship in FUTURAMA). So the problem is... I am keeping track of every single tile, on and off screen. Every time the character moves, the (x,y) of every single tile needs to be adjusted. This is eating my frame-rate ferociously, because of the ridiculous amount of processes involved. Has anyone experienced this problem, or have any good solution?

Possible Solutions???

-Smaller World.
-Make every layer into one single bitmap. <- wouldn't have any idea how to implement this b.s. but it would be cool


Any halp is awesome, and well appriciated.

[pritam]

I think a possible solution would be to have an offset for your tilemap, something like this.

Code: Select all

int tmOffsetX;
int tmOffsetY;

And then when you render your tiles you just add them to the X and Y parameters of your draw function. Hope it works out.

[eatcomics]

and if your tiles aren't on screen, don't draw them :D

[zeid]

if your tiles aren't on screen, don't draw them :D

The other calculations barely cost anything compared to the cost of rendering. Always try and draw as little as possible.

If you want to get crazy with optimisation you could consider grouping the tiles in a quad-tree like fashion.

[cypher1554R]

Also, instead of doing user defined per frame calculations for every tile, just move the moving sprite and follow it with camera (change view matrix accordingly).

[Falco Girgis]

This is a subject that I believe many people on these forums have experience with...

Suppose I have a tile based game. And suppose the character can move, but he really stays in the same spot on the screen, as the entire world moves in the opposite direction he is running in (Kinda like the space ship in FUTURAMA). So the problem is... I am keeping track of every single tile, on and off screen. Every time the character moves, the (x,y) of every single tile needs to be adjusted. This is eating my frame-rate ferociously, because of the ridiculous amount of processes involved. Has anyone experienced this problem, or have any good solution?

Possible Solutions???

-Smaller World.
-Make every layer into one single bitmap. <- wouldn't have any idea how to implement this b.s. but it would be cool


Any halp is awesome, and well appriciated.

What? Dude, when a scene is rendered, hundreds to thousands of render calls are made. The only difference between a scrolling tile game and nonscrolling is an integer offset. The calculation amounts to a simple difference in the x and y. So that's two subtractions per render call...

It sounds to me like your bottleneck is RENDERING not CALCULATING. If you are RENDERING a million tiles that aren't even on the screen (especially with SDL or software rendering) then yeah--shit can get hella slow. I'm sure that you're rendering your tiles with something like:

Code: Select all

for(y = 0; y < map_height; ++y)
    for(int x = 0; x < map_width; ++x)
        DrawSprite(map[y][x]);

Just write your loop a little more intelligently so that you aren't rendering EVERY tile, just the ones that need to be in the scene.

[eatcomics]

so basically what falco is saying is, make it so if your tile's x < 0 && y < 0, or x > screenwidth && y > screenheight, don't draw the tile :D

[mv2112]

I draw all the tiles under the character onto a bitmap and only manually render tiles above the player, and i only blit a clip of the map bitmap to the screen. I also use a camera that tells the engine where to clip the map so i don't render the whole thing.

[eatcomics]

yet he manually called a destructor...

[mv2112]

yet he manually called a destructor...

Why the hell is it such bad practice to call destructors? Who says it is bad practice? Why does it matter?

Ahh, i feel better now...

[XianForce]

yet he manually called a destructor...

Why the hell is it such bad practice to call destructors? Who says it is bad practice? Why does it matter?

Ahh, i feel better now...

Erm, I'd say Bjarne Stroustrup would say so...

Destructors are automatically called. So when you manually call it, it will actually be called twice most likely. So let's say you had this:

Code: Select all

SomeDestructorExample::~SomeDestructorExample()
{
delete pSomeDynamicallyAllocatedMemory;
}

And later the destructor is also automatically called... Then you run into things like segfaults and access violations...

That's probably why it's a bad practice... It's also just plain out unnecessary...

[dandymcgee]

Destructors are automatically called. So when you manually call it, it will actually be called twice most likely. So let's say you had this:

Code: Select all

SomeDestructorExample::~SomeDestructorExample()
{
delete pSomeDynamicallyAllocatedMemory;
}

And later the destructor is also automatically called... Then you run into things like segfaults and access violations...

Not if you have good coding habits.

Code: Select all

SomeDestructorExample::~SomeDestructorExample()
{
    delete pSomeDynamicallyAllocatedMemory;
    pSomeDynamicallyAllocatedMemory = NULL;
}

It's also just plain out unnecessary...

This.

[Ginto8]

Not if you have good coding habits.

Code: Select all

SomeDestructorExample::~SomeDestructorExample()
{
    delete pSomeDynamicallyAllocatedMemory;
    pSomeDynamicallyAllocatedMemory = NULL;
}

It would have to be more like this:

Code: Select all

SomeDestructorExample::~SomeDestructorExample()
{
    if(pSomeDynamicallyAllocatedMemory) {
        delete pSomeDynamicallyAllocatedMemory;
        pSomeDynamicallyAllocatedMemory = NULL;
    }
}

[dandymcgee]

Not if you have good coding habits.

Code: Select all

SomeDestructorExample::~SomeDestructorExample()
{
    delete pSomeDynamicallyAllocatedMemory;
    pSomeDynamicallyAllocatedMemory = NULL;
}

It would have to be more like this:

Code: Select all

SomeDestructorExample::~SomeDestructorExample()
{
    if(pSomeDynamicallyAllocatedMemory) {
        delete pSomeDynamicallyAllocatedMemory;
        pSomeDynamicallyAllocatedMemory = NULL;
    }
}

Actually, that's redundant.

http://opensource.devx.com/tips/Tip/14443

Null Pointers and Delete

C++ guarantees that operator delete checks its argument for null-ness. If the argument is 0, the delete expression has no effect. In other words, deleting a null pointer is a safe (yet useless) operation. There is no need to check the pointer for null-ness before passing it to delete:


if (p) // useless; delete already checks for a null value
delete(p);

[XianForce]

But what Ginto posted is still good practice. Because what if it ISN'T NULL? I use that practice all the time =p