gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > isometric games

#29424 - blinky465 - Fri Nov 19, 2004 9:55 pm

Heres my latest development, remaking a platform isometric-style puzzle game to the GBA (for those of you who remember such things, its based on Head over Heels and Batman for the ZX Spectrum);
I've done a few of these in Flash, but this is my first real attempt at anything other than a tiled scrolling rpg for the GBA.

http://www.multiedge-net.co.uk/gba/demo.gba

There's a few graphical glitches at the minute, and I suspect my linked list isn't quite sorting the way that it should.
Has anyone done anything similar, to swap ideas?
I think that I'll get there in the end, but if anyone has a completed example and can offer some pointers, I'd be very grateful.

#29434 - bertsnks - Sat Nov 20, 2004 12:15 am

i think you'll get into problems with using only sprites for this

#29437 - DiscoStew - Sat Nov 20, 2004 1:03 am

bertsnks wrote:
i think you'll get into problems with using only sprites for this
For just the purpose that blinky465 is trying to do (in my frame of mind), sprites are the way to go. I don't think he is trying to make an isomeric map out of sprites, but objects (sprites) interacting with each other with visual priority in an isomeric manner (with height prioritizing).
_________________
DS - It's all about DiscoStew

#29453 - Wriggler - Sat Nov 20, 2004 11:04 am

Looks good so far, I'll be interested to see how it develops!

Ben

#29460 - Quirky - Sat Nov 20, 2004 6:26 pm

blinky465 wrote:

I think that I'll get there in the end, but if anyone has a completed example and can offer some pointers, I'd be very grateful.


I played about with a similar idea (using sprites) but gave up when I got sick of drawing isometric blobs :-) The way I did it, and you probably have a similar thing going on, was to give each block a width, depth and height and calculate everything from the centre of each, rather than calculating offsets from the corners. The order was a case of going along the rows, then columns then the height. I didn't get very far though, got the basic engine running then realised pixel art is an even more time consuming hobby than programming. If you're a fan of Batman, check out Gwatman on the gbadev archives, it's a great remake that someone did of the speccy version using this sprite technique.

As for sprites not being the best way... 100 objects in a smallish room is more than enough. Another way of doing isometric is the Tactics Ogre/Final Fantasy Tactics style, which is good for large open "rooms" but then you have limited scope for the positioning of objects and stuff, all your rooms would be variations on a hill from the top corner to the bottom corner.

The final way that I can think of to do iso would be forget the hardware and use software sprites and backgrounds. Obviously the speccy games do this, but so does Monster Max (an overlooked Ritman and Drummond classic) on the GB and it means 'unlimited' room scope, though no rooms really go further than what 100 GBA HW sprites could do anyway.

Good luck! Isometric platformers are lovely :)

#29461 - keldon - Sat Nov 20, 2004 6:38 pm

Or you can mix the methods together. Render linking tiles at run time so you don't end up with 2^tiletype tiles.

What you will have for each tile is: (16x16/32x32 tile, from ROM) + (tiles for each connective drawn at run time)

The benefits for this is the removed need to have connectives in ROM that aren't going to used, and also you don't have to create connectives anymore. And your 16x16/32x32 tile can quite happily loop itself as all that is extracted from a tile when creating a connective is a diamond portion. Or you could create a tool that extracts only the pixels inside the diamond, and use that to create connected iso-tiles.

I have not tried this out, but it sounds *almost* solid and golden.


p.s. Good Work

#29495 - blinky465 - Sun Nov 21, 2004 2:33 am

Thanks to everyone for all the positive comments.
I've updated the file at

http://www.multiedge-net.co.uk/gba/demo.gba

and managed to remove a couple more glitches. I reckon that I'm almost there with the sorting now- just the one where you jump in front of a block higher up to sort out and I reckon I'll be ready to put some proper graphics in there.

The objects are coded to allow their behaviour to be changed by setting a couple of switches (e.g. the 'floating' block has no_fall=true, the one that drops at the beginning has no_fall=false etc.) So once the iso sorting is done, I should be able to get a working game engine up and running quite quickly.

Has anyone done anything similar in the past, or have an iso sorting routine for use with a linked list of sprites? (not just depth=x^2+y^2+z^2; I've tried this and it doesn't work properly for me!)

Anyone interested in helping turn this into something a little more interesting than moving blocks around a screen?

