Infinite Loop

Been a while again. The dev journal has been quiet, but I've been making plenty of progress. If fact, I may have something releasable in a few short weeks - Lua has sped up development considerably, along with the jump from DS to PC.

I decided to make the switch mostly because the DS homebrew scene is losing steam; looking at gbatemp.net and DrunkenCoders, there just doesn't seem to be much interest anymore. Add to that the fact that the original DS has been replaced twice now with new handhelds, and I can't really justify sinking that much time into it.

That's not to say that I'm completely abandoning it. The engine as it stands is built largely using classes and techniques I developed specifically for the DS, and it would still be possible to port it back if I ever really felt like it. But for now, it's going to be much easier to develop content rapidly and keep myself interested if I focus on a system with wider support and better access.

Currently, I've got the bots working with the buttons. They move as they're supposed to, and there aren't any glaring holes in the game logic so far. My next tasks are sound, a title screen, and logic for the win condition. Judging by the pace I've set in the past month and a half, I should have a release-worthy version of Bits N Bots by Halloween or so (for Linux, anyway - I haven't focused on Windows yet, though I plan to eventually).

Working beautifully so far - I've got a rough directory structure going, with object classes and util classes separated out. So far, so good. I took some time out to whip up a background tilemap editor over the last few weeks as well. It's almost entirely in-browser, written in Javascript and using the Canvas element, and while it's limited to operating in Firefox for the moment it can still be used from multiple platforms. I'll post a link once I've found hosting for it (it's on my work computer), and I've had a chance to clean up the code just a touch more.

Other than that, working with Lua (especially loading the first file from the FS) has opened up a world of IO exercises for me, which was pretty critical. My latest task has been integrating libgif, so as to load gfx assets from easy-to-edit .gif files (as opposed to the old way of using Grit to transmogrify an image into an includable C file). It's going well, with background support nearly complete, and my next task is to allow dynamic loading of Sprite gfx as well. Progress!

Got a good start on Lua - the project compiles and links (thanks to the use of a Makefile from the MicroLua project), and I've gotten a simple external file to load and run. I'm tearing out any class which isn't related directly to hardware interaction, and rebuilding some of my classes within Lua. Some of the classes may be a little more in-depth than what Lua is geared for (the CollisionNode class tree, for example), but in general it'll make the event-based logic much easier to work with. Next up, I need to build some simple test Lua classes and try some hardware interaction - display a background, move the camera, etc.

..Been hung up on logic for a good long while. A-ISM isn't flexible enough and is a pain in the ass to work in, so I took a brief stab at making a more advanced scripting language. Slow going, though, and I'm on the verge of saying screw it and switching to Lua (lua.org).

I like the idea of coroutines - basically a pseudo-threaded routine which will run until it's either completed or it hits a 'yield' statement which suspends execution and returns control to the calling routine, and can be resumed later at the same point. Makes for nicely looped scripts for NPC actions, like so:

while coroActive == true do -- set mirroring, to face left hMirrored = true loopEnd = false -- loop until we reach the left threshold while loopEnd == false do -- walk left x = x - 1 -- iterate frame frame = ((frame + 1) % 4) -- check for left threshold if x < 10 then loopEnd = true end -- suspend execution until next cycle coroutine.yield() end -- clear mirroring and reset loop var hMirrored = true loopEnd = false -- loop until we reach the right threshold while loopEnd == false do -- walk right x = x + 1 -- iterate frame frame = ((frame + 1) % 4) -- check for right threshold if x > 100 then loopEnd = true end -- suspend execution until next cycle coroutine.yield() end end

The scripts then take on the heavy lifting of animation, which is both a pro and a con. It's certainly less complicated than trying to rely on the Frame class, since you need a Frame for each instance of animation AND logic. In this scenario, the Frame only needs to hold rendering data, which is much more manageable. Still need to figure out how to handle Events, and how to swap in a new coroutine when an event changes the object's state, but it definitely has promise.

*Edit: Lua snippet compiles now - bad syntax pretty much everywhere. RTFM, etc.

..Broke the hell out of the engine. Still compiles and runs - dragons bouncing all over the place, like before - but the doodlepad on the bottom screen stops functioning altogether. Not sure if it's a facet of how the stylus itself is handled, or a change in graphical functions, or what. I just reverted to the release of libnds I was using previously, which I'll keep on using until I find a solid reason not to (probably once I start messing with FS operations).

On the bright side, I have a shiny new install of Ubuntu 10.04 as my dev environment. I torched the tower pretty badly trying to compile MPlayer-CE for the Wii, probably while trying to install some necessary dev libraries. Bleh. At least I finally managed to fix the playlist bug I'd been chasing (Issue #555 on the Google Code project page - I'm MoikMellah).

