MLS, a new graphics system

[saimo]

Recently I've been working on a new graphics engine.

VIDEO PREVIEW #1
[ Show youtube player ]

VIDEO PREVIEW #2
[ Show youtube player ]

VIDEO PREVIEW #3
[ Show youtube player ]

VIDEO PREVIEW #4
[ Show youtube player ]

DEMOS VIDEO / 1
[ Show youtube player ]

DEMOS VIDEO / 2
[ Show youtube player ]

EXPERIMENTS VIDEO / 1
[ Show youtube player ]

EXPERIMENTS VIDEO / 2
[ Show youtube player ]

OVERVIEW

"ALS" stands for "AMOS Layers System", as it turns the screens of AMOS Professional into layers that can be laid over one another, with complete control of order, opaqueness and colors, while keeping them renderable as usual.
It is easy, does not require much knowledge of the Amiga graphics hardware, does not need installation, does not depend on third-party extensions and comes as a collection of variables, arrays and procedures written in fully-commented AMOS code - it can be thought of as an AMOS source-level library.

ALS comes in two versions:
* v1: for OCS/ECS/AGA - bigger and slower (and no longer developed)
* v2: for AGA only - smaller and faster

https://www.retream.com/ALS


GENERAL FEATURES

· Layers usable as screens and vice versa
· Overlaying of multiple layers
· Overlaying order freely arrangeable
· Per-layer planes height
· Per-layer planes number
· Per-layer double-buffering
· Per-layer vertical positioning
· Per-layer colors
· Per-layer 257-degree opaqueness
· Per-color 257-degree opaqueness
· 24-bit internal colors
· LORES horizontal positioning of layers
· LORES and HIRES display resolutions
· Programmable display window size
· Automatic centering of display window
· Automatic adjustment to chipset (OCS/ECS/AGA)
· Automatic creation of layers from ILBM files
· Display descriptors
· Layer descriptors and snapshots
· Global snapshots
· Palettes management
· Banks management
· Basic file management


ECS/AGA FEATURES

· Selectable video standard (NTSC/PAL) <ECS Agnus / AGA>
· Display border blanking <ECS Denise / AGA>


AGA FEATURES

· Non-EHB 6-plane displays
· 24-bit display colors
· 24-bit palette colors
· SHRES display resolution
· HIRES and SHRES horizontal positioning of layers
· 4x planes fetch mode


RESTRICTIONS DUE TO HARDWARE

· Maximum number of visible planes / 1-plane layers: OCS/ECS, HIRES: 4; OCS/ECS, LORES: 6; AGA: 8
· On OCS/ECS, EHB mandatory for 6-plane displays
· On OCS/ECS, 12-bit display colors
· On OCS/ECS, 12-bit palette colors
· On OCS Agnus, video standard (NTSC/PAL) dictated by the hardware
· Limited horizontal positioning of display window
· Same width for all layers
· Same horizontal positioning for all layers


RESTRICTIONS DUE TO AMOS

· Maximum number of in-use/ready-to-use layers: 8
· Maximum number of planes per layer: 6


RESTRICTIONS DUE TO DESIGN

· Most AMOS display/screen commands not allowed/possible
· Floppy drives not usable when the display is on.


HOW ALS WAS BORN

In 2003 I wrote a Copper-based screen flipping effect for a developer who was making a game with AMOS. Eventually, the effect was not used (and the game was not made at all), but writing it gave birth to a whole bunch of ideas, which little by little transformed into a collection of procedures that constituted a small graphics system called XPF (Cross PlayField).

The development however, having started from an effect and having proceeded spontaneously, lacked the necessary rigour that a proper system requires, so I decided to rewrite everything from scratch and created CSS (Custom Screens System). That one turned out to be a clean, feature-rich system. It worked nicely and I even wrote a few tutorials for it.

But it did not support sprites. While pondering on how to add them, I realized that actually the core design was not good enough and that an alternative one would have allowed sprites and have been more efficient, too. Therefore, I wrote another system: AVS (Advanced Video System). When I was at about 80-90% of the development... I lost the sources. I cannot remember how that happened, but for sure I could not recover them, so I remained only with the sources dating back to some days before, when a lot of important code had not been written yet. The anger, which made me hate the idea of reimplementing what had been lost, coupled with the fact that I was about to move country, killed the project.

The idea of rewriting an old game of mine using CSS - which was good enough for the purpose - kept on lingering in my head through the years. I kind of promised myself I would do that sometime, as a smaller project between bigger ones - provided I could swallow the idea of using a suboptimal system, that is. In fact, in a few occasions, I considered completing AVS first... only to drop the idea immediately: I just could not bother getting acquainted with that old code, maybe discovering that, after all, I would do things differently once again.