Last edited by blinky465 on Sun Nov 21, 2004 2:50 am; edited 1 time in total

#29496 - blinky465 - Sun Nov 21, 2004 2:40 am

Quirky wrote:
The way I did it, and you probably have a similar thing going on, was to give each block a width, depth and height and calculate everything from the centre of each, rather than calculating offsets from the corners.

I never thought of centring the sprites, I'm working from corner-to-corner.

Quirky wrote:
The order was a case of going along the rows, then columns then the

I tried this approach, but came unstuck when I jumped in front of a 'pile' of 2 or more sprites (I still have a problem with this in the latest version, even using my own sprite sorting routine.) I basically draw all the sprites at the start, then use ham_SetObjBefore(chars[j], chars[i]); to swap the order in which they are drawn.

I intend to hand code this one day, but I'm still getting to grips with the C language (although it shares a lot with Java anyway) and HamLib does help you to get up and running quite quickly!

Quirky wrote:
heightGood luck! Isometric platformers are lovely :)

I couldn't agree more. Now I just need something a little easier on the eye than my programmer artwork....

#29500 - tepples - Sun Nov 21, 2004 4:42 am

blinky465 wrote:
Has anyone done anything similar in the past, or have an iso sorting routine for use with a linked list of sprites? (not just depth=x^2+y^2+z^2; I've tried this and it doesn't work properly for me!)

In a rotated orthogonal projection such as what many of us call "isometric", depth should be a simple dot product of the coordinates with a vector pointing out of the screen. (A dot product is the sum of componentwise products of two vectors.) The value of this vector depends on how you define the coordinates x, y, and z. Then just Shell-sort based on the depth value.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#29524 - blinky465 - Sun Nov 21, 2004 1:34 pm

tepples wrote:
depth should be a simple dot product of the coordinates with a vector pointing out of the screen.

It's a while since I did this, but isn't dot product:
r.q=rxqx+ryqy+rzqz

where r=x,y,z and my starting vector q=0,0,0
which would reduce this to
r.q=rx+ry+rz
to give me depth=x+y+z?

I have tried this (before using the power 2 solution) but hit upon problems when, for example, A is at x0,y5,z3 and B is at x4,y2,z0 as I would still want B in front of A but this depth calculation would put A in front of B.

#29526 - tepples - Sun Nov 21, 2004 3:17 pm

blinky465 wrote:
but isn't dot product:

r.q=rxqx+ryqy+rzqz

where r=x,y,z and my starting vector q=0,0,0
which would reduce this to
r.q=rx+ry+rz
to give me depth=x+y+z?

Not necessarily. The vector r doesn't have to be (1, 1, 1); it depends on how you interpret your coordinates. It should be a vector that projects to nothing.

Quote:
hit upon problems when, for example, A is at x0,y5,z3 and B is at x4,y2,z0 as I would still want B in front of A but this depth calculation would put A in front of B.

Again, if you want good help, please explain how x, y, and z are interpreted in your engine, either in words or (preferably) using a diagram.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#29539 - blinky465 - Sun Nov 21, 2004 5:44 pm

tepples wrote:
please explain how x, y, and z are interpreted in your engine, either in words or (preferably) using a diagram.

Sorry tepples, I was assuming that everyone used x,y,z in the same way. First lesson learned!

[Images not permitted - Click here to view it]
The diagram at http://www.multiedge-net.co.uk/gba/isolayout.gif shows how I'm using x,y,z co-ords, with 0,0,0 being the furthest point from the screen. I was hoping to use a simple 'depth' formula, but as you can see from the final diagram, I want the block 'A' to be behind block 'B' but in this instance, the depth of A would render it over B.
I used the simple d=x+y+z for this, then worked on actual distance from 0,0,0 using pythagoras (ok, so the final answer should be the square root of x^2+y^2+z^2 but the result is the same!)

My blocks are positioned from their furthest corner.
My latest development uses a linked list of sprites and every time a block moves, I walk along the list, find a sprite that I know is definitely in front of the moved block, and place the moved block behind this one in the list.
(this is done by comparing the x,y,z and maxX, maxY, maxZ of the blocks in a series of if statements).

I'm quite happy to overhaul the sorting function to get it working, but if anyone can understand what I've been doing with the x,y,z comparisons, I'd quite like to be shown where I've gone wrong (source code available on request).

Code:

