'Dixel' scrolling... Ghosts 'n' Goblins

General software. From trouble with the Banyan Tree to OCP Art Studio, post any general software chat here. Could include game challenges...
User avatar
Joefish
Rick Dangerous
Posts: 2041
Joined: Tue Nov 14, 2017 10:26 am

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

Post 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.
User avatar
5MinuteRetro
Manic Miner
Posts: 755
Joined: Mon Nov 13, 2017 12:21 pm
Location: UK
Contact:

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

Post 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?
Retro stuff, real quick
YouTube: http://bit.ly/5MinuteRetro
Twitter: https://twitter.com/5MinuteRetro
User avatar
Joefish
Rick Dangerous
Posts: 2041
Joined: Tue Nov 14, 2017 10:26 am

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

Post 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]
Wall_Axe
Manic Miner
Posts: 492
Joined: Mon Nov 13, 2017 11:13 pm

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

Post 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
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

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

Post 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.
User avatar
5MinuteRetro
Manic Miner
Posts: 755
Joined: Mon Nov 13, 2017 12:21 pm
Location: UK
Contact:

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

Post 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?
Retro stuff, real quick
YouTube: http://bit.ly/5MinuteRetro
Twitter: https://twitter.com/5MinuteRetro
Wall_Axe
Manic Miner
Posts: 492
Joined: Mon Nov 13, 2017 11:13 pm

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

Post by Wall_Axe »

the altered beast game probly has repeatable blocks that are made up of these smaller ones
C.Born
Manic Miner
Posts: 202
Joined: Sat Dec 09, 2017 4:09 pm

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

Post 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
Wall_Axe
Manic Miner
Posts: 492
Joined: Mon Nov 13, 2017 11:13 pm

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

Post by Wall_Axe »

i see the srl which i assume is the rotation
why are bits being set in the 2 subroutines though?
User avatar
Joefish
Rick Dangerous
Posts: 2041
Joined: Tue Nov 14, 2017 10:26 am

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

Post 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!
Wall_Axe
Manic Miner
Posts: 492
Joined: Mon Nov 13, 2017 11:13 pm

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

Post 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
User avatar
Lethargeek
Manic Miner
Posts: 734
Joined: Wed Dec 11, 2019 6:47 am

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

Post 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.
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

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

Post 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.
User avatar
Lethargeek
Manic Miner
Posts: 734
Joined: Wed Dec 11, 2019 6:47 am

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

Post 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
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

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

Post 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.
User avatar
Lethargeek
Manic Miner
Posts: 734
Joined: Wed Dec 11, 2019 6:47 am

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

Post 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.
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

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

Post 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.
User avatar
Lethargeek
Manic Miner
Posts: 734
Joined: Wed Dec 11, 2019 6:47 am

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

Post 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.
catmeows
Manic Miner
Posts: 711
Joined: Tue May 28, 2019 12:02 pm
Location: Prague

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

Post 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 ?
Proud owner of Didaktik M
User avatar
Vampyre
Manic Miner
Posts: 833
Joined: Wed Nov 15, 2017 2:51 pm
Contact:

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

Post by Vampyre »

Edit: Doh! I can see that the "dixel" term had already been found way earlier in this thread!
ZX Spectrum Reviews REST API: http://zxspectrumreviews.co.uk/
wizbob
Drutt
Posts: 4
Joined: Mon May 20, 2019 12:24 pm

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

Post by wizbob »

catmeows
Manic Miner
Posts: 711
Joined: Tue May 28, 2019 12:02 pm
Location: Prague

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

Post by catmeows »

wizbob wrote: Tue Sep 01, 2020 12:47 pm I don't know if you guys have seen this beautifully illustrated review of the dixel scrolling in Ghosts'n'Goblins.
Thanks.
Proud owner of Didaktik M
Nienn Heskil
Microbot
Posts: 132
Joined: Tue Jun 09, 2020 6:14 am
Contact:

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

Post by Nienn Heskil »

Spends waaay too much time on obvious things like the sprite method, but it was interesting to learn about the scrolling of attributes at least (I've used a similar approach in Mint). Perhaps this is one of the reasons there's no color on levels with vertical scrolling added.

I think the most interesting thing about GnG is definitely the crazy way the backgrounds are put together from different elements. This and Marauder, also maybe Zynaps... I've always wondered what sort of tools they've used to make the level maps (assuming it's not all hardcoded).
User avatar
Einar Saukas
Bugaboo
Posts: 3070
Joined: Wed Nov 15, 2017 2:48 pm

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

Post by Einar Saukas »

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

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
Ouch!

Here's my version of dixel scrolling:

Code: Select all

    ld hl,16384
    ld bc,24
loop:
    rr (hl)
    ex af,af'
    rr (hl)
    ex af,af'
    inc l
    djnz loop
    inc h
    dec c
    jp nz,loop
The same routine using unrolled loop:

Code: Select all

    ld hl,16384
    ld b,192
loop:
REPT 31
    rr (hl)
    ex af,af'
    rr (hl)
    ex af,af'
    inc l
ENDR
    rr (hl)
    ex af,af'
    rr (hl)
    ex af,af'
    inc hl
    dec b
    jp nz,loop
presh
Manic Miner
Posts: 237
Joined: Tue Feb 25, 2020 8:52 pm
Location: York, UK

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

Post by presh »

Einar Saukas wrote: Tue Sep 01, 2020 6:53 pm Here's my version of dixel scrolling:

Code: Select all

    ld hl,16384
    ld bc,24
loop:
    rr (hl)
    ex af,af'
    rr (hl)
    ex af,af'
    inc l
    djnz loop
    inc h
    dec c
    jp nz,loop
The same routine using unrolled loop:

Code: Select all

    ld hl,16384
    ld b,192
loop:
REPT 31
    rr (hl)
    ex af,af'
    rr (hl)
    ex af,af'
    inc l
ENDR
    rr (hl)
    ex af,af'
    rr (hl)
    ex af,af'
    inc hl
    dec b
    jp nz,loop
Came here after spotting this in the Common machine code sequences thread, and was curious to see how it compares to the version posted in YS which I remembered being mentioned here.

Loving the use of EX AF, AF' to preserve the carry bits. Genius! :ugeek:
Post Reply