Log In  

I'm trying to make a thexder demake for pico8, and this is an mock up image.

I'm trying to use 3x3 tiles for the map with thexder being 9X12 and enemies being 6x6, instead of 8x8 tiles as they are too big for thexder's gameplay where the player can transform as a jet to get into narrow 3 block tunnels.

Since pico8's map can only support 8x8 I need to make my own mapping to use smaller 3x3 grids.

tilex = {}
tiley = {}
for i=1,252 do
for i=1,126 do

I tried making two arrays of each x and y variables, and the tiles are suppossed to be drawn at the position where both tilex[?] and tiley[?] equals 1.

for i=1,42 do
for i2=1,42 do
local xck=(player.x-20+i)+1
local yck=(player.y-20+i2)+1
if xck>0 and yck>0 and xck<=#tilex and yck<=#tiley and tilex[xck]==1 and tiley[yck]==1 then

the entire screen has space for 42X42=1764 tiles, but displaying all those tiles with sspr like adove code makes a bad result. it already uses half of the cpu that I imagine it will be really unplayable when players, enemies, and other systems are all thrown in.

I really have no idea efficiently utilizing 3x3 tile mapping, can anyone give me some hint to make it as efficient as using 8x8 tiles in pico8's default mapping ?

P#120793 2022-11-16 11:23 ( Edited 2022-11-16 11:24)

you need a better data structure for your map:

  • why not fully mimicking the map data structure? eg a flat list of bytes?
  • if too complex, a table of table will do
  • you need a structure that can directly address a map starting point (both 1d array and flat list will do)

The key aspect is finding the top/left corner of the map:

— assumes x/y are in map units
— ensure mx/my are within bounds

next find corner (using a 1d table):

local offset=mx+my*map_width
for j=0,39 do
 for j=0,39
 local tile=tiles[offset]
 — next tile
— next line

note: this will be slower than regular map() call as this is calling sspr much more

note: cannot provide a working example right now!

P#120794 2022-11-16 12:04 ( Edited 2022-11-16 12:07)

Would using flat list of bytes be something like this ?

Tiles[?]= "XXXYYYB"

First 3 letters for x coord, next 3 for y, and last for checking blocked or empty.

P#120797 2022-11-16 13:57 ( Edited 2022-11-16 13:57)

you can create a table in a table

for y=1,10 do
  for x=1,10 do
    field[y][x]=0 -- empty
field[1][2] = 20 -- set column(y) 1 row(x) 2 to value 20
P#120799 2022-11-16 14:36

maybe this can be useful for you:

#  #  #  #  #
# ### # #1# #
#  #  #  #  #

for l in all(split(gamefield,"\n")) do

width=#field[1] -- when all lines have the equal length!

print(width .. " x " ..height)
P#120800 2022-11-16 14:53

see discord ;)

and GPI answer is also good (except I find 0-based tables easier to work with in such case)

P#120804 2022-11-16 15:50 ( Edited 2022-11-16 15:52)

Now I understood how to properly store tiles in array theoretically, drawing optimization is the next issue as calling over 1000 sspr per frame is too slow.

I'll try just using spr to see if it's faster, and If I can't find any good ways I'll just use chonky 9x9 tiles to make both mapping and drawing much simpler as calling 196 sspr or spr will be a lot lighter.

Thexder gameplay can still work in 9x9 tiles,
even through the levels will look much blockier.

P#120818 2022-11-17 00:39 ( Edited 2022-11-17 00:42)

@hijongpark, there is another way.

