Your game looks good, I'll definitely try it out.
I'm not releasing the full source right now as it's a bit of a pig's ear, having been put together in three days. I'll probably release it if/when I clean it up a bit, but right now I'm a bit busy working on my compo entry.
Is there anything in it you where interested in? I'd be happy to pull out bits and explain them. Nothing is handled in a particularly elegant way, however!
All of the levels are raw byte by byte maps produced in the NES Screen tool - I did this as I also use them for collision detection, which is how the spikes, the lava, the gold and the player physics work.
The enemies are a set of arrays, the main one being "enemy_active", which the central routine runs a for loop against, like this:
Code:
for(index = 0; index < sizeof(enemy_active);++index)
{
if(enemy_active[index] == 0x01)
{
//do enemy routine
}
}
There are then a bunch of other arrays - enemy_x, enemy_y, enemy_directionfacing, etc - all of which correspond to the same index as enemy_active.
Those two and the player physics are pretty much the bulk of the game. The player physics are pretty basic - I haven't noticed the lag in movement myself, but it is likely because I am using an 8.8 movement system - so there are eight positions for each pixel.
Jumping is something I would definitely improve on if I did this again. Currently, the longer you press the jump button, the more is added to the magnificently named variable player_remainingjumpstrengthtoapply. Chunks of this are then whacked on to the players Y value each frame until it is zero, or the player hits their head. Gravity is actually running the whole time on them, so it just kind of naturally takes over, much like in real life. Hence the awkward jumping. I would go for velocity based system if I were doing it again.
The big thing that I've found programming in c on the NES is that you really, really need to appreciate it is just converting everything to 3 registers in the backend. So there lots of occasions where I'd like to be comparing two arrays together, like this:
Code:
if(enemy_destination_x[index] > enemy_x[index])
{
//do something
}
Only the result of the above will default to true, no matter what the values in enemy_destination_x and enemy_x.
Storing one of the values to a var, and then doing the comparison, makes it work properly however. So this works:
Code:
index2 = enemy_x[index];
if(enemy_destination_x[index] > index2)
{
//do something
}
Apart from the obvious stuff, like yes, even I can technically put a NES game together, this is the most important thing I learned - if a routine isn't working, it's probably too complex for the machine, and you need to shift some of the values off the registers and in to RAM. At least, I think that is what is happening. Regardless, it works, as the above is a literal example that had me stumped for a good hour or two before I figured out the answer.
