Rendering Pt1: Windows on Windows

Since the Aberoth client is basically a renderer connected to the internet, I decided to describe the rendering process in more detail. I will also talk about the network commands responsible for rendering, of which there are plenty.

Part I: Windows on Windows

The first thing that happens after login is the client receiving a CREATE_WINDOW message. This message contains all the information needed to setup the clients main window, but mainly the screen size. The only two sizes sent are 960 by 540 pixels for widescreen and 640 by 480 pixels otherwise. Since by default one "Aberoth voxel" is four pixels wide and four pixels high, the actual resolution of the game is 240 by 135 (widescreen) or 160 by 120.
Slightly more interesting is the fact that the CREATE_WINDOW message contains a lot of stuff that is not used by the game. For example, it actually contains a window title, which is probably meant for the Java clients window. However, neither the Java client nor the HTML5 client make use of this title, so changing it will have no visible effect. In practice the title is always "Aberoth". The Java client uses the same title, but has the text "Aberoth" hardcoded into it and does not pull it from the message.
Another thing that is somewhat unused is the functionality to only enable specific input events. With that it is possible to, for example, disable all input from the mouse or the keyboard. Why a function like this exists is not clear to me, neither is the fact that it is possible to enable tracking of mouse movement. In practice, keyboard input and mouse clicks are always enabled, while mouse movement tracking is disabled. The HTML5 client actually rejects messages that specify otherwise.
Finally, there is the window Id. It is used to tie user input to the window. I have never seen window Ids with a value other than 1.

The main rendering actually does not happen on the main window, but on subwindows of which there can be up to 256 different ones. They work exactly like layers in an image editing program. Like the main window, they have an Id, which doubles as their rendering order. Subwindows with higher Ids are drawn on top of those with lower Ids.
The Subwindow with id 0 is created by automatically by the CREATE_WINDOW message and has always the same size as the main window. All other subwindows must be created by a CREATE_SUB_WINDOW command. This command contains the id of the new subwindow, as well as it's size and position on screen.
The server selects which subwindow it wants to render to by issuing a SWITCH_TO_SUB_WINDOW command. This command contains the id of the subwindow that should be used for the following rendering commands. When the server is done rendering to that subwindow it can use the SWITCH_BACK_TO_PREVIOUS_SUB_WINDOW command to... switch back to the previous subwindow. It is only possible to go back to one previous subwindow, since only one is saved when switching. Interestingly, the SWITCH_BACK_TO_PREVIOUS_SUB_WINDOW command actually also contains a subwindow id, which goes unused.
Finally, if a subwindow is no longer needed, the server disposes of it by sending a DESTROY_SUB_WINDOW command. This command will remove a subwindow from the renderer.

Some interesting stuff about subwindows:

• Subwindow 0 is the contains the main gameplay. It is created by the CREATE_WINDOW message.
• Subwindow 1 contains the player's HP bar.
• Subwindow 2 is used for the experience bar at the bottom of the screen.
• Subwindow 3 contains the realm indicator in the bottom right corner. 
• All items in the player's inventory live on their own subwindow. This makes it easier to find out if one of the items has been clicked, since the subwindow Id sent on every mouse input.