Category Archives: Code

Posts about Code.

GLESGAE and Scripting

0
Posted by stuckie on January 31, 2012 – 10:40 am
Filed under Code, GLESGAE

It’s been a while since I had time to look at GLESGAE, but I had some time last night to do so.

I’m surprised that it’s still relatively clean, and in a working state! But I did seem to split it and spew it across all manner of source control systems – two public SVNs, a public git, a private SVN and a private git – so finding the current version was fun.
Though from what I was up to last time with the rewriting of the graphics system, it looks like I broke shader support – but then for what I’m about to do, I’m not going to be needing that for a while yet anyway, so that can be fixed in due course.

One of the things I’m particularly partial to is that of offloading as much as I can get away with to a scripting language. This generally allows quicker iteration of ideas, and anything that slows down can (generally) be easily translated to a native function if need be – you’d just need to overload the function call!

For the most part, my language of choice has been Lua.
It’s fast, it’s small, it’s very easy to embed and extend, and I’ve been fiddling with it for years now.
I do like me a bit of Lua.
Lua was going to be my first choice of implementing a scripting language into GLESGAE… however, with the rise of HTML5 and JavaScript, I’m having a slight change of heart.

The past few months, I’ve been looking over HTML5 and JavaScript. Having quick fiddles here and there, and playing with things like Impact, WebGL and Canvas directly. While it’s been relatively painless on my development environment of choice – Linux and Chromium – it’s not quite been as easy to get things running on other browsers without oddness, and especially on mobiles as generally they lag well behind their desktop counterparts, and are a much more constrained platform to work with.
Luckily, there are several projects providing technology to help bridge this gap – such as Appcelerator, and AppMobi’s various projects, to name a few. These work by binding JavaScript to their engine-like system, and parsing it directly without the overhead of a full browser, as well as providing a bunch of extra overloads and libraries for various things to make your web app feel and act like a native app.
This is nice and all, but they also throw in everything and the kitchen sink ( the test apps for both companies are actually labelled as such too! ) whereas for doing something like games, you don’t generally need as much, or would at least like to get rid of as much cruft that’s not being used as you possibly can.

So, I’ve been thinking that the first scripting language that GLESGAE will be supporting is JavaScript.
However, this brings about it’s own dilemmas… supporting JavaScript isn’t exactly an easy endeavour as it’s more of a specification of ECMAScript than of a nice compact module or library you can just throw into your code, like Lua. As such, I’ve been looking at JavaScriptCore ( and the entirety of WebKit in general ) and Google’s V8 to use in such a manner.

V8 looks really nice and clean, and provides a C++ API – which as I’m using C++ in GLESGAE anyway, is a nice little boost.. though wrapping around C isn’t exactly problematic anyway. I had examples compiling and running in a little under an hour, and felt experienced enough to take on the task of adapting a system-like interface for easily extending classes, managing contexts, etc…
There is a slight hiccup though.. I haven’t really found much of a way of getting it running on iOS nicely, and while GLESGAE doesn’t actually support iOS at all just now, it will do in the near future.

JavaScriptCore, on the other hand, does run on iOS… it’s also already embedded in the OS to begin with as it’s part of WebKit – which powers Safari. It exposes a C API to deal with binding, and while there’s certainly more tutorials and examples on using it, it just doesn’t feel as “clean” as V8 does. That said, it’s still straight-forward enough to use.

While I really do like V8, and would much prefer to use that.. it seems that without it supporting iOS at the moment, my hands are a bit tied ( I’d love to be pointed to some help on actually getting it compiling and working on iOS without resorting to jailbreaking the device! ) So it’s JavaScriptCore for me.

This will all be added to what is now going to be the main and only supported repository of GLESGAE; The github project. I may still maintain a personal one for random fiddlings, but the public engine itself shall be opensource under the LGPL v2.1 with the terms effectively summarised as:

  • You can either link via a shared object ( e.g. GLESGAE.dll ) or you can statically link.
  • If you statically link, you must either provide the object or source code to your application along with any libraries and custom tools not available with a standard platform development kit that use this code, or simply provide a written offer, valid for three years, to provide these materials upon request to anyone with a legal copy of your application.
  • If you link via shared object, just note which version (GIT Revision/Tag or Binary Release Version) you have used.

    • The offer of a “private” license is still open as well, should the LGPL not be to your liking.

    Anyway, with that out of the way, and now knowing what I’m up to again, expect JavaScriptCore bindings in GLESGAE at some point!
    What? where you expecting an actual date for me to miss? ;)

    Engines vs Games

    0
    Posted by stuckie on October 28, 2011 – 4:46 am
    Filed under Code, GLESGAE, Random Gibberings

    Let’s have a quick moan before jumping on a train in the early hours of the morning.

    I think one of the reasons why I haven’t managed to get Quirks done much this month is that I’ve fallen into the trap of building up GLESGAE rather than the game itself – I’ve been building an engine rather than a game. ( Of course, the main reason is more lack of time, but this one doesn’t help either… )

    This is a trap I have a habit of falling into a lot, due to striving to try and get things “right” first time. That never happens! You code to what you need at that specific moment in time, and make it flexible enough to update later on, when your requirements change – part of the reason why I love component systems so much, as that’s effectively what they’re designed to do.

    A lot of the Ludum Dare projects I’ve done have been built on top of my old SGZEngine ( or SGZ2D, or whatever I named it at that point in time ) which had already had a good year or so of development time pushed into it, so was pretty full fledged already. GLESGAE, on the other hand, is still in it’s infancy. Getting it to do things requires actually writing the thing to do, and I think that once I get the component system and Lua bindings in, it should be easier to work with. That said, I did manage to do Thieving Fingers with it – even if it didn’t get submitted in time – and that was additionally with the “broken and convoluted” Resource System, so using it is doable and especially so since I’ve fixed a fair amount of things since then.

    But, sitting writing an engine isn’t going to get the game done… and there’s a constant fear of implementing engine features that aren’t going to be used, which of course just wastes time.

    But writing a game without an engine can make it hard to strip things out to reuse the code…

    Hmm… sod it, let’s go license iD Tech for Little Quirks.. I’m sure they’d find that hilarious ;)

    Git!

    2
    Posted by stuckie on September 1, 2011 – 9:03 am
    Filed under Code, GLESGAE, Random Gibberings

    Ahem.

    I’m rather used to Subversion as my source control system of choice. I use the very nice http://xp-dev.com/ for hosting of engine code, for example, and I have a few other SVN servers for hosting my own personal projects.

    However, SVN breaks down a bit with branching.. branches can get messy.. and it wouldn’t be the first time I’ve managed to kill a repository with a branch that just hasn’t gone in properly.
    From looking around my backup drives to clean them up the past few months, I’ve spotted a pattern I used to get around this – multiple local copies all over the place from different revisions, named with different experiments I was trying. Obviously this isn’t clean in the slightest, and it’s also rather confusing as to what the latest version actually is.. as I’ve counted twelve variants of SGZEngine all with slightly different bits and pieces, and some cleaner than others.
    This is a problem…

    Enter the distributed version control systems!

    There are two major ones that get touted about a fair bit these days – Mercurial and Git.
    My self imposed challenge for the next two weeks will be to have a look at Git and try get my head round it to start pushing stuff over, as it means I can branch out my little experiments much easier and tag them all properly, without losing information on what they are.. and anything important or fun, can be committed back onto the server.

    The following two weeks will be Mercurial, and I should hopefully have a favourite at the end of the month.

    Or I suppose, I could always go back to CVS….