Back on the Apple ][ when Ultima ][ made the platform, I was intrigued to see how they could manipulate their maps so quickly. It was machine-language yes but it seemed to run a lot faster than other mapped games.

Turns out after closely examining what they did - is not redraw every single tile every single frame like Ultima 1. But keep track of every single tile in a 2nd array. So for instance if you had something like this. Let's say the dark gray is grass and the light is forest:


And you wanted this:


You would compare the two arrays and makes changes ONLY the tiles that changed like so:


Therefore only redrawing =2= tiles instead of =9=

This would also work for a scrolling map, for instance if you have just a few tiles changing in a 9x9 field, like forest, you would only update where they were and where they are going whereas the other tiles visually do not change, like grass, so therefore - you need not redraw them.

P#120820 2022-11-17 01:10 ( Edited 2022-11-17 01:11)
function _init()
for i=1,31752 do


function _update()

if btnp(0) then
if btnp(1) then
if btnp(2) then
if btnp(3) then


function _draw()

local ty=player.y-20

for i=0,41 do
local tx=player.x-20

for j=0,41 do
if tx>=1 and tx<=252 and ty>=1 and ty<=126 and tiles[tx+ty*252]==1 then




This is the 3x3 tile map example I have managed to implement. uses 3x3 tile drawn in 0 sprite number, and use arrows to scroll.

solving the 50% CPU usage for calling spr() 1764 times per frame is still a mystery.

dw817 // That looks good, but I can't grasp my head to make that, because I think you eventually need to check every 31752 arrays to compare the difference per frame...

P#120828 2022-11-17 04:42 ( Edited 2022-11-17 04:50)

Hi @hijongpark.

Well here now you also shouldn't draw tiles that aren't there. For instance your entire map may be 31752 tiles but how many tiles will be on the screen at a time ?

If you like I can write an example of the speedy tile-plotter that uses the method I talked about earlier. It's not that tricky, it's just a matter of doubling the memory used to keep track of what moved on the screen.

P#120830 2022-11-17 06:05 ( Edited 2022-11-17 06:06)


The code I wrote displays 1764 tiles max, 42x42.

I'm not sure how will your method decrease the amount of spr calls for tiles, as it just tracks differences and don't drastically change the amount of tiles needed to draw.

P#120832 2022-11-17 06:23

you have multiple option but first is really to remove all maths from this core loop
all indices can be precomputed

second, you are drawing too many pixels, spr can take a fractional argument (3/8) to indicate sprite size

if not enough (agree that 41x41 spr calls is a lot), dw advice is valid - eg draw only needed tiles.
First frame:

  • draw map & copy to 0x8000


  • calculate offset with previous frame position (eg how much camera moved)
  • memcpy map to screen (shifting by y offset)
  • rebase gfx to screen
  • shift whole screeen with spr(0,-offsetx,0,16,16)
  • draw ‘missing’ tiles (eg screen borders)
  • copy screen to 0x8000

Tbh not sure this is going to cost less than 50% cpu 😜

P#120834 2022-11-17 07:14

Then I think the best solution will be :

  1. Squash thexder into 8x12 and 8x8 space somehow and use standard 8x8 tiles, althrough that means It can't shoot laser in exact center of the tile.

  2. Use 9x9 tile and only draw 196 tiles per screen.
P#120837 2022-11-17 07:37

Problem solved !!! It was actually very easy to put thexder in 8X12 and 8X8 sprites, so I can use standard 8x8 tiles now,

for laser firing positions I'll fire laser from two positions per frame when the jet is facing upward, downward, and diagonals as that will look cooler...

P#120842 2022-11-17 11:38

Hi @hijongpark.

Cart #map_3x3-3 | 2022-11-17 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA
TO LOAD THIS CART in immediate mode, type: load #map_3x3

Here is code example I wrote demonstrating to write to your screen of 42x42 tiles in addition to only drawing the parts that need redrawing.

When running, press CTRL+P. Notice when there is no map activity that it runs at 17%. At maximum it runs at 19%.

Try working your way towards the center of the map and you will notice something. Suddenly the clicking representing the map changes stop. Why ? Because at this point you are moving without changing any tiles.

Same thing if you enter the water. Eventually it realizes no tiles are changing so none are drawn and the CPU usage goes down.

Press πŸ…ΎοΈ to swap between the normal view you have now and movement mode which shows only what tiles are changed by a red square.

P#120860 2022-11-17 18:48 ( Edited 2022-11-17 19:31)

thanks for the effort @dw817, I hope this will be helpful to my possible future projects or others.

P#120884 2022-11-18 01:20

UBetcha. Glad to help, @hijongpark. :)

P#120887 2022-11-18 02:04

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2023-01-30 17:49:19 | 0.038s | Q:32