It definetly isn't dead there just hasn't been progress. School is a time sucker, but summer is coming up, and then there are the weekends when I work so that's all. Nothing is dead. Believe I will be working on this over the summer.

Ok I think it's time you guys no a little bit of what I have been thinking of because I have been thinking seriously in this time that I have gotten off. First off I have decided to make this my PRIMARY project over the summer and that will not change. Secondly is an advancement in the graphics aspect of this game so hear it goes.

I was sitting around one dark and dreay night staring at Jim_e's tilemapper code, a modified version of Dwedit's but faster, and I was thinking. Crap this goes really slow when you have 255 tiles because you have the shift 2040 bytes. So I was like how the hell can I make this faster! Well I have come up with two plans that may or may not work because I have not timed them out yet.

1. Well let's say we can cut down how many tiles it has to shift. I have come up with a plan to find out the 96 tiles, 12x8, that the tilemapper will be mapping. Then all you have to do is shift 96 or less tiles instead of 255 tiles. So that should be a great speed boost although the process of making sure there are no duplicates is very hard although I will try.
2. Well if the offset that the tiles will be shifted is 7 them that's going to take a d*** long time to shift all of those tiles to the left. So then I got an idea why not split them. If the offset is between -3 then start in the left byte and if it is between 4-7 then start in the right byte. So it's like this

Offset between -3
---- shift right
%11111111,%00000000

Offset between 4-7
<------ shift left
%00000000,%11111111

So that means that there will only be a maximum of 3 shifts or less to do then 7 or less. I think these will do a considerable job in speeding up the process of the smoothscrolling tilemap.

I will begin dissection of Jim_e's cryptic code tonight o.o

I can't wait for more screenshots!

here's what you do
make jim_e's code an inc file, and .org it to $9d95, then at runtime, copy the code to $9d95, and then call it.  Then it'll be in RAM, and can use SMC as needed.
PS: make sure you clear out $9d95-$bfff before exiting the app, or bad things will happen.

ah, i see now

App tilemapper that goes real fast? You got me interested here...

If you need any help, I'll be very willing to give some of my time.

12 height or 12 wide? cause 12 wide is pretty strange and non-efficient, 16 wide would be better, but in case you meant 8 wide, then it's good. still 16 could be more efficient if it was possible.

12 wide isn't strange, it's THE WIDTH OF THE SCREEN.

Sorry I don't know what you guys are talking about seriously...when did I mention 12? The tile size if definetly 8 so far... dun dun duh haha. Really I intend on making a 16x16 tilemapper that is app-friendly. But basically why I am making this 8x8 is for tile manipulation. I *WANT* to have map deformation which would call for having 2 16x16 tiles for one being deformed and one not. But if I have 4 8x8 tiles making up a 16x16 tile then I can change one to make it deformed so that 40 bytes to 64 bytes. That is my only reason for using a 8x8 tilemapper, but if I decide I don't want deformation then I will have the 16x16 tilemapper there just in case.

@Fall_Ghost: Haha it's funny you say that because you usually are the first one I come to for anything about apps. But yeah I will probaly need you for the 16x16 app-friendly tilemapper, but so far I have like half of the 8x8 tilemapper code working in an app and debugged fine.

Oh yeah and I am keeping this on the same track so both the 8x8 and 16x16 tilemappers will be open-source!

wow and I never knew app-friendly smoothscrolling tilemappers were so special. Aren't there already like a couple out there??