*Edit - every side is apparently bright. I'm full of sunshine.

StorageMgr has been (partly) implemented for the ImageLibrary class, and it's working well so far. I still need to update ImageLib's destroy() method to properly account for and destroy objects stored this way, but that shouldn't be too much extra work. One thing I do need to consider yet is how best to handle adding an object where there's already one in the array - currently the set() method for StorageMgr will just overwrite the reference for the old object and return a TRUE boolean value, which can lead to memory leaks and an eventual crash. I think it might be wise to return FALSE immediately if there's already an object reference there, and rely on the calling class to unset() the reference first (and properly delete the referenced object) before putting the new object in place. Still, so far it's looking much simpler and faster than the linear-array-based storage the ImageLib used previously.

*Edit: Reconsidered - it's the calling class' responsibility to both test for overwriting, and to properly destroy() each stored object. StorageMgr is meant to be a simple but flexible storage method; if I felt like implementing garbage collection, I wouldn't be programming in C/C++.

On a side note, I almost threw in the towel yesterday when I noticed some sprite tearing in my test case - tearing would mean that the engine isn't completing each round of processing within a single screen refresh, which makes the entire engine pretty much useless (or at least, I'd need to tone it down to a lower framerate). I don't think it's my code, though - I'm using desmume for testing, and Anguna (an extremely well-written and polished bit of homebrew) has some tearing when run in that emulator. I need to test on live hardware (haven't in months), but I'm pretty sure it's just the emu acting wonky.

Work's finally coming to some semblance of order, and playing through Retro Gaming Challenge on the DS has put me in the mood to start working on the engine again. This week's task is creating a new storage class to address my loading concerns: currently everything is statically indexed in arrays, so the GameObject for a Dragon references the logic script at ID 5, the image at ID 2, and the frames at IDs 0-7. It works for demo purposes, but what happens when I build another resource set and want to import the Dragon? If I already have resources at the above IDs, I have to add the resources for the Dragon in at new positions in the arrays and comb through the Dragon's data to update any references appropriately. In effect, I end up reprogramming an object almost entirely for each context in which I want to use it.

The solution: the above-mentioned StorageMgr class. StorageMgr will store a series of arrays, each with its own ID, and each element in the array will have its own ID as well; each array will be loaded on an as-needed basis. The IDs as stored in Object/Frame data don't need to change - the Set ID is stored in the current ID field as the most significant bits (i.e. assuming 6 bits for the Set ID and 10 for the Image ID: Set 2, Image 4 will be stored as (2 << 10 | 4 == 2052)) and parsed when retrieving the object from the StorageMgr. The three main benefits I see of this system are the easy importation of Objects to new contexts, the speed of numerically-indexed arrays (as compared to something higher-level like a HashTable, which I had considered for this purpose), and a low memory profile.

I'm almost done with the StorageMgr class, at which point I'll implement it first as the storage for the ImageLibrary. I've been meaning to update that class in this manner for a while anyway, so that a GameObject can easily update its base Image set and change appearance on the fly without needing to program a unique Frame set for each (think Fire Mario versus regular Mario). More on this when I've had a chance to implement..

*Edit: NO BLEH!

Bleh. The unpicked fruit withers on the vine, and whatnot.. Too much going on at work. I'm close to completing my magnum opus, an online sales system based on the A-ISM scripting language from this project, and it's taken a lot of wind out of my sails. Still, the project isn't dead. I've implemented Bresenham's algorithm (..thanks in large part to Dovoto, whose code I lifted), and will have a more robust doodlepad written shortly.

I have decided to press ahead with at least some aspects of the LAMP project for organizing resources - A-ISM was getting to be a bit much to manage by hand, so I've come up with a slightly higher-level markup language with nicer punctuation and a PHP script to reformat it. More soon!

Well, got a rudimentary doodle pad working on the touchscreen. Only one color, and it isn't very solid quality yet, but it is programmed entirely via the scripting language. I actually had to cheat a bit - rather than program a separate object which follows the stylus, I just had one of the background objects execute the drawing and erasing logic. It's not even a background on the same screen, but meh. Long as it works.

The exercise has made me realize that I need to put a little more into the doodling. Specifically, one needs to draw a line between the last position and the current position, or the drawing ends up really 'faint' - most people move the stylus more than 1 pixel per frame, so the draw function has to fill in the gap between the two positions.

Not great, but it's a start:



*Edit: Toggle button: