Hi Amiga fans
Because of the many positive feedbacks and the multiple tests of the scenes that I sent on all possible Amiga configurations, I want to continue my little dev log.
So here I am
As expected, scene 3 is a small tribute to the
Amiga's capabilities to make nice platform games.
But platforming can mean scrolling and that's precisely the case here.
And who says "scrolling", says smooth "scrolling" (50 or 60 fps depending of the video mode), so at VBL. Otherwise we are on Atari. "Hé hé hé" (French laugh).
So the dev log will be composed of two messages. Today I propose to talk about scrollings in general and we will be more interested in the scene (n°3) itself of the demo in the next message.
Otherwise it would be too long and we will all fall asleep.
There are many possibilities to scroll on the Amiga.
Two parameters guide the implementation: the scrolling orientation (horizontal, vertical or multidirectional) and the total size of the scrollable area.
If it's a scrolling on a relatively small area (for example an area of two screens like in "Pinball Dreams"), and that we have enough chip memory (so we'll say 512Kb in standard on an Amiga 500), then
it's simple, we put the whole surface in memory and we simply change the display pointers of the bitplanes.
This is what is done in the game James Pond 1 for example :
You can read the coder's interview here:
https://codetapper.com/amiga/interviews/chris-sorrell/
There is a little subtlety in Amos : we can't allocate screens bigger than 1024x1024 because to make it simple the instruction "Screen open" allows to define the size of the bitplanes (limited to 1024 in OCS) and not the size of the play area which is a chip memory reservation that can be displayed by changing the start address of each bitplane.
In fact, this could be done by redefining the copper list itself, which is possible with the "copper off" instruction, but this is not really Amos anymore.
There would also be tricks in Amos to do a monodirectional scrolling exploiting the content of the chip based on the Copy instruction for a first possibility or on the fact that "screen offset" reads the contiguous memory in case of overflow.
But we only have 145 kB of chip memory so we have to forget about that. By the way, I made this prototype which uses the copy command:
https://www.youtube.com/watch?v=TlTFEVr ... l=Saberman
Maybe one day I'll do something with that stuff, but this is not our subject.
Besides, if the scrolling is multidirectional like in the fabulous Turrican 2
we'll also be bothered in Amos.
You can do it by using the blitter: so we can shift a whole screen by a few pixels with the blitter and complete with the new pieces of scenery appearing.
But we forget about the 50 fps unless we are in 4 colors. I forgot to mention that we want at least 16 true colors.
Some games use this technique. Many games developed before 1991 are made like this. Even great games.
For example "Super Cars 2", which is in EHB (extra Half bright, 64 colors) uses the blitter to scroll according to a guy who made a recent AGA port of the game.
By the way the game, which is still excellent, is in 25 fps unfortunately.
To achieve a smooth multidirectional scroll on large level sizes, so like Turrican 2, you have to use an algo exploiting copper (called copper swap sometimes).
So in Amos, if you want to keep a standard use, it is not feasible.
It doesn't matter, we can still make a mono directional scrolling, so horizontal in our case (and in both directions right/left), (almost) infinite by using a technique based on a double screen.
Here is the principle:
Let's suppose that the world is : ABCDEFGHIJK, knowing that we can only display 4 letters take the whole visible size. If the visible size is 320 pixels, we assume that we have a screen of 320x2=640 pixels
[----]---- : So 8 dashes for 640 pixels. Between brackets, the visible area.
At the beginning we initialize the visible screen with ABCD:
[ABCD]----
We will display the next element of the scenery just before scrolling, so E and we will scroll. But we display E on the right but also on the left of the visible edge (so invisible for the moment).
We obtain:
E[BCDE]---
E replaced A but the player did not see it because it is on the invisible part.
Then we continue with the F, then G, then H and each time we copy on the right and on the left:
EF[CDEF]--
EFG[DEFG]-
EFGH[EFGH]
So at this point we scrolled to the end of the possible area. We could think that we are stuck because the right edge reaches 640 pixels.
But since we were smart and built the same screen on the left side, we can go back directly to the left part (Screen offset at zero) and the player will see nothing:
[EFGH]EFGH
And we can continue with IJK etc
I[FGHI]FGH
IJ[GHIJ]GH etc...
So we can define an infinite horizontal scroll in Amos using this algo. As we only move the display pointer with screen offset and we only copy a small piece of scenery at each iteration, we obtain a smooth scroll.
In fact we have to add small strips on the right and on the left of the visible window in order not to see the icons displayed during the completion of the scenery and we have to manage the display by icon according to the speed and the direction of the scroll but
the principle is the one described.
This is what will be implemented for the scene 3 presented in a next post with a small adf as usual.
Bye
Aghnar
EDIT : Images of the game are taken from the great Amiga "Hall of light" site