void putInCorrectPlace(struct obj *nodeToMove){
   // walk through the list, from the head to the end
   // when you hit an item that is to be draw on top of this one
   // put the moved item in the list BEFORE that item

   // we need a pointer to point at the items in the list, one at a time
  struct obj *p;
  p=head;
  int k=0;

  // let's also keep track of the last valid next node
  // (so if we get to the end of the list and still not updated position,
  //  we can put out item *after* the last node)

  struct obj *pLast;
  pLast=head;

  while (p!=NULL && k==0){

     if(p->next!=NULL){ pLast=p->next;}
     if(p==nodeToMove){
        // don't bother comparing a node to itself!
     }else{

        int aX=nodeToMove->x;
        int aY=nodeToMove->y;
        int aZ=nodeToMove->z;

        int aXMax=aX+7;
        int aYMax=aY+7;
        int aZMax=aZ+7;

        int bX=p->x;
        int bY=p->y;
        int bZ=p->z;

        int bXMax=bX+7;
        int bYMax=bY+7;
        int bZMax=bZ+7;

        int AbeforeB=0;
        int BbeforeA=0;

        // only compare items that could possibly 'overlap'
        if( (abs(aXMax-bX)<8 || abs(aX-bXMax)<8) && (abs(aYMax-bY)<8 || abs(aY-bYMax)<8) && (abs(aZMax-bZ)<8 || abs(aZ-bZMax)<8) ){
           if(aZMax<bZ){
              AbeforeB=1;
           }else if(aZ<bZMax){
              if(aXMax < bX){AbeforeB=1;}
              if(bXMax < aX){BbeforeA=1;}
              if(aYMax < bY){AbeforeB=1;}
              if(bYMax < aY){BbeforeA=1;}
           }else{
            if(aZMax < bZ && (abs(aXMax-bX)<8 || abs(aX-bXMax)<8) && (abs(aYMax-bY)<8 || abs(aY-bYMax)<8)){ AbeforeB=1;}
            if(bZMax < aZ && (abs(aXMax-bX)<8 || abs(aX-bXMax)<8) && (abs(aYMax-bY)<8 || abs(aY-bYMax)<8)){ BbeforeA=1;}
           }

           if(AbeforeB==1){
              MoveListItem(nodeToMove,p,1);
              k=1;       
              break;
           }
        }else{
           // this item in the list is too far away to have an impact on the item to move
        }
     }

     p=p->next;
  }

  if(k==0){
     MoveListItem(nodeToMove,pLast,2);
  }

}


My movelistitem function takes two linked list items and places one either immediately before (third param is 1) the other, or immediately after (third param is 2). The variable BbeforeA is not used, other than to help me debug.

#29561 - ScottLininger - Sun Nov 21, 2004 11:21 pm

keldon wrote:
Or you can mix the methods together. Render linking tiles at run time so you don't end up with 2^tiletype tiles.

What you will have for each tile is: (16x16/32x32 tile, from ROM) + (tiles for each connective drawn at run time)


Another option is to use two background simultaneously, with transparency to allow for the "connectives" to take care of themselves.

This is hard to explain, so here's a graphic:

[Images not permitted - Click here to view it]

If one wanted to use all four backgrounds, you could have the ability two place sprites between to isometric "metalayers" for some very cool effects... say, your avatar walks into a building and foosh! The building's walls fade away to 15% alpha once you're inside and you can see the contents.

Maybe I'll work on this next. ;)

-Scott

#29579 - DekuTree64 - Mon Nov 22, 2004 4:45 am

But the 2-layer method is so inefficient, because not only does it take 2 layers, but you also have half your VRAM wasted on the transparent pixels between tiles. I like Keldon's idea better. It would pretty much require dynamic loading of chars, since you'd be creating all your border tiles on the fly, but I think you could get it pretty darn fast by writing specialized assembly code for each of the possible angles to be copied. Another nice thing is that if your tiles are at normal 2x1 iso perspective (like 32x16 diamonds), then you know you'll be copying 2 pixels at a time since the edges look something like:
Code:
    XXXX
  XX    XX
XX        XX
  XX    XX
    XXXX

