/\it would indeed. also, i need to redo this, because, as you can see if you look closely, i did it wrong so there are spots where the map repeats itself horizontally.
basically, my approach right now for this project is to get all the concrete things done first (map, tiles, etcetera), then make the dungeon section, and finally move on to the main engine, as that was what killed me last time

if i were writing a processor-intensive program that had a lot of variance in framerates, how could make them stable?
interrupts would slow things down too much, wouldn't they? would measuring out the difference in number of cycles at any branch in the code and then adding in a wait for that long on the slower one work?

i finally figured out how to rip data directly from the rom, so i'm starting there, laying out the tilemaps and such before getting into other things. i've figured out that the overworld levels all have <=160 tiles, the overworld maps are 160*160 tiles large, and, for compression purposes, those tiles are grouped together into larger 4*4 tiles. there are <=80 tiles for the dungeon maps, the map storage seems really confusing at the moment, so i'll probably just redo that entirely. here are the first few tile sets and the complete map of level 1's overworld (warning, it's fracking huge. oh, and the white text marks enemy spawns and the blue and yellow are warps.). if anyone has any ideas on how to best compress this, they would be welcomed =).

this is just a little bit fantastic news! i'm sure that it will bring in the crowd of new CX using students pretty quickly and motivate some of them to make things of their own.

some of them look like they were resized from a larger image <.< >.>
the clones are nice, but their legs look too far forward to actually be attached to their bodies.

it's in the right forum (other calc-related projects and ideas) now because i moved it there.

jonius: a nibble is four bits, or half a BYTE
saintrunner: c0de fellow posted a decent example there. here it is explained, though:

[HEXCODE]->Pic1 //this is the place where you put the hex data for all of your sprites, one after another.
[MapDataInNibbles]->GDB1 //this holds the map data in nibbles, which basically just means that every four bits holds a binary number from 0 to 15 (or 0 to F) to describe what tile to draw in what location. here they are listed in rows of twelve.
For(A,0,95) //a for loop. 12*8 (the screens width and height in increments of 8) is 96, so it has to run from sprite 0 to sprite 95 in order to cover the whole screen.
nib{GDB1*2+A}->B //this gets the sprite that is to be drawn next. it uses a "nibble pointer" rather than a "byte pointer" (i'm not sure what these are actually called...), so the "byte pointer" location of GDB1 has to be doubled. A is then added to determine which one to draw currently.
A^12->X //a modulus 12, or the whole integer remainder that would remain after A is divided by 12 is stored to X
A/8->Y //the integer value of A, were it divided by 8, is stored to Y
Pt-off(X*8,Y*8,B*8+Pic1) //drawing sprites to the screen. because B holds a value from 0 to 15, multiplying this by 8 and adding Pic 1 slides the pointer to the spot where you stored your sprite data and then jumps forward to the number desired.
End