1
\$\begingroup\$

I'm making custom menus and buttons (I don't want to use scene2D) and I have everything in atlases, but when I draw a button, if it has text, the texture binding is always x2 because of the switching back and forth between the texture in the atlas and the bitmapfont.

(example of drawing order)

public void draw(SpriteBatch b){
   if(texture != null)
      texture.draw(b);

   if(text != null && !text.isEmpty())
      font.draw(b, "TEXT", x, y);
}

So as you see, if I have 3 buttons, each button will increase the texture binding x2. When using several buttons, texture draw/bind is maybe around the number 24. This hasn't cause noticeable performance issues yet (FPS stay at 60~61) but I want to know how I can reduce the number of bindings when drawing textures and fonts at the same time.

\$\endgroup\$
4
\$\begingroup\$

Make two batches, one for the buttons (texture) and one for the labels (bitmap font).

That is also why you normally batch draw-calls. Group the things using the same resources to reduce draw calls and expensive unbinding/binding of textures and shader-programs.

\$\endgroup\$
8
  • 2
    \$\begingroup\$ The OP's case is a typical pitfall of OOP thinking when it comes to designing a renderer: "each object should know how to draw itself", but that leads to a design that doesn't batch well. Instead each object should add it's draw parameters to a render queue, and the render queue has a manager that then sorts into batches and does the actual drawing. \$\endgroup\$ – Maximus Minimus Jul 10 '18 at 12:50
  • 2
    \$\begingroup\$ @MaximusMinimus sort of pit-fall. But less of OOP and more of teaching of OOP. OOP, you can perfectly well encapsulate the whole rendering process in each object, as long as it is only the information and not the process of rendering. Thus another piece of code (e.g. call it system) can then interpret the information and proceed with rendering it however optimized it can. What we did here is separating data from processing, in web-dev this is called MVC (Model-View-Controller). In game-dev it is called E(C)S (Entity-(Component-)System). \$\endgroup\$ – dot_Sp0T Jul 10 '18 at 14:17
  • \$\begingroup\$ Yes, good point about information vs process. \$\endgroup\$ – Maximus Minimus Jul 10 '18 at 15:44
  • 1
    \$\begingroup\$ @Jh62 - if you have to break a batch then you have to break a batch; there's an obvious tradeoff here. \$\endgroup\$ – Maximus Minimus Jul 11 '18 at 8:45
  • 1
    \$\begingroup\$ @Jh62 very fancy, you'll def go for two draw passes per z-level then \$\endgroup\$ – dot_Sp0T Jul 12 '18 at 5:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.