Shadow Covenant

Since my artist is still out of commission (and probably will be for another month), I’ve been doing mainly technical things…

Since I was feeling lazy and didn’t want to add the tutorial code yet (since that’s GUI work, and I hate GUI work), I’ve decided to start porting “Cell.ection” (if I haven’t mentioned it yet, that’s the current name for the game, although we’re still arguing between “Cell.ection”, “Cell.Action”, “Cellection”, with different types of writing styles) to personal computers (Windows, Mac, Linux are the targets).

Decided to start with the easy one: Windows, and I partially succeeded…

Found several problems:

• A small bug: I deleted an object from itself (“delete this”), but I set the animation of that object to false afterwards… curiously enough, this didn’t raise an exception, but it crashed (or more precisely, Visual Studio raised an exception because it detected memory that should have been free altered) because of memory corruption… This behavior didn’t happen on the mobile version because apparently Marmalade doesn’t use the same trick to track this kind of problems.
  On allocation (and on debug mode), VS initializes memory to zero, and when a de-allocation occurs, it sets that space to a familiar pattern (like all bytes set to 0xAE or something like that). When an allocation occurs, the system verifies that all the bytes are set to 0xAE, if not someone messed with that memory address after it was released and raises an exception. It’s a neat trick… In this case, messing with the memory like I was doing wasn’t a serious issue (hence no big issue in the mobile), since I deleted the object and set a boolean value to false, so I couldn’t corrupt any new objects in the process, but it could mean something serious. Ah, obviously enough, the heap is all initialized with that mask (or else the first allocation would raise an exception).
• If you look at the screenshot above, the GUI is all compressed… That was a trick to get it to render at all… I didn’t remember, but the D3D API doesn’t allow for negative values on the viewport settings, and that was what I was using to simplify my multi-resolution, aspect-ratio agnostic system… So I’ll have to change the way this works (probably by shifting the viewport to be all positive, and offsetting the objects there to reach the same visual result).
• The fonts look terrible, due to the larger screen size… they probably look terrible on the mobile as well, but it doesn’t show because the screens are smaller. Need to work something out on this, probably change my bitmap font generator so that it does some multisampling on the fonts, or maybe integrate OpenType to build the fonts in real time from TrueType fonts, adjusting to the resolution.
• No cursor… In mobiles, we don’t need/want a cursor, but in a mouse based system, it’s kind of necessary… Not only that, but some feedback on the buttons when the mouse is over them is also a bit necessary… This implies having some “ifdef/endif” blocks in the code, which is kind of ugly… Of course I could do this data driven, but sounds a bit like overkill for something like this.
• File directory structure… Marmalade assumes that all files in a certain “data” directory will be packed into the package for mobiles… Problem is that if I use the same paths on the mobile and PC version, I need to have some DLLs on that directory (FMod, for example), which sucks big time… Probably need to think a bit better on the directory structure, specially to see if I can sort out some kind of override system so that I can have different assets for different platforms (more resolution on the fonts, for example), while keeping the common part together…

This is one of the reasons why this project is so interesting from a learning perspective… Although the code part of it was ported without needing many changes, just create a new VS project and dump the files there, there are still lots of small issues associated with multi-platform deployments that must be addressed (and now is a good time, since I can still change the way SurgeED works to do a better job at this multi-platform asset management).

I’ve also been working on a second port, this time from PC to mobile… An old (unreleased) casual game of mine:

The game won’t work on smartphones, but it’s a good match for tablets… Currently, I’m just trying to get the old code compiled with the latest version of Spellbook, but even that’s been proving hard, specially because of the font, since I changed it a year and a half ago (so that includes the concept of character metrics). Problem is that the hand-worked fonts of Something Fishy were done with the old system and while they worked well with that, they miss information necessary to work nicely with current Spellbook…

Need to fix that, either by generating the missing information, reverting that component to an old state (if I can find an old version of Spellbook pre-change), or *shiver* adding by hand the information…

