'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
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: Thu Dec 07, 2017 2:55 pm Cobra scrolls two pixels at a time as well. That's done by re-drawing the screen every time from pre-shifted blocks, rather than rotating the pixels that make up the screen.
The trick there is having a small number of scenery blocks, and further limiting which block you can place next to another block, because what you're really pre-shifting is the transitions from one block to another, and the number of those can get out of hand if you're not careful.
I really have no idea what any of that means. Good games both, though! :shock:
Retro stuff, real quick
YouTube: http://bit.ly/5MinuteRetro
Twitter: https://twitter.com/5MinuteRetro
User avatar
ZXDunny
Manic Miner
Posts: 498
Joined: Tue Nov 14, 2017 3:45 pm

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

Post by ZXDunny »

Pre-shifting offloads much of the work in a scrolling game to outside of the game loop. For example:

You are scrolling from right to left. You draw a column of blocks at the right hand edge of the screen, and then you literally process every single byte in the display - rotating the bits in each byte to the right by one place, copying the leftmost bit into the next block to the left etc. After you've done this 8 times (6144 bytes each time for a full screen) you draw another column of blocks to the right. Rinse, repeat - you're scrolling the screen.

It's damned slow. How to speed it up? Well, your screen is likely to be mostly full of empty space. No need to scroll those. And it's made of blocks that you're drawing at the right hand edge, yeah? Well, if you store 8 copies of each block, each rotated one place, then instead of wasting time rotating the screen bytes, you instead just draw the blocks you want at the positions you want, choosing an already-scrolled version instead.

bingo, a much faster scroll. Downside is 8x the memory usage (at best, more if blocks can sit next to one another) as those pre-rotated blocks have to be stored somewhere. But with careful and clever planning, you're good.
User avatar
Joefish
Rick Dangerous
Posts: 2041
Joined: Tue Nov 14, 2017 10:26 am

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

Post by Joefish »

Not quite. First split your scenery map up into 16x16 pixel blocks.

Now, imagine the Speccy screen was just one tiny 16x16 pixel window view of the level. At any one moment you'd only be able to see one scenery block scrolling out to the left as another scrolls in from the right. You'd be watching a sort of animation as one block slides out to be replaced by another. By pre-drawing a series of these animations you could display any part of the level going past at any time (within that one-block-sized window). There'd be various different versions of this animation as different blocks scroll out to be replaced by others. But by careful level design, you could keep the different combinations down to a minimum.

Now imagine the Speccy screen as a 16x12 fixed grid of 16x16 pixel blocks. By displaying one of these animations in each block, you could create the look that the whole level is scrolling past.
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

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

Post by Seven.FFF »

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
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
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 good example of game with efficient scroll engine is Stormlord. It's better engine than Ghosts'n'Goblins or Cobra as it allows much more variety of graphics.

I made a post about it on old WOS but i may repeat it here.

So the scroll is by 2 pixels and framerate is 25 fps. you have 16x16 pixel tiles, each in 4 versions, shifted by 0,2,4 and 6 pixels.

The trick is assuming that some tiles may touch only selected another tiles so you have for example

- brick wall touching another brick wall
- edge of brick wall touching empty space
- left part of mushroom touching middle part of mushroom and so on

In shifted tiles we have a part of original tile and a part of neigbour tile. You don't have to combine them by OR, XOR or whatever. You just copy it directly from memory to screen.

A bonus to such approach is that you don't have to draw empty tiles. While everything moves "edge tiles" (edges of walls and other objects) which include some empty space effectively clear everything behind them. Maybe one day I'll make a screen about it as it may be hard to imagine from verbal description but it works (if there is enough empty space as scrolling totally filled screen would be too much for 25 fps).

-----------------------------
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. :)
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

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

Post by R-Tape »

Robin, please remember this is a Spectrum forum. We'd appreciate it if you post your Atari 2600 vids elsewhere.

Thankyou.
User avatar
Seven.FFF
Manic Miner
Posts: 735
Joined: Sat Nov 25, 2017 10:50 pm
Location: USA

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

Post by Seven.FFF »

R-Tape wrote: Thu Dec 07, 2017 8:42 pm Robin, please remember this is a Spectrum forum. We'd appreciate it if you post your Atari 2600 vids elsewhere.

Thankyou.
LOL!

The really, really annoying thing is that Mark Turmell did it all on the woody with 128 bytes of RAM and 4 KB of ROM :((((
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

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

Post by R-Tape »

Ralf wrote: Thu Dec 07, 2017 8:41 pm 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 never investigated the code but I was impressed by the GnG scroller, it does a lot of ~detailed graphics quickly and smoothly over a large area. I guess ^that^ would explain it, lots of designed for purpose routines that are horrible to unravel but do one job well.
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 »

Ralf wrote: Thu Dec 07, 2017 8:41 pm A good example of game with efficient scroll engine is Stormlord. It's better engine than Ghosts'n'Goblins or Cobra as it allows much more variety of graphics.

I made a post about it on old WOS but i may repeat it here.

So the scroll is by 2 pixels and framerate is 25 fps. you have 16x16 pixel tiles, each in 4 versions, shifted by 0,2,4 and 6 pixels.

The trick is assuming that some tiles may touch only selected another tiles so you have for example

- brick wall touching another brick wall
- edge of brick wall touching empty space
- left part of mushroom touching middle part of mushroom and so on

In shifted tiles we have a part of original tile and a part of neigbour tile. You don't have to combine them by OR, XOR or whatever. You just copy it directly from memory to screen.

A bonus to such approach is that you don't have to draw empty tiles. While everything moves "edge tiles" (edges of walls and other objects) which include some empty space effectively clear everything behind them. Maybe one day I'll make a screen about it as it may be hard to imagine from verbal description but it works (if there is enough empty space as scrolling totally filled screen would be too much for 25 fps).

-----------------------------
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 read it. Read it again. And read it again. And I still don't really geddit. I really appreciate all the effort here but I suspect the only way I'd ever understand all this stuff is with an animation of some sort. Either way, all this shifting sounds like immensely hard, complicated work!
Retro stuff, real quick
YouTube: http://bit.ly/5MinuteRetro
Twitter: https://twitter.com/5MinuteRetro
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: Thu Dec 07, 2017 6:25 pm Not quite. First split your scenery map up into 16x16 pixel blocks.

Now, imagine the Speccy screen was just one tiny 16x16 pixel window view of the level. At any one moment you'd only be able to see one scenery block scrolling out to the left as another scrolls in from the right. You'd be watching a sort of animation as one block slides out to be replaced by another. By pre-drawing a series of these animations you could display any part of the level going past at any time (within that one-block-sized window). There'd be various different versions of this animation as different blocks scroll out to be replaced by others. But by careful level design, you could keep the different combinations down to a minimum.

Now imagine the Speccy screen as a 16x12 fixed grid of 16x16 pixel blocks. By displaying one of these animations in each block, you could create the look that the whole level is scrolling past.
Actually, I suppose I *do* kind of get this. But it sounds enormously labour-intensive to have to draw all the possible background/tile combinations. In fact, having just watched a Stormlord video on YouTube, I simply cannot imagine how all that is feasible in 48K.
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 »

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.
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

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

Post 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.
Inactive account
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 »

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?
Retro stuff, real quick
YouTube: http://bit.ly/5MinuteRetro
Twitter: https://twitter.com/5MinuteRetro
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 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.
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 »

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.)
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 »

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!
Post Reply