Cairo Test

I am testing the cairo drawing library. I modified the transparency test program from my last blog post so, that it paints an avatar image with nickname instead of the pattern from the last blog.

I can move the avatar around and positioned it on top of a browser window. The result looks like there is an avatar standing on the browser - looks like everything is ready. But it's just a fake avatar. It is static, not animated, not from a chat room. It is just an image painted on a transparent window with the cairo drawing library. But as a cairo test, it is quite successful.

Painting graphics with cairo feels really backwards for us web programmers. We are used to markup: HTML, SVG, and XAML. Programming with "hard coded" functions like cairo_move_to, cairo_set_line_width and cairo_fill feels odd. No CSS, no div, no img-tag. Just good old C++ code with function calls.

I discovered another argument for cairo compared to WebKit. In a blog post (which I do not find anymore) a Google Chrome developer discusses the choice of skia. Skia is not hardware accelerated, which makes skia look like a bad choice. But, the Chrome developer argues, that most of the time the browser spends in HTML code, arranging DOM elements and applying hierarchies of CSS styles. Once the rendering code knows where to paint something, then only a small fraction of the time is spent for the actual drawing. This is a hint, that using WebKit is much worse performance-wise than using plain cairo. When we use cairo directly, then we get rid of all the time that WebKit spends dealing with HTML features. The trade off is, that there is no CSS, no JavaScript, and no iframe in the avatar display. CSS makes applying different styles easy. Styles and themes need much more effort in plain cairo drawing code. But it is should be much faster. And speed counts, because we do not want to slow down your PC.

OK, so, cairo works. The image above is only a fake. It is still a long way to go, but we are on the way.

Starting Avatar Display Development

The client has currently much backend code. It has all the protocol handling, user data, and chat functions we need. But there are no avatars yet. The "green" region is (almost) ready. The "red" region is still missing.

(Another part that is missing is a chat window. But when avatars are done, then the chat is a simple, trust me.)

(The IRC module will not be necessary for chat with avatars on web pages. Supporting the IRC chat protocol in addition to XMPP/Jabber is an option for later.)

So, now it is all about the "red" circle: animated avatars on a transparent layer over the web page.

The data is available, graphics is available, is just has to be painted. This sounds simple. But, it is not that simple. We are programming software that should be portable to different platforms, specifically to MacOS and Linux although the original development (and first release) is on Windows. Painting on different platforms is not as simple as it sounds, because it is not possible to use the painting functions of the operating system. These functions (called drawing API) are not available on other operating systems. And because drawing code is heavy and takes much time to write, it is not good to adapt it for each operating system.

What we need is a cross platform drawing API. Many of us use Firefox or Chrome on Windows, Linux, and Mac. These programs have the same problem. And they solved it by using cross platform drawing APIs. Firefox pains everything you see on the screen using a library called cairo. Chrome uses skia. These libraries are ways to abstract drawing, so that the display can be ported to other platforms with reasonable effort.

There are other ways to paint stuff in a platform independent way. One possibility is to use a HTML-renderer, such as WebKit. We could integrate WebKit and paint avatars and chat balloons with HTML and JavaScript. Actually, this is a good solution, because we intend to integrate WebKit anyway for program windows and dialogs. The only drawback is, that it is not much fun to write lots of drawing code in JavaScript. Also, performance might be a problem, because the drawing code would be interpreted by the JavaScript runtime and every visible element would be in HTML with CSS. This is how web browsers work and it is OK for them. But when you surf the Web and your animated avatar is painted all the time, then you don't want your avatar to take much CPU. A web browser can take much CPU while it paints a page, but after that it is silent. Avatars, however are animated and paint again and again. Very much like a Flash banner on newspaper page, that always draws CPU and slows your PC. We do not want to slow your PC.

On the other hand painting is much easier with WebKit than with graphics libraries like skia and cairo. Speed speaks for skia and cairo. The JavaScript programming issue speaks against WebKit. No easy decision. Do you have any ideas?

