Well, the trick is to set yourself some strict rules for level design to reduce the number of potential combinations. The easiest is to always leave one whole empty tile between different objects, then each object is only ever paired up with empty space.

On the other hand we have Ghosts'n'Goblins. I'm probably in minority but I consider it to be a bad port It''s smooth but that's all. It's very simplistic, with few tiles, ugly graphics, tiny sprites, few levels compared to arcade and crazy difficulty.

I respect the author (Keith Burkill) of course. He wrote Commando as well which is simply splendid without discussion.

As for the Ghosts'n'Goblins engine, I inspected the game code a bit once and would say there isn't any Really. For me engine is something reusable that you can use for another game. Here everything is hardcoded, data mixed with code all the time. There aren't any tiles or maybe there are tiles of different width and height. There is different code to scroll graves, different to scroll ground, different to scroll trees, platforms and so on. Totally crazy code that devil himself wouldn't understand.

I'd say the underlying game itself is bad to begin with, regardless of platforms. That out of the way, I do agree about the graphics to an extent. Specifically, it is this very messy way they use to combine the sprites with the bg that irks me the most (I have the impression it might be caused by badly designed sprite masks), I think it would have actually looked decent if not for this one problem. Mind you the second part has always looked much worse to me in comparison, I mean that f..king tree branch.

And yep, it has pretty crazy code that's hard to make heads or tails of. - Interestingly, it also adds vertical scrolling starting from lv2 in spite of it all. IIRC, a good number of Keith Burkhill's titles work this way internally (aside from Commando, there's also Marauder for instance). Notice however that he is actually building fairly coherent and varied levels with it. So I don't think it's all one-off hardcoded stuff, there's probably methodology and/or tools to build levels in this way.

And yep, it has pretty crazy code that's hard to make heads or tails of. - Interestingly, it also adds vertical scrolling starting from lv2 in spite of it all.

And not just vertical -- it's diagonal on the ice level. So, eight-direction smooth scrolling. Surely, at least so far as I understand it (which isn't much, tbh), the whole pre-drawn tiles idea can't work here. It can't be possible/practical to draw/store every possible tile combination for eight-way scrolling?

And not just vertical -- it's diagonal on the ice level. So, eight-direction smooth scrolling. Surely, at least so far as I understand it (which isn't much, tbh), the whole pre-drawn tiles idea can't work here. It can't be possible/practical to draw/store every possible tile combination for eight-way scrolling?

No, you wouldn't pre-shift the tiles vertically. For vertical movement you'd just draw them higher or lower on the screen. Shifting things vertically from one row to the next is fairly simple, as you're just copying to a different memory address. It's shifting horizontally at less than 8 pixels that's a problem for the Spectrum, as that entails rotating the bits within a byte. So it's much more efficient to prepare that in advance - though it does eat up memory.

The only faff with vertical scrolling is deciding how to do the cut-off rows at the top and bottom of the screen. If you're using a table of addresses for the lines of the screen, you can draw more lines than you need, and use that table to divert off-screen lines to redundant bits of memory. Or you can draw more than you need on the screen, and hide the cut-off areas behind all-black attributes. Or you can draw in whole rows to a buffer screen in memory, then copy a narrower window from that to the screen to trim the odd lines at the top and bottom. Or you can write a routine that can just draw a reduced number of pixel lines for each row of blocks, to trim down those at the top and bottom of the screen. But sometimes this can add so much extra checking that it's quicker just to draw everything and throw away a few lines of graphics with one of the other methods.

And not just vertical -- it's diagonal on the ice level. So, eight-direction smooth scrolling. Surely, at least so far as I understand it (which isn't much, tbh), the whole pre-drawn tiles idea can't work here. It can't be possible/practical to draw/store every possible tile combination for eight-way scrolling?

No, you wouldn't pre-shift the tiles vertically. For vertical movement you'd just draw them higher or lower on the screen. Shifting things vertically from one row to the next is fairly simple, as you're just copying to a different memory address. It's shifting horizontally at less than 8 pixels that's a problem for the Spectrum, as that entails rotating the bits within a byte. So it's much more efficient to prepare that in advance - though it does eat up memory.

The only faff with vertical scrolling is deciding how to do the cut-off rows at the top and bottom of the screen. If you're using a table of addresses for the lines of the screen, you can draw more lines than you need, and use that table to divert off-screen lines to redundant bits of memory. Or you can draw more than you need on the screen, and hide the cut-off areas behind all-black attributes. Or you can draw in whole rows to a buffer screen in memory, then copy a narrower window from that to the screen to trim the odd lines at the top and bottom. Or you can write a routine that can just draw a reduced number of pixel lines for each row of blocks, to trim down those at the top and bottom of the screen. But sometimes this can add so much extra checking that it's quicker just to draw everything and throw away a few lines of graphics with one of the other methods.

Okay, yep, I kinda get that too. Kinda. Still seems enormously complex to have to do that for numerous 16x16 tiles across the screen, on top of tracking which frame/object should be in which tile at any one time and have all that flow seamlessly, but I guess that's why I'm not a programmer or a Z80 processor.

A related question, though, now that I *think* I'm beginning to understand this is... why 16x16 blocks? I can see why one might avoid 32x32 blocks, for level-design reasons (to avoid huge blocks of empty space, for example), but why not apply this same 'dixel' technique to 8x8 blocks -- would that not allow for much-more-intricate level design? Or does effectively quadrupling the pre-shifted/tile-update overhead make this impractical/too slow?

You can use any size you want. A lot of games use 16x16 and similarly sized sprites, as it's a convenient size for both. You can get enough detail in for most characters, and they're not too big that they take too long to draw.

The trade-off is how much data it takes to store a level. If you do it character-by-character a whole screen is 768 bytes. Use 16x16 blocks and it's a quarter the amount of data to store a screen. Use 32x32 blocks and it's only 48 bytes. Another method is to arrange characters into 4x4 blocks (so 16 bytes each) then draw the level from those 4x4 blocks. It's all a trade-off between the amount of data, the time it takes to turn that data into graphics, and how detailed and varied you can make a level.

They don't have to be square blocks either. For a horizontally scrolling game you might even store complete vertical strips of scenery the full height of the screen and just arrange them in different orders, as in this ST demo:

A related question, though, now that I *think* I'm beginning to understand this is... why 16x16 blocks

16 x 16 pixels is a good compromise.

32x32 would be too big in most cases as you say although there are games that use it - as an example I can give Robocop 3, have a look on graphical representation of memory:

As for 8x8 tiles there are two problems:

1) Memory:
Imagine that you have to build a Spectrum screen which is 256x192 pixels from 16x16 tiles. It would be 16x12 tiles=192 bytes if we store tile number as one byte.

Now you are building it from 8x8 tiles. It is 32*24 tiles =768 bytes, 4 times as much. You may simply lack memory to store level maps with such approach.

2) It's hard to tell what is what
Now have a look at tiles in memory of game that uses 8x8 pixel tiles: Altered Beast

Can you tell what is what? I suppose no. Now imagine that you have such tiles and have to build a level with them in some level map editor. It's a nightmare.

Okay, i practice you probably have some more advanced design - for example you store definitions of objects like house or tree from single tiles and there are two levels - your map is made of objects which are made of tiles. But for me it's still a lot of work of building a world from such small bricks and I would never attempt it myself.