But it’s true. I’ve now had the (dis?)pleasure of working with several GUI systems both through work and outside of it. There have been a great many people who have attempted to tackle “The GUI Problem” online. I believe I have the reason why there are so many different solutions, but they’re all awkward to use.

GUI is easy.

It’s just 2D. We work in 3D now, the 2D stuff is no problem.

Right?

NO!

Getting a nice GUI system is very difficult. The system itself should take just as much care, architecting and design as a physics solution. On top of that, usually, you don’t want programmers just tweaking values, so you have to spend a good deal more time on top of that making an artist/designer interface. These things seem to have been overlooked.

Let’s take a step back and look at the different types of GUI solution available at this point, in particular for games. I will attempt to not use names to protect the guilty (ha!)

Firstly we have the most basic of basic, an Immediate Mode system. This is very quick to develop, and pretty quick to prototype. It’s straight forward. It’s clean. You tell it to draw a button and it draws a button. So what’s the problem here? Well, unless you are one of the incredibly rare crossbread of programmer/designer/artist, you will find this incredibly cumbersome. Yes, you can throw together a layout pretty quickly, but you actually have to do the throwing together in code, and it usually ends up with the GUI code being spread throughout the project, as different things might need to display things at different times. If you plan this well, you can consolidate all the GUI code in one place, but even then it becomes unsightly and awkward.

I will skip the more standard code driven system as it has many of the same shortcomings as Immediate Mode, apart from, for the most part, you can init and forget, instead of manually drawing every image every frame. But that leads me nicely onto a data driven system. For the most part these work in a very similar init and forget way, but there can be little to no actual GUI code written. The GUI layout is loaded in as data files. The benefit here is that you can quickly change the GUI without recompiling. This is actually a very good system, as long as it doesn’t take 30,000,000 XML (yeuch!) files to be written before you can display anything.

Before I go on, I should say that at no point, yet, have we seen an editor. It’s even safe to say that for the code driven systems, it’s near impossible to make one (unless you want to make an editor which outputs code, which I guess is an option…) This displays one of the biggest issues with GUI systems. Editors are always an afterthought. GUI systems are written by programmers, so they have programmer interfaces first and foremost. Editors come after if/when there’s time and they seem even more of a tacked on addition to the tacked on feel of the GUI system itself.

Finally, the most favourable option right now, is to use an existing format for GUI. The “industry standard” is using Adobe Flash through Scaleform. I myself have used something similar. Artists love it. They can design the GUI in an environment that they are familiar with and they can have access almost straight away to a lot of shiny features and animations. Leaving any prejudice of Flash behind, the IDE is possibly the pinnacle of what could be considered GUI editor design.

Am I saying we should all be using several thousand dollar flash libraries for our GUI? Definitely not. This causes a lot of issues, if you take a moment to think about it, it becomes obvious. Flash is designed to be entirely standalone. True, you can send things across the net to have your flash application talk to other things, but in general, it doesn’t expect to be communicating with anything else.

Very usefully, flash actually is quite flexible. You can try to call a function in actionscript which doesn’t exist. Most languages, if you tried to do this, at best you get a message our assert saying it can’t find the function, after which behaviour may be a little unexpected. At worst the program crashes, that’s if it’s allowed to compile. Flash shrugs it’s shoulders and continues as if nothing happened.

This means that within your game, you can implement some new magic functions and when you do any testing add a standalone flash application, it will just ignore it. This works absolutely great for menus as they can be, for the most part, pretty self contained. When it comes to in game GUI, you usually require a much tighter link with game code to make it feasible.

Basically, what I’m getting at is that the best solution right now can only be a series of hacks.

I’m not denying that they are good hacks, but they are hacks. And hacks are almost always the weak point.

