User avatar
Aghnar

Posted Thu Jul 08, 2021 2:28 pm

McTrinsic wrote: And I wound be honored to na a source for your title. Thinking about it, Amiga love, AmigaLove and amigalove offer so much to play with I‘d say it would fit better .
Ok :-) the title will be "Amiga Love"

User avatar
BatteMan
France

Posted Sun Jul 11, 2021 5:15 am

Tested on my A1000 and it works perfectly ;)

User avatar
Aghnar

Posted Sun Jul 11, 2021 7:50 am

Thanks @Batteman for all these feedback

Scene 2 is in progress. I hope that I will do a small dev log at the evening of one day in next week.

Now I have the idea of the orchestration of the different scenes: each scene will start with an "I love ..." related to the scene that follows.
For example scene 3 I have in mind will start with "I love these smooth scrolling platforms" or something like that.

All this in the idea of the "Amiga love", title of the demo and a tribute to this cool forum.

All ideas are welcome of course.

Bye,
Aghnar

User avatar
McTrinsic

Posted Sun Jul 11, 2021 8:26 am

I love (pun intended 😉) the idea of an ongoing theme throughout the demo. Especially if connected to this forum 😀👍

User avatar
comma1571

Posted Tue Jul 13, 2021 11:27 am

Nice tune! I'm running the demo using Amiga Forever with v1.3 (in Windows 10).

User avatar
Aghnar

Posted Thu Jul 15, 2021 3:53 pm

Hi,

Let's go for a little dev log as planned for scene 2 of our demo.

The scene 2 is the first scene that starts with a text "I love something" related to the content.

So before anything else, I need a system to display text with a nice font.
For this, I use a classic technique: I created an image with a gfx editor containing the letters of my font.
I cut each letter and put them in an Amos icon bank.
In the code, I define a string containing all the letters I have. For example :
alpha$="ABCDEFGHIJKLMNOPQRSTUVWXY0123456789!"
If I want to display the string "HELLO WORLD", for each letter of this string I look at its position in alpha$ (instruction "instr" in Amos)
and deduce the icon I have to display.
Example :
H is at the 8th position in alpha$, so I display the icon 8 which represents the H
E is at the 5th position, so I display the icon 5 which represents the E
And so on.
By the way, I'm going to use the same font I created for the yes! intro (you can see this intro but the intro works well only in PAL: https://demozoo.org/productions/278143/)

The scene itself is a pretext to display a nice raster with the copper. I find that it is interesting because these beautiful rasters are a kind of a signature for all the Amiga when most of the computer couldn't display more than 16 colors...
Amos allows to create rasters with the instructions "set rainbow", "rainbow" and "rain". I spoke a bit about that in the dev log of the first scene.

There are plenty of images on the Web with 80's type gradients associated with a sunset and palm trees.
Let's do this: a small palm trees scrolling with a sunset made of the sun (of course) and a nice raster.

The screen is a dual playfield:
- the first field is composed of the palm trees and is 960 pixels wide. I have to take the same depth as the second field so the first plane is in 4 colors (2 bitplanes).
I got from the Web an image of palm trees that I changed to 2 colors and reworked. To obtain an infinite scrolling, the portion from 640 to 960 is identical to the one from 0 to 320 pixels.
You can see this for more info: https://github.com/alain-treesong/amiga ... lPlayfield
- the back field, 320 pixels wide, is filled with color 1 (actually 9 if you consider dual playfield). I will put a raster in it. Not using color 0 is a trick because Amos does not allow to manage borders: the raster is always in horizontal oversan with color 0. To keep a border (black here) I use another color.

The sun is a 84x84 bob. In fact having a 84 wide bob is not clever because the width of a bob is necessarily a multiple of 16 so the blitter handles a 96 wide bob.
But I don't need any specific optimization in the case of this scene.
I don't have a memory problem either. The double buffer is only useful for the back so the memory consumption is not huge.
So all is very simple here. :boing: :boing: :boing:

It gives this:
AmosPro2_007.png
To simulate the night that falls, a small fade is performed on the raster, which also descends like "cette obscure clarté qui tombe des étoiles" (Victor Hugo).

Well, it's not too bad for a first version. I can improve the gradations of the raster (especially the red to blue transition), deform the sun and add small stars.
It will be done in the final version.

