by Karsten-Olaf Laux

The Concept

The development was started with the idea in mind to create an isometric client for Altima (back in those days, the project had this name.) The drawing engine, well in fact it did not deserve this name, was tile based, meaning that all entities were placed on a fixed grid with the possibility of an offset for finer placement. This concept is nice and fast, as long as you stay more or less in one plane; it fails however, if you want to display an environment, which is defined within a three dimensional space. So, meanwhile, uclient has advanced from the grid to a threedimensional coordinate system. This however brings up the problem in which order the entities have to be blitted to the screen; this is still not solved. Uclient is meant to use a screen resolution bigger than 800 x 600 pixels, so a system is needed to decide which parts of the screen have changed and thus need to be updated to the display. If the whole screen would be updated everytime a single entity has moved, it would creep like a turtle. To solve this the display plane is divided into small boxes (about 150 x 100 pixels) and a two dimensional bsp tree decides to which box a given entity belongs. So if an entity moves or changes due to its animation, only the box to which it belongs is updated to the screen. I plan to speed up scrolling similar to this in the near future.

In the beginning different threads seemed to me an easy way to implement independant processes within the client: user interface, database, drawing engine, server agent. However the development shows, that using threads has two major drawbacks. The main point is, that I cannot set different priorities: Why should the userinterface consume as much cpu time as the drawing engine? The fact that Windows does not implement threads is the second drawback. SDL emulates threads under windows, but that does not work very well. So I plan to unify the existing threads; there is no real need for them anymore: the drawing engine has short drawing cycles, user and network input get buffered.

Many ideas have been posted about the functions and appereance of the user interface - this issue deserves it?s own article in the next Chopping Block - but only some ideas have been realized by now. The essence of all discussion is that the user interface should be customizeable in all details in order to adapt the client to the different game worlds. In my eyes the user interface and perhaps other parts of the client as well will be completely defined by configure files at runtime: use this uclient.ini to have an WarForge Client or use that uclient.ini to run a Cyphesis Client. AppConf by Karsten Ballüder & Vadim Zeitlin will do a good job on this.

The Windows Port

Uclient makes heavy use of the Simple DirectMedia Library (SDL) to access any system services, so the windows and the linux version compile both from the same sources. For the moment just different makefiles are needed, but this might be improved in the future, too. For network communication uclient uses netlib from Sam Lantinga (author of SDL), this works under linux and windows as well. The user interface is based upon libu, a c++ widget library, which implements the signal slot concept and thus allows easy coding. As this library features some nice helper classes for points and rectangular screen areas, it is also used within the drawing engine. libu is based on SDL and thus works fine under windows as well.