ALS, a new graphics system - RELEASED!

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

VIDEO PREVIEW #1
VIDEO PREVIEW #2
VIDEO PREVIEW #3
VIDEO PREVIEW #4
DEMOS VIDEO / 1
DEMOS VIDEO / 2
EXPERIMENTS VIDEO / 1
EXPERIMENTS VIDEO / 2


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.

Nice!

@saimo

fantastic mate. :)
maybe is time to go back to amos..

@orgin

Thanks!


@afxgroup

Thanks and LOL!


@all

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

nice work on Amos !

@AmiDARK

Thank you!


@all

VIDEO PREVIEW #4

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.

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.

VIDEO PREVIEW #5

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.

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 ;)

FINAL VIDEO

@saimo

I have released a minor bugfix update for ALS which fixes a few minor issues.

v1.89 (21.03.2021)
* Fixed bug in ALS_SET_DISPLAY_COLORS_RANGE_FROM_PALETTE_SEGMENT[], which caused the low 12 bits of the colors to be set to the same value as the high 12 bits (because the instruction Areg(0)=PSA was placed just after the beginning of a loop, despite the comment just above said: "Areg(0) is set only once before the loop thanks to the fact that it is updated by Call with the value returned by ALS_SETCOLORXXRANGE()").
* Replaced all End/Pop Proc[False] with End/Pop Proc[0], as False might crash the Compiler in some circumstances.
* Fixed a comment in the ALS code.
* Fixed the metadata of a couple of ILBM files.
* Added a note to the demo3 program.

Working on Follix (which uses ALS) inspired a few improvements.

v1.94 (06.06.2021)
* Added ALS_CHECK_LAYER_INDEX[].
* Added ALS_COPY_PALETTE_SEGMENT[].
* Added ALS_CREATE_LAYER_AS_CLONE[].
* Added ALS_SET_LAYER_A_AND_COLORS_FROM LAYER[].
* Made check on layer index in ALS_DESTROY_LAYER[] and ALS_MAKE_LAYER_DESCRIPTOR[] more robust.
* Removed check on layer index from ALS_GET_LAYER_DEPTH[].
* Simplified ALS_OPEN_FILE[].
* Updated manual.

https://www.retream.com/ALS

@saimo

thanks for the continuous updates on all of your programs lately

@328gts

My pleasure :)


@all

Just released another update.

v1.95 (4.7.2021)
* Optimized ALS_SET_DISPLAY_COLORS_RANGE_FROM_PALETTE[] and ALS_SET_DISPLAY_COLORS_RANGE_FROM_PALETTE_RANGE[] a little bit.
* Removed wrong comment from ALS_SET_DISPLAY_COLORS_RANGE_FROM_PALETTE[].

https://www.retream.com/ALS

This is the last version that supports also OCS and ECS. ALS v2 will be AGA-only. The reason is that supporting all the chipset requires lots of additional code and also slows down execution in many places, while functionality is still very limited on OCS and ECS due to the fact that they offer only 6 bitplanes and 32 color registers. ALS is much more useful on AGA, so it makes sense to have a leaner and faster version for that chipset.

Also, I decided to postpone the release of Follix to after ALS v2 is done, so that the game can benefit from it.

v1.96 and v2.0 released

