[Slackers] GDK update

Steve Judd sjudd at ffd2.com
Sun Dec 18 09:52:08 CST 2005


Hola dewdz,

I (finally) had a little more time to work on this, so... an update.

The sprite editor now can edit a sprite reasonably well, both hires and
multicolor.  I'll be building up the sprite object capabilities next.
Slang has been working out very well so far -- very easy to get things
going quickly.  I find that I usually still "think in asm", and am
learning to "think in Slang".  I've encountered more bugs, but nothing
very big and all easy to work around.

I've talked about how the GDK is layered and since I've finalized the
sprite layers maybe it will help make things clearer.

The first layer is the "spritedat" layer.  This is a bunch of 63-byte
chunks of sprite definition data.  The Slang code is an Nx64 array of
bytes.

The second layer is the "spritedef".  This is a little structure
containing sprite parameters such as multicolor, x/y-expand, priority,
color, and a data pointer -- an index into the spritedat layer.  You also
give them a name ("shipsprite1" "bullet" etc.).

The third layer is the "spriteobj".  A sprite object is simply a list of
spritedefs at position offsets.  That is, you can place several sprites
together to make a larger object, or overlay the sprites to make a
many-colored sprite, etc.  These too are named.

The fourth layer is the "spriteanimobj", which is simply a list of
spriteobjs along with a framing rate.  That is, this guy displays a
succession of sprite objects at some rate.  Again these are named; the
names become the variable names in a Slang program.

So you can see that you always have access at the lowest levels, but can
use the high-level stuff for most situations.  As you might expext, these
layers are then used by the game engine (the highest layer).  That is, you
have a game "object" with various traits

	position in game world
	velocity
	state, health, etc.
	render info (pointer)

In an action game you'd probably render it as a sprite, so you'd pass the
"spriteobj" or "spriteanimobj" info to it.  In a 3D game you'd use a 3D
structure instead; in an Ultima-style game the object might be a 4x4
charset.  The object stays the same/similar; the interaction with the map
stays the same/similar; the rendering method can change totally.  This is
the point of the GDK.  It's not so much a set of specific routines as a
methodology, for organizing and implementing games.  The design is what
makes the same stuff usable for an action game, an RPG, a 3D game, etc.

The beauty of all this, incidentally, is that Slang handles the details.
That is, from the above it sounds like it might be very cumbersome to
implement.  In asm it would be.  In Slang the compiler fixes everything up
and all the overhead happens at compile time, not at runtime.

OK, back to work :)

cu,

-S


More information about the Slackers mailing list