There is one more solution that’s come up more recently which is to use a 3D editor to lay out the GUI in 3D, then draw it using an orthographic camera. This is a great idea in principle, it makes the GUI part of the actual game world so it makes tying into game code almost trivial. It allows you to use whatever editor software you already have set up for game design. I still have issue with this. The best 2D artist/designers I know are just that, 2D designers. Sure, we can ask them to learn 3D tools, but it’s a workflow that they’re not necessarily most comfortable with.

There are a great many things to consider here. Am I just going to sit back and complain? Well, I’m tempted now. But I can make a couple of suggestions. Most of which I am attempting to address in the combination of Maratis and Löve2D. First of all, the system should be pretty easily integrated with any game code. This will come down to the API I expose on either side of the interface but as the interface can be entirely open (unlike the flash layer) then that shouldn’t be an issue at all. Secondly, the editor. I would absolutely love to be able to use an existing and proven editor, but that would probably end up as another series of hacks. The main thing is that, from the word go, the editor should be planned for. Finally. One incredibly important thing which I haven’t mentioned yet, and possibly should have, is flexibility. No GUI solution is ever complete. There are always bespoke things that the game you’re working on will need. Making the system flexible enough to extend is fairly easy, making the editor accept and respect the extended features is a little more complicated, but should be do-able.

Anyway, I think I’ve ranted enough about this topic. I would love to hear if someone has any experience with GUI systems, especially if they think they’ve found a good one. Also, with more user interfaces now moving into 3D, is this even relevant any more?

I failed to notice the supported version of OpenGL.

The Intel i915 chip meant that it only supported OpenGL 1.4.

OpenGL prior to 1.5 would only support one texture coordinate per point.

So yes. I got one texel per particle.

While trying to figure out what I was doing wrong, I made some headway in terms of allowing the particle system to not only have point sprites. As I’ve spent all this time trying to get point sprites to work, you might think “why bother”. Well, the thing is, point sprites are very limited. You can’t really do arbitrary rotations per particle, from what I can see. You can’t specify different sizes per sprite. You can’t have animated textures. But what you can have is a great many particles, very very cheaply. I really have to start tying the profiler into this, but I’m pretty sure that, even with my pretty simple calculations in the update, it’s still more likely to be a bottleneck than the rendering. Hopefully soon I will have empirical evidence as to what the performance is like. Before I do that, though, I think it might be a good idea to know what sort of numbers I would aim for. I will probably start thinking about that within the next week.

It turned out that I did end up that my netbook, which I also had with me, did support OpenGL 2.1, unfortunate that I didn’t realise until the last day, after I’d spent a day reformatting and setting it up.

Anyway. I did finally make some breakthroughs when I got back home. It turns out that, for some reason, I cannot specify a colour array for a vertex array of point sprites. I was either getting it drawing everything in black, or not drawing at all. Things started working a bit better when I removed the colour array altogether. I’m not entirely sure what I can do in this case, because, with the way things are set up, I need the colour array to hide the inactive particles.

But, I have textures. And I made a little video to show it. So that’s a start.

What is left to do then? Well, a great deal. As I’ve said, I want to do some profiling. The reason is that potentially I still would like to move the update functionality to the GPU. Any GPU work would not be done any time soon, but need to be considered with any data/design decisions. There’s still the standard billboard quad sprites which need to be implemented, along with extra features for them, like rotations, and growth. Finally there’s the world interaction, I want to be able to block out a room, and get particles to fill it with smoke, then drop an object into it and have the smoke swirl around it. I don’t think that needs a lot of physics work. In fact, I think we can probably get away with AABBs for the most part of world collision, maybe a couple of spheres, and simple sphere collision between particles.

There’s still a lot to do, and unfortunately a lot still to think about and plan, so, while I try to make decisions about some of them I will tidy up the interface, tidy up what’s exposed to the editor, and maybe make some examples of what currently works. See how things go.

I have to admit, I’ve not done anything overly interesting with the particle system as of yet. It’s still just spraying out a few hundred black dots. I unfortunately haven’t really had time to sort the textures for the point sprites, nor have I had time to add any new features. It’s been a lazy day. I have, however, done some research into OpenCL.

