Horizontal scrolling solutions #1457

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Horizontal scrolling solutions #1457

Post by R-Tape »

Another way I looked at of scrolling a decent sized screen and staying within 25fps is to cheat a bit, as I mentioned in the Edge Grinder thread I couldn't work out how to scroll only the background onscreen, I came up with this a while back (not saying it's an original idea).


Image

The most time consuming part of a scroller is the buffer rotation. In this example we only scroll the rows we need, all based around a controlling byte. So if the byte is set to 11111111 it scrolls the whole screen, if 11000011 only the top and bottom two rows. When it's scrolling the whole screen you are close to 2 full frames and overspilling a HALT, but there is still time for 1 or two sprites. When only doing the outer bits there is time for plenty of sprites.

The good news is that you don't have many sprites in the closed in parts, and you have more when it's open. You can't have what you want when you want it, but I think it's a goer. It's yet another neverplayed (or rather never finished) symphony but I usually end up returning to these things.

In the snapshot it's scrolling 4 rows and ORing 6 sprites at 25fps, buffer PUSHed to screen, POKE 39427 with 255 and see it slow down to 12.5fps.

Download here and a zipped version here.
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Horizontal scrolling solutions #1457

Post by Hikaru »

Well, yes. Expand that 'horizontally' to account for individual tiles within the rows as well, and you will get the R-Type method (Zynaps is only marginally similar).

As an aside, the reason I personally find the subject of scrolling interesting is because I know for a fact it's something the Speccy can do quite well - maybe C64\NES level, with just a bit of exaggeration - and that we're not quite there yet in terms of existing works. This is in contrast to let's say 3D engines, where you sorta know from the beginning that you're going to need a fast CPU, and the result is not going to look all that impressive anyway.
Inactive account
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: Horizontal scrolling solutions #1457

Post by R-Tape »

Hikaru wrote: Thu Nov 16, 2017 8:47 am Well, yes. Expand that 'horizontally' to account for individual tiles within the rows as well, and you will get the R-Type method (Zynaps is only marginally similar).
It sounds so easy! I'll need to set a full day aside after a good night's sleep before I dare attempt it again.

An advantage of the way I mention is that no time is spent checking. You plan the game around it and setting the scroll type is just as much of an event as an attack wave. When you decide you want to scroll the whole screen you know you can do so at 25fps, could a ‘check if scroll’ Zynaps/R-Type scroller doing a full screen (say 16 x 30) manage that?
Hikaru wrote: Thu Nov 16, 2017 8:47 amAs an aside, the reason I personally find the subject of scrolling interesting is because I know for a fact it's something the Speccy can do quite well - maybe C64\NES level, with just a bit of exaggeration - and that we're not quite there yet in terms of existing works. This is in contrast to let's say 3D engines, where you sorta know from the beginning that you're going to need a fast CPU, and the result is not going to look all that impressive anyway.
No problem with asides in this thread, I wanted to hear other stuff.
User avatar
Joefish
Rick Dangerous
Posts: 2041
Joined: Tue Nov 14, 2017 10:26 am

Re: Horizontal scrolling solutions #1457

Post by Joefish »

Hikaru wrote: Thu Nov 16, 2017 8:47 amAs an aside, the reason I personally find the subject of scrolling interesting is because I know for a fact it's something the Speccy can do quite well - maybe C64\NES level, with just a bit of exaggeration - and that we're not quite there yet in terms of existing works.
Not sure where you expect more developments to come from? There are loads of different techniques known about, some using buffers, some scrolling in-place, some doing complete re-draws every time. I guess they've not been explored recently in homebrew games, but they're all there in the Speccy's backlog of games.
Hikaru wrote: Thu Nov 16, 2017 8:47 amThis is in contrast to let's say 3D engines, where you sorta know from the beginning that you're going to need a fast CPU, and the result is not going to look all that impressive anyway.
On the other hand, I think there are lots of refinements from 3D techniques that have developed on other machines that haven't really been explored on the Speccy, and there are loads of optimisations in the mathematics that could be tried.
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Horizontal scrolling solutions #1457

Post by Hikaru »

