Screen System

Dec 19, 2007 at 9:10 PM
Now that the graphics system is more or less in a usable state, it's probably best for me to turn my attention to other tasks for the time being. There are still a couple of fix ups that I want to do with the StaticModel class, but everything else (like the modular shader library and shadowing/lighting) can wait until the important engine systems are working. Following the graphics theme, I will probably start with the screen system next, which will allow us to composite scene rendering with GUI/overlays and post-processing effects.

Feel free to use this thread to post your ideas/suggestions/criticisms on how this system should be implemented!

The approach I plan on taking with this is to treat it as a compositor. Every system that renders graphics in any way will be assigned one or more "screens" or "overlays." A screen is defined as a rectangle of the screen space, along with a depth. Screens will be rendered and composed back to front to maintain proper ordering but also to allow some interesting blending effects between background and foreground. Think scene rendering blurred in the background with an Options menu overlayed on top of it. A screen could also be a post-process effect. For instance, the scene could be rendered to a 128-bit FP render target, and a screen could be used to bloom/tone-map the render target.

As an example, you could have the following hierarchy in the compositor:
    Scene Rendering (128-bit FP HDR) -> Bloom Post-Process -> Tone-Map Post-Process -> Player GUI (health, ammo, weapon reticule, etc.) -> FPS Counter Overlay -> Rendering Stats Overlay ->Final Back Buffer

Each screen would be a class inheriting from a given interface/abstract class.

Using this system, the question becomes: do we integrate this with the graphics system, or treat it as a separate system? It could definitely benefit from having direct access to the graphics system resources, like render target data, so I'm currently planning on embedding it within the graphics system.

Comments?
Dec 19, 2007 at 9:49 PM

Using this system, the question becomes: do we integrate this with the graphics system, or treat it as a separate system? It could definitely benefit from having direct access to the graphics system resources, like render target data, so I'm currently planning on embedding it within the graphics system.


What is the difference here? I come to think that this means that it won't be possible to extend our engine unless you modify the source of the engine. This should be reconsidered, most will not wish to tough the engine code, and just implement their game on top of it, similar to the sample game.

So would scenes be both pre and post rendered? Or should they just be on top of the current game scene?
Dec 19, 2007 at 10:32 PM
I don't see that it has any impact on extensibility.

As part of the engine functionality, the scene will be rendered to a "screen." Whether graphics system or scene manager "controls" this screen, it really doesn't matter. The GUI system will also render onto one or more "screens." Client game code will interact with the screen manager/compositor (I like the name compositor, and its less likely to be confused with scene manager) and assign a composition order to all screens, scene rendering and GUI rendering being two of these screens. The engine may also provide pre-implemented, optional screens like an FPS counter, rendering statistics, various post-processing effects. Basically, each screen will be rendered using the previous screen's output as a background, or texture (depending on what the screen requests).

As an example, the Bloom Post-Process and Tone-Map Post-Process "screens" above will request the previous screen's output as a texture. The Player GUI, FPS Counter Overlay, and Rendering Stats Overlay will request that the previous screen's output just be used as the background and will write over top of it.

Extensibility will be maintained in any case since all programmatic "screen" classes will implement an interface or abstract class.

Coordinator
Dec 19, 2007 at 10:54 PM
I'm ok with this system, provided the following:

1.) It is easy to manage screens, through code, and just plain intuitive.
2.) I can still get a good framerate using only the main "screen" which would be the game view itself (3D), and a 2D HUD.
3.) I haven't thought of 3 yet, but you can damn well bet there will be one later :oP
Dec 20, 2007 at 2:30 AM
Kinda what I would think too, but reading your initial post it just sounded like there would be a difference in how much "low-level" access there would be in we implemented them in the Graphics system.