Although, in the meanwhile, I dedicated myself to many other projects, the ghosts of those systems kept on haunting me. In 2019 I presented CSS to the world with a video preview: it was an attempt at doing justice to the system (and thus hopefully making peace with it) and at forcing myself to complete the work by exposing publicly the waste it represented. Since then, I made a new game (Blastaway), I continued the work on and released a preview of a game (QUOD INIT EXIT IIo), I released two little updates for another game (MeMO), I almost finished an update for yet another game (SkillGrid), I created two other graphics systems not related to ALS and I made a demo (THE CURE) with one of them. But the ghosts were still there.

Well - as they say - enough is enough and better later than never: the time to get rid of them came and in July 2020 I designed and implemented a new and proper system from the scratch - and so ALS was born.


PERFORMANCE

Whenever a color, an alpha value, or the stack of the layers gets changed, it is necessary to recalculate many or even all the colors starting from those relative to the first bitplane of the first layer affected. That is a CPU-intensive operation that AMOS struggles with, so it must be avoided as much as possible by not using dynamic changes or by precalculating palettes (ALS provides specific procedures for that).

Other than that, the system is quite lightweight.


WHY AMOS SOURCE CODE?

ALS could have been written in assembly and made available as high-performance source code, as a linkable object or as an AmigaOS library, but it has been written as pure AMOS code for AMOS programs, instead. Even within the AMOS world, it could have been written as an extension or at least as embedded machine language procedures, thus resulting more efficient (in particular, the ALS_CALCULATE_PALETTE*[] procedures would have been dramatically faster). Why AMOS source code, then?

First of all, because of how ALS was born; secondly, because returning to AMOS and writing everything in such language - the language I started programming on the Amiga with - after many years was fun; then, because I enjoy the idea of showing that AMOS, which way too often gets exaggeratedly bashed, is actually more capable than it is commonly thought of; finally, because I find it just too amusing to see the surprised reactions from people who can barely believe that what ALS achieves is done by means of the original AMOS alone.

[skan]

Neat!

[khph_re]

Absolutely love seeing people experiment like this!
Brilliant stuff.
Also, congrats on your demo win :-)

[saimo]

@skan @khph_re

Thank you, guys!


@all

Added information to the OP.

[saimo]

VIDEO PREVIEW #2

[ Show youtube player ]

This second preview shows 3 layers scrolling horizontally and vertically, while the resolution cycles continuously from LORES to HIRES to SHRES. More precisely, the background layer scrolls horizontally only, whereas the middle and foreground layers scroll both horizontally and vertically.