Now. At this stage, OpenCL is overkill. I don’t even have a fully functional particle system. However, it’s something I don’t know much about, and it’s definitely interesting. Plus, I think it would be a nice feature at some point to be able to have an options menu somewhere and say “High Quality Visuals” or something… anyway, I’m getting ahead of myself. I will be from for the majority of this next week, I’m going to take my netbook with me, but it isn’t designed for anything particularly heavy. I have, however, been trying to set it up so I can easily develop on it, so I’ve been pulling all my projects, making sure they compile, run etc and that I have the latest version of Maratis for them to compile against. After this was all sorted, as well as non-computer related tasks, I had myself a couple of hours, so I thought I would dip into OpenCL briefly. Actually, that’s not strictly true, I had a random urge to look at functional programming languages. After I scraped what was left of my brain up, I attempted to look at OpenCL.

I had a couple of things in mind when I was looking into what I can do. Firstly and most importantly for me, how good is the documentation/support. A library can be the best thing since computers made beeping noises to connect to the internet, but without some clue as to what to do with it, it’s near to useless. I don’t have time to practically reverse engineer things. So, what did I find. Well, to be honest, I was a little let down. There are certainly books and tutorials and everything you’d expect, but not the plethora of choices I’m used to when I type in <something> tutorial into Google. On the other hand, I didn’t have to wade through too much useless garbage to find what I wanted, so I guess I can’t complain too much. Secondly, how easy was it to install and set up. I would give it a little flexibility here as there are 3 major GPU manufacturers, and one organisation trying to write a standard. I got pretty much what I was expecting. Everything installed smoothly and I had an empty project linking to the newly installed libraries within a matter of minutes. Finally, the API itself. Now, I definitely haven’t spent enough time to be able to tell you how much I like or dislike it, but it seems decently structured. Everything is in the cl namespace, and then neatly sorted within that. I was a little disappointed to see that “Hello World” was 93 lines long, plus the kernel, but having sorted through the code, the majority is aggressive error checking and boilerplate code.

So, my current opinion? Well, I wasn’t horrified by anything I found. I was quite happy with the API and I think adding OpenCL support to MParticle would be a worthwhile investment at a later date. It will be a considerable amount of work so before I begin working I think I will wait until I know that what I am wanting to do with the particles is definitely too much for the CPU.

There is one more thing that I would like to add before I finish up tonight. As MPlugin slowly gains more functionality, I would appreciate some feedback as to how people would use it. Unfortunately with the plugin code not being even in the upstream Maratis svn repository, I can’t realistically expect people to test a plugin that they’d have to totally recompile Maratis from an unofficial source for. However, if someone is interested, feel free to send me a message and we can try to arrange things to be set up in a more comfortable manner.

So, what do people think? Am I aiming too high too early with even considering OpenCL now? Have I forgotten something in my research? Can you suggest some way to make testing MParticle a bit nicer? Whatever it is, I’d like to hear your thoughts.

It may not look like much, indeed, it’s not much at all really. It sprays out 1 particle every 5ms with a random spread up to a maximum of 20 degrees. It also has “gravity” acting on it. Although, MPhysicsContext doesn’t allow you to retrieve the world gravity, so I have hard coded that. Everything else is exposed to the editor.

So far, the particle emitter will only create 1,000 particles. I’ve attempted to increase the emitter to 10,000, but it takes a long time, then hangs. Not quite sure why at this point, but that shouldn’t be too much of an issue really.

What’s next for the particle system? There’s still a lot to do. I think, potentially, the next logical step is to actually texture the points, so we can start creating pretty particles. After that, there’s quite a few other things to do, like semi-physics collision between the particles (I see a significant framerate sink here) and also allowing for some more fancy features, like spinning particles.

