The scope I've had from the beginning for TMJ has been so big that there was always the chance that it couldn't fit into a mobile browser. There are always the issues of speed and memory, which become bigger and bigger problems as game engines gain complexity.

The Olmar farm demo was inherently a tilemap, but it really contained two overlaid 8-bit PNG images of the width 672x544 clipped to 320x212 and 8 sprites that are each 128x256 8-bit PNGs clipped to 32x64. This ran at a fairly decent speed on the Nintendo 3DS browser, even with collision-detection and linking.

As I've been working on the Bryn tilemap this week, it quickly became apparent that there is no way that the Nintendo 3DS browser would be able to handle the same method of scrolling. Just the south entrance to Bryn is 992x768 pixels so far. The final village will be much bigger - probably around 3200x3200. Remember that PNGs are compressed during transit, but they are uncompressed to display in the browser window, so two layers of PNGs of this size would already be 20MB! Content of this memory usage will easily lead to out-of-memory errors in the browser.

I don't like to give up, since I started programming on a 1MHz Commodore 128 and stepped up to a 20MHz 386 a few years later. I'm used to slow code execution, so I've learned to make the best of it. Thus, I ran a few tests...

First, I tried testing 32x32 tiles being scrolled in a JavaScript canvas. This was so painfully slow that I nixed that idea.

Second, I tried bumping up the tile size to 64x64, and it was still too slow. Canvas was definitely not the way to go for any full-screen project of playable speed.

Third, I tried placing the 64x64 tiles into Image elements that scrolled in a clipped screen area. This was better but still too slow.

It was that moment I gave up. Sorry, but TMJ has been scrapped.

Haha, I had you for a moment, didn't I? Let's continue...

After a full rewrite of the scrolling engine, I came to a solution: 320x212 tiles! The magic of that tile size is that it is the screen resolution of the browser's bottom window. Thus, the browser only has to display 1-4 tiles (2-8 on the foreground and background layers) at one time.

Why do I say it's "magic"? Since the entire screen can be filled with 1-4 (2-8 ) tiles, what's the need to keep the rest in RAM at any one time? The PNGs are still fairly small, at 8kB to 16kB, so they can load over the Internet in just a few seconds. Thus, I just swap out tiles in real-time. This gives the speed of the large tiles and the small memory footprint of using tiny tiles.

Are you ready for levels of unlimited size? I know I am!