Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualJosh Petrie

Posted 22 July 2013 - 10:23 AM

fragment shaders will work only on visible fragments and "discard" others automatic, right?

Not necessarily, deferred rendering is meant to address this issue.  Some other behind the scenes optimizations require some thought on your part.  Depth sorting for one...

 

If you load 1 big VBO then you can still access them individually by using the models indices.  I would not do this.  Accessing a component still requires additional draw calls if you want to change anything.  If you combine this with the headache and nuisance of adding and subtracting and hopping through indices then it may not be worth the extra few percentage points of performance increase.  Some implementations may slow down, who knows?  Messing up the index management can crash a computer. You won't know all your particular  issues until you try what you've built on every single machine that you can get your hands on.

 

Even most of those silly little handheld phones can handle at least several dozen VBO draw calls before they start complaining too much, some of them will do 100 or more per frame, easily.  This is combined with changing shaders and textures for many of those models.

 

Depending on your setup:

(i)You can use a distance check to disable whatever is off screen.  if(modelPosX > -5.0 && modelPosX < 5.0){displayArea_1();} helps a lot to manage top view and side view games.  Also if you isolate collision + animation within these screen-sized chunks then you can get really carried away for every discrete area.

(ii)If, when you change rooms it's only vertically or horizontally, then you will never have to display more than two areas at a time which gives you lots of flexibility in how many draw calls, texture and shader swaps can take place. 

 

You could pack all the floor tiles for a room into one VBO, I think this would be practical and easy and safe.  Same for trees, rocks, bushes.   Now for the tiles, rocks, trees, and bushes you would have only 4 VBO's to switch between.  Even a wrist watch running Java could handle that much.

 

Pay attention to optimization but don't become so hung up on it that you set yourself behind several years worrying about it.  Stability is far more important.  Finishing something is also good.

 

p.s. You mentioned something about creating the required VBO's every frame.  I would say, avoid that.  Even changing them per-frame can stall things, I imagine creating them per-frame will be far worse. My imagination can't be stretched far enough for me to come up with a good reason to do this.


#2marcClintDion

Posted 22 July 2013 - 03:16 AM

There is far too much arrogance and out right abuse by site moderators, they are teaching other people to behave this way.  The posts I've made will all be shorty removed and replaced with this notice.  Game development is not the only thing being taught here, bad behavior is being taught as well.


#1marcClintDion

Posted 20 July 2013 - 01:59 PM


fragment shaders will work only on visible fragments and "discard" others automatic, right?

Not necessarily, deferred rendering is meant to address this issue.  Some other behind the scenes optimizations require some thought on your part.  Depth sorting for one...

 

If you load 1 big VBO then you can still access them individually by using the models indices.  I would not do this.  Accessing a component still requires additional draw calls if you want to change anything.  If you combine this with the headache and nuisance of adding and subtracting and hopping through indices then it may not be worth the extra few percentage points of performance increase.  Some implementations may slow down, who knows?  Messing up the index management can crash a computer. You won't know all your particular  issues until you try what you've built on every single machine that you can get your hands on.

 

Even most of those silly little handheld phones can handle at least several dozen VBO draw calls before they start complaining too much, some of them will do 100 or more per frame, easily.  This is combined with changing shaders and textures for many of those models.

 

Depending on your setup:

(i)You can use a distance check to disable whatever is off screen.  if(modelPosX > -5.0 && modelPosX < 5.0){displayArea_1();} helps a lot to manage top view and side view games.  Also if you isolate collision + animation within these screen-sized chunks then you can get really carried away for every discrete area.

(ii)If, when you change rooms it's only vertically or horizontally, then you will never have to display more than two areas at a time which gives you lots of flexibility in how many draw calls, texture and shader swaps can take place. 

 

You could pack all the floor tiles for a room into one VBO, I think this would be practical and easy and safe.  Same for trees, rocks, bushes.   Now for the tiles, rocks, trees, and bushes you would have only 4 VBO's to switch between.  Even a wrist watch running Java could handle that much.  

 

Pay attention to optimization but don't become so hung up on it that you set yourself behind several years worrying about it.  Stability is far more important.  Finishing something is also good.

 

p.s. You mentioned something about creating the required VBO's every frame.  I would say, avoid that.  Even changing them per-frame can stall things, I imagine creating them per-frame will be far worse. My imagination can't be stretched far enough for me to come up with a good reason to do this.


PARTNERS