Which leads me onto the next point. We can’t use point sprites for everything. They will be ideal for displaying a large amount of particles, as they’re cheap, but they don’t allow for things like rotating the sprites. Which means for some particle emitters, we might want to add a flag to draw the particles as tri lists. That would mean we not only have 6 points per particle, but we also have to maintain a separate array for this, possibly create or update it every frame. I am willing to bet that this will have a reasonable performance hit, but we can then also only draw the active particles. Particle emitters which have rotations will probably have to be kept to a smaller amount, but that shouldn’t be too much of an issue. Non-rotating particles can be kept as point sprites.

Anyway, that’s it for now. Now it’s time for lunch. Then probably attempting to texture the particles. Wish me luck?

I don’t think it exists. What I mean is. I don’t think there’s a “nice” way to organise the data, at least for what I’m planning. I would like to be able to, potentially, have multiple particle emitters interacting with each other. A direct example is, in my game, I want to have a smokey room. Potentially I can put an emitter near the ceiling which will create a smokey ceiling. That should work reasonably well. But I also would like to have someone walk into the room and have them smoking, and their smoke join with the smoke on the ceiling. I guess I could just have separate emitters and them not actually effect one another, it would probably look alright, but I think, if possible, I’d like the ability to have particle systems merging.

So, what that suggests is splitting the code into 3 different classes, at least initially. The first will be the emitter itself, this will be a behaviour and be able to attach onto any object. I would like to have a derived MObject3d, but I don’t think that it’s possible at this stage, so I’ll make do. The second is a particle system. I’m playing with the idea of having multiple systems, but I think I’m probably going to stick with a singleton. This will be in charge of updating and managing the particles. Finally, the particles themselves. As far as I can see, they don’t need to be much more than pure data.

But, with one “system”, we can maybe have crazy things happening, like water getting blocked by smoke and stuff, right? Well, yes and no. I’m hoping to put in some sort of rudinemtary physics, probably bounding spheres on the particles, and then give each one a mass, so water should, theoretically, be able to push the smoke aside in a semi-realistic manner. Whether this is going to work or not is a different matter. Secondly, you could easily add flags to each emitter, stating different emitter types it doesn’t interact with, so the smoke wouldn’t be affected at all. That would obviously be a lot cheaper and might avoid nasty effects of cheap physics. We’ll see how this goes.

So, my issue from the previous post. Where does the positional data live? Indeed, where is the ownership of any data at all? Does the particle manage it’s own lifetime? Does the particle system? Or the emitter that created it? This is where I feel it really gets messy. When you start thinking of the fact that you could potentially have thousands of particles to manage every frame, some newly created, some about to die, you don’t really want a huge load of reallocations. So, it’s probably best to keep a pool of particles within the system. That way we can  just have a giant array within the particle system that we can use. But the issue still stands about the positional data. We really want one big array of positions in the emitter, so we can draw it as one array of point sprites. So we have to have a similar pool within the emitter of positions, then, when we emit a particle, we give it the address of it’s own position. For both these pools, we also need to keep some sort of list of the available free data which we can use for allocating new particles.

It’s sort of nasty having the particles themselves being managed by one thing and their position being owned by the emitter, but I can’t think of a much nicer easy to do it. At least with this plan, the particles are being managed separately so we can make them interact, but don’t have to build a new vertex array every frame.

What about dead particles though? Well, nonactive ones can be skipped from updates with a simple flag. Removing them from being drawn is a slightly bigger issue. Ideally, we don’t want them in the vertex array at all, so they won’t take up draw time. However, as we probably want random lifetimes fort particles (within a range) then there’s no simple easy to guarantee which ones will be alive, again without rebuilding the vertex array every frame. The solution I will try is to also have a colour array. Usually this can be set by the particle definition, our even interpolated over time, but dead particles will then be able to be made totally transparent. They are still being drawn, which isn’t great, but I hope, as I would like to be using point sprites, that this overhead will be less than the alternative. There will be further investigation, I’m sure.

