Try Copy() (in the math menu)

Copy(source, destination,size)

Fill(PTR,SIZE) : The byte already at PTR is copied to all the bytes after it until SIZE bytes have been filled with that value. Zero is not a valid Size.
Fill(PTR,SIZE,BYTE) : SIZE bytes of data starting at PTR are filled with a value. SIZE must be greater than 1.

Copy(PTR1,PTR2,SIZE) : SIZE bytes starting from PTR1 are copied to PTR2 onwards. Zero is not a valid Size.

This is what the commands index says. I think it's pretty straightforward unless you don't understand pointers. If you don't understand pointers, check out this explanation, it's pretty good. (You can find other excellent tutorials and explanations of stuff here) If you still have questions, feel free to clarify/respond.

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...)

The custom variable method was created to make creating custom variables relatively easily.
x->{L1+2}^r is the same speed and size as L1+2->^oVAR : x->VAR

Note that you can abuse the custom variable system to create named constants, similar to finals in java, only you can actually notice the speed difference. For example, 32->^oMapW allows you to use ^oMapW in place of 32, anywhere in your code. Useful for debugging and clarity

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!

Hi everyone.

So, if you've been paying attention to any of the other threads on this forum, you might have noticed that I'm resuming work on this project. Today I completed enough progress to warrant making an official update

The tilemapper turned out to be quite a challenge to code. I wanted to use calcGS to handle the map and tile creation, since honestly, doing such a large project on calc was a massive PITA. However, using calcGS came with its own set of problems: export as 12x12 tiles? Or export as 4 8x8s? Well, at first I tried using 4 8x8s; it's kind of inefficient space-wise, but it plays nice with Axe's built in functions. I glanced at the old source code and chuckled. What was I thinking when I wrote THAT thing?? The old mapper handled each movement with its own routine, scrolling the map using Horizontal/Vertical and drawing with, get this; MASKED TILES mostly off-screen where they'd be shifted in appopriately. What was I doing??

I thought, I can just redraw the map every frame and have a nice, clean tilemapper, the kind I've been using in StickNinja, Embers, and Sandland. Except...grayscale. Oops, looks like even with my leet optimization skillz I can't get the mapper to run fast enough to support good grayscale.

Okay, no problem...I can do what i did before, but hey, I don't need to use masked tiles...this should be fine...

Nope, using 4 8x8 tiles with 12x12 tiles leaves clips and/or screen residue when you scroll, depending on whether you use Pt-On or Pt-Off. Choose your poison. So THAT's why I was using masks...

Well. This new version has to be at least a LITTLE better than the last one. There's no way I'm storing my tiles as masks...not to mention that calcGS does NOT play well with masked tiles.

Enter chickendude. With his help, along with lots of additional help from Runer112 and jacobly, I've managed to put together a hybrid Axe/Asm tilemapper from scratch (okay, maybe I did copy paste those 12 line blocks of rr (hl) \ inc hl's, thanks chickendude)

Anyway, in conclusion, check out the super not impressive screenie:



Oh, and as I promised, open source. The first page will be the go-to point for latest builds, screenies, and source

To do, by priority:
See if I can make the tilemapper run off of Archive. This, I think should be feasible and will let me cut down on user RAM and have 256 tiles per map
Add character sprite, animation
Start making tiles
(Later, after adding NPC rendering, I'll work on timing the gray better)
Begin infrastructure on sections of the program (menu, map transfer, npc, battle baselines)

*Documentation update*

(see first post)
The project is now (almost) officially moving out of spec-writing stage , just going to tighten up the memory allocation meta