Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


[SDL] map with animated tiles. performance question.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Nausea   Members   -  Reputation: 258

Like
0Likes
Like

Posted 24 June 2013 - 06:27 PM

Hi!

 

I've tried to get animated tiles to work on my tile map and I've run into what may be a problem going forward.

I'll try to explain how I have it constructed in my code.

 

First:

My map class stores two vectors, one with tiles (one of each kind) and one vector stores "tile slots".

It also holds a tile sheet.

 

Second:

My tile class handles updating the sprite animation, only changes coordinates for the target sprite. 

Handles frame rate etc.

 

It also holds an ID to connect this with a tile slot ID.

 

Third:

My tile slot class holds ID, type, and x/y for where to draw them on the map.

ID is used to link it to a tile during rendering.

 

....

I did it like this because it was the only way I could think of, this way I could make it so that I only need to update the animation once per tile.

However, when I need to draw the tile slots for where the animated tile will be drawn I run into the problem of having to go through all tile slots and then go through all tiles to draw the correct tile at the correct place.

I can cut down on some of it by checking if the tile slot is inside of the camera, but this still leads to going through the entire tile slot vector.

 

My worry is that this will be very taxing on the computer when I get to the point of making a full fledged map. Not to mention when I will have to in some way check for collisions with the tile slots.

 

I wish that someone could maybe give some input on this.

 

Thank you!


Edited by Nausea, 24 June 2013 - 06:30 PM.


Sponsor:

#2 Ludus   Members   -  Reputation: 970

Like
0Likes
Like

Posted 25 June 2013 - 01:47 PM

Are all of your tiles the same size? If so, there are calculations you can perform based on the position of the camera and the dimensions of a tile, returning the element numbers of which tiles to draw (I could go into more detail if this is the case). If your tiles are not all the same size, then you might have to use a space partitioning method such as quadtrees.



#3 Nausea   Members   -  Reputation: 258

Like
0Likes
Like

Posted 25 June 2013 - 02:26 PM

Are all of your tiles the same size? If so, there are calculations you can perform based on the position of the camera and the dimensions of a tile, returning the element numbers of which tiles to draw (I could go into more detail if this is the case). If your tiles are not all the same size, then you might have to use a space partitioning method such as quadtrees.

The tiles are all the same size. 

 

However I mostly wonder if this will be a real bad solution?

 

I've tried to fill up the screen with tiles without feeling any real performance problems and I wonder if that will change when I have a full map even tho I will only draw the tiles inside the camera and the collision boxes will be fewer to check for.



#4 frob   Moderators   -  Reputation: 22783

Like
1Likes
Like

Posted 25 June 2013 - 02:37 PM


My worry is that this will be very taxing on the computer when I get to the point of making a full fledged map. Not to mention when I will have to in some way check for collisions with the tile slots.

How many do you have? Be realistic.

 

Rectangular collision tests are cheap. Performing even 10000 rectangular collision tests on your objects probably isn't going to be a noticeable blip on the profiler.

 

If you are running with multiple thousands of rectangular tests every frame, or hundreds of non-rectangular tests every frame, then begins to make sense to use a spatial tree.  

 

If your numbers are small then don't bother with the added complexity.

 

 

 

EDIT:

 

However...

 

The thing that concerns me MUCH more is that you are describing a situation where you are probably sending all the data from the CPU to the GPU every frame.

 

You implied but did not actually state how you intend to render it. Sending all the data to the GPU every time is incredibly inefficient and slow. Make sure you are using SDL methods and objects that move the content to the graphics system a single time.


Edited by frob, 25 June 2013 - 02:44 PM.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#5 Nausea   Members   -  Reputation: 258

Like
0Likes
Like

Posted 25 June 2013 - 02:43 PM

 


My worry is that this will be very taxing on the computer when I get to the point of making a full fledged map. Not to mention when I will have to in some way check for collisions with the tile slots.

How many do you have? Be realistic.

 

Rectangular collision tests are cheap. Performing even 1000 rectangular collision tests on your objects probably isn't going to be a noticeable blip on the profiler.

 

If you are running with multiple thousands of rectangular tests every frame, or hundreds of non-rectangular tests every frame, then it will make sense to use a spatial tree.  

 

If your numbers are small then don't bother with the added complexity.

 

 

Ok.

Well I won't be having over 1000 tongue.png

I guess I don't have to be worried, good to hear some thoughts on the subject tho.

 

Thanks

 

EDIT:

 

 

However...

 

The thing that concerns me MUCH more is that you are describing a situation where you are probably sending all the data from the CPU to the GPU every frame.

 

