Sunday, December 11, 2016

Vala Revisited

The last time I looked into Vala, I became a bit discouraged. I couldn't find good tooling. The documentation could be better. I wasn't getting good performance. I think a full GObect is too expensive for game components.

I have found better tooling. There is a Vala plugin for VSCode I like vscode. It's fast, easy to use and flexible. I can focus on my code and stop worrying.

But whan I say Vala, I really mean Genie. Most of my code for valac is written using Genie. So I've started a plugin for Genie Along with the  LLDB, CMake and C/C++ plugins, I have all I need for quick iterative development.

Now about GObject. The documentation is unclear. All the examples extend it as a base class. Why do I need it? There are dire warnings that language features like interfaces and properties won't work without it. And then there is a disclaimer that 'In a more recent Vala compiler' this is relaxed. But there are no specifics. Has that version been released? I think I'm better off not reading the documentation.

So I've factored out GLib.Object to 'try it and see'. All my classes now extend a custom, empty object. In one posting, Gnome calls these 'Non-Object' classes. But, as it turns out, it makes no difference. When I removed GObject, no features were impacted. My performance problems went away, but adding GObject back in doesn't re-introduce them... So where did they come from? What changed?

Time passes - new computer. New OS. Newer SDL libraries. Newer Vala runtime. Take your pick. But the good news is that it works pretty good now. Comparable to Nim.

Benchmarking can be tricky. So I've tracked the average time per frame taken up by the update method on my game object. 

    time in ms

            nim           vala     
    min     0.00015     0.00019     
    max     0.00202     0.0035     
    avg     0.00082     0.0009     

At 60 fps, each frame is .0167ms, and these are all very acceptable times. Vala and Nim seem pretty well tied for performance.