But that wouldn't prevent that I have to re-type the hole map instead of just changing one byte in ram.

I don't really get what you mean....sorry

and then I change GDB1 etc. ? I'll try that, but I can't until tomorrow, still have a lot of other stuff to do

EDIT: WHait a sec, that wouldn't do it as I sometimes still need the original map........ I think I really don't understand what you mean, sorry. If you gave me your email I could send you all the files and you could try it out.

This looks great!

The reason your original code didn't work is because you compiled it to an app.  This means that all data in your program is read-only since the program is put in flash rom.  Now that said, you can still keep your program as an app, but you have to manipulate your levels in ram.

You were on the right track before when you did "Copy(K,L1,714)" to put the level data in ram then make changes like "5->{L1+20}" for instance.  The last statement where you copy it back to rom is not going to work though.  Instead, use "L1" as the pointer when you render the graphics instead of K since L1 holds the correct data with the correct modifications.  If you need L1 for other things though or you need more space than L1 can possibly provide, you can create an appvar in ram any size you want and use that pointer instead.

What Hayleia is talking about is that its generally a good idea to store data to static pointers instead of variables because the code optimizes better and uses less memory.

Also I saw on your Cemetech post that you had Dispgraphr in a loop with getkey.  If you want a better quality grayscale, you should not use the super slow "getkey" command.  Also you should turn interrupts off.  Using the direct getkey(#) is recommended instead.  This gives you consistant timing between frames.  You might even need to add some more pause back in.  I know on hardware the 4 level grayscale is almost completely out of sync if constantly updating unless a small pause is added.

a correctly timed pause. See, the actual lcd refreshes at 60 FPS, so you want to match that. Any faster and you miss some frames being shown, any slower and you show the same frame twice, both of which cause flickering.

Also, the front sprite looks exactly like the one from the tilemap example in BBC Basic. Is that where you got it? I could see it ending up looking the same by coincidence, though, since it's only 8x8.

bump.

I randomly saw this topic in the board, and it looks awesome! Any progress/plans on finishing it?