The sharp-eyed viewers will have surely noticed that, vertically, the layers scroll indipendently from one another, but horizontally they scroll together: that's due to an unfortunate limitation of the Amiga hardware.
(Note: the only way to overcome such limitation is to restrict the layers number to just 2, basically obtaining a "super" dual playfield which, in addition to the standard dual playfield, provides alpha values for layers and colors; however, implementing such special case in MLS would complicate code beyond what I find pleasant and recommendable, so I'll leave that for a future project.)

Notes about the layers:
* background layer: 32 solid colors;
* middle layer: 3 partially transparent color + 1 transparent color;
* foreground layer: 1 partially transparent color + 1 transparent color.

P.S. While writing a little game to test MLS, I convinced myself more than ever that sprites, in this system, are just too unpractical, so I decided to put their implementation on hold. At the same time, I decided that, after all, horizontal scrolling should definitely be implemented, despite the aforementioned hardware limitation. I have updated the specifications in the opening post accordingly.

[saimo]

VIDEO PREVIEW #3

[ Show youtube player ]

After a long pause forced by a house move, ALS development resumed and it is now nearing completion. Many new features have been added, the existing code has been improved and documentation has been continuously updated and extended.
This preview shows a feature added at the end of August, i.e. NTSC support. The demo program is the same as the one shown in the preview #2, but now it toggles also the video standard. More precisely, these are the screen modes it cycles through at intervals of 5 seconds:
1. NTSC, LORES;
2. NTSC, HIRES;
3. NTSC, SHRES;
4. PAL, LORES;
5. PAL, HIRES;
6. PAL, SHRES.

(Note: the video is recorded with a frame rate of 60 Hz, but PAL modes actually run at 50 Hz, so they will not look exactly like they are supposed to. The demo runs 100% smoothly on real hardware, so any stuttering you might notice is due exclusively to the video playback.)

[saimo]

Quick update: implementation finished! Now it's time to do some testing and writing the second tutorial.

[saimo]

VIDEO PREVIEW #4

[ Show youtube player ]

The implementation is complete and a new demo program has been written both to test ALS and to provide a practical programming example.

The demo initializes a 2-layer display:
* background layer: 4 planes, with opaque colors, for fixed graphics;
* foreground layer: 2 planes, with (partially) transparent colors, for bobs.
Then, it makes some 3-color ghosts bounce around on the foreground layer while changing cyclically their colors and opaqueness.
The effect could be achieved also without ALS by means of the Set Bob and Palette commands, but:
* all the planes (6) would be double-buffered instead of just the planes for layer 1 (2), thus wasting a lot of memory;
* rendering the bobs would be slightly more demanding (as the rendering code would have to consider 6 planes instead of 2);
* it would not be as easy and efficient to handle colors;
* more in general, it is more comfortable to have separate layers/screens to render to.

[saimo]

Last week I analyzed the code produced by the AMOS Professional Compiler and changed the ALS code in order to have the compiler output the most efficient code it is capable of. Contextually, I have also added a new little feature (palette segments), updated two demos and improved the documentation constantly.
This week I'm continuing the review of the documentation and constantly improving it. Once done, (hopefully) it will only be a matter of preparing a web page before ALS gets released.

[saimo]

VIDEO PREVIEW #5

[ Show youtube player ]

Since last time, I improved/fixed a few things, revised greatly the documentation and updated the programs shown in the video. I also prepared the project web page: https://www.retream.com/ALS (redirects to https://retream.itch.io/als).
Currently I'm continuing to revise the documentation iteratively: when no more corrections are needed, ALS will be released - and I hope to make that happen this week.

[roondar]

Impressive stuff, especially since it's aimed at AMOS. Looking really good

[saimo]

Thanks roondar
After making this post, I also noticed that the Metal Slug port thread is now dealing with dual playfield (with unusual bitplanes split) and using bitplanes creatively (and I also noticed that you mentioned SkillGrid - thanks for that and also for appreciating SkillGrid's technique!). I guess I should post some spam over there - kidding aside, maybe it's worth showing this stuff to the people following that thread.

[saimo]

It took longer than I thought, but finally ALS is out!
Get it for free from https://www.retream.com/ALS.
I hope that it will be useful to somebody, and that some day I'll get to see a cool game made with it

[ Show youtube player ]

Edit: could an admin change the thread title to "ALS, a new graphics system - RELEASED!", please? Thanks in advance.

[Amigajay]

Impressive work!

[roondar]

Cool! Congrats on the release

[saimo]

Thank you, guys!

[roondar]

You know, I do have one question: how do you deal with the layer's individual motion? Vertical is probably quite easy (just use different offsets for the bitplane pointers). But horizontally you only have two playfields to shift and only across odd/even bitplanes to boot.

Do you just brute force it? Or is there a bit more going on?

[saimo]

Originally Posted by roondar

You know, I do have one question: how do you deal with the layer's individual motion? Vertical is probably quite easy (just use different offsets for the bitplane pointers). But horizontally you only have two playfields to shift and only across odd/even bitplanes to boot.

Do you just brute force it? Or is there a bit more going on?

Legit question. Well, quite simply, I don't allow independent positioning - that's what I refer to with these restrictions listed above:
· Same width for all layers
· Same horizontal positioning for all layers

In the .guide included in the archive, I say a little more about the subject in the "UNIMPLEMENTED FEATURES" chapter:

INDEPENDENT HORIZONTAL POSITIONING OF LAYERS

A restriction of ALS is that all the layers must have the same horizontal positioning. That is a direct consequence of an Amiga hardware limitation that can be overcome only in two ways: by restricting the layers number to 2 or by restricting the per-layer offsets to multiples of the planes data fetch width (16 pixels on OCS/ECS, 64 pixels on AGA).
The first solution would basically reduce ALS to a special Dual Playfield mode which differs from the standard one "only" for the opaqueness settings of layers and colors. Implementing such mode in ALS would dirty the code, so that is left for a separate and future system (whose making is all but guaranteed).
The second solution allows only very coarse and difficult positioning. Moreover, although it would be easy to implement, it would not be worth the extra computing power and the more complex API it requires since it would be useful only in very special cases.

[roondar]

Originally Posted by saimo

Legit question. Well, quite simply, I don't allow independent positioning - that's what I refer to with these restrictions listed above:
· Same width for all layers
· Same horizontal positioning for all layers

In the .guide included in the archive, I say a little more about the subject in the "UNIMPLEMENTED FEATURES" chapter:

Ah, I did read the OP but missed that bit. Makes perfect sense!

[saimo]

No problem