Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: ALS, a new graphics system  (Read 1495 times)

0 Members and 1 Guest are viewing this topic.

Offline saimo

ALS, a new graphics system
« on: July 16, 2020, 02:59:04 PM »
In the past few days I've been working on a new graphics engine.

VIDEO PREVIEW #1


OVERVIEW

"ALS" stands for "AMOS Layers System" (formerly "MLS" = "Multi-Layer System"), as it turns the screens of AMOS Professional ("AMOS" from now on) into layers that can be laid over one another, with complete control of order, colors and trasparency, while keeping them renderable as usual.
It is easy to use, does not require much knowledge of the Amiga graphics hardware, does not require installation or extensions, and comes as a set variables, arrays and procedures written in fully-commented AMOS code - it can be thought of as an AMOS source-level library.


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
· 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-planes displays (display colors 32...63 equal to display colors 0...31 with halved brightness)
· 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 brought to the creation of 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 didn't support sprites. While pondering on how to add them, I realized that actually the core design wasn't 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% of the development... I lost the sources. I can't remember how that happened, but for sure I couldn't recover them, so I remained only with the sources dating back to some days before, when some key additions had not been made yet. I was so angry that I hated the idea of reimplementing what had been lost, and that, coupled with the fact that I was about to move country, marked the end of 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'd do that sometime, as a smaller project between bigger ones. But, at the same time, I could never really accept the idea of using a non-optimal system, so a few times I considered completing AVS... only to drop the idea immediately: I just couldn't bother getting acquainted with that old code, maybe discovering that, after all, I'd do things differently once again.
Although I dedicated myself to many other projects, the ghosts of these systems kept on haunting me. In 2019 I presented CSS to the world with a video preview: it was an attempt between doing justice to the system (and thus hopefully make peace with it) and forcing myself to complete the work by exposing publicly the waste and the shame it represented. Since then, I made a new game (Blastaway), I continued the work on a game and released a preview of it (QUOD INIT EXIT IIo), I released two little updates for another game (MeMO), I prepared an update (still unreleased) for yet another game, I created two other graphics systems and 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 I designed and implemented a new and proper system from the scratch - and so ALS was born.


WHAT'S GOING TO HAPPEN?

ALS is almost complete - only one thing is still missing: unsurprisingly, sprites support*. Even the documentation is in place, so, in theory, it could be released already - yes, the plan is to make it available so that other developers can build games and other cool stuff on top of it. However, I'm not going that route because, firstly, I want to test the system thoroughly and, secondly, because it might be lacking in some department and I haven't realized that yet.
Therefore, I decided to develop one or two mini-games with it before releasing it: that will make for a proper test and give me the chance to make also the dream of pimping up an old game come true.

*Sprites are always left behind for one reason: with this system, it's natural to use all the bitplanes available to have as many layers and colors as possible; as a consequence, all the color registers are set automatically as needed by the layers; since the hardware assigns some of those registers to the sprites according to a very limiting scheme, it's very hard or even impossible to draw and arrange the sprites. The only practical solution is not using all the planes (at most 4 on OCS/ECS and 7 on AGA), but that reduces greatly the power and the beauty of layers, which defies the purpose of having layers in first place.
Anyway, implementing sprites is possible and I do intend to do it (a routine is already in place, actually).


PERFORMANCE

Whenever a color, an alpha value, or the stack of the layers gets changed, it is necessary to recalculate all the colors starting from those relative to the first bitplane of the first layer affected (for example: on AGA, if all the bitplanes are used, layer 2 starts from the 5th bitplane and its alpha gets changed, all the colors from 16 to 255 must be recalculated). 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). To give an idea: the video has been recorded using UAE, but on my Amiga 1200 equipped with a 68030 @ 50 MHz the same demo, compiled, slows down when the HUD layer fades in (the colors from 64 to 255 need to be recalculated).
Other than that, the system is quite lightweight.


WHY AMOS CODE?

