After having to drop out of LD48 #16 after about the fourth hour due to personal emergency, I’ve decided to come back and give it another go.  For added splash and dash, I’ve decided to impose the additional restriction on myself that my entry needs to run on my GP2X as well as Win32 and Linux (summer road trips coming up and all that).

-Tools-
compile and link: (arm-linux-)gcc (with friends ld, as, etc.)
text editing: Dev-C++
sounds: SFXR, GoldWave
music: MilkyTracker
graphics: GIMP (with MilkShape and POVRay, if needed)
stress management: AssaultCube, Winamp, XMMS, ModPlug Player

-Code-
I’ll be using a skeleton that

• initializes Allegro
• creates the window/gets access to the display and creates a double buffer (plus forcing a hardware blit on the device as a workaround for a bug on first- and second-generation ’2Xes)
• initializes a music-playback library (JGMOD, available freely, but current URL unknown)
• provides a way for the app to over- or underclock at run-time (GP2X only)
• provides a simple abstraction layer for reading key or joystick input
• has a prebuilt main menu
• has some fast additive and subtractive blending routines, courtesy of fblend (see fblend.sf.net)
• has some built-in tilemap support with lighting effects
• has a few built-in effects useful for screen transitions (wipe, blur, distortion map)

In spite of all the bullet points above, it’s woefully incomplete and doesn’t really give too much of an advantage (it probably would in the hands of someone capable, but that’s hardly me, heh).  In the spirit of fairness, I’ll post sources as a response to this ASAP (I’m at work now, so it’ll have to wait until later in the day).

-Misc-
Habanero hot sauce, Clif bars and energy drinks have been acquired.

And now, we wait.

This is our first time competing in LD48 (although not our first time competing in a short dev cycle contest). Hopefully, we’ve prepared enough; starting with a mostly-working engine instead of rolling one from scratch on contest day should help.

The obligatory stats:

Tools:

• compilation and linking: GNU toolchain
• graphics: GIMP 2.2
• sound: MilkyTracker, SFXR
• level: Mappy
• engine & framework: preexisting custom 2D
• helper libs: Allegro 4.2, DUMB, fBlend
• target platforms: Win32, x86 Linux, GP2X (maybe)

We’ll see how things go.

More about the internals:

In accordance with contest rules, here’s a note on how the framework and tile engine work.

The game is treated as a series of states – a state for the main menu, a state for gameplay, and so on. There is a state structure that looks like so:

typedef struct
{
unsigned which;
void (*init)(void);
void (*tick)(void);
void (*draw)(void);
void (*load)(void);
void (*unload)(void);
} GAMESTATE;

Before we start executing any game logic, there is an array of gamestate structs that gets populated with the functions from the various states. Each state reads input, advances counters, starts sounds, etc. in tick() and does all its painting in draw(), and these both get called at a regular rate. init() is called to reset any internal variables to their start values, and load() and unload() get or free assets from disk.

Tilemap internals

This is fairly straightforward – a level has several planes, each of which are an array of bytes that control things like what tile should be drawn where, what eyecandy should be applied to it, entity spawn points and the like.

Other

There are functions to do a few graphical tricks like waviness in water tiles, a circular wipe, full-screen blur, etc.