The music used is "First and last" by Cueder (Thanks !). This music is interesting because of its tempo. If you try the adf, you will see what I mean. Normally it works as well in PAL as in NTSC but for NTSC I am not sure, so tell me if you want what you think and if it works well in NTSC. It's smooth (50fps) in PAL anyway.

For those who want to test this, here is an adf.
scene2.zip
(240.54 KiB)
I will make a probable post for the next scene by the end of the month or a bit after. If you like BC Kid, this scene 3 may interest you.

See you soon.
Aghnar

User avatar
Aghnar

Posted Sun Jul 25, 2021 3:30 pm

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 :boing: :boing: 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 :
01Pond.png
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
02Turrican.png
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.
03SuperCars2.png
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

User avatar
Aghnar

Posted Mon Aug 02, 2021 2:39 pm

Hi,

Here is the continuation of the setting up of the scene 3.
The idea of this scene is to praise the quality of rendering of platform games on Amiga by using graphic elements of BC Kid from Factor 5:
https://hol.abime.net/81

BC Kid is a port of the first PC Kid / Bonk from the PC Engine. If you don't know BC Kid, I invite you to play it. The game gathers the technical quality of the Amiga (global fluidity, colored raster, top music)
and an excellent gameplay. In short, one of the best of its kind on the Amiga in my opinion, perfectly playable today even by your children (which is rare).

So after extracting the graphics with "Gimp" (https://www.gimp.org/) on my PC from a screen shot of one of the BCKid levels, I got a 16x16 icons board and I used the excellent free editor tiled (https://www.mapeditor.org/) to make a level composed of 6 screens of 320 pixels wide.
sc3Tiled.png
6 screens are more than 1024 pixels and force to use the infinite horizontal scrolling technique presented in my previous message. Everything is consistent :-)

Tiled produces files in text format (csv or xml) so easily parsable. The data are then extracted and transformed into a binary bank where each byte corresponds to an icon on the level.
This bank is loaded (Bload instruction) in AMOS and the level is then displayed.
The scrolling technique has been slightly improved to handle scrolling in both directions (here to the right and to the left).
The memory consumption of about 50 kB is quite low because I don't use a double buffer for this scene (possible because the main character is a sprite and not a bob) and I'm only in 8 colors.

The sprite of the "hero" is composed of about 25 images. These images come from the Arcade version.
On the Amiga, the sprites use the index colors 16 to 31 even if you are in a screen with less colors.
For example, when we are in 8 colors (3 bitplanes), the sprites have consequently a dedicated palette
When we are in 32 colors, the colors of the sprites and the 16-31 index colors displayed on the screen are shared.

By the way, most of the games with scrolling on the Amiga are in fact in 16 colors, either 4 biplanes, or in dual playfield (two times 8 colors).
The 32 colors mode is rarely used because having a smooth scrolling (50 fps in pal, 60 in ntsc) is more difficult. Some developers managed to do it of course.
However, 16 true colors for the scenery with sprites having 16 other colors and combined with the rasters of the Amiga make it possible to obtain very colorful games in spite of a relatively restricted color mode.
This is the case of Turrican 2 for example which is in 16 colors or Shadow of the beast 1 in two times 8 colors. Superb isn't it?
sc3Shadow.png
In fact the Amiga manages 8 real sprites of 4 colors (each block of 4 colors is used by two sprites) and 16 pixels wide (and a height that can reach the height of the screen).
They can be combined 2 by 2 and each combination can use then the 16 index colors 16 to 31.
The "hero" of our scene is about 32 pixels wide and therefore consumes two sprites of 16 colors, i.e. 4 hardware sprites.
In fact, when scrolling, depending on the screen size, not all eight sprites are available. With Amos it's even worse because the internal sprite management routines, if they are honourable, work especially when the screen is fixed.
So you might think that there are 4 hardware sprites of 4 colors left but in fact there are at most 2. We don't need them for our scene anyway.

A small finite state machine has been implemented to manage the state of the sprite (walking, jumping etc) as well as a small collision management with the background.
So I got an embryo of a horizontal platform game. There is still a lot to do to get a complete engine but it is enough for our demo.

I put of course a music. This time, this is a chiptune called chip-it-16 by Develin/Pain in 1996. Thanks to him.