Although assembly would make the routines dramatically faster, one amusing and motivational thing for me was precisely using AMOS only. Returning to AMOS and writing everything in such language after many years was fun and, additionally, it's just too cool to say: "Hey, this stuff is made in AMOS!"
« Last Edit: October 19, 2020, 12:46:46 PM by saimo »
 
The following users thanked this post: Gryfon, trekiej, F1Lupo

Offline Gryfon

Re: MLS, a new graphics system
« Reply #1 on: July 16, 2020, 06:55:29 PM »
Amazing work, I look forward to seeing how people use it.
\\"We should take off and nuke the entire site from orbit.  It's the only way to be sure.\\" Ripley, Aliens
 

Offline saimo

Re: MLS, a new graphics system
« Reply #2 on: July 16, 2020, 08:14:09 PM »
Amazing work, I look forward to seeing how people use it.

Me too... when the thing is available, that is ;D
 

Offline TribbleSmasher

Re: MLS, a new graphics system
« Reply #3 on: July 16, 2020, 08:27:42 PM »
But it has to be an Extension, doesn't it? Sooo, ASM again? ;D
 

Offline saimo

Re: MLS, a new graphics system
« Reply #4 on: July 16, 2020, 08:36:58 PM »
But it has to be an Extension, doesn't it? Sooo, ASM again? ;D

Nope, it's exactly what I wrote it is: a collection of AMOS Procedures written in 100% AMOS ;)
 

Offline Steady

Re: MLS, a new graphics system
« Reply #5 on: July 17, 2020, 01:45:37 AM »
Frankly, that is amazing. Nice work :-)
 
The following users thanked this post: saimo

Offline saimo

Re: MLS, a new graphics system
« Reply #6 on: July 21, 2020, 11:21:52 PM »
VIDEO PREVIEW #2

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.
 
The following users thanked this post: F1Lupo

Offline First Ninja

Re: MLS, a new graphics system
« Reply #7 on: July 22, 2020, 12:03:59 PM »
Amazing work, I look forward to seeing how people use it.

Unfortunately, a few things can already be foreseen - it's not going to be usable with RTG-graphics nor networking cards, and I very much doubt that AHI-powered audio is on the table either. Again, unfortunately.
 

Offline saimo

Re: MLS, a new graphics system
« Reply #8 on: July 22, 2020, 02:28:36 PM »
Unfortunately, a few things can already be foreseen - it's not going to be usable with RTG-graphics nor networking cards, and I very much doubt that AHI-powered audio is on the table either. Again, unfortunately.

To write software for RTG/AHI/younameit it is necessary to use the appropriate tools. This is a project to make stuff for the original hardware of classic Amigas using AMOS, nothing else.
« Last Edit: July 22, 2020, 02:29:20 PM by saimo »
 

Offline saimo

Re: ALS, a new graphics system
« Reply #9 on: September 08, 2020, 04:45:36 PM »
VIDEO PREVIEW #3

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.)
« Last Edit: September 08, 2020, 04:48:31 PM by saimo »
 

Offline saimo

Re: ALS, a new graphics system
« Reply #10 on: September 11, 2020, 10:34:38 AM »
Quick update: implementation finished! Now it's time to do some testing and writing the second tutorial.

Offline saimo

Re: ALS, a new graphics system
« Reply #11 on: September 16, 2020, 03:19:24 PM »
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.

Offline saimo

Re: ALS, a new graphics system
« Reply #12 on: September 29, 2020, 11:31:38 AM »
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.
 

Offline Bennymee

Re: ALS, a new graphics system
« Reply #13 on: September 30, 2020, 11:58:18 AM »
Thank you, looks good!
Amiga 500, 1200, 4000, Amigaone, Morphos, CyberstormPPC, Blizzardppc, OS4.x
 

Offline saimo

Re: ALS, a new graphics system
« Reply #14 on: October 15, 2020, 01:13:29 PM »
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.
 
The following users thanked this post: F1Lupo