So, all this talk, no action? Not at all. I haven’t pushed anything to github yet, because I have nothing much to show, I’m still in a planning phase really. I do, however, have the majority of what I’ve got mentioned above. I don’t have any physics or rendering, but I have the majority of the framework in place to do these things. And thanks to debuggers, I can verify that everything is working pretty well.

I just hope I haven’t overlooked anything major.

Please let me know what you think. Do you think this is likely to work or had something I’ve suggested got a much larger overhead than could be usable?

Edit: So, I’ve got the particles moving “up” and also rendering. I’ve already noticed two problems. The first is that I can’t seem to be able to set the alpha on the particles. Not too big an issue, I probably don’t have alpha blending on or something, I’m sure that’s solvable. The second is that, from what I can tell, Maratis doesn’t support Point Sprites as a primitive type (yet). I guess this means that I’m going to be modifying Maratis code some more. Code will be uploaded to github presently though

Having said that, not everything is a loss. I mean, I have written a (small) particle system before, but I definitely think I’ve learned from prying into PAPI. Hopefully I can make a better system now than I did a couple of years ago.

So, what was the problem with PAPI? It seems like only yesterday I wrote about it. Am I giving up on it too soon?

Woh. What’s with all the questions? Right, so. It wasn’t yesterday, it was actually exactly a week ago I wrote about it, but I’ve actually been wrestling with some of the PAPI stuff for a few days before I wrote anything. As such, I think I’ve given it more than enough time and it’s come up with a lot of little perculiarities which caused problems.

The main problem is one I’m going to have to overcome at some point myself. I’m not saying the solution that PAPI had was incorrect, but it definitely wasn’t suited to what I want to do. The problem is that each particle is it’s own entity. It has it’s own age, mass, velocity, position. That’s all absolutely correct. It makes perfect sense to bundle these up together, in a struct for example. But then, when you get around to render them, you don’t need all this information. All you need is the position. In fact, to do the fastest rendering, you need all of the positions in one big array which you can pass to the GPU.

The way that the PAPI examples worked is that they just gave an array of Particle structs to the GPU and then used the stride to skip the bits that it didn’t need. I checked the size of these structs, 144 bytes. A position is 3 floats. 4 bytes each. Assuming a particle system of, let’s say 1000 particles, that works out at a little over 140kilobytes for the array in place of a little under 11kilobytes. Now, I haven’t checked whether OpenGL is clever enough that, when you give it a vertex array, tell it that you’re using floats, but give it a stride of 144, it would not send the data that isn’t needed to the GPU. If it does that, I’m impressed, but even then, it’s probably extra overhead, having to seek. Either way, I don’t like it.

I said that it’s the main problem even though I don’t know if it actually caused any problems. The reason for that is quite simple. I spent a while looking into the code and, much as I understand roughly how the system works, a lot of it just seems to spring out of nowhere. Like the vertex array, it took me a little while to figure out why the stride was 144, for example. Hopefully, if I try and write one from the engine side, rather than writing a system from the particle side and trying to make it generic, it might be clearer, at least in the context of Maratis. A particle system isn’t overly hard to write, after all.

So, if I’m going to start writing this myself, how am I going to start? Gah. To be honest, I have no idea. I’ve been looking into different things and trying to decide what the best plan of attack is. As I’ve mentioned in the previous post, I would like the posibility of moving the bulk of the calculations onto the GPU at some point, if they become too heavy. I haven’t done any GPU programming yet though. I also like the idea of potentially tying it in with Bullet. Although that would probably remove all chances of GPU work.

I have yet to do a little more planning on this before I get started, but, so far, my proposed plan of attack is to read up on the GPU stuff, but not intend to implement anything at this stage. With some extra knowledge, I should be able to write it in a way that leaves it open for that later. I can then start working on a simple particle system, just working with some simple trivial physics calculations. At that stage, I should be able to assess performance and what has the greatest potential. I expect, what I would probably end up doing is to add some very basic physics shapes as particle blockers of some form. Probably even keeping them axis aligned. Then they can be added to objects in the world that particles are meant to interact with. In that way, I don’t rely on the whole Bullet collision system, and I’ve got some physics to get some collision objects that I can have particles interact with.

