The map is just drawn before the first frame and the rest is shifted in See the first post for installation instructions/what the source is. I'm very happy with how it turned out, since I think it has the potential for lots more abuse (For example, I'm using the bitmap command for the initial map-draw LOL but hey, who cares, you can't see it) especially I think for the ability to call sprites in from archive allowing me to use a full range of 256 tiles for every map Thanks for all your help!

Well, what happens is that the scrolling/movement routine requires the next row of sprites to be shifted in to be copied into RAM (about 384 bytes worth). Right now it's set up so that at the beginning, when I load the map, about 1kb of tiles are imported from archive into RAM, and the shifting routine "spritebank" is created by referencing that 1kb. I'm planning to "cut out the middleman," and see if I can create the spritebank by drawing on the tiles in archive. That way I can effectively have access to any and all tiles in archive The spritebank creation copy routine is only run once per button-press, so I'm hoping that the speed difference will be negligible.

Progress for today: shifted the extra 4 pixels to the top of the screen, since I realized the character (being 12x16) will appear more centered that way. Began writing custom assembly aligned-masked-16x16 character display routine.

Edit: It works. Every map now has access to 256 different tiles.

Woah, that's amazing! I made something similar for a project of mine in Axe, but it has nowhere near the fluidity of yours - excellent work! Does it constantly archive and unarchive areas that it loads in/out?

No, it's copied into ram from archive. That's why it's so fast edit:  ninja'd by hayleia lol

Each region is 24x24, stored in archive. There exists a meta-map, or tilemap of tilemaps (32x32) that determines how regions are placed in relation to each other.

When the loadmap routine is called, it takes metamap X and Y coordinates as arguments to determine which 24x24 tilemap is needed to be copied in. However, the amount of memory I allocate for the "active" tilemap is 32x32-- so that the edges of other maps can be easily scrolled in and out. The routine takes (X-1,Y-1),(X,Y-1),(X+1,Y-1),(X-1,Y),(X,Y),(X,Y+1) etc. and copies in the appropriate parts of each surrounding map to RAM, creating a 32x32 tilemap where the center 24x24 is the "active tilemap." When you walk off the 24x24 section, your metamap coordinates are updated accordingly and the loadmap routine is called again.

Note that this means that all the maps are static; and that they can only be changed temporarily. But that's the way the engine's always been so whatever.

One unavoidable issue is that if you change maps in the X direction, you will automatically take 2 steps. You will only notice this is you aren't holding down the button, so I don't think it'll be a huge issue. It's because a 32x32 area can only hold 4 tiles extra to be scrolled in on every side, and when walking to the left (due to the way the map is aligned) you would need 5 tiles. So I force map change a tile early when walking this way, then force another step so it doesn't get messed up. You can probably observe this by playing with it a bit in the build

Major mapping update



-Finished custom asm mask routine (although I need to change it a little to draw to any tile once I implement NPCs) Yeah, the routine is kinda poorly written; I'll eventually get around to optimizing it. Don't look! But the important thing is that it works for now lol
-Sprited character and animations
-Optimized/modularized movement code to allow tap-to-face-direction and improved speed with one change.
-Draws black automatically if shifting in non-existent data
-Last, but most definitely not least, implemented seamless map transitions. Remember in the demo and in Embers, in order to change areas you HAD to go through a door or something? No longer; now you don't notice anything when you move from one area to another (well, if you look really closely the grayscale flickers a tiny bit). Effectively, the world the player inhabits is 9216x9216px or 768x768 tiles...That's 589,824 tiles, or over 13,000 screens of world all seamlessly put together. The screenshot shows the character walking around on the edges of 3 areas. It only takes 2kb of RAM to run this mapping system

As usual, the build and source can be found in the first post

To-do:
-Collision detection + map switching via portals/doors
-Fix up mask routine
-NPC render engine (then I'll be done with all the overworld stuff...)

Wow, that's an awfully large world you will have to play with. Very impressive! The mapper is looking quite smooth so far. Nice work!

Thanks everyone

Streetwalker; yeah.

Sadly, I think I'm going to have to cancel plans for compression of maps. It's quasi-avoidable, but I think we'd see some drastic slowdowns during map switching and a sizable exec size increase. sorry guys

Yeah, he's always one tile over to the right Well, I could move him over a tile, but then he'd be off a little to the left, and this way the sprite routine gets to draw something aligned.

So yeah, the map always scrolls with the player.

Also I take back what I wrote earlier. Compression is still going to be implemented, although the total map area available will go down a bit (to 384x384 tiles which is plenty)

That sounds pretty cool!