TILES! A brick wall made of them...

[TMD2003]

...that's what I've just hit. It always happens when I'm trying to learn something new. I come across a concept that's completely alien to anything I've ever encountered before, that I can't even relate to anything else to understand via analogy. If it happens with Python, as it already has, I'm scuppered because the option is to ask someone who knows, and when it comes to "proper" programming, the more they know, the less likely they are to help. I have just watched a particularly scathing video about Stack Exchange and the way noob-questions are handled, and the high-end users are inevitably rude and snarky. "If you are unable to understand this concept that I find triflingly simple because I've been programming in this language for 30 years, you are unworthy of my time, now begone, pleb!" And that's if you're lucky - others may just issue a dismissive "RTFM!"

But this isn't Stack Exchange. Fortunately.

I have RedTFM (if you see what I mean) until the end of chapter 17 and come across tiles and the TILE command. Unfortunately, there is no satisfactory explanation of how to use it - the syntax of the TILE command is explained, and there's a mention of one to three BANKs to hold the tile data (defined by the TILE BANK command) and one further bank to hold the tile map (defined by the TILE DIM command).

The tile map is where I have run into a brick wall, because there are no instructions whatsoever about how to create the tile map, from scratch, in Next BASIC.

So I went looking to see if there were any instructions. One video by ChibiAkumas is about how it's done in Z80 - he's got tons of machine code programming information, but that's not what I want right now. There's this bloke called Lee who has a very high-pitched voice, who did at least show the existence of Remy Sharp's sprite editor. Thing is, that's also not what I want at this stage. It's a bit like getting in one of those future-cars from Demolition Man and setting it to Auto-Drive. What I want is the equivalent of: if I am completely competent with a self-driving car of 2032, how do I drive a 65-year-old Dodge Charger with a manual gearbox?

i.e.:
"Press and hold the clutch pedal down"
"Move the gearstick left and forwards to engage first gear"
"Bring the clutch up until you can feel the engine starting to engage"
"Press the accelerator down, gently, while releasing the clutch, gently..."
...and we move off.

A poor explanation would be: "put the clutch down, put it in first gear, bring the clutch up" - but bringing the clutch up immediately will cause the car to lurch forward and then stall. "But I did what I was supposed to... why did it do that?" Think of that as they equivalent of an error report, where it's completely un-obvious where it's coming from, because the reason why it happened wasn't even mentioned, let alone explained.

So this is where I am now: tiles6a.bas

What I have is a program that draws 64 "test tiles", 16×16 pixels, in the top third of a LAYER 2 screen, thus filling BANK 9. Each one of these is scanned sequentially with POINT... TO and poked into BANK 10 in sequence, so that each 16×16 tile has been cut into 16 rows and all these are placed side by side to make a 256×1 strip, in the middle third of the screen. BANK 10 is copied to BANK 47, which has been assigned as the tile bank.

So all I need now is a tile map, held in BANK 46, which will allow me to access any of the 64 tiles and print them on screen... somehow.

The only explanation I can find is on this page, where everything ins explained in a highly abstract, technical way, designed to be understood only by those who already have a total understanding of the Next's architecture. As far as I could understand - the tile map should be a mere 128 bytes long, two bytes for each tile, the first byte (bits 0-7) being the number of the tile... 0-63 or 1-64 or something like that - which appears to have no connection to the parameters of the TILE command - and bits 8-15 don't appear to be something I'd need to know for now - I'm not trying to rotate or flip the pattern - so I've set them all to zero. This is what I've done in the last procedure that I've called deftilemap()...

...but whatever I do, all I've been able to manage is to get "tile 1" to print somewhere in the lower third of the screen, which I left blank for testing purposes. Nothing I have tried so far will induce TILE to print one of the other tiles anywhere. And I have no idea whatsoever what I'm doing wrong, or why, or how it can be fixed.

I did try the Sprite Editor to get some kind of example of what a tile map should look like: I drew a 16×16 sprite, stuck it in the tile section, downloaded the tile map and examined it in a hex editor. This did not reveal any secrets as to how the tile map worked, only that it starts with eight bytes that translate to "PLUS3DOS", and is 320 bytes long - when I was expecting 128. This has been no help at all.