I don’t suppose anyone has any experience with this at all? I’d love to hear what you’ve got to say about any of this.

More updates once I’ve done some more planning.

The idea of this plugin is that it will be able to create a profile of the engine and game (and other plugins) in order to tell you how much time is spent in what parts, helping to identify bottlenecks.

So, let’s talk about the aim of this little beast. Starting at the beginning of the minimum functionality then.

• Simple plugin that, when found in the Maratis “plugin path” will spew the time spent in each function in Maratis Engine/Core/Gui/Editor/Player to stdout.
• Simple config file and ability to output to stdout and/or file (on close)
• MGui popup window with profiling information displayed in real time
• Ability to track memory usage, creating a second tab for the MProfiler window
• If I get to this stage, might be nice to generate graphs, have config options in another tab etc.

Now, for something which doesn’t add directly to the game I’m making, this seems like a lot of work. However, it’s something I think will will be both useful for the game, but also for testing the plugin architecture and workflow. Things like working out a standard way to sort the plugin UI, doing a relatively easy plugin, seem like a good way to start things.

Starting at the beginning then, it’s probably quite obvious that I haven’t split up how to make the profiler at all. There’s a very simple reason for this. That is that I don’t plan on writing one. In fact. I’ve basically already completed this stage. I have chosen to use Shiny Profiler as the base for this plugin. It claims to be lightning fast and well documented. We shall see.

So, the way that Shiny works is that it requires tags to be put into the source code, they are macros which will automatically interact with the profiler. In itself, it’s very simple to add to an existing project, the issue is that it’s not quite the design I had in mind. For this to work, shiny would have to be a library, compiled into Maratis. As we’re making a plugin which shouldn’t always be available, this seems like a bad plan.

I have had to do a little bit of surgery on the Maratis source code to get it to work, which I will explain in the next post, but the basics is that there is a MProfilerContext in Maratis Engine which is null by default and a series of macros which evaluate to nothing in release builds, but in debug builds look for a MProfilerContext and send information to it. The plugin then registers itself as the current profiler, when loaded, and awaits information to be poured it’s way.

Once that’s hooked up, every function within the Maratis code has to have these tags put at the beginning of them. This is a LOT of tedious work. I could probably write a script that does it, but I haven’t yet. I’ve done the majority of Maratis Editor and tested it to get some sensible numbers coming out. Just have all the other tags still to put in, then I can move onto part 2.

Shiny Profiler doesn’t sort memory profiling. I’ve found no libraries which would do that actually. That’s not too much of an issue, although it will take further Maratis source butchery. I’m also not sure, at this point, how the best way to do it is. Of course the way to sort it is to implement a custom new/delete. These can then do a similar thing to the tags and check if there is a current profiler. This has the main problem that there are potentially a lot of new/delete calls before the plugin gets initialised. I guess it’s not too much of an issue as, in general, people would be most interested in profiling the memory usage in their game, rather than the engine. Also, as it will be using the tags to provide the scope in the profiler and the engine will most likely be compiled without the tags, it’s only going to be relevant for the game-side stuff anyway.

If you want to grab the code, it’s up on Github, as usual, but it currently won’t work without some Maratis changes. Let me know if anyone’s interested and I’ll package them up for you and stick them somewhere.

Well, that’s about it for now. Does anyone have any comments? Much as I’ve done a little of this at work, I’ve been using systems that have already been set up, so I’m pretty much flailing in the dark here. But doing so happily.

I have begun work on attempting to integrate it with Maratis/MGui as a “behavior” in a dll. Unfortunately, at this point, it doesn’t seem to work. Ok, more than that, it crashes. Still, I’m happy that it actually compiles with the minimal work I’ve done. I will look into why it crashes and fix that. If anyone wants to take a look at the code, it’s up on github for all to see.

