search

adi64 / terminus

Game Programming Seminar 2014/15
3 stars 0 forks source link

Refactor Rendering Code #213

Open lw0 opened 8 years ago

lw0 commented 8 years ago
adi64 commented 8 years ago

tmp_9887-img_20161031_184914933236118

adi64 commented 8 years ago

tmp_9887-img_20161031_1848541737990378

NaskyD commented 7 years ago

terminus-classdiagram

New class diagram

adi64 commented 7 years ago

I thought it might be nice to add an abstraction layer between our game application (that would be the Application class) and the class inheriting from QQuickItem. Currently (in our code) that is the same class. Looking at the most recent class diagram, I am not sure how this is handled, since the new Application class seems to have a QWindow?

Anyway, having an abstraction layer in between would allow us to swap out the underlying context-creation code without touching any of our "game" code. Another thing that I noted is the problem that a class derived from QQuickItem will eventually include the Qt OpenGL bindings, which conflicts with any other bindings.

Opinions?

lw0 commented 7 years ago

As far as I understood, the class diagram represents the current status of the refactoring and some expected changes. Nothing is final yet. The Composition-Edge between Application and QWindow is a little misleading. Application does not have (own) the window but only keeps a reference to query its dimensions later, when the viewport needs to be set. There might be a more elegant solution...

I totally agree that a separation of Qt/QtQuick classes and our game logic is desirable. Unfortunately I do not quite remember our ideas in that direction. We might have intended Game to own the Renderer instance and pass through the render() calls from Application. However that would compromise the decoupling of rendering code and game logic necessary to use Game and its GameObjects in a server scenario. I would prefer Application to own and provide the Renderer to Game. That would make it easy to have a ServerApplication providing a DummyRenderer to the same Game. As Renderer does not need any OpenGL binding specific includes in its header, it is feasible to let Application create a Renderer instance.

Does this cover what you meant or did you refer to a possible decomposition of Application itself? We might find it difficult to disentangle the QtQuick UI from the game lifecycle logic (single-/multiplayer game start, interactive train configuration, ...). Though it would be a major improvement I do not know whether this particular refactoring should attempt anything of this kind.