As announced recently, here is ALS v2, whose main difference with the previous versions is that it's for AGA only and, therefore, can benefit from faster and smaller code (the compiled binary is about 3.5 kB smaller).
Besides the work done for the AGA-only transition, there are also a few more improvements, many of which made it also to a new v1 library (v1 is supposed to be end-of-line, but still I couldn't resist fixing/improving what surfaced along way). The changelogs below detail the changes.

https://www.retream.com/ALS

v2.0 (6.7.2021)
* Removed useless code from ALS_COPY_PALETTE_SEGMENT[].
* Removed OCS/ECS code.
* Removed OCS/ECS palettes support.
* Removed ALS_CHIPSETID, ALS_MAXLAYERCOLORSNUMBER, ALS_MAXPLANESNUMBER, ALS_PALETTECOLORSNUMBER, ALS_ADDRESSABLECOLORSNUMBER.
* Optimized code for AGA.
* Optimized ALS_SET_DISPLAY_COLORS_FROM_PALETTE[], ALS_SET_DISPLAY_COLORS_RANGE_FROM_PALETTE[] and ALS_SET_DISPLAY_COLORS_RANGE_FROM_PALETTE_SEGMENT[] a lot.
* Added ALS_BUILD_DISPLAY_COPPERLIST_HEAD[] and ALS_BUILD_DISPLAY_COPPERLIST_TAIL[].
* Made various other improvements.
* Revised/extended manual.

v1.96 (6.7.2021)
* Removed useless code from ALS_COPY_PALETTE_SEGMENT[].
* Optimized ALS_SET_DISPLAY_COLORS_FROM_PALETTE[] a little bit.
* Added ALS_BUILD_DISPLAY_COPPERLIST_HEAD[] and ALS_BUILD_DISPLAY_COPPERLIST_TAIL[].
* Made various other improvements.
* Revised/extended manual.

I have tested both version extensively through their test/demo programs and by means of ArtPazz and Follix. All tests have been done on a real Amiga 1200 (with and without accelerator board) and in UAE, and ran both from interpreter and as compiled programs. No issues were found, so it looks like the massive work didn't break anything.

Just released an update aimed at improving the terminology and the documentation.

v1.97 & v2.1 (16.7.2021)
* Renamed "palette segments" as "segments".
* Renamed: ALS_COPY_PALETTE_RANGE[] as ALS_COPY_SEGMENT_FROM_PALETTE_RANGE[]; ALS_EXTRACT_PALETTE_SEGMENT[] as ALS_CREATE_SEGMENT_FROM_PALETTE_RANGE[]; ALS_SET_DISPLAY_COLORS_RANGE_FROM_PALETTE_SEGMENT as ALS_SET_DISPLAY_COLORS_RANGE_FROM_SEGMENT[].
* Updated/revised in-code documentation.
* Updated/revised/fixed manual.

https://www.retream.com/ALS

@saimo

amazing all the updates you've been putting out lately

Ring around the World received an update yesterday. Today is ArtPazz's and Follix's turn - but first comes the library they're built on: ALS.

v1.100 & v2.4 (18.3.2023)
* Removed dependency on mathtrans.library by replacing CN=2^LD with CN=1 : Rol.l LD,CN.

v1.99 & v2.3 (20.2.2023)
* Changed the conditions of many If, Until and While statements to have the AMOS Professional Compiler produce shorter and faster code.
* Touched up manual.

v1.98 & v2.2 (19.2.2023)
Added CPU caches clearing after machine code routines generation in ALS_INITIALIZE_SYSTEM[].

A couple of experiments done while brainstorming about a new game made with ALS.
The first effect is obtained basically at no processing cost, while the second one requires only the minimal cost of blitting a 2 bit mask. A stock Amiga 1200 can handle this without breaking a sweat.

https://www.youtube.com/watch?v=_Il8SYeYoAs

To be honest, I'm at a loss regarding which game to make.
It all started with the itch of remaking the second game I ever made (and never publicly released), but while fiddling with ALS these effects came to mind - and they don't happen to be very suitable for that game.
So, I tried to think of alternatives, and the best idea I came up is a game where: there are two parallel worlds, a real (dangerous/dark) one and an illusory (pleasant/nice) one; the screen mostly shows the illusory world, but the character controlled by the player is inside a bubble around it that shows the real world or there's some mechanism that allows the player to somehow reveal the real world - e.g. with a sort of torch light. The problem with this idea is designing the game and producing the content (double graphics work!) - it's something I can't undertake now.
Also, a sports game is sorely missing from my catalogue, but so far I couldn't think of anything interesting.

More experiments with ALS...

https://www.youtube.com/watch?v=XNVDGbproek