You implied but did not actually state how you intend to render it. Sending all the data to the GPU every time is incredibly inefficient and slow. Make sure you are using SDL methods and objects that move the content to the graphics system a single time.

 

 

Hmm.. I have a render function in my map class that goes over the tile slots, if the current tile slot is inside the camera range, go through the list of tiles and check which ID it corresponds to and render the tileslot at x/y with the tiles sprite x/y. This render function is run inside the applications render function, when all the things in the program has been through the render function it blits it on to the screen.

 

Maybe my wording is poor. What i mean to say is that the maps rendering function blits the stuff on to the screen surface, later in the applications render function when everything in the program is blitted on to the screen surface i "flip" it.


Edited by Nausea, 25 June 2013 - 03:12 PM.


#6 Ludus   Members   -  Reputation: 970

Like
0Likes
Like

Posted 25 June 2013 - 03:06 PM

If you still wish to look into a more efficient way of handling collision and rendering with tiles, I suggest looking into Tim Jones' tutorials on his website, and especially his tutorial on maps (though you'll probably still have to read up on the previous tutorials to better understand the framework).



#7 frob   Moderators   -  Reputation: 22783

Like
1Likes
Like

Posted 25 June 2013 - 10:47 PM

 
I have a render function in my map class that goes over the tile slots, if the current tile slot is inside the camera range, go through the list of tiles and check which ID it corresponds to and render the tileslot at x/y with the tiles sprite x/y. This render function is run inside the applications render function, when all the things in the program has been through the render function it blits it on to the screen.
 
Maybe my wording is poor. What i mean to say is that the maps rendering function blits the stuff on to the screen surface, later in the applications render function when everything in the program is blitted on to the screen surface i "flip" it.

Would be nice if you could reply to it so I know if I'm actually doing something wrong, which I don't think that I do.

A quick way to test if your framework has the problem is to write a simple stress test.

I'm not sure about it, but it sounds like you are filling the screen with small tiles. In my mind, that means you have perhaps 30x20 background tiles + 50 or so foreground tiles + 50 or so UI sprites, totaling about 700 or so sprites. So load up and draw 1,000 sprites in a frame for one test and perhaps 2,000 or even 5,000 sprites in a frame in a second test, doing the same thing you do to normally draw them. Those can even be copies of the same image, if that is how you intend to run it. Run it and look at performance.

It is not uncommon that drawing a tile-based world in the way you described -- drawing the tiles individually -- has difficulty in running at a high frame rate. Many times (but certainly not always) the simple implementations will run into problems because they are copying the sprites to video memory every frame. Using SDL objects correctly probably won't have the problem. The test is to just make sure you are using them correctly and your solution will work.

Running a quick stress test can easily verify that your intended method can or cannot handle that many individual draw calls.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#8 Nausea   Members   -  Reputation: 258

Like
0Likes
Like

Posted 26 June 2013 - 07:21 AM

 

 
I have a render function in my map class that goes over the tile slots, if the current tile slot is inside the camera range, go through the list of tiles and check which ID it corresponds to and render the tileslot at x/y with the tiles sprite x/y. This render function is run inside the applications render function, when all the things in the program has been through the render function it blits it on to the screen.
 
Maybe my wording is poor. What i mean to say is that the maps rendering function blits the stuff on to the screen surface, later in the applications render function when everything in the program is blitted on to the screen surface i "flip" it.

Would be nice if you could reply to it so I know if I'm actually doing something wrong, which I don't think that I do.

A quick way to test if your framework has the problem is to write a simple stress test.

I'm not sure about it, but it sounds like you are filling the screen with small tiles. In my mind, that means you have perhaps 30x20 background tiles + 50 or so foreground tiles + 50 or so UI sprites, totaling about 700 or so sprites. So load up and draw 1,000 sprites in a frame for one test and perhaps 2,000 or even 5,000 sprites in a frame in a second test, doing the same thing you do to normally draw them. Those can even be copies of the same image, if that is how you intend to run it. Run it and look at performance.

It is not uncommon that drawing a tile-based world in the way you described -- drawing the tiles individually -- has difficulty in running at a high frame rate. Many times (but certainly not always) the simple implementations will run into problems because they are copying the sprites to video memory every frame. Using SDL objects correctly probably won't have the problem. The test is to just make sure you are using them correctly and your solution will work.

Running a quick stress test can easily verify that your intended method can or cannot handle that many individual draw calls.

 

 

From what I can tell my program takes up 0% in the task manager with a 1000 tiles drawn inside and outside the screen region.

I go through my tilelist, blit the tiles and then when all are blit I send it from the buffer to the screen in one go.

 

I might go for splitting the map up in sections just because of speed anyway, might not be needed but might be a good thing anyway.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS