@Deep Thought: That is partially the reason. Originally, I was making a reference to Old Amber (the stuff that Aerodactyl was resurrected from). Then I started thinking about it and thought it was a great idea because it was a color/stone. As well, when I was trying to think of a name for Jade, I thought of Amber and decide to keep with that idea.

@deeph: I have an events handler that holds all of the event tile data (trees that can be cut, boulders that can be moved, warp tiles, items, NPCs). Essentially, I just loop through the events and draw any necessary sprites and execute any events. There are no events in the current map, but once I add them, it will start to slow things down. (60 events could take over 100 000 t-states to handle)

Also, each event will have some flags associated with it (in the save file). The reason for why I am doing it this way is so that maps don't have to be edited as the player plays the game. If an item is picked up, a flag is set and the event is removed. When the map is drawn, first the tiles are drawn, then the events are placed on top. If the item flag is reset, it won't get drawn, and the tile works normally again. If the player goes back to the map, the item is no longer added to the events list when the map is loaded.

Trees, boulders, and warp tiles don't have any flags associated with them (so trees reappear every time you re-enter a map). I think there will only ever be 20 to 30 events max per map. and the only ones that will be drawn are items, NPCs, trees, and boulders.

I have some feature requests...

I finally used this for the first time today and I really like it! I was trying to make masked sprites, but there aren't any options available. Instead, I used the 4-level gray option and toggled the pixels accordingly. Unfortunately, this makes it kind of tough to visualise the sprite to make sure I am setting the pixels properly, so it would be cool to have it as an option. There are two ways that I am familiar with (and I have used both, depending on the conditions) :

---

Method 1: AND - OR
First layer is used as an AND mask. This tells which pixels to erase/preserve on the current image. Alternatively, you can make it so that a pixel OFF on this layer corresponds to an OFF pixel in the sprite. In other words, you can start this as all black.
Second layer is used as an OR mask. These are all the pixels that are set by the sprite.

The cleanest way to display this is to have it so that an ON pixel in the AND mask is displayed as gray, an OFF pixel is displayed as white. Any pixels OFF in the OR mask do nothing, pixels ON show as black. If the user toggles a pixel off, it should turn the pixel off in both masks.

---

Method 2: OR - XOR
The other method, the first layer is an OR mask, turning on pixels, the second layer has set bits that turn pixels OFF.

A pixel ON in the XOR mask should also be ON in the OR mask. This makes a white pixel.
A pixel OFF in the XOR mask and ON in the OR mask makes a black pixel.
A pixel OFF in both masks won't change the background.

The visualisation for this would be gray if both pixels are off, black if only the XOR pixel is off, white if both pixels are ON.

---

The other request would be one of data output syntax. I don't know how popular it is, but I tend to store my gray and masked tiles such that the two layers are interleaved (for assembly, this is easier/faster for me). So for a ball, I might have:
;OR Mask
.db $3C,$7E,$FF,$FF,$FF,$FF,$7E,$3C
;XOR Mask
.db $00,$3C,$7E,$7E,$7E,$7E,$3C,$00
That will cause the pixels on the outside of the ball to be unchanged when it is drawn, the pixels inside get set to white, perimeter is black. The data as I store it:
;Interleaved
.db $3C,00,$7E,$3C,$FF,$7E,$FF,$7E,$FF,$7E,$FF,$7E,$7E,$3C,$3C,00

I hope this makes sense! I won't have much trouble converting it myself (I have a spreadsheet that I have had for a looong time to interleave data and do other manipulations )

To answer DJ_O about the missingno. question, I don't plan to add that in.

Now I have another small update (I am afraid that I am concentrating too much on details, now). A few days ago, I had some scrolling done, but it didn't scroll in the new tiles, making it bad looking. I now have smoothscrolling finished for up/down, but now I need to finish left/right. Luckily, I have an idea for how to make it work (and it will be about the same speed as scrolling up or down). As well, I found a small issue with my code that was actually slowing down animation significantly. I was resetting the wrong flag in a routine, causing the tilemap to be redrawn and the LCD to be updated every time the interrupt fired (instead of when a tile went to the next animation frame). After fixing that and taking out about a 1000 cycles of code on top of it, I had to increase the animation counter from 16 to 128 to make it reasonable


Oh, I also added an in-game menu with options that don't do anything (except the Options menu and Exit). I forgot to include it in the screenshot, but maybe I won't next time

The character sprite does actually have a walking animation, but it isn't very good and you can't easily see it. I am thinking of making the character sprite 16x16, keeping 8x8 tiles, but I haven't decided on that yet (you can see a lot more on screen with 8x8 tiles and 8x8 character sprite).

That is an excellent idea! So the code would look like:
     ld ix,gBuf+128
     ld b,64
shiftrightloop:
     srl (ix-128) \ rr (ix-64) \ rr (ix) \ rr (ix+64) \ inc ixh  ;100
     rr (ix-128) \ rr (ix-64) \ rr (ix) \ rr (ix+64) \ inc ixh   ;100
     rr (ix-128) \ rr (ix-64) \ rr (ix) \ rr (ix+64)  ;92
     dec ixh \ dec ixh \ inc ix ; 26
     djnz shiftrightloop
     ret
That is 21210 t-states, which is much nicer!

