That's good JincS cause I really don't like people who sell out. Well I would still like you if you did, but that's a different story . I hope you stay in the TI community even when you become a Bill Gates, but then I guess you could make your own calc and have your own community haha

There are 1TB HD's?? I didn't think there were so I was just going to get 2 500 GB HD's

Why don't you post the source. I am sure if SPASM can compile Spencer's 20 gigillion lines of Zelda then its not a problem with the compiler. I could be wrong but just to make sure post the source. Maybe some conditionals are unbalanced.

Yeah I know about that process, but first off I don't think you have read the post up the page a little further. I am not using his code at all in fact. I am just studying it and them making my own smoothscrolling tilemapper for a number of reasons. The special clipping I will need to do, animations, and integration. So I am just making an app compatible smoothscrolling tilemapper, maybe later I will convert it to SMC.

Yo that's so awesome I didn't know you were making all this hardware stuff. I have been looking into getting into hardware so I could make some cool stuff for the calculator and mod it out and stuff.

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

First off I would definetly help. I think though that you should make a universal language for the project or something called DevC so that people could use that and use a compiler you make. Overall I would code this project in C++. Also it might not be deathly to hard to make a 3D modelling program since you could use Blender3D source code as a core.

Here is what I am interested in by numbers.

1
2
3
4
5
6

2
3
4
5
6
7
8
9

Haha so that's almost anything. So what are you coding this in so far?? If you need any help I will be here.