Finally, also been thinking a lot on the new Image Bank system for Spellbook… I need a way to make it “multi-layer”, so I can have normal maps with the images aswell (some nifty 2d effects and for use with decals)… To do so, I want to add an Image Bank editor/generator into SurgeEd, but I need to think if an Image Bank is a component or a resource (probably both)… I already have a Font Generator in the SurgeEd, but I don’t like the way that turned out, so I‘m thinking to handle any resource editing as a separate component of the editor, with its own specific subsystems, but I haven’t made up my mind yet…

So stay tuned for more developments!

I love Lua for scripting… It’s easy to integrate with any C/C++ framework, powerful, fast, takes little memory, good debugging hooks, memory control, and (best of it all) it has coroutines, which is something that I utterly love in game development.

But this is not an article praising Lua… To the contrary, it’s a rant about the stuff that annoys me in it and that I wish someone would fix… I know most of this could be fixed by me, since Lua is Open Source, but to be honest most of it would be a huge endeavor in the guts of Lua itself.

1. Why 1-based arrays? Every language I know of has 0-based arrays (that is, arrays that start at position 0), but Lua had to be different… This is not a big problem per se, but the amount of times you do it wrong because you’re shifting from C/C++ to Lua is huge… Probably someone that sticks to Lua can do it without messing up a single time, but I’m an indy programmer!
2. Why THEN and END? This is my main annoyance with Lua… All IFs in Lua have to have the keyword THEN after the condition, and END up when the syntax block ends… I understand being mandatory an instruction block (i.e. not allowing for a single instruction), since that leads to some ambiguities and tricky to spot bugs sometimes, but couldn’t they have used ‘{‘ and ‘}’, or even ‘[‘ and ‘]’, or something else but a clunky keyword that makes your code seem ugly? On the same note, the FOR and WHILE loops also require the DO keyword, which also sucks… is it that complicated to make a parser that doesn’t need those things?
3. Use of doubles for numbers. This one I understand… numbers in Lua are expressed as doubles (which allows them to be fractional and yet provide a good range of integer numbers without loss of precision). But when you’re making games, you don’t want to keep switching between single and double precision on the FPU, and Lua kind of forces it (since you’re probably using floats all the time for everything else, like meshes). Adding an integer type and going for floating point numbers would help tremendously here (although I believe it wouldn’t be such a simple task as I’m stating, since the typeless nature of Lua makes it complicated, but I wouldn’t mind having some methods to work with floating point numbers, and others for integers for this purpose). The way I have it now, I do a compilation of Lua with numbers as floats for my game projects, and cross my fingers so that the precision doesn’t byte me in the future.
   What I do is when I want to treat a number as an integer (in comparisons and things like that), I round to the nearest integer… Hopefully that’s enough to stop some problems (which might be tricky to debug, since 3.9999999 != 4)
4. Lack of types. This one isn’t really Lua’s fault (since most languages don’t do this), I would just really really really appreciate if I could have 2, 3 and 4 dimension vectors treated as internal types, so that I could use vector math in Lua (without the performance hit I get when I use arrays as vectors)
5. Lack of pre-processor. Again, not Lua’s fault, but it would be nice to have a preprocessor in Lua’s parser… I can run stuff through the C preprocessor and feed that result to Lua, but that screws up debugging a bit, which is too bad…
6. Lack of a class based system. I know I can use meta-methods and tables to mimic a class in Lua, but that’s not the same. Imagine that I return an object from C code. That implies that I “copy” the data from the C++ object to a Lua table, and push also some functions (C/C++ and Lua). This sounds terribly inefficient. It would be better to be able to specify some classes (with the methods associated to them), and just copy the data on top of the table. You might be able to do this with some trickery, but I haven’t found the trick yet, I admit. This one isn’t very serious, since Lua never pretended to be an OO language, and I can live just fine with passing some light user data values back and forth between Lua and C/C++.

I’ve looked into several other scripting languages (mainly Javascript (through the V8 engine) and Python), and they have more serious handicaps for my taste than Lua, and that’s why I keep using Lua.

Some of these seem pretty easy to fix for the developers (or someone that really takes the time to delve into the Lua source-code). Of course, changing these, will it still be Lua? I like to think that it would some sort of Lua+, different yet better. Maybe one of these days I’ll take the time to fix 1, 2 and 4 (well, 1 and 2, 4 might be too hard). If anybody knows someone that’s actually done some of this, feel free to give me a poke!