The way I have it is the tilemap is drawn to the graph screen (plotSScreen, 9340h) and certain 'events' such as NPCs, the player sprite, items, movable boulders, and anything else blocking paths are drawn to two other buffers (one buffer for the sprite mask, the other for the sprite data). Then during the LCD update, I just take the three layers and mash them together. My LCD updating code is basically:
     ld hl,gBuf
     exx
     ld hl,buf0
     ld de,buf1
     exx
     ld a,20h
colm:
     out (16),a
     inc a
     cp 2Ch
     ex af,af'
     ld b,40h
rowm:
     ld a,(hl)
     exx
     or (hl)
     ex de,hl
     xor (hl)
     ex de,hl
     inc de
     inc hl
     exx
     inc hl
     out (17),a    ;79 t-states is enough
     djnz rowm
     lcddelay()
     ex af,af'
     jr nz,colm
     res lcdupdate,(iy+asmflags)
     ret

While the tilemap is drawn with aligned sprites (it is more 10 than times faster than my general sprite routine, I think), scrolling the screen will still take a speed hit and the difference will be noticeable from scrolling up/down versus left and right. By my estimate, scrolling the screen left/right will be about 4 times slower, so I will have to add in additional code to keep scrolling consistent.

Here is a screenshot from another project where I wrote a tilemap routine:

That is with basically no delays, but also no smooth scrolling. This is an example from the same project with smoothscrolling:

Since Pokémon Amber uses a different gBuf setup, (and since tilemapping and whatnot is done from an interrupt), I don't know how speeds will compare. However, that is basically the same technique I plan to use. Shift the screen, shifting in the appropriate sprite data. This is why it will shift in whole tiles 1 pixel at a time. I won't have to do anything too complicated or slow.

(screenshots are from the OmniRPG - Coding discussion)
I wonder if I should use those tiles? ...

Well, i've a nspire touchpad so the gba emulator doesn't work in this nspire. And this seems to be very cool

Hmm, the GBA emulator works on my CX CAS and the GBC emulator works on both of my nspires.

Also, a minor update:

There is now some basic walking and navigation. I am working on adding in the smooth scrolling part (I have the sprites for the player to walk, as well as the code done).
Smoothscrolling will probably slow things down to 1/4 the speed, depending on how I do it. That should make it a more comfortable speed.

Can you port it to nspire?

I can try. I do need to get experience with nspire programming.

that's amazingly fast. wonderful =)
if it's supposed to be the ancient past, are you going to have any trainers?

There will be trainers, but there will be a few other important design differences. There won't be a PC, so your bag will be bigger. It will be able to carry your items and 20 Pokémon. There will be places where you can drop off your Pokémon, too, like a daycare, and in order to retrieve your Pokémon, you need to go back to the specific daycare. Internally, going to a given daycare will be the equivalent of opening up a box in your PC. In your bag, there will be two pockets for items (one of them is analogous to the items box on your PC), a pocket for apricorns (ancient version of Pokéballs), a key items pocket, and a TM/HM pocket. HMs will also work differently in Amber.


I still need to work out a good storyline .__.

Pokémon Amber is neither a clone, nor a port of a Pokémon game. It takes place 100 million years in the past, before Fossil Pokémon went extinct. After doing much research into ancient Pokémon, it is realised that we don't know the habitats of most Fossil Pokémon and there is some ambiguity in their types. What was the Pokémon world like 100 million years ago? What other Pokémon existed that have not been discovered? How have they adapted through time? These questions and more will play a key role in the development of Pokémon Amber.

Note: This game is not endorsed by Nintendo or any other Pokémon-affiliated organisation. This is just a game being developed by a fan purely for the enjoyment of others. There will be some creative liberties taken.

---

I thought I would start posting progress here instead of keeping it to my signature. As of yesterday, the following screenshot was up-to-date on showing progress:

As you can see, I have a scrolling, animated tilemap with proper clipping, and working text commands. As well, I wrote routines for easily making menu and drawing rectangles. Internally, there is a token set, so words that are used frequently in the game can be represented by 1 byte and menus can be somewhat interactive.

I ended up completely rewriting the graphics today, after analysing a different approach. This made the tilemap routine take about 60% of the time previously required (so it is a lot faster) and all of the current drawing got a speed boost (as well as LCD updating). My plan is to keep it running at 6MHz and it is currently energy friendly, I hope (it makes heavy use of the halt instruction).

Things I need to do:
I need to place a player sprite on the screen as well as NPCs and other objects. These are all handled by the event handler, so once I have that finished (probably a good hour or two of focused coding), then trees (or Vines, in this game), boulders, non-player characters, doorways, warp tiles, and all of that will be in working order.

I need to make a smooth-scrolled transition as the player walks. This will definitely slow things down, but that should be fine.

I have not started on battles, Pokémon, or Items yet.

This game will probably use a lot of RAM. I am trying to keep it all in non-user RAM, but that will not be possible with the storage system. Save data will be about 1000 bytes, plus however many Pokémon I allow in the PC (it is about 50 bytes for each Pokémon). So to use the PC system, I either need to have all the boxes in RAM or, only a few at a time (like how the first two generations required you to save every time you changed boxes, it was basically archiving the data and bringing a new box to RAM).

Sprites are going to be monochrome, 24x24 and I plan for 64 pokémon total. This means 4608 bytes of sprite data, but they will all have additional information, bloating it to around 6400 bytes for Pokémon data. Because of this, I will probably have map data and most other event data stored in archived appvars, unless somebody thinks it is a better idea to keep it all in a multi-page app. If I keep it separate, it might be easier to create new games.

Here is a more current image: