I have been building a framework for a game and I have encountered a few issues I would like to get opinions on. #1. I am building a basic GUI system and I would like to know if my screens and controls should be prerendered, built on the fly or a combination of both? #2. If I prerender a screen made up of components such as 4 corners and 1 vert and 1 horizontal, is this a good design? #3. My demo is going to be 3D but the screens outside the main game screen are in 2D so I am thinking about having a ScreenManager pass the screen to be rendered to the displaymanager, how does this sound? Thanks

Quote:Original post by sosa222
#1. I am building a basic GUI system and I would like to know if my screens and controls should be prerendered, built on the fly or a combination of both?

It depends. Do you want to be able to rapidly build new UI and deploy it in the game? Then build on-the-fly. Do you want to be able to compress the resources for size? Prerender. Do you have a procedural system in place? Then you have the best of both worlds.

Quote:#2. If I prerender a screen made up of components such as 4 corners and 1 vert and 1 horizontal, is this a good design?

Four corners plus one horizontal and vertical section yields a frame, and is not prerendered. You might want to explain this a bit better, as I don't quite understand.

Quote:#3. My demo is going to be 3D but the screens outside the main game screen are in 2D so I am thinking about having a ScreenManager pass the screen to be rendered to the displaymanager, how does this sound?

I don't understand what you're asking, or even saying. Choose your words carefully - what do you mean by "screens," for example? Spend more time and words to explain yourself, because the terms you are using to describe things are probably wrong and nobody else uses the same terms.

ok, to clarify, the frame method you mention is what I would like to do. Meaning that I will use sprites to draw the frame, background, and any controls that exist on the screen, does this make sense?

As for #3, what I mean is that I am using an object to store the frame, background, and controls and then passing it to the Rendering Display Manager to draw it on the screen. Do you think this is a good design or is there a better method?

Thanks

Quote:Original post by sosa222
ok, to clarify, the frame method you mention is what I would like to do. Meaning that I will use sprites to draw the frame, background, and any controls that exist on the screen, does this make sense?

It's certainly an acceptable approach. You have to weigh the memory savings of real-time compositing against the performance penalties. It's a judgment call - your call.

Quote:As for #3, what I mean is that I am using an object to store the frame, background, and controls and then passing it to the Rendering Display Manager to draw it on the screen. Do you think this is a good design or is there a better method?

(Small nit-pick: your "Rendering Display Manager" should simply be called a "Renderer," unless it is responsible for managing multiple concurrent renderers. Don't make things sound more complex than they are; all you need is a Compositor to bake the frame, background and controls into an image, and a Renderer to draw it to screen.)

It's the same case as the preceding: the pros in terms of memory savings thanks to having a smaller set of resources vs the losses in terms of compositing that at runtime. If the resulting image isn't too large for your minimum RAM requirements, then you might as well not bother. If there are a bunch of these objects that add up to a lot of disk storage, however, you may want to create a procedural system that composites them for a single level/area, so that they're always manageable in RAM but never consume too much disk space.

What do you mean by "bake the frame"?

Thanks