can you maybe scale it down a bit?

Holy crap that engine looks amazing. With graphics like that I don't mind monochrome at all

I don't see why we should include sound if we're worrying about people having a shell or not......

@Shmibs, so the laser attack would shake the screen too...I don't see a downside....

I was working on a separate engine to handle animated sprites Also, if I have it so that it smoothscrolls 8 pixels at a time, I can get rid of the difficult parts of the tilemap engine. (Basically, if you move left, it will scroll in 8 times, kind of like how Pokémon does it).

@tr1p1ea: For the animated tiles, I was thinking of having a format like this:
Tileset:
;     .db Evolvesto   ;This is the tile it turns into on the next frame
;     .db TileInfo    ;a bit here will indicate that the tile needs to be updated this frame. I am sure other info
;     .dw ;TilePointer  ;This points to the sprite data
will be needed.
Then, a copy of the current map (I called it MapShadow), will be scanned every time through the loop. Each byte will point to a tile in the tileset, the byte will be replaced by the byte it evolves into (I'm thinking in terms of cellular automata) and if a specific bit is set in the TileInfo field, the LCD will be updated using the data and TilePointer.

This will make it very easy to have tiles animated at different speeds, without keeping a timer for each tile. It will also allow for arbitrary speeds, like some tiles could move every frame and others could move every 3 or 5 frames. It will also mean that you can keep a low number of base tiles for the actual map data (like 16, for nibble packing), but still use 256 tiles in all (or more).

Precisely, and if we went that route, coding would be much easier, with a lot less error checking. I found out my first final doesn't start until tomorrow, so I will try to get to writing up a better engine

+ collision detection is way easier and smaller...

So I think the movement will be like this? ok lol :p

And then all walkable tiles before non-walkable this and collision detection is based on if the number-of-map-tile your standing on, is smaller then the number-of-first-non-walkable tile...?

And i sugest tiles as following: sand, dirt, stone, grass, and some other .. all to walk on, and some fences as non walk-able and some other...

Yes, this is definitely the next important thing that will need to be figured out after the map engine is made. In my experience, it is always easiest to have walkable tiles as the first tiles in the set.

I coded a very simple (and a bit optimised) smooth-scrolling engine (after all, I'm at school, thanks to Wabbitemu ). It's only 963 bytes, so I thank that we should compare our techniques.



Here's the code :

:.AXESMTH
:[3C4281818181423C→Pic1TILE
:[3C7EFFFFFFFF7E3C
:[0000000000000000
:
:Buff(384)→GDB1MAP           // this does take a lot of the 963b of the prgm
:0→H→V→S-1
:For(384)
:+1→r1
:rand^3→{r1+GDB1MAP
:r1
:End
:
:While 1
:‾1
:For(10)
:+1→r2
:‾1
:For(14)
:Pt-On(+1→r1-1*8-(H and 7),r2-1*8-(V and 7),{VAsm(CB2DCB2DCB2D)+r2*8*3+r1+(HAsm(CB2DCB2DCB2D))+GDB1MAP}*8+Pic1TILE
:r1
:End
:r2
:End
:
:DispGraphClrDraw
:getKey(1)-getKey(4)*2+VAsm(E5)≥≥0?Asm(E1)→V,Asm(E1)                                  \  I move 2 pixels
:getKey(3)-getKey(2)*2+HAsm(E5)≥≥0?Asm(E1)→H,Asm(E1)                                  /    by 2 pixels
:EndIf getKey(15)
Fun fact : I used #ExprOff to optimise this program for size, and the size remained the same

Yes it is ashame i don't get it xD