For the fillrect routine, do you just define the window and write the same two bytes over and over? I imagine you would make the A register the height, then DE contains the values to write, HL could be the width and use the increment mode going down:
     ld c,11h
     dec hl
     inc h
     inc l
fillloop:
     ld b,a
fillloopinner:
     out (c),e
     out (c),d
     djnz fillloopinner
     dec l
     jr nz,fillloop
     dec h
     jr nz,fillloop
     ret

I am not familiar with the extreme tricks yet

Quote from: Xeda112358 on September 13, 2013, 11:20:43 am

I have a class dealing with optimisation that I have been bored in and so my mind wanders.

Lol I guess we all (as in us, Omni members) get bored at some point in CS class.

It's actually a mostly math-oriented class (mathematical programming and optimisation).

It is on hold until I have free time to work on certain aspects like the battle engine. That will take a while to code and I will need to be focused on it, which I am not at this point (work, school, clubs, homework, and sleep all leave me a few hours a day to do stuff). However, some aspects like design and layout are being worked on as those don't require as much focus, compression is something I am working on as well for both OmniRPG and Amber. I have a class dealing with optimisation that I have been bored in and so my mind wanders. I came up with another compression technique that I have been using class as 'free time' to analyse.

I know, I just had a pre-built map from the last project and I only changed a few tiles to add the houses.

I really need to work on the map editor to make it more user friendly and flexible. I am trying to make it so that whole houses and trees can be placed at once. I also have to work out a final format for the tilemaps as well as the compression and decompression algorithms.

Quote from: Xeda112358 on September 12, 2013, 10:09:28 am

The app could also handle loading a save file and copying the main program to RAM and running it (thus protecting the user from RAM clears making them lose the game and having to redownload it to their calc.).

Not sure what you mean by that, could you explain a bit further ?

If the person runs the app OmniRPG, it can be used to load the game, as well as providing a bunch of routines and holding data.

The automated keystrokes was precisely what I was thinking of yesterday after seeing this video.

The Tutor App can be found here, along with descriptions of the functions.

However, now that I think about it.... You said that you used stat plots to jump to pixels, so what if the key hook instead just jumped to a pixel directly? Edit (penrow) while in Trace mode. You might still have to move the arrow up/down, though.

Here is some code I started, designed for an app:
SetHook:
     ld hl,keysequence
     ld (keyseqloc),hl
     ld hl,HookStart
     in a,(6)
     bcall(4F7Bh)
     ret
HookStart:
     .db 83h
     cp 1Bh
     ret nz
     ld hl,(keyseqloc)
     ld a,(hl)
     or a
     jr nz,$+6
Exithook:
       or 1
       ld a,b
       ret
;commands are:
; bit 7 set means press Key, reset means set penrow
; if setting penrow and bit6 set, causes UP to be pressed, too.
     inc hl
     ld (keyseqloc),hl
     jp p,$+8
       and 7Fh
       ld b,a
       jr exithook
     bit 6,a
     ld b,0
     jr z,$+4
     ld b,4      ;skup
     and 3Fh
     ld (penrow),a
     jr exithook
keysequence:
     .db 0
;Use 0 to end the simulation.
;Use 1 to 127 for regular keypresses. The OS defines them like skUp, skEnter, et cetera.
;Use bit 7 set to set the pen-col coordinate, to [0,63] and bit 6 set as well will cause it to set the coordinate and simulate an UP keypress.

I have not tested that code and I think there are a few issues with it.

Wow, those tiles are fantastic! I am also pleased to find that I actually made a map editor for Amber (though not very user friendly). I completely forgot about it.

Also, speed-wise, 4-level gray and 3-level gray LCD updates are about the same speed, and since the tilemap runs from an interrupt and is animated, you could technically make the tiles animate at about 40FPS while allowing movement (and this is at 6MHz). However, there are a handful of difficulties including how to handle grayscale backgrounds while a menu is open or text is on the screen, and energy consumption (I am pretty sure grayscale would cause more of a drain than b/w most of the time).

I really do like those 16x16 tiles!

EDIT: Also, my hope is that groups of tiles such as those for whole houses would take up 1 byte when compressed.

I am not sure who all is in on the coding, except Matrefeytontias and I, but it might be a good idea for me to share what I am doing. For my tilemapper and all of the associated graphics including menus, text, rectangles, and most of the other drawing functions I have, they use a vertically aligned buffer instead of horizontally aligned. This means that instead of the bytes being:
0  1  2  3  4  ...
12 13 14 15 ...
24 25 26 27 ...

I have it as:

0  64 128...
1  65 129...
2  66 130...
3  67 131...
.........
I am using this method because it is working a lot faster and the code is smaller (it's also easier, actually). Axe uses the former method, and I know there will be a bunch of Axe coding for this project. Because of this, I think the tilemap stuff should be vertically aligned and everything else can be horizontally aligned to make Axe coding easier. As an alternative, I can create graphics routines callable from the Axe programs that work with vertically aligned buffers.

Since I will probably be the one delegated to tilemap stuff, which functions should I create? I was thinking that the following commands might work:

LoadMap(basename,mapID). basename would be something like OMAP and the ID would be two bytes identifying the map number. This command would load all of the appropriate data and pointers required to actually draw the map.

MoveLeft() This would scroll the map right if the player is able to move to the tile to the left. Return the value of the tile currently being occupied, the tile.
MoveRight()
MoveUp()
MoveDown()
TileSel() returns the tile value that the player is facing. For example, if the player presses Enter or 2nd, this might be called to see if the tile is anything useful.
AddEvent()
DelEvent()

These would be routines that the Axe code would make a call to to update tilemap stuff. The tilemap I have is running from an interrupt, by the way. I found it to be very useful for updating animations at a fairly constant rate.