World Map (Reading random data with the FX)

This little demo demonstrates reading portions of a large image straight into the screen buffer.


The repo is here > GitHub - filmote/WorldMap

Here is the original map … its 1191 x 848 pixels (and has a number of flaws including the UK joining France!)


I see lots of potential. Good demo mate!

1 Like

Now all we need is a mode 7 this is really incredible great work I’m impressed! Great job!

1 Like

I’ve actually looked into this before (back in 2019). The problem is getting decent performance.

There might be ways to speed things up that I haven’t thought of or ways to achieve similar effects,
but copying what Mode 7 actually does results in inferior performance.

Drawing.ino.hex (22.3 KB)

1 Like

Funny you guys mention that, ive been playing Mechwarrior 5 recently and it reminded me of the original on SNES (which used Mode 7) cuz i really want to make a version for rhe Arduboy (so.ive been reading/thinking about it a lot lately)… Granted ill have to finish Firestarter first (just to work up to something that complex) but i totally think it could be done (if not using mode 7 people in these forums have found several other methods to achieve the same result)… also just watched something about mode 7 and aside from the sprite scaling it allowed the background to be drawn in front of or behind other sprites, and some games use this differently… like mechwarrior its just the flat ground but other games like castlevania used it in a way that it almost looked like it could be wrapped around like a tube (if that makes sense)… im not sure the specifics of how everything works under the hood (obviously lol) but this may be part of why it renders slower in your demo (i only say this because of how the surface almost appears to curve up in the same way, maybe it can be further optimized, just a guess though idk).

Also stumbled across this yesterday: NES Mode-7 engine progress June 30, 2019 -- 8-bit 360 movement - YouTube

Nice! I see you’re getting the hang of it :slight_smile:

Now imagine you don’t have to convert the worldmap image to a data array and you could include it in the fxdata.txt file as

image_t worldmapGfx = "../graphics/worldmap.png"

and you can draw the map as:

FX::drawBitmap(x, y, worldmapGfx, 0, dbmNormal);


BTW I pushed an Homemade package / FX library update yesterday. You now no longer need to do a FX:disableOLED() before FX:begin() and there’s a new function FX::display() added so you can use that instead of the FX::enableOLED(); arduboy.display(); disableOLED(); making things just a tad easier :wink:

1 Like

My image is 1191 x 848 … would FX::drawBitmap() handle this size and handle it efficiently?

Yes and you don’t need a multiple height of 8 pixels either (the masking is handled properly too).

Part of my learning was to read segments of a larger array. I am thinking the array may not be an image but rather a level map.


Is there any upper bound to this efficiency or is it only pulling what is visible? i.e. could the world map be 10 times bigger than this and drawn in the same method?

drawbitmap() only draws the visible portion of the image and the image can be as large as you want. The limit is the flashchip size.

You could store a 1-bit version of Zelda’s 2560x2048 pixel overworld in a 560K image if you want to :slight_smile:


I’m hoping to get chance to extend my recent tile map demo to render a map from the FX for demonstration purposes. (But if anyone else wants to beat me to it then they’re welcome to do so.)

For those to whom it may not be so obvious: the reason a tile map is more useful than mere bitmap data is because a tile map can include things like whether the tile is solid, thus allowing for collisions and thus being a big step towards creating a proper game.

1 Like

Also keep in mind, you can write to the flash memory too so if you want the player to be able to manipulate the map that’s also possible too. Explode open cave doors and such. Just don’t go crazy with the writes but if you wanted to use it to record states in an RPG game that would work really well.


You can, but it’s not quite as simple as with RAM or EEPROM because of the way flash works - you can toggle a bit from 1 to 0 fairly cheaply, but to set a bit from 0 to 1 you have to erase an entire page, which sets all bits in that page to 1, which means you’d effectively have to keep a copy of the map in RAM so that you could restore the data that you didn’t want to change.

At least, that’s how I understand it.

You could possibly use the screen buffer if you can read / update / write in a single action.

1 Like

This is true (a page is 256 bytes compared to the 1KB frame buffer), though if the erase and write speeds are significant you may have to bypass the rendering phase for a few frames, or just put up with the delay somehow. It’s not impossible by any means, it just means extra work and hurdles.