So, what are the goal of this particle system. A quick list to see what we’re wanting to do:

• Be able to place multiple particle emitters around the level. Probably as a behaviour is easiest.
• Be able to tweak emitter variables from within Maratis Editor and see things update within the editor without running the game.
• Potentially use MPhysicsContext (Bullet) for particle behaviour.
• Potentially move particle behaviour onto GPU.

Now, it’s unlikely that we can do both using physics for the behaviour and moving it onto the GPU (although Bullet now can do calculations on the GPU). It just depends how things look, how it will evolve I think.

The thing I would really love is to be able to create a particle system which emulates a cloud of smoke and reacts to the player moving through it, swirling around them. I’ve looked into fluid dynamics and I think, in order to model this on the scale of a particle system, it really should be on the GPU, but using a physics system might be able to approximate it well enough.

What do people think? Any experiences at all with this?

Well, yes and no. Maratis does one thing really well and that is that it’s very easy to set up a 3D scene and have something working. I would even say it does it more or less as well as much more mature engines like UDK. What it doesn’t seem to do well is 2D.

“You’re making a 3D game, why are you worried about 2D at all?”

I’m not as such. But almost every game, whether 2D or 3D has 2D in it somewhere. Menu systems and heads up displays (HUD) are two common offenders. Maratis has an inbuilt UI system for user interface, but it’s currently not exposed to (game) plugin development and also, it’s entirely code driven. That’s great, if you have a coder who is also the artist and designer, but, anyone who has seen my art would understand, I’m no artist.

The other option in Maratis is to do the UI in a 3D scene and render it without perspective on top of the actual 3D scene. This is actually an acceptable solution as it’s more or less how any 2D system would do it anyway, but having to do the layout in a 3D editor seems more than a little clunky, and a lot of 2D designers/artists are unfamiliar with 3D stuff, making it a pain in the neck to use for all concerned.

Having said that, I’m actually pretty good at UI layout. But it’s usually a tedious to-ing and fro-ing between the person who made a mockup and myself “move this 2px up and 1px to the right” etc. What would be ideal is if the artist/designer who made the art in the first place could just save what they’ve done in some sort of format that the engine could open up and use. Then a programmer can tie in any functionality into the game, either before or after the 2D work has been done.

The first thing that I should mention is that this has been done a lot of times. A lot of AAA games use Scaleform, which basically renders a Flash swf on top of the game. That, in itself is derived from the public domain gameswf library which I’ve had some experience with. I decided, much as flash is widely used, I would keep away from it for now.

Enter löve2d. It’s an amazing little 2D game engine. All the development is done entirely in lua. It already has several pretty nice looking UI libraries. Now, it’s more complete than we “need” for a UI system in Maratis, it’s unlikely that UI will ever need Box2D for example, but there’s no reason to take it out as such. If we could get love2d integrated into a Maratis plugin, we could then maybe use love files for our UI, or maybe even do something a little more fancy.

Now, the astute reader will notice that we’ve not actually solved the problem here. A programmer will still have to write all the love UI code, right? So why not just do it in MGui in the first place? And we’re involving another language which we potentially wouldn’t have a dependency on. (ok, Maratis already has lua inbuilt and all the examples are lua, but you could do the entire development in C++ if you wanted) So again, why integrate this whole engine, when it’s not making any difference?

Well, I think it will. Right now, every love UI library requires the layout to be done in lua. Which is no good. I recently set myself a little task to see how difficult it would be to write a data driven UI system in lua. I have to admit that it’s not very nicely written, yet, and that it’s nowhere near complete. However, it’s a proof of concept at this stage. I even started working on an editor, although, I’m still in the design stage of how that should work. If anyone wants to check this out, I’ve stuck the work onto github. Would love to get feedback on it.

