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\$

1 Answer 1

Reset to default
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
    Commented Jul 10, 2018 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
    Commented Jul 10, 2018 at 14:17
  • \$\begingroup\$ Yes, good point about information vs process. \$\endgroup\$
    – Maximus Minimus
    Commented Jul 10, 2018 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
    Commented Jul 11, 2018 at 8:45
  • 1
    \$\begingroup\$ @Jh62 very fancy, you'll def go for two draw passes per z-level then \$\endgroup\$
    – dot_Sp0T
    Commented Jul 12, 2018 at 5:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .