binary1248/SFGUI — comment on commit 035d96af5b5980cbcd8852f40279534c921ba04a
File:  line 0
By binary1248:

Is there really no way to add an extra layer on top of the scene for GUI purposes? From what I understand you can add arbitrary objects to the scene in this game creation software, so you would be mixing GUI elements and game elements (e.g. cars, the player, other objects) together. If I remember correctly, the whole purpose for a scene graph is to manage your scene for you so you don't have to draw everything yourself every frame. This is basically what this new renderer in SFGUI is trying to do. However because the scene graph in your game creation software is used for everything it might also take care of (e.g. physics, occlusion culling, visibility testing) in the game. Adding GUI objects to the scene graph would therefore cause unneeded CPU load because it is already taken care of by SFGUI, and you wouldn't have to (or want) physics applied to GUI elements.

That being said, I'm curious. If you can add any kind of object to the scene it would mean that they all have to be encapsulated in some kind of container so that the scene graph manager knows what to do with them. Is there no way of just adding the widget to the scene and calling the Display() function sometime later, like at the end of each frame? Widgets are still independent of each other, however they are all rendered at the same time now. That is the main difference between before and now.

I would highly recommend separating the GUI from the rest of the scene into it's own layer on top of everything, for efficiency purposes among others. That's how most commercial games seem to handle their GUIs.

As for sf::View compatibility, I plan on implementing only the needed functionality for Views within the GUI. That would mean that you can draw widgets in given viewports anywhere on the screen, however you won't be able to e.g. rotate these views (which would make little sense with a GUI).

The renderer (it's working name is ProjectO, it will be renamed when it is done) is not complete yet. When it is nearing completion, or maybe even earlier, I'll reimplement widget culling. This will however be in a totally different way to the old implementation, taking into account the final pixel positions on the screen after all transforms. As such the only way pixels (widgets) can be culled would be if you cannot see them at all in ANY viewport, which would solve all problems and make no sense to disable (because internally the GPU doesn't process fragments which are off-screen anyway).