2
\$\begingroup\$

I am working on a GUI in XNA 4.0 at the moment. (Before you point out that there are many GUIs already in existance, this is as much a learning exercise as a practical project). As you may know, controls and dialogs in Windows actually consist of a number of system-level windows. For instance, a dialog box may consist of a window for the whole dialog, a child window for the client area, another window (barely showing) for the frame, and so on. This makes detecting mouse hits and doing clipping relatively easy. I'd like to design my XNA GUI along the same lines, but using overlapping Textures instead of windows obviously.

My question (yes, there's actually a question in this drivel) is: am I at risk of adversely affecting game performance and/or running low in resources if I get too nuts with the creating of many small textures? I haven't been able to find much information on how resource-tight the XNA environment actually is. I grew up in the days of 64K ram so I'm used to obsessing about resources and optimization.

Anyway, any feedback appreciated.

Improve this question
\$\endgroup\$
1
  • \$\begingroup\$ This is where the obligatory Michael A. Jackson quote comes in: "The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet." It is usually more important for your program to be understandable, and maintain structure, than to perform optimizations. PC Video cards today are extremely powerful, and even with thousands of state changes per frame, they will hardly break a sweat. However, if this is an optimization learning exercise, or you're programming embedded devices, then it's a whole different story. \$\endgroup\$
    – Panda Pajama
    Nov 13, 2012 at 6:09

3 Answers 3

Reset to default
3
\$\begingroup\$

Any slowness in this situation would be caused by the switching of texture states, as another poster also mentioned.

If you are finding that you have performance problems you can combine all of your small textures into a larger sprite sheet texture to eliminate the switching of which texture is on the GPU. You will just need to use a rect to access the correct portion of the sprite sheet when you make the call to ContentManager.Load().

Improve this answer
\$\endgroup\$
2
  • 1
    \$\begingroup\$ +1 for the sprite sheet. This is definitely the way to go with many small textures. \$\endgroup\$
    – Maximus Minimus
    Nov 12, 2012 at 23:52
  • 1
    \$\begingroup\$ Notice the technical term is not "sprite sheet" but "texture atlas". May help you find resources when searching online if you use the most accurate term \$\endgroup\$
    – Panda Pajama
    Nov 13, 2012 at 7:01
1
\$\begingroup\$

Well no, generally not. Only thing is that changing the texture state is somewhat slow. So using less textures can make the rendering of the GUI a whole lot faster (~a few milliseconds). But it won't impact anything outside of the GUI rendering code. We are talking about really tiny amounts of memory here and also tiny amount of indices. That wouldn't even have made a impact 10 years ago.

Improve this answer
\$\endgroup\$
10
  • \$\begingroup\$ BY "changing the texture state" you mean changing the contents of a texture? I get that that probably means cpu time, then reloading the texture into the gpu area. But what about for instance moving textures around on the display. Does that load the cpu or is that mostly gpu? See, these are the types of questions that can be important for writing code but are generally only answered through experience -- either your own or that of people who've already tried it. \$\endgroup\$
    – Donutz
    Nov 9, 2012 at 18:27
  • 1
    \$\begingroup\$ Textures most definitely do not take up "tiny amounts of memory". \$\endgroup\$
    – kevintodisco
    Nov 9, 2012 at 18:29
  • 1
    \$\begingroup\$ @Donutz No, I meant switching between textures. Drawing two rectangles with the same texture is much faster than drawing two rectangles with different textures. It's all done on the GPU, no texture data is loaded from the GPU to the CPU (unless you explicitly ask for it). The CPU is doing nothing but sending orders/data to the GPU, from which the GPU then builds the picture and sends it to the monitor. \$\endgroup\$
    – API-Beast
    Nov 9, 2012 at 18:34
  • 1
    \$\begingroup\$ @ktodisco Context. The OP specially asked for "small" textures. \$\endgroup\$
    – API-Beast
    Nov 9, 2012 at 18:35
  • 1
    \$\begingroup\$ @Mr.Beast, thanks for that. I know in computer science we're taught that the computer should be programmed as an abstract machine and hardware specifics shouldn't be important. But for cases like XNA and video programming, a detailed discussion of what happens behind the scenes would really help for understanding how programming strategies actually play out. \$\endgroup\$
    – Donutz
    Nov 9, 2012 at 18:49
0
\$\begingroup\$

I'd like to design my XNA GUI along the same lines, but using overlapping Textures instead of windows

This is a bit of a tangent on your actual question, but bear with me.

I may be taking your wording a bit too literally but in the event I am not, I would suggest that you do not represent your GUI elements with a series of Texture2D instances, but rather, a collection of Rectangle instances. You could then wrap the Rectangle with something such as BaseWindow class, where each base window class holds both a rectangle and a texture, as well as other tidbits that you will need to manage the object. This will allow you to have windows that are not the same size as your texture, so that you can employ a few tricks (such as a 1x1 pixel texture being stretched to entirety of the window to simply fill with a solid color).

Now on to your real question.

am I at risk of adversely affecting game performance and/or running low in resources if I get too nuts with the creating of many small textures?

If you are loading up all of your textures via the ContentManager, then your chances of adversely affecting performance is minimal. The reason being that the content manager class handles duplicate texture loading for you, by simply returning a reference to the original loaded texture, should you try to load the same texture all over again. This makes it very easy for you, since you really don't have to worry about managing duplicate resources.

However, common sense and good programming practice still applies.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

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