The main thing that I think is a really great thing for this is that, on every project I’ve been on, we’ve needed custom UI elements. It’s unlikely that any UI system has covered every possible option for what you would need. If it has an editor, the chances are it’s also not flexible enough to allow you to create your own elements. If the UI code is all in lua, as lua is interpreted, the editor can load the standard UI elements itself, then look in the project and add the definitions for any custom elements. Basically the editor becomes as flexible as the UI system itself. That’s the idea anyway.

The other benefit of lua is that it’s incredibly quick to prototype things in. When I’ve written custom element definitions in C++, it’s required anything up to a few hundred lines in source and header files as framework, before it actually did anything. Ok, that might be a bit of an exageration, but when I was creating new elements in lua it was much quicker.

So, in summary. Using Löve2D within Maratis is overkill. It’s also likely to be the quickest and most flexible solution to 2D UI layout, without resorting to Flash.

Or does anyone else have any other thoughts

I always have a design, even if it’s just in my head, of how I want things to work. My design is usually coherent with itself and, when coded, should make a reasonably decent, clean, efficient application.

Libraries don’t always agree with my design.

This is why I usually end up reinventing the wheel and trying to write everything from scratch.

My current pet peeve is libraries for file loading, such as image and model loaders and in particular, currently, the FBX SDK. My resource management design is that I have a resource manager that loads the files and copies the data into file classes, created from factories, which then know what to do with the data. The reason behind this is that at a later date it will be easy enough to replace/extend the resource manager to load the files from an archive, decompressing the data into the buffer in the file classes. This means it’s only the resource manager that would need to change, nothing else cares where it comes from, and the resource manager only has to change one code path. I could even stream data over the internet or by sampling electromagnetic waves around the computer, it wouldn’t matter.

I’ve talked to other programmers, and they agree, this is a reasonable design. So I set up my file loading framework and made it load, and parse my config files. No problem. All my code. Nice and simple. Next, I wanted to load an image to display on screen. libjpeg is open source. So is libpng. I took a quick look at these and found there was no simple way to load from a data buffer, they just took filenames and FILE*. Sure I could hack this and either inject the data into a FILE struct, or use a temp file, or even fix the libjpeg source code myself if I so wanted… but this seems like far too much work for something which seems such an obvious thing. In the end I went for FreeImage which did allow for loading from a data buffer. My model loading so far is stuck with hacking in FBX.

Here’s the thing, FBX does animation, texturing, lighting, model loading, everything. It’s awesome and amazing in the amount it does. It’s free. It would be perfect for my engine to use. But it breaks my design. This has got me so worked up that on several occasions I’ve thought of just ditching FBX and writing my own model loader for something simple and starting from there but I’ve stuck with it.

Another thing that pains me about libraries which offer “solutions” such as FBX, or actually SDL for that matter, is that they can very often do a lot of different things. SDL is actually a better example here as it does window management, input, 2D graphics etc. However you have to use them in precisely in the way they expect, and if you use one component, you almost always have to use everything. What I’m referring to here is SDL, again breaking my design in a way I’ve ranted about before. I begun using SDL to create my windows, as it was nice and portable. However, since I wanted all of my modules to be as uncoupled as possible, I didn’t approve of SDL requiring me to use it for the input handling. Sure I could have written my input handler module to use SDL, but then I couldn’t replace it later on for something that had better support for joypads or something. I don’t know, it might seem pedantic, but I would really _really_ like it if you could just turn off features in some of these things. If I had the choice whether or not to use SDL for input, I’d probably be using it.

No matter how amazing your design, if you build your palace out of other people’s work, it will look patchy, uneven and will make you wonder why you made a nice design in the beginning.

On the other hand. If you designed a great pyramid and tried to build it single handedly, you’d drive yourself insane… so I guess when needs must… enlist slaves.

Has anyone else had any interesting arguments with libraries? Some design ideas that make you wonder what the original writer was thinking? I’d love to hear them, especially if they don’t affect me