Page 1 of 3

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Thu Dec 07, 2017 11:18 pm
by Joefish
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.

But yes, it means a simple platform block becomes three separate tiles; empty space->platform, platform->repeated platform, platform->empty space.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 6:22 am
by Hikaru
Ralf wrote: Thu Dec 07, 2017 8:41 pm On the other hand we have Ghosts'n'Goblins. I'm probably in minority but I consider it to be a bad port :twisted: 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 :lol: 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. :lol:

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.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 9:33 am
by 5MinuteRetro
Hikaru wrote: Fri Dec 08, 2017 6:22 am 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?

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 11:44 am
by Ralf
I read it. Read it again. And read it again. And I still don't really geddit.
Okay. I guess I'll need to write a proper long post with pictures about it :) Especially as people showed interest in other posts.

Actually I disassembled engine of Stormlord some time ago and have my own game, about 30% finished using it so I know the details.

I'll try to do something during this weekend.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 11:47 am
by 5MinuteRetro
Ralf wrote: Fri Dec 08, 2017 11:44 am
I read it. Read it again. And read it again. And I still don't really geddit.
Okay. I guess I'll need to write a proper long post with pictures about it :) Especially as people showed interest in other posts.

Actually I disassembled engine of Stormlord some time ago and have my own game, about 30% finished using it so I know the details.

I'll try to do something during this weekend.
That would be amazing. I am very interested, but I think only an illustrated guide will help fix the concept(s) in my head.

(I imagine that GnG's eight-direction scrolling is a different thing entirely, though obviously I really have no idea. But if you could start with the tiling thing, that'd be marvellous.)

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 2:48 pm
by Joefish
5MinuteRetro wrote: Fri Dec 08, 2017 9:33 am 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.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 3:08 pm
by 5MinuteRetro
Joefish wrote: Fri Dec 08, 2017 2:48 pm
5MinuteRetro wrote: Fri Dec 08, 2017 9:33 am 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?

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 3:21 pm
by Joefish
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:

[youtube]https://youtu.be/NRMOan38qRU[/youtube]

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 9:59 pm
by Wall_Axe
I read that R-Type book again recently
I think it uses 2x2 (a.k.a. 16x16) blocks i think, for the scenery, it saves memory

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Fri Dec 08, 2017 10:45 pm
by Ralf
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:

Image

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

Image

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.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sat Dec 09, 2017 3:18 pm
by 5MinuteRetro

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.
The 8x8 sure looks like a confusing mess. But that's to me, not the programmer. I would've thought to the programmer these are just hex (or whatever) references that need to be called in a particular order. The programmer wouldn't be looking at the raw content of the 8x8 grids, surely?

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sat Dec 09, 2017 3:51 pm
by Wall_Axe
the altered beast game probly has repeatable blocks that are made up of these smaller ones

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sat Dec 09, 2017 5:28 pm
by C.Born

Code: Select all

; your sinclair issue 19 page 74
; it stll needs a full loop

org 32000
        di
        ld bc,6144
        ld hl,22527
loop:   srl (hl)
        call c,sub1
        srl (hl)
        call c,sub2
        dec hl
        dec bc
        ld a,b
        or c
        jr nz,loop
        ei
        ret
sub1    inc hl
        set 6,(hl)
        dec hl
        ret
sub2    inc hl
        set 7,(hl)
        dec hl
        ret

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sat Dec 09, 2017 6:36 pm
by Wall_Axe
i see the srl which i assume is the rotation
why are bits being set in the 2 subroutines though?

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Dec 10, 2017 12:06 am
by Joefish
The 'carry' bits dropping off the end of the rotations trigger bits to be set in the previously rotated byte. This method must be shockingly slow though. It must be quicker just to do two passes of a single pixel scroll!

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Dec 10, 2017 1:57 am
by Wall_Axe
oops yeah

yeah you've got a call to a sub twice instead of just jumping over the set command if no pixel needs to be set

I assume the advantage of dixel techniques would be if you are storing pre-rotated bytes, you only need half the amount

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Jan 05, 2020 2:45 pm
by Lethargeek
Joefish wrote: Thu Dec 07, 2017 11:18 pm 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.

