Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualServant of the Lord

Posted 14 July 2013 - 04:07 PM

I am currently working on a 2D RTS game (tiled based and oblique projection). I wanted a way to only draw the entities that are currently on screen, my first instinct was to store the entities in an array, then check through that array, to see if any entities where inside the camera view, and if they where draw them.

Seems reasonable.
 

However, this will become taxing to do if...

Do I detect a hint of premature optimization? smile.png
 

...if there is a large amount of units and/or players (enemy), as it would have to sort through the hundreds(ish) of times...

Hundreds doesn't sound bad at all. It's a simple collision: Does sprite rect collide with camera rect? 3D games do way more advanced collision than that - it shouldn't be too slow.
 

...it would have to sort through the hundreds(ish) of times a second.

If it does become a slowdown (when testing in release mode and after profiling, ofcourse), you could make it not check every entity every frame. Batch them - do 1/3rd of the checks one frame, the second 1/3rd the next frame, do the final 1/3rd the third frame.

 

An every simpler solution would be to just draw the 100-ish sprites continually. Seriously, 100 sprites should render very quickly. A single 3D model can be 100,000 polygons or more. 100 or even 1000 sprites shouldn't pose too much of a problem.


#1Servant of the Lord

Posted 14 July 2013 - 04:00 PM

I am currently working on a 2D RTS game (tiled based and oblique projection). I wanted a way to only draw the entities that are currently on screen, my first instinct was to store the entities in an array, then check through that array, to see if any entities where inside the camera view, and if they where draw them.

Seems reasonable.
 

However, this will become taxing to do if...

Do I detect a hint of premature optimization? smile.png

...if there is a large amount of units and/or players (enemy), as it would have to sort through the hundreds(ish) of times...

Hundreds doesn't sound bad at all. It's a simple collision: Does sprite rect collide with camera rect? 3D games do way more advanced collision than that - it shouldn't be too slow.

...it would have to sort through the hundreds(ish) of times a second.

If it does become a slowdown (when testing in release mode and after profiling, ofcourse), you could make it not check every entity every frame. Batch them - do 1/3rd of the checks one frame, the second 1/3rd the next frame, do the final 1/3rd the third frame.

PARTNERS