We use an inhouse tool for our GUI, but ever single piece of art that you would see in our game is at screen resolution. Often we take certain elements that are used in multiple places and reuse them, or cut part of them out and attach them to something else. It takes up a tremendous amount of disk space, it''s true, but it''s necessary to look good. If you are using a gui that has windows and such, you can make your window up out of 9 pieces - four corners, four ''bars'' on the edges, and one texture that tiles across the window''s background. Buttons can then be added and fonts written on them. But for really fancy looking windows it''s all art at full resolution. We dynamically load textures based on the GUI stack ie we have all the textures loaded for the current screen, the previous one and the next screen so that when the user advances, the textures are there - we then load the textures for the next screen.. this helps smooth out loading times between screens but there are still cases when the user can get ahead of our loading and they just have to wait.

To get our 512x213 texture on screen we break it into chunks using a tool that lets us refer to the texture as one object, even though it contains multiple sub-textures. Then at load time we load the one texture and our system transparently handles the loading and initializing of the subtextures. Calling draw using the main texture will cause all the subtextures to be drawn.

Anyways, hope that adds some food for thought.

We don''t ever explicitly write LoadTexture("widget.tga") .. we have a system that takes all of the textures required for a screen and bundles them together using a chunk-based file scheme. Each chunk has an ID that describes what kind of data it is. On loading, when we parse each chunk, we can determine if it is a ''single texture'' or a ''multiple texture containing main sub textures''.