But yes, it means a simple platform block becomes three separate tiles; empty space->platform, platform->repeated platform, platform->empty space.
I think there's other way as well. I mean, to mark the places of the current frame where proper scrolling is required and other places where a copy of the neighbouring (just scrolled) tile could be push'ed fast. Do not bother with combinations and wasting memory on pre-shifted tiles. Speed is determined mainly by the least percentage of empty space of all the possible frames. It is also possible to dynamically generate the scroller code making it faster. All in all, i think a screen similar to Stormlord's may be scrolled in 50fps with one-pixel precision.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Jan 05, 2020 3:29 pm
by Ralf
I think there's other way as well. I mean, to mark the places of the current frame where proper scrolling is required and other places where a copy of the neighbouring (just scrolled) tile could be push'ed fast. Do not bother with combinations and wasting memory on pre-shifted tiles. Speed is determined mainly by the least percentage of empty space of all the possible frames. It is also possible to dynamically generate the scroller code making it faster. All in all, i think a screen similar to Stormlord's may be scrolled in 50fps with one-pixel precision.
If you feel that it's doable then please do it :) We all would like to see something like that.

The closest existing thing I know is this demo, It is one pixel precise and running at 50 Hz indeed.
https://spectrumcomputing.co.uk/index.p ... 6&id=30420

But it's more similar to Cobra and not Stormlord as it has very limited graphics.
And adding sprites to it would probable slow it down and spoil all the effect.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Jan 05, 2020 3:55 pm
by Lethargeek
Ralf wrote: Sun Jan 05, 2020 3:29 pmIf you feel that it's doable then please do it :) We all would like to see something like that.
i did something similar 10 years ago, an example of alternative scroller for Sea Dragon:
https://zx-pk.ru/threads/11233-sea-drag ... post344002
tbh not quite the Stormlord style gfx, but it's actually scrolling the edge tiles
and it's more cluttered but about 1/2 frame time in the worst case
(press any key to see the time spent on the border)
Ralf wrote: Sun Jan 05, 2020 3:29 pmThe closest existing thing I know is this demo, It is one pixel precise and running at 50 Hz indeed.
https://spectrumcomputing.co.uk/index.p ... 6&id=30420

But it's more similar to Cobra and not Stormlord as it has very limited graphics.
And adding sprites to it would probable slow it down and spoil all the effect.
afaik it's only pushing pre-shifted data, no real scrolling and no skipping of empty spaces

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Jan 05, 2020 4:21 pm
by Ralf
Nice!

But would it work with graphics like Stormlord? Or Zynaps? Or Robocop?
I believe in your case you have quite a lot of simple graphics - empty space (filled with 0s) and solid space (filled with 255s).
In case of more complicated background you wouldn't be able just to update the edges and ignore middle parts of background objects.

I's all tricks and tradeoffs. Solutions working with specific type of data. You can't do on Spectrum full brute force 1 pixel scroll running at 50 Hz.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Jan 05, 2020 4:51 pm
by Lethargeek
Ralf wrote: Sun Jan 05, 2020 4:21 pm But would it work with graphics like Stormlord? Or Zynaps? Or Robocop?
It would be slower, yes, to push instead of just skipping the solid space. But typical Stormlord screen usually has much more empty space to skip. Zynaps - maybe, with careful level design. Definitely not Robocop.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Jan 05, 2020 6:22 pm
by Ralf
But typical Stormlord screen usually has much more empty space to skip
Maybe you missed it from the earlier discussion but Stormlord actually skips empty space.

At address 36132 you have CALL NZ, 36226. Which means draw a tile only if tile nr<>0. And tile nr=0 is empty space.

It works more or less the same way that you are talking about, I believe. Tiles are stored with some empty space at the edges
and when game area scrolls new tiles clear everything behind them.

Raf Cecco was really a clever guy.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Sun Jan 05, 2020 7:08 pm
by Lethargeek
Ralf wrote: Sun Jan 05, 2020 6:22 pm Maybe you missed it from the earlier discussion but Stormlord actually skips empty space.
No, i missed nothing. My point was it has more empty space to skip than my example.
Ralf wrote: Sun Jan 05, 2020 6:22 pm It works more or less the same way that you are talking about, I believe. Tiles are stored with some empty space at the edges
and when game area scrolls new tiles clear everything behind them.
Absolutely not the same way. Doesn't scroll anything on-screen and is wasting memory for pre-shifted tiles.

In my example, tiles are stored only once (and rotated 90 degrees to appear at the edge pixel-by-pixel) and later are actually scrolled on-screen.

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Tue Jan 07, 2020 9:24 pm
by catmeows
Seven.FFF wrote: Thu Dec 07, 2017 8:19 pm This is things in the foreground moving horizontally, rather than the entire background - but you can get pretty fast and furious, and deal with different speeds, when you scroll preshifted stuff. As long as you have the space to store all the different versions. I've gone 128K-only here for that reason!

Image
Eeeee. Does this thing really exist ? On Zx ?

Re: 'Dixel' scrolling... Ghosts 'n' Goblins

Posted: Wed Jan 08, 2020 8:44 am
by Vampyre
Edit: Doh! I can see that the "dixel" term had already been found way earlier in this thread!