Abandon Rocket and move to our own UI

[fabianschuiki]

In the Settlement experiments I realized that a nice windowing mechanism may be implemented by using the cairo drawing library (in use in GTK+, etc.) to draw the GUI to an image buffer. Then a simple UI stack wraps these image buffers as windows and displays their contents. This is about the same as your everyday OS does it.

Cairo has the advantage that it provides beautiful antialiased rendering and is in general faster than redrawing the whole GUI every frame with OpenGL. GUI rendering may even be moved to its own thread!

[keigen-shu]

Why not just draw the Windows with SFML?

[fabianschuiki]

Yeah that's possible as well. But since SFML most likely offloads the drawing to the GPU we don't get any of the nice antialiasing and similar things that Cairo provide, as well as no beautiful Pango text layouting ;)

[hoshi10]

Interestingly, I've experimented with moving the rendering to a separate thread just a few days back on a separate branch. Haven't pushed the commits yet, but it seemed to work. I'll upload them later so you can take a look.

With regards to the GUI, I agree that we could look for a more robust GUI library. Eventually we'll also have to add menus, modal windows and pop-ups, which might be difficult to implement with what we have now.

May I suggest that we consider Qt as well? It's a modern C++ GUI platform with the ability to do many of the functions mentioned earlier. In fact, Canonical (which backs Ubuntu Linux) is moving Unity, their windowing system, towards a Qt/QML based implementation.

[fabianschuiki]

I think I recall reading that OpenGL is not thread-safe on all platforms, i.e. the thread that created the OpenGL context is the sole one to issue commands. Then again, NVIDIA's technology talks usually involve multithreading in OpenGL, so I might be gravely mistaken ;).

Only handling events in the main thread and moving rendering to a thread and simulation to another would greatly improve responsiveness and speed :). I've had a look at the boost mutexes and synchronisation tools, and they have brilliant read/write mutexes where multiple threads can read a value, but the mutex blocks a writing thread until it has exclusive access.

I agree with you on a proper GUI toolkit. I've never thought about actually using one of the big ones (GTK, Qt, etc.), but if it worked it would be awesome. With GTK I'm positive that it renders stuff down with Cairo graphics, I don't know about Qt. I'd love to try this xD

And finally the SimCity servers started to work more or less ;)

[hoshi10]

Ok, I've uploaded the multithreading branch on my repo. Sorry it took so long. It's not very thread-friendly as of now because of all the locks/mutexes required to allow atomic changes to the game state before the render thread displays the information. Further exploration of how to decouple updates from render may be necessary. But this is just a proof-of-concept. Perhaps we can put this (and the GUI library) on the back-burner for now while we focus on implementing more of the game logic.

OT:
I'm glad I didn't pre-order SimCity. I did with Diablo 3 and got burnt badly by the infamous server errors. After reading the reviews and feedback about the game, I think I'll wait till the dust settles and the major bugs resolved before reconsidering this purchase. BTW, where do you live Fabian? Asian countries got to play slightly earlier than US and there were problems right from the start.

[fabianschuiki]

I'll check it out. I've started some tampering with multithreading in my experimenting repository (Settlement) as well. Boost has brilliant multi-read-unique-write mutexes that has two locking modes: one for reading of which is nonexclusive and one for writing which is exclusive. I have a few thoughts on separating game state and drawing; I'll spawn a new issue for that.

[fabianschuiki]

I'm in Switzerland BTW ;) Check out Issue #44 .

[HongPong]

took a spin at replacing rocket with its successor #62