R-Tape wrote: Thu Nov 16, 2017 9:55 am It sounds so easy! I'll need to set a full day aside after a good night's sleep before I dare attempt it again.
Well, I mostly mean that it's essentially the same concept. A bit like going from an one-dimensional array to a two-dimensional one. (Yes, more work)
R-Tape wrote: Thu Nov 16, 2017 9:55 am An advantage of the way I mention is that no time is spent checking. You plan the game around it and setting the scroll type is just as much of an event as an attack wave. When you decide you want to scroll the whole screen you know you can do so at 25fps, could a ‘check if scroll’ Zynaps/R-Type scroller doing a full screen (say 16 x 30) manage that?
That's one way of categorizing these engines.
A) Redraws everything at all times, therefore always running at a near-maximum load regardless of the number of actual onscreen tiles, but can be said to be 'effective' at this task. For instance PUSH-scrollers.
B) Only scrolls/redraws the required parts, skipping over the empty space and whatnot. Execution speed depends on the average number of onscreen tiles, so it's easily possible to make it run way faster than type A in that sense. However, it is normally less effective than type A under the maximum load, although this also depends on the scrolling method (e.g. RL might be slower than LD or PUSH).

For type B, you can normally estimate the rough maximum number of onscreen tiles at any one time, and design your maps with that in mind. There are also more subtle considerations, e.g. balancing the number of sprites vs the number of tiles. So you can have areas with 'lots of enemies and few tiles', and those with 'lots of tiles and few enemies', which also makes sense from the gameplay/logical perspective (i.e. where would you put more enemies on the screen if you already have lots of bg anyway?). In some engines, this might even be happening automagically to some extent, if let's say the sprite routines were designed to skip drawing the sprite parts that are occupied by the bg.

Then there are certain other tricks that are more psychological in nature. For instance, the star field in R-Type runs independently from the main engine using IM2. Try to disable it and I'm sure you will see why. :) Likewise, if something is running slow to begin with, no-one is going to be bothered much even if it slows down some more in places, unlike with the 'initially 50/25 FPS' engines.

As I said, it's an interesting topic. :)
Inactive account
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Horizontal scrolling solutions #1457

Post by Hikaru »

Joefish wrote: Thu Nov 16, 2017 11:40 am
Hikaru wrote: Thu Nov 16, 2017 8:47 amAs an aside, the reason I personally find the subject of scrolling interesting is because I know for a fact it's something the Speccy can do quite well - maybe C64\NES level, with just a bit of exaggeration - and that we're not quite there yet in terms of existing works.
Not sure where you expect more developments to come from? There are loads of different techniques known about, some using buffers, some scrolling in-place, some doing complete re-draws every time. I guess they've not been explored recently in homebrew games, but they're all there in the Speccy's backlog of games.
First of all, known techniques aren't the same thing as existing games, are they?

Apart from that - oh, you have got to be kidding me. Where are my 50FPS full screen scrollers with loads of fully unrolled data-as-code (think Amstrad CPC) masked sprites taking advantage of the whole available 128K extra memory? Where are the '25 FPS and less screen', Cobra-like (or maybe even omni-directional, same thing more or less) games in full grorious 8x1 and 8x2 multicolor? Because that is just the tip of the iceberg in terms of what's possible at present as you might have heard. The absolute, bare, essential minimum I personally am expecting of the future to bring with this is for multicolor to become the new 6912 - that's already a sh.tload of 'developments' I guess you can say. Multiple scrolling playfields with Trigger and Gainax-like pseudo-3D and vector effects? Of course we are only getting started. :lol:


Joefish wrote: Thu Nov 16, 2017 11:40 am
Hikaru wrote: Thu Nov 16, 2017 8:47 amThis is in contrast to let's say 3D engines, where you sorta know from the beginning that you're going to need a fast CPU, and the result is not going to look all that impressive anyway.
On the other hand, I think there are lots of refinements from 3D techniques that have developed on other machines that haven't really been explored on the Speccy, and there are loads of optimisations in the mathematics that could be tried.
In my opinion, the problem with 3D, if you can call it that, lies elsewhere. During the Speccy times, we (basically most people, I think) weren't really exposed to 'real 3D' much, it was always a somewhat rare and marginal thing, which is understandable. We have only seen what 'real 3D' is like on later, more powerful machines. And this was already more or less the full glory 3D, fast, textured, with advanced lightning effects and whatnot. Put another way, we've been somewhat spoiled by this without much in the way of intermediate stages. So now if you decide to go back and reimport some of that ... it's sort of like there's hardly any previous context to it, at least in relation to the Speccy. The end result probably would not 'look impressive' in itself, despite best efforts (and we know beforehand there's only so much that can be done). It's a bit of a difficult topic for me to explain but perhaps you see what I'm saying.
Inactive account
User avatar
utz
Microbot
Posts: 113
Joined: Wed Nov 15, 2017 9:04 am
Contact:

Re: Horizontal scrolling solutions #1457

Post by utz »

Hikaru wrote: Thu Nov 16, 2017 12:20 pm Because that is just the tip of the iceberg in terms of what's possible at present as you might have heard.
Wow, hadn't heard about that yet :o Congratulations, excellent work.
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Horizontal scrolling solutions #1457

Post by Hikaru »

utz wrote: Thu Nov 16, 2017 1:29 pm
Hikaru wrote: Thu Nov 16, 2017 12:20 pm Because that is just the tip of the iceberg in terms of what's possible at present as you might have heard.
Wow, hadn't heard about that yet :o Congratulations, excellent work.
Thank you. I owe much to the good people in the WoS +2A/+3 floating bus 'research' thread. Without that effort (and the excellent results we've found) it would've made far less sense to me to bother with aline to say the least. But yes I think it, or a better derivative, will probably play its part in helping to eventually bring out the Spectrum's (unknown) full potential. ;)
Inactive account
User avatar
Joefish
Rick Dangerous
Posts: 2041
Joined: Tue Nov 14, 2017 10:26 am

Re: Horizontal scrolling solutions #1457

Post by Joefish »

Hikaru wrote: Thu Nov 16, 2017 12:20 pmWhere are my 50FPS full screen scrollers with loads of fully unrolled data-as-code (think Amstrad CPC) masked sprites taking advantage of the whole available 128K extra memory? Where are the '25 FPS and less screen', Cobra-like (or maybe even omni-directional, same thing more or less) games in full grorious 8x1 and 8x2 multicolor? Because that is just the tip of the iceberg in terms of what's possible at present as you might have heard. The absolute, bare, essential minimum I personally am expecting of the future to bring with this is for multicolor to become the new 6912 - that's already a sh.tload of 'developments' I guess you can say. Multiple scrolling playfields with Trigger and Gainax-like pseudo-3D and vector effects? Of course we are only getting started. :lol:
Well, I've done full-screen 50fps parallax scrolling and 8x1 multicolour scrolling and frankly I'm bored... :lol: :D :lol:

What 3D needs is some ideas of how to put some gameplay into the techniques. That Wolfenstein demo is technically impressive but not much of a game. Make it a maze and put some locks / keys / treasure along the way and you'd at least have something to do. Use those XOR fill techniques and pseudo 3D roads and do Dun Darach as a first-person RPG. Use the scaling-detail techniques of Damocles to make an open-world game. etc.
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Horizontal scrolling solutions #1457

Post by Hikaru »

Joefish wrote: Thu Nov 16, 2017 6:44 pm
Hikaru wrote: Thu Nov 16, 2017 12:20 pmWhere are my 50FPS full screen scrollers with loads of fully unrolled data-as-code (think Amstrad CPC) masked sprites taking advantage of the whole available 128K extra memory? Where are the '25 FPS and less screen', Cobra-like (or maybe even omni-directional, same thing more or less) games in full grorious 8x1 and 8x2 multicolor? Because that is just the tip of the iceberg in terms of what's possible at present as you might have heard. The absolute, bare, essential minimum I personally am expecting of the future to bring with this is for multicolor to become the new 6912 - that's already a sh.tload of 'developments' I guess you can say. Multiple scrolling playfields with Trigger and Gainax-like pseudo-3D and vector effects? Of course we are only getting started. :lol:
Well, I've done full-screen 50fps parallax scrolling and 8x1 multicolour scrolling and frankly I'm bored... :lol: :D :lol:
>8x1 multicolour scrolling

Image

But how easy/hard it is to actually build a project with it that incorporates user input and whatnot? Because IIRC that was mostly 'the' question. Otherwise you're essentially comparing games with demos, which have been of course doing multicolor just fine since late 80's anyway.

About 3D and so on, I guess a better way to phrase it is this. I believe that, ultimately, you could put together a Spectrum scrolling game next to let's say a NES scrolling game, and it won't be that obvious a comparison anymore. Okay, maybe NES is a bit of an exaggeration, but OTOH C64 is of course out of the question. :lol: Either way, it can be made to look good and very much on par with some of the best 8-bit examples. And well, I just don't see doing the same with 3D engines, which is why they seem less interesting to me. Insofar the gameplay of those goes, I agree that there are many unexplored possibilities.
Inactive account
User avatar
Joefish
Rick Dangerous
Posts: 2041
Joined: Tue Nov 14, 2017 10:26 am

Re: Horizontal scrolling solutions #1457

Post by Joefish »

My original River Raid Tech Demo used 8x1 multicolour and read the data from a buffer, so by changing the start address of the buffer you could scroll it. It used a 00001111 pattern in the background so it only moved the colours, not the pixels.

I've just got an 8x2 multicolour function working that uses a buffer with a variable starting point, and it's looped, so there are only four lines of unrolled code (one character row, then it loops). Although it's only 22 characters wide. I can do 24 wide, but that requires some top-border time to part-draw the initial attributes and free up the time it needs to manage the looping. The buffer can be any height and width, so you can scroll the colours in any direction just be changing the start address.
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: Horizontal scrolling solutions #1457

Post by Ralf »

Some quick questions.

Do you copy both pixels and attributes to screen now or is it still 00001111 pattern?

Would it be hard to add moving sprites to this engine?
User avatar
Joefish
Rick Dangerous
Posts: 2041
Joined: Tue Nov 14, 2017 10:26 am

Re: Horizontal scrolling solutions #1457

Post by Joefish »

Depends on what I want to do.

For something like River Raid, I'd probably leave it with the 00001111 pattern so I can paint the scenery in 4x1 extra-wide blocky pixels and scroll it vertically at any speed instantly. Horizontally, you could have two colour buffers prepared, and swap between them to give the impression of a 4-pixel horizontal scroll. But mainly the advantage here is a smooth vertical scroll at little cost. You could try different pixel patterns, e.g. thin vertical lines, then do horizontal lines with 8x1 matching INK and PAPER colours to make a scrolling grid.

There's no reason why you can't have regular standard resolution sprites on top of this. You just have to erase them or paint over them with the background attributes again, and make sure instead of deleting their pixels you replace them with the background pattern (e.g. 00001111). Probably best not to try and pixel-mask them onto the background; just do a straight block copy. But you could maybe use transparent PAPER, or invert part of the sprite and give it transparent INK if it's right-hand edge is more exposed. But probably best to just have it bounce off or crash into anything too detailed!

For finer horizontal scrolling, you need to do what Hikaru has done, which is to repaint the pixels quickly with something lke Joffa's super-fast Cobra scroller in-between passes of the multicolour routine. With a buffer (or two copies of your multicolour routine) you can render the attributes to a hidden buffer on your first pass, then repaint the pixels, then switch the colours over to the prepared buffer instantly. You can do the sprites like that too; first the colours to a back buffer, then switch it in the instant you've rendered their pixels.
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Horizontal scrolling solutions #1457

Post by Hikaru »

Right, I remember that RR demo. Incidentally, I think I found a way to use non-black colors like green? for the sync marker area in aline, with artifacts kept to a fairly low amount (as sparse bits of BRIGHT for half the line). :roll:

Mint uses just one multicolor 'canvas' (data+code buffer) for everything. The canvas isn't looped so the attributes are updated the old-fashioned way by repainting them over, although in a somewhat complex manner, greatly cutting on the amount of data to process, as well as accomodating for the 'mc-paper 8x2 mode' backgrounds. Additionally, it doesn't touch the mc-attributes at all times but only at specific intervals while the camera is moving.
The method for multicolored sprites itself is mostly there on the paper. However, I found that the sort of sprites my immediate project uses aren't really suited for it. So this functionality will probably have to wait.
Inactive account
Post Reply