So if you use 8-bit graphics (which you pretty much have to if you're dynamically combining them), then you won't have any odd pixels to deal with. Granted, you may be able to optimize it even further by loading straight into registers and combining and stmia'ing them out, but that could get complicated with this next trick...

Instead of storing the 32x16 diamonds as 4x2 chars, offset vertically by 4 pixels so they take 4x3 chars (with the top/bottom corners sticking out 4 pixels into the top/bottom chars). While it seems wasteful, it will get the 2 center-most chars of the 32x16 diamond completely seperated from the edges, so you can just copy them in straight away, and also recycle them if you ever get repeats of the same tiles on screen.
But with your diamond offset by half a char, then on the right/left corners, you'll have 3 diamonds' corners all showing in the same char, like this:
Code:
aabbbbbb
aaaabbbb
aaaaaabb
aaaaaaaa
aaaaaacc
aaaacccc
aacccccc
cccccccc

So that's the bottom corner of 'b', and top corner of 'c'. Not too big a deal, but then you'd have to have 3 tiles' pointers loaded at once when doing the dynamic char loading, which wouldn't really effect the innermost pixel loading/combining loops, but would slow down the outer which-tiles-do-I-copy-now loops.

That's where the no odd pixels fact helps out. When you're drawing 'a', just copy it by itself into that char. Later, while you're rendering b and c's other angles, write their pixels into that corner char directly. You'd need a way of keeping track of which corner char goes to which tiles, but I think it would be faster than trying to shuffle all those pointers around to do it in one pass.

It surely would be fun to try out, but sadly I don't think I'd ever use it since I like the look of square-based tiles more anyway.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#29584 - ScottLininger - Mon Nov 22, 2004 5:07 am

DekuTree64 wrote:
But the 2-layer method is so inefficient, because not only does it take 2 layers, but you also have half your VRAM wasted on the transparent pixels between tiles.


Very true. Dynamic tiles would obviously use some amount of space, but it's probably not as much as the 2-layer method with all of that empty space, unless you happened to design a map where the number of unique intersections got really large.

If you use 256x256 backgrounds, having two of them is no big deal. The maps take up MUCH less vram than the tileset. On that note, I've found that so far I've never run into a situation where I've *needed* more vram, and I'm using a third of it for a mode4 dialog box. The only limit I've run into is with sprite tiles. The actual map VRAM has been more than sufficient.

But back to the dynamic tile idea... If you could get a nice, efficient algorithm for creating the connective tiles on the fly, you could grow the engine to use all four layers for various effects, including multilayer isometric paralax, which I've only ever seen in a few shoot-em-up flyer games. It is VERY cool looking.

Are you thinking that you would create the connective tiles when you load the map, or could it happen dynamically as you scroll around?

-Scott

#29589 - tepples - Mon Nov 22, 2004 5:57 am

Technically, isometric is a parallel projection, and parallel projections shouldn't have parallax. Only perspective projections should have parallax.

Or am I missing something?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#29597 - blinky465 - Mon Nov 22, 2004 12:10 pm

Ok, I think I have it sorted - almost.
The problem wasn't so much with the sorting code, but when it was called. I was only calling the update position in list code when a block moved. But then I forgot that moving one block may cause the relative position of other blocks around it to move, to keep the illusion of depth.

So now, every block checks to see if it's in the right place in the list, whether it has moved or not, and the effect is quite satisfying.

I'm in work, behind a stupid locked down firewall at the minute, but will post and updated gba file as soon as I can.

Thanks to everyone who has offered help and support.
(my iso-engine is a lot simpler than a lot of the suggestions!)

#29621 - blinky465 - Mon Nov 22, 2004 8:31 pm

Here's the link to my latest demo:
(hopefully the depth ordering thing is sorted out now)

http://www.multiedge-net.co.uk/gba/finaldemo.gba

It contains pushable, floating, falling and disappearing blocks.
Just a few others to do and then I reckon we'll have the basis for a half-decent game engine.
If anyone is interested in developing this further (ie into a game) please let me know and I'll start a new post as necessary.

#29632 - blinky465 - Mon Nov 22, 2004 11:33 pm

Sorry about the multiple posts. But I'm off to bed in a minute and am quite excited about my new game engine. (see post above for link).
Here's my current to do list:

Types of blocks we have so far:

1. floating
2. falling
3. pushable
4. disappearing
5. collectable
6. conveyor belts
7. deadly

Type of blocks still to do:
1. auto-animate (ie baddies which are just deadly blocks that move on their own!)

Types of block that we may do but can't really be bothered:

1. objects that can act as lifts? (ie if the player is on a lift object, it will cause them to rise)
2. linked objects? (ie tie one object to the top/side of another)
3. springs?


All comments welcome.

#29636 - ScottLininger - Tue Nov 23, 2004 12:49 am

This is a really cool idea you're working on. Some possibilities that suggest themselves:

- 3-D mazes
- "pipedream" kind of interface where you have to place pipe sections before time runs out
- Burgertime kind of thing where you have to stack stuff to get points


One suggestion I'd make is to implement shadows on some kind of floor layer... might help to visualize the elevation of a given block.

-Scott

#30327 - blinky465 - Tue Nov 30, 2004 9:40 am

Not even 10 days after starting, and I think my iso game engine is coming along quite well now. I've ironed out a few bugs, stopped the main characters falling through blocks and got them falling properly when they hit a wall.

Latest developments as always are at http://www.multiedge-net.co.uk/gba/demo.gba

If anyone is interested in creating sprites/characters/floors and walls, please let me know. My artistics talents are already seriously overstretched!

Anyone else have plans for developing a multi-level iso game?


Scott, I tried shadows on a floor layer, but couldn't get them to consistently line up. For example, when my main character jumped on top of a block, their shadow showed on the floor under the block! I'll have a look at this one again....

#30535 - Paradroid - Wed Dec 01, 2004 10:22 pm

Hi, I tried out your code and unfortunately it didn't cope with a complicated level (eg 40-50 blocks). If you're looking for spot-on ISO sorting use this routine. It's a 'C' version of the method used in Ultimate games on the Speccy, eg Knight Lore etc...

Oh, and sorry - the formatting went AWOL...!


struct ISOStruct {
int sprite; // Sprite graphic index
int x,y,h; // x,y,h of sprite, eg 16,16,52(height of floor is 40) - fs origin is middle,bottom of block
int xx,yy,hh; // size of block div by 2, x,y and height, eg 8,8,12
int hx,hy; // hotspot for sprite, eg -16,-20
};

// Objects in room
ISOStruct ISOObjects[] = {
{ 0x15,0x80,0xAA,0x40,0x07,0x07,0x0C,0xF0,0xF9 },
{ 0x25,0x80,0xAA,0x4C,0x07,0x07,0x0B,0xF0,0xFD },
etc...
};

ISO Sort+Draw routine as used in Knight Lore/Alien 8 etc...

ISOStruct *pObjectX,*pObjectY;
bool bSortList[256];
int nSortObjects;
int TempSortList[256];
int nTempSortList;
int Index,Plane,IndexX,IndexY,StoreIndexX,StoreIndexY;
int i,x,y;

nSortObjects = sizeof(ISOObjects)/sizeof(ISOStruct);
memset(bSortList,0x0,sizeof(bool)*256);
nTempSortList = 0;

scanobjectx:;
// Scan to find first object we haven't draw
for(Index=0; Index<nSortObjects; Index++) {
if (!bSortList[Index]) { // FALSE is yet to draw object
IndexX = StoreIndexX = Index; // Found object 'X'
goto scanobjecty;
}
}
// Return, we've drawn all objects
return;

scanobjecty:;
// Scan for next object we haven't drawn
for(; Index<nSortObjects; Index++) {
if (!bSortList[Index]) { // FALSE is yet to draw object
IndexY = StoreIndexY = Index; // Found object 'Y'
if (IndexX!=IndexY) { // Different object to 'X'? If so, check objects
Index++;
goto checkobjects;
}
}
}
IndexX = StoreIndexX;
goto drawobject; // Draw object 'X'

checkobjects:;
pObjectX = &ISOObjects[IndexX];
pObjectY = &ISOObjects[IndexY];
Plane = 0; // Set 'Plane' as result of checks with two blocks
if (pObjectX->h<(pObjectY->h+pObjectY->hh)) {
Plane++;
if (pObjectY->h>=(pObjectX->h+pObjectX->hh))
Plane++;
}

if ((pObjectX->y-pObjectX->yy)<(pObjectY->y+pObjectY->yy)) {
Plane+=3;
if ((pObjectY->y-pObjectY->yy)>=(pObjectX->y+pObjectX->yy))
Plane+=3;
}

if ((pObjectX->x-pObjectX->xx)<(pObjectY->x+pObjectY->xx)) {
Plane+=9;
if ((pObjectY->x-pObjectY->xx)>=(pObjectX->x+pObjectX->xx))
Plane+=9;
}

switch(Plane) { // Use 'Plane' to decide how to sort blocks
case 3:
case 4:
case 6:
case 7:
case 12:
case 15:
case 16:
for(i=0; i<nTempSortList; i++) { // Scan to see if 'StoreIndexY' already exists in temp sort list
if (TempSortList[i]==StoreIndexY) {
IndexX = IndexY;
goto drawobject; // Draw if find as can't draw scene correctly(objects intersect)
}
}
TempSortList[nTempSortList] = StoreIndexY;
nTempSortList++; // Add to end of temp list

IndexX = IndexY;
StoreIndexX = StoreIndexY;
Index = 0;
goto scanobjecty; // Scan object list from start

default:
goto scanobjecty;
}

drawobject:;
bSortList[IndexX] = true; // Tag as drawn
nTempSortList = 0; // Reset temp list

pObjectX = &ISOObjects[IndexX]; // Get screen coords
x = pObjectX->x+pObjectX->y-128 + (signed char)pObjectX->hx;
y = ((pObjectX->y-pObjectX->x+128)>>1)+pObjectX->h-40 + (signed char)pObjectX->hy;
// And draw at 'x,192-y-spriteheight'
//...
goto scanobjectx; // Look for next object to draw

#30581 - blinky465 - Thu Dec 02, 2004 9:23 am

Paradroid wrote:
It's a 'C' version of the method used in Ultimate games on the Speccy, eg Knight Lore etc...

Fantastic! I will look at this in a little more detail when I get the time. I hunted high and low for something like this for a while. I must admit to not trying my iso code with more than 25 blocks (and figured that this would be enough for most puzzle rooms!)

edit: I had a few compile errors and tied myself in knots trying to understand where the program execution goes to after running into a chain a of gotos. I take it that this is a working example, so will spend more time with it after work.

#30584 - Paradroid - Thu Dec 02, 2004 10:07 am

It does work. If you send me a private message with your e-mail address I'll send you the complete file+levels+gfx+other goodies. I wish I had this code when I wrote my own ISO game - it would have saved a lot of time!

#32631 - blinky465 - Fri Dec 24, 2004 12:40 pm

ScottLininger wrote:
Another option is to use two background simultaneously, with transparency to allow for the "connectives" to take care of themselves.

This is hard to explain, so here's a graphic:

[Images not permitted - Click here to view it]

Maybe I'll work on this next. ;)


Well it's nearly Xmas so just a few coding hours left. I've ressurected my iso game for a little while and tried a few of my own ideas - I quickly ran out of memory for drawing the rooms using just sprites, and quite liked Scotts idea of two layers for the background (I'm pretty new to GBA programming which is why I'm using HAM and HEL but have managed to make a background using a tile/map editor so that's the way it's going for now.)
I know it's a bit wasteful with all the transparent pixels, but until I get a deeper understanding of the hardware, limitations etc. and bother to write a bit of asm, I'll stick to the higher-level stuff and just get it working.

Progress - if anyone is interested - will be posted here and maybe even a website charting development stages in the New Year.

Happy Xmas!

#32939 - blinky465 - Wed Dec 29, 2004 1:06 pm

Well that's it now for another year - hope everyone had a fantastic Christmas... I've managed to spend a bit of time on my isometric game over the holidays (though I'm back in work at the moment).

Latest developments include:

splash screen (doesn't everyone just love them?)
menu to set control/sound options
floors and walls in the main game.

Comments appreciated.
I know that the palettes are all out of synch and that the splash/menu graphics are typical stinky coder art!

#34798 - blinky465 - Wed Jan 26, 2005 1:23 pm

For anyone interested in an update, the new iso game can be found at http://www.multiedge-net.co.uk/gba/demo.gba but it's getting a bit big now (a whopping 370kb) so you can also get a zipped version from http://www.multiedge-net.co.uk/gba/demo.zip

Updates include doors on stacked pillars (you can't actually go through them yet, but it's coming!)

The rooms are all ready to read from a load of arrays so a map editor is under construction

The idea was to have people send in pictures and have the incorporated into the game - so press select during a game will take you to the select character screens (which in turn will take you to different parts of the map once it's all tied together).

As ever, the artwork is still a bit rubbish but at least the main palette has been synchronised so the doors are the correct colour etc!

Comments welcome.