I have decided that enough is enough and I need to sit my butt down on my creaky $35 walmart office chair and finish a darn Ti 84+ project for once.

I've had some experience as of late making small roguelikes (I have a roguelike I wrote in C for the 6502 that's build is <3.5kb!) and I want a "real" (ascii) roguelike for the ti 84+. I absolutely adore Calcrogue for the m68k calcs and I want that experience on the 84+ b/w calculators.

I just got maps that are larger than the screen working. Here's the main code (don't worry about GDB0, its just an Axe 1D/2D array):

Code:


So basically, this shows that I have the main rendering loop going, and this is very very nice. But how do I change the code so that I can render NxM map sizes? Right now, the code can only render a set size (offsets of 3, see?)

Once I get NxM maps working, I may shrink the tileset so its not 8x8 (possibly 6x6 or something a tad smaller to fit more map on the screen)

Roguelikes I've made before do not have a viewport as viewports take up precious bytes of memory! However, I want a scrolling tilemap.

It seems that the plurality of scrolling tilemaps work by having the player stay stationary and have the map move around the player. This would work, but its not what I'm going for. I want to go for the sprawling map style but still allow your character to move around a static viewport as I find it much less disorienting.

Currently, I have a render loop that places the tilemap from the upper left-hand corner, and then draws the player from the upper left-hand corner as well. This works well for a non-scrolling map. Is the solution to have two separate render loops, one if the map should scroll and the other if the map should stay stationary?

Okay, I think I may have worked out the steps:
I need a map-relative player.x,player.y and a screen-relative player.x, player.y and have these two play off each other. Every time I do a movement, update the global. But if I am within the bounding box I choose, update the screen-relative position only here. And if I'm outside the bounding box, I stay the same screen-relative position and scroll the map. Draw the map first, then player

I think I got it.

I need a map-relative coordinate pair for the player, a screen-relative coordinate pair for the player, and a screen-relative coordinate pair on where to draw the map.

It will be pretty "simple". Move the map-relative player coordinate every time you move.
Then, move screen space player if within the bounding box, and move the map space if outside the bounding box!

I'll see if I can't prototype something at home after work

I have made scrolling map algorithms before and they work quite well. Let me give you a rundown...

You need four [^^r] variables.

Code:

By using the ^^r we are able to increase the variable size from 16 to 256.

Now storing and displaying maps is a little more difficult. Since each map is just a string of characters we can combine X and Y placements like below to get a place in the map.

Code:


And lastly we can combine these below to get a pretty fluid map display.

Code:


Edit:
I would replace the extensive getKey layout for something more compact.

Code:

That way you can have much quicker program speed and it give +1 or -1 respectively which you can add to the player positioning.

Edit: Noticed problem with my code: didn't divide by 8. Added double r for larger values. Fixed "appvar" to "appv"

Another Edit: realized another incorrect piece of code.