To finish, I walked through the level and recorded the joystick movements that I play back to simulate the hero's movement.
This gives this:
sc3Kid.png
Here is an ADF.
scene3.zip
(293.25 KiB)
You can test this scene on your Amiga. So normally it should work on a vanilla Amiga 500 of course and on an Amiga 1000 with only 256Kb of chip (and a little more in total) as planned in the specifications ;-).
The screen is 192 pixels high and therefore NTSC compatible. Everything should be very smooth.
Feel free to give any feedback. I don't have a lot of tests feedback (with an not too expanded A1000 or with ntsc for example) so don't hesitate...

August is a period of vacations... and I try to rest my eyes. So I won't do any dev in the month. I'll go for a walk on Amiga love from time to time though.
In the next one, I will do some 3D. More in September.

See you soon.
Aghnar.

User avatar
BatteMan
France

Posted Tue Aug 03, 2021 7:50 am

Hi Aghnar,

I didn't take time to post here before, but I want you to know that I love this thread, your project and all your explanations.

Thank you ! <3 :boing: <3

User avatar
Aghnar

Posted Fri Sep 03, 2021 11:55 am

Hi Amiga lovers,

The vacations are over and my eyes have rested. It's time to resume our little project. :-)

As we said, the scene n°4 will display some 3D things (after scene 2 and 3 containing only bitmap things).

3D can mean a lot of things. What I have planned here is to use 3D applied to infinite bobs algorithm.
The infinite bob algo is a technique that cyclically displays a finite number of images whose content is built up as they are displayed. The displayed content is "compatible" with the previous images giving the impression of a huge ("infinite") number of moving objects on the screen.

Historically on Amiga as its name indicates the idea was applied to bobs giving the impression of a display of a colossal number of them.
This idea can obviously be applied to 3D. There are a lot of examples but one of the best recent demos on Amiga exploits this particularly well, the magical "Zener Drive" / Altair 2017 :
https://www.pouet.net/prod.php?which=71996

I modestly already applied this to one of my demos, so already in Amos (I'm making an easy entry, eh, you have to know how to take care of yourself). So it's in the little intro "Yes!" coded last year:
https://demozoo.org/productions/278143/screenshots/
yesInfinite.png
In Amos, this technique has several ways of being implemented. The most natural way is to use all the native commands (since Amos 1.0) allowing to create a "screen" (in the Amos sense), to hide it, to display it... etc.
You can define 8 different screens with the "Screen Open" command, so 8 groups of bitplanes (of different sizes if we want).
In addition, Amos manages a double buffer allowing per screen to have a physical (what is displayed) and logical (in non-visual memory therefore alterable without adverse effect) view.
We therefore have 16 groups of bitplanes, which is therefore more than enough for a good rendering (in yes! I only use 8 screens of 3 bitplanes).

The problem in our case is obviously memory. We only have 145 Kb of chip memory in total so around 100-120 Kb for this scene (let's not forget the music which will consume at least 20 Kb).
If I consider 2 bitplanes of 320x144 for example, this therefore represents 11.25 Kb per screen. If we use 8 screens, we will consume 90 Kb. So we are going to use that.

The principle of the algo is as follows.
Suppose we only have 3 images. I will take for the illustration the implementation of a starfield (which is generally not done like that in fact :-) ).
An empty screen is represented by [...........] and the stars by "+"

screen 1 : [+..........]
screen 2 : [.+.........]
screen 3 : [..+........]

If we cycle the three screens, we have the impression that the star advances by 2 notches.
I only have 3 screens so we go back to screen 1 but we display the star as if it were continuing the route started:
screen 1 : [+..+......]
screen 2 : [.+..+.....]
screen 3 : [..+..+....]
Obviously the first display remains. So we have the impression that two stars advance.

If we continue:
screen 1 : [+..+..+..]
screen 2 : [.+..+..+.]
screen 3 : [..+..+..+]

We therefore have the impression that a lot of stars (so 3 here :-)) cross the screen.
You can apply this trick to any thing that you build as long as there is a recurrence.

So I'm going to think about what I'm going to do as a render.
If you have some ideas, don't hesitate to give it :-)

So see you soon (during september probably)

Aghnar / Agima





Return to “The Lounge”