I the meantime, I made a simple program that just paints patterns transparently on the background. It is a demo to check how that works on Windows. All we have to do is to use skia, cairo, or WebKit or someting else to paint avatars on such a transparent layer. We will decide soon which library we will use.

If you have comments, let us know.

Hammer vs. Coffee Machine

I implemented a simple "competition" feature. Competition means, that some items can damage other items. This is another check of the item server design.

Competition is a bit more advanced and demanding, than the crafting. During implementation I learned, that we need floating point values in addition to integer values. I could map all crafting actions onto integers. But competition needs finer grained computations. So I had to change the database. I also added time values to implement a cool down period and had to change the database structure again. Effectively, the cool down implements a hit-rate limitation, which leads - in combination with damage values and modifications - to the usual DPS (damage per second) statistics.

Before I started coding, I modeled the behavior in Excel:



Here is what we can see at on the inventory web pages. This is the inventory with a hammer and a coffee machine. I used the coffee machine to make coffee, but the hammer can also damaged it:



This is the coffee machine. It is in perfect shape (Condition: 100%, Hitpoints: 1000). Obviously, the coffee machine is susceptible to shock damage and piercing damage. But shock damage is more dangerous. Piercing damage can be absorbed more easily.



The hammer. It can be used once per second (Attack cooldown). The hammer is a shock device. It smashes into something. It does no piercing damage. A knife would be different. The hammer makes 100 points shock damage. But the victim will absorb some of the damage.



Now I can hit the coffee machine one with my hammer with this command:
http://localhost:3277/Portal/Inventory/DroidAction/61/Hit/47
After the "hit", the coffee machine is in worse condition than before. It lost a bit of its "Condition" value (Condition: 93.0 %):



The hammer lost also a bit of its condition. Much less than the coffee machine. It is just a bit worn down (Condition: 99.9 %). The hammer will have to be repaired after some time in order to project the full damage.



Very simple, isn't it? But there are powerful mechanisms implemented which we will use later. The design of the item server has been verified and completed with workflows of different areas. The item server:
  • caches items,
  • loads items from a database
  • returns item properties on request
  • has user actions
  • has interactions between items, and
  • saves changes to the database

I will now leave the item server and return to work on the client. The client has lots of back-end and protocol code. But it does not really show avatars. We want to see animated avatars chatting on web pages. The client also needs a user interface. It needs windows, dialogs, a settings dialog, a buddy list, etc. But most important are avatars. That's the next step. Not a small one. I'll keep you updated.

Coffee and Cola Sample Implementations

I implemented a crafting process in the item server and the portal.

I am using two examples to check if the details make sense: coffee machine and cola dispenser with their respective ingredients and products.

The image shows all items which are currently defined. Most of them are for testing various functions.
This is a view of my visible inventory. One of them is a cola dispenser, a cola machine which makes a noname cola from water and syrup. It also needs energy. If I click the cola machine, then ...
... I see details of the cola machine. The machine is already equipped with water, syrup and batteries. It has a button to produce cola. When I press the button ...
... then I get an additional item, a small can of cola. Actually, a noname cola. Not very fancy, but still.

(For game designers: all item interactions are modeled with items. We took some days to replace a property driven model by an item driven model. It might be a bit less realistic, but manipulating items is more fun than manipulating item statistics.)

I can click on the cola can and see the datails ...
... including a button which lets me drink the can. Usually I won't drink it myself. I would offer it to visitors of my web site. If someone else drinks it, then we both get social points.

This is all just in aplain white design, actually not really a design. Only the bare minimum to check HTML/CSS structure and classes.

There will be a real design later. What about the green we were used to? or facebook blue? What do you think?


For developers: the item server has now 63 unit tests, the portal is still at 69. There are 74 different types of properties, which manage all item interactions.

Next steps: we will implement a little bit more item interaction, including damaging some stuff. After that we will turn back to the client and add a cool avatar display.