Does anyone know - or should I try the Spectrum Next forums? They seem to be a bit short on activity, mind...

[Seven.FFF]

Those forums are pretty dead. All the action is here

https://www.facebook.com/groups/ZXNextBasic

And here

https://discord.gg/SsfYaQSpKB

[TMD2003]

Right - I signed up there, I see you've posted a few times.

Big Tech is something I tend to give a wide berth, but I suppose this is one of the times it's inevitable...

[TMD2003]

UPDATE for @Seven.FFF after that Discord session:

The mystery of the tile map is still not entirely solved. After defining the 64 numbered tiles (now 0-63), I can confirm they're saved properly in the tile bank. So, if I wanted to print them all successively in reverse order, surely what I have to do to create the tile map (BANK %m) is:

Code: Select all

FOR %n=0 TO 63: BANK %m POKE %n,%63-n: NEXT %n

Of course not! It's never that simple, is it? What I have to do is:
POKE 63-48 to addresses 0-15;
POKE 47-32 to addresses 64-79;
POKE 31-16 to addresses 128-143;
POKE 15-0 to addresses 192-207.

Why would that be? Seeing as, in the original version in the code tags, I had something POKEd into addresses 16-63 and it had no effect on the top row, it looks like this is 48 bytes of wasted space. Is it wasted?

EDIT: I had the TILE DIM width set at 64, thinking this meant "the total number of tiles", when it's supposed to be the number of tiles in the x-dimension.

It further occurs to me that at least one tile is going to need to be defined as totally transparent if the TILE command is going to be of any practical use, as I can find no other way of getting the tiles to print at a specific position on screen, and they also appear to be locked into the 16×12 grid if we're dealing with 16×16 tiles. There I was thinking I could put them at a specific PRINT POINT position. I suppose that's what sprites are for.

So in reality, printing tiles on screen is a bit like... gasp! - Commodore BASIC!

Code: Select all

PRINT "{heart}{a load of Qs and square brackets}*"

Except here, it's a case of "define tile 0 as completely transparent, then fill the screen with 0 tiles until we're at the position we want"...

Someone at Next HQ owned a VIC-20 and they miss those chunky characters.

[Seven.FFF]

TILE by itself will display an entire screen of tiles.

Code: Select all

TILE
TILE AT x,y
Draw entire screen from tilemap, from tile offset x,y in the tilemap (0,0 if not specified).

So if you have cells in that entire map that need to display "nothing", then of course you need a "nothing" tile to display there. It can be transparent if you have another layer that needs to show through from begind, or it can be your background colour if "nothing" really means the background colour you want to use. It's really not any different from any other tile.

But it sounds like you want to do sparse tile printing of a smaller section of the map. That's what the additional arguments to TILE are for:

Code: Select all

TILE w,h
TILE w,h AT x,y
TILE w,h TO x2,y2
TILE w,h AT x,y TO x2,y2
Draw section of screen from tilemap.
Number of tiles to draw is width w, height h.
Draw from tile offset x,y in the tilemap (or 0,0 if not specified).
Draw to tile offset x2,y2 on the screen (or 0,0 if not specified).

If you wanted to draw a single tile from the map at the 10,12 cell, then TILE 1,1 AT 10,12 would do that.

If you wanted to draw a 3x4 block of tiles from the map, with the top left corner in cell 4,5 and the bottom right corner in cell 6,8, then TILE 3,4 AT 4,5 would do that.

[TMD2003]

All those "specific tile" and "section of tiles" commands were as clear as very dense mud until I'd completely worked out how the tile maps are laid out. Initially, I'd been trying TILE... AT... TO and all I could get it to do was print tile 0, and always in the same place. But it's all sorted now.

So unless there are any more pitfalls (which I won't rule out), then some time tomorrow, I can actually clean up and release my first ever Next program. It's not going to be big or earth-shattering, but it might just be helpful.

And then I can move onto sprites... those are going to be fun, I can see it now.