Mockup of a basic tileset I currently have going on:
I've decided to move MicrORPG off of BYOND, as I do with quite a few of my other projects. The reason for this is because I am finding myself needing more out of my hardware, and BYOND doesn't seem like the sort of engine I should be using for my projects. I have switched to BlitzMax for primary development, and I might go off into the world of Java and JavaScript for a while.
Anyhow, regarding the hero sprite, it turns out that keeping the body frame small, but enlarging the limbs and head tend to make the sprite look well-contained in the small size it is allowed to have. Usually in most RPGs, the head is the largest limb, and the torso is the second largest. I really like the way the style of this guy looks. It's slightly Megaman-esque.
As for the tilemap, I'm trying to use as few layers as I possibly need, so if I can get away with one background layer and one foreground layer, I'll be all set. Making several layers for a map is very tedious. I'd rather draw the combinations of different tiles together into one tile in order to achieve the desired effect rather than attempt to use two layers to combine tiles.
The palette uses only four colors, with a hot pink for transparent pixels. The game is meant to represent the Game Boy, so any alpha is omitted, and is instead replaced with a transparent mask for all images (the hot pink color). If any necessary transparency is needed, I'll need to resort to dithering to have a "half-transparent" look.
I'm sure I've shown this sort of UI many times before. Because BlitzMax's 2D Drawing command set allows me to take complete control over how things get rendered on screen, I've added things like scanlines and different overlay colors. The current state of development results in 60 frames per second, even when more than 17k 10x10 pixel images are being drawn to the screen per frame.
The screenshot above has some debug stuff shown on screen:
MEM (bytes of memory used):
The reaosn why this is so high right now is because it's taking into account the tilesets I have loaded, which are 200x1000 pixels each (I think I have two of them loaded). In Task Manager, the game sits at around 26Mb of RAM. This includes instruction code and libraries included in the executable, as well as the amount shown above.
FPS (Frames per second):
Pretty self explanatory. I'll be testing this on my older laptop to see if the FPS happens to drop when performing stress tests.
S (Sprite Counter):
This is reset to 0 every frame. Whenever a tileset blits a tile to the screen, this counter increases by one. Currently in the screenshot, 7580 sprites are being drawn to the screen (although you cannot see them because they currently are all blank). This includes the HUD (40x30x2 sprites), the tilemap (41x31x4), and the debug panel (40x2 for the BG, 16 for the key input squares).
There's currently no sprite sorting. I don't want to hang my program up sorting through sprites every frame, so instead what I plan to do is keep two arrays for actors. The BG and FG layer. Because a tilemap's layer can be drawn at any point, the order of the tilemap's drawing can be controlled. However, as actors appear on screen, their creation order is too difficult to track. Instead, their sprite data will hold another byte for drawing layer, and the program will simply loop over all of them twice (once for the BG layer, and again for the FG layer).
