I got it to work, but it needs collision detection.
It is seemingly bug free.

Code:

Note: The map isn't rendered until after you move the first time.

Old post: When you use the LOCATE command with a String, the whole string is placed on the screen at once. Using simple equations, you could change the start of the string displayed. Combine these with 7 strings down the screen and you would not only have very fast map rendering, but you would also have easily changeable graphics on the screen. The only problem is, I don't see how collision detection would work.

However, even on a Prizm with a max String length of 255, this would increase the max size of a map from 21x7 to 255x99(Not sure about the Y coord).

Clever idea. By Y-Cord do you mean the graph screen or the X and Y coords on the home screen? If so, shouldn't it match the number of strings you can have? In this case it looks like 99 from your post.

By Y coord I mean the number of rows available for text on the regular screen, and yes. I'm just not sure how many strings I can have at once.

I'm not sure what the Casio equivalent of substring is, but you could probably use that. If I remember correctly, there is some pretty outstanding support on their calcs, so I'm sure there's some command to do it.

StrRight I believe selects everything after a certain number.

You should be able to use that or some other command to get all the characters around where the current user is, and then just check with that. I don't know how the strings are held or anything. If it's like on the TI, you'll have to have some if statements to check if the user is in row three, than above him is Str2 and below him is Str4, or something like that. Having those would probably mitigate the usefulness of this, unless you're able to store them in some kind of array. Assuming I'm understanding what you're saying correctly.

For the strings problem, you could still achieve impressively large maps with a limit of just 10 strings with your proposed method of map recal and rendering. One possible ammend to it could be to support 64*40 cell maps with only ten strings, each 255 chars long, by splitting each string into four 64 char long rows right before rendering. It would be a bit more work and slightly slower, but not too hard to not consider

Maybe I could get together with some programmer buddies and build one awesome map engine.

You seem to be in the perfect place to find programmer buddies

She could also have some outside Cemetech, Ashbad.

GoGoGo!

But we're for sure the cool ones!

Need some Prizm buddies first D:

Aw, Sarah. If I had more time to devote to my Prizm outside my work and hobby I'd totally be right there next to you on this.

Post a project topic and slowly develop it. People will get interested over time as more people get Prizms. Perhaps I'll take some time out of my hobby and learn the Prizm so I can slowly update it with you.

You plan to do this in BASIC, right?

Yeah

I got the scrolling to work - However, two bugs came up, the map scrolls in the direction opposite of that you move in, and it renders the wrong side of the map.

You should share the source, perhaps we'll be able to guide you through fixing it

Okay
No collision detection yet. I reversed the X+1->X and X-1->X so that the reverse scrolling was 'fixed'. But the other issue has not been fixed.

Code:

It seems all okay to me, but I guess there's something in there still causing that second error -- what exactly do you mean by the "wrong side of the map"? Is it backwards, upside down, or something?

You should start on the left side, but you start on the right.

Well, I'm not sure (can't test it right now), but it seems that the problem is near the end; you don't seem to draw the player (Which I assume is the 'O'?) with an X coordinate; you draw it at (11, Y). Could that be it?