Week 6/2013: Shell as the Server UI
Last week my time was spent cleaning up the server binary and building the Shell GUI app.
As a background process, a server should not have any dependencies to UI or graphics libraries. However, such dependencies have hitherto been unavoidable because the server and the client have been located in the same binary. Now that they're separated, I was finally able to sever the remaining ties doomsday-server has to OpenGL and GUI. As a consequence, the server binary now has no UI of its own any more — the old dedicated mode text console has been dropped.
A similar convoluted situation with dependencies existed in the libdeng2 (Doomsday 2) library. I split it into two parts so that the GUI-related functionality is now in a separate shared library called libgui (e.g., deng_gui.dll) that links with GUI and OpenGL.
The changes made to the server binary are actually quite profound: because there is no UI, there are also no window management and input events and thus no need for a bindings system or player controls. In other words, quite a hefty chunk of code was omitted from the server. This is a nice example of the evolution that the client and server binaries will be exhibiting in the future: engine subsystems will be refocused with the client/server architecture in mind, with only a selected few systems spanning both.
Some regressions had crept up in the unstable server, so I took a few moments to fix them: the server was crashing when any plane was moved, and the initial player angle was incorrect when a new client joined the game. The former issue was caused by the server binary not having any renderer-related data structures set up, while the latter issue was caused by the missing player controls messing up the server-side player thinkers.
The rest of the week I spent with the Shell, which acts as a standalone UI for servers. Here's an example of what the text-based app looks like:
As you can see, it has a basic console command line and history and a menu for easy access to functions. The text-based Shell will only be available on Unix platforms where it is commonplace to run stuff in a terminal, particularly on servers.
The GUI Shell is a more full-featured interface. It reuses the console command line and message history from the text-based UI, but will also feature a fuller set of status monitoring facilities. This is what the Shell presently looks like on Mac OS X:
However, please note the UI is still a work in progress... Some elements are missing and/or will be revised.
As a background process, a server should not have any dependencies to UI or graphics libraries. However, such dependencies have hitherto been unavoidable because the server and the client have been located in the same binary. Now that they're separated, I was finally able to sever the remaining ties doomsday-server has to OpenGL and GUI. As a consequence, the server binary now has no UI of its own any more — the old dedicated mode text console has been dropped.
A similar convoluted situation with dependencies existed in the libdeng2 (Doomsday 2) library. I split it into two parts so that the GUI-related functionality is now in a separate shared library called libgui (e.g., deng_gui.dll) that links with GUI and OpenGL.
The changes made to the server binary are actually quite profound: because there is no UI, there are also no window management and input events and thus no need for a bindings system or player controls. In other words, quite a hefty chunk of code was omitted from the server. This is a nice example of the evolution that the client and server binaries will be exhibiting in the future: engine subsystems will be refocused with the client/server architecture in mind, with only a selected few systems spanning both.
Some regressions had crept up in the unstable server, so I took a few moments to fix them: the server was crashing when any plane was moved, and the initial player angle was incorrect when a new client joined the game. The former issue was caused by the server binary not having any renderer-related data structures set up, while the latter issue was caused by the missing player controls messing up the server-side player thinkers.
The rest of the week I spent with the Shell, which acts as a standalone UI for servers. Here's an example of what the text-based app looks like:
As you can see, it has a basic console command line and history and a menu for easy access to functions. The text-based Shell will only be available on Unix platforms where it is commonplace to run stuff in a terminal, particularly on servers.
The GUI Shell is a more full-featured interface. It reuses the console command line and message history from the text-based UI, but will also feature a fuller set of status monitoring facilities. This is what the Shell presently looks like on Mac OS X:
However, please note the UI is still a work in progress... Some elements are missing and/or will be revised.