If I've been silent so far it was because I was testing some things. So...
First of all, I can see two options to gain performance out of this:
a) Use a single big backgrop object and all the movable parts as different objects (such as crumbly walls or animated stuff). This way you get a ton of OP processing time back
b) Keep using tiles-as-objects but add branch objects
Option b is a bit more advanced so I wouldn't recommend that at all. So let's go with a. The question of course would be "how to fill such an object"? Here I could just tell you to draw each map as bmp, pack them, import them into the game and unpack them per screen. But that's again a bit advanced and hassle-y. I'd only recommend that if your graphic artist would like to go wild and draw the level as a single thing, not as tiles.
The other option is, like you did, store the map as rectangular tiles into values inside an array. Then you can draw the map easily and check for collision and stuff using this. But again the question remains, how to fill the object?
That's why I sat down and created a mini project that does exactly this. Let me paste the code over and walk through it:
set maps as short
... snip 998 lines...
dim x as short
dim y as short
dim c as short
dim tilex as short
dim tiley as short
dim map as short
dim i as int
DIM pi!: pi=3.1415926535897932384626433832795
for map=0 to 49
' Draw map
for y=0 to 19
for x=0 to 19
tilex=(c % 20)
for i=0 to 7
'Bring the map to screen
for ph=0 to pi/2 step pi/90/2
'Pause so the level can be seen
for i=0 to 255
'Send the object offscreen
for ph=pi/2 to 0 step -pi/90/2
First of all, the map itself. As you see it's stored inside the array maps, which is 20 columns and 1000 lines. If 1000 seems too big, it's just that I stored 50 levels one after the other. So maps to maps has the first map, maps to maps[20+19][20+19] the second etc. You'll also notice that each line of the map is enclosed in curly braces, that's essential so the compiler can know how the map is dimensioned. Lastly that "0x" business before each value means that the value is in hex. You don't need to do that yourself, plain decimal values are ok. I used hex because the maps were taken off a game and they came in binary format (hex looks much more tidy). FWIW the maps and tileset I used were taken from a PD ST game called Lost world (which, incidentally, is a manic miner clone ).
The most crucial part is that of map drawing. But to explain this I have to lay down some parameters first.
- The screen object is a 320x200 buffer in 4bpp mode
- The tiles are stored in a completely similar object
- The tiles are 16x8 pixels each
So if you do some number crunching then you'll see that each tile is 8 bytes in width (16 pixels * 4 bits per pixel / 8 bits per byte. So we need to copy 8 bytes horizontally times 8 times vertically per tile. For this I used lpoke which copies 4 bytes in 1 go. Which means we'll need 2 lpokes for copying 8 bytes per tile's line. The innermost loop (for i ... next i) copies a tile from the tile map at coordinates (tilex,tiley) to screen coordinates (x,y). tilex,tiley coordinates come from the map's current tile value, and converted to position inside the map. i loops for as many vertical lines per tile.
The x and y loops simply iterate through the whole map.
Then the rest is just bringing the map object to screen, pausing, and then sending it away. I decided to do this in order not to show the map redraws which could be ugly (plus, this is the 64 bit powerhouse, let's show some big object movement there!). But if you notice I don't pause when the object is off screen but it seems that the map is filled up pretty quick (at least on vj ).
So anyway that's mostly it. It shouldn't be too hard to convert to 8x8 tiles, just one lpoke per line would be needed and the offset calculation will need some adjusting but I trust people will get the idea! Full project will be pushed to the repositories right after I hit "submit" here .
Edited by ggn, Thu Mar 23, 2017 12:40 AM.