@Fl@sh

WriteChunkyPixels(…)

My suspicion about this functions seems to be correct, first of all its slow.. here is the quote from the autodocs.

“Since WriteChunkyPixels is not (currently) particularly fast on
systems without the chunky-to-planar hardware, time critical
applications (games, etc) may want to use their own custom conversion
routine if GfxBase->ChunkyToPlanarPtr is NULL, and call
WriteChunkyPixels() otherwise. “

http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node033C.html


So modern hardware likes byte size pixels, it does not like bit sized pixels, modern GPU shaders can only do floats, so I guess for GPU’s pixels should be float sized.

I guess most ideal formats are byte-plains, or float-plains. Anyway, float is not good for older graphic cards without shaders, a floats are big, the biggest issue we have now is bottleneck problem, or transferring data to graphic cards sometimes without OS support for DMA, and Gart.

Modern graphics has grown fat, because technology has driven by development is photo realistic photos. And not by memory efficiency and size.

The most ideal outcome is a byte per plain per pixel, even so we need to do it on the CPU, there is no readymade transformation routine, well there is chunkyplains2, but I felt it was worth barking down that path, wasted too many CPU cycles, only in special cases where plains did not line up, was it worth it, and majority of cases that never happened.

Last edited by NutsAboutAmiga on 25-Jul-2020 at 10:51 AM.
Last edited by NutsAboutAmiga on 25-Jul-2020 at 10:43 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@saimo

Quote:

When I write "planes" I mean "bitplanes". Just shortening for convenience So, yes, the layers are made of bitplanes.

Okay that makes sense.

Quote:

The only practical solution is not using all the planes (at most 4 on OCS/ECS and 7 on AGA), but that would reduce greatly the power and the beauty of layers, thus defying the purpose of having layers in first place.

If you only wanted 4 or 7 layers it may work. Or even less.

Quote:

That said, it is technically possible to add sprites support. If that happens, the features will be as follows.

Okay, looks fine there.

Quote:

This is what I was referring to with this piece from a previous post (sorry, again I'm too exhausted):

That fine, no need to repeat yourself. By the looks of it the horizontally scrolling would need to be in blocks of 16 pixels at a time. Since they don't have their own scroll offset. That's understandable. Since they make up the entire bitmap.

Quote:

MLS doesn't use the Blitter.

Yes I realised that. I'm just thinking up ways around it. Using the blitter to scroll each layer.

Quote:

EDIT: only now I realized what you referred to with this (I'm too tired, sorry). Yeah, I was quite annoyed, to put it mildly. But it didn't burn exaggeratedly much at the moment: rather, it kept on stinging me through the years.

Fair enough. Thanks for explaining.

BTW, when AGA came out I recall these simple demos. They used to display digitsed pictures and fade between them. It was one of the cool effects AGA could do. Well I only noticed it being done on AGA. I always wondered how it was done. Does MLS use a simlar technique?

Last edited by Hypex on 25-Jul-2020 at 06:23 PM.

@NutsAboutAmiga

Quote:

My suspicion about this functions seems to be correct, first of all its slow.. here is the quote from the autodocs.

It doesn't mention it specifically, rather implied, but what it would be talking about is Akiko. CD32. Only Amiga released with chunky to planar hardware. Though on examination they would have been better doing it the VGA way. Chunky pixel write to bitmap planar hardware conversion.

Quote:

So modern hardware likes byte size pixels, it does not like bit sized pixels, modern GPU shaders can only do floats, so I guess for GPU?s pixels should be float sized.

That's interesting, it must be like the music industry, where it's all turning to floats. Well, floats can fit in 32-bits. But, in the end, it looks like Commodore may have been right, with 32-bits per gun. Like SetRGB32(). We're not there yet. But pushing RGB integers into RGB floats may push that over the line.

Quote:

I guess most ideal formats are byte-plains, or float-plains.

A packed plane. Like a wide plane I guess. Instead of multiple Z planes like on Amiga, it has an X plane with bits stored across.

@Hypex

Quote:

Quote: The only practical solution is not using all the planes (at most 4 on OCS/ECS and 7 on AGA), but that would reduce greatly the power and the beauty of layers, thus defying the purpose of having layers in first place. If you only wanted 4 or 7 layers it may work. Or even less.

1 bitplane less = half the number of colors available -> most of the times, not worth it (especially OCS/ECS). MLS is layers-oriented, so it makes little sense to sacrifice layers for sprites. For the moment being, they're out.

Quote:

That fine, no need to repeat yourself. By the looks of it the horizontally scrolling would need to be in blocks of 16 pixels at a time. Since they don't have their own scroll offset. That's understandable. Since they make up the entire bitmap.

16 pixels is too coarse a resolution: it causes scrolling to be way too jumpy and/or too fast. On AGA, to benefit from the 4x fetch mode, that's even worse: 64 pixels.

Quote:

Quote: MLS doesn't use the Blitter. Yes I realised that. I'm just thinking up ways around it. Using the blitter to scroll each layer.

That slows hugely everything down. Anyway, if the programmer doesn't (need to) care about the frame rate, MLS doesn't stop him from using the Blitter.

Quote:

BTW, when AGA came out I recall these simple demos. They used to display digitsed pictures and fade between them. It was one of the cool effects AGA could do. Well I only noticed it being done on AGA. I always wondered how it was done. Does MLS use a simlar technique?

Cross-fading is possible also on OCS/ECS, it's just that there are less colors available and the color resolution is inferior. And yes, it's exactly the same effect: calculating the palette so that the colors "mix".

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@ppcamiga1

Quote:

ppcamiga1 wrote: @saimo AMOS never was fast enough on original hardware. For games and demos You have to have something better.

That is your opinion, and you are entitled to it. I am sure many others would disagree with that sentiment. It was used in some commercial games, and some PD ones as well as a few demos (Syntex made several of note - and yes I am aware that several of those integrated ASM code into AMOS to help speed things along).

Quote:

Quote: I'm doing what I'm doing because of what explained in the opening post, i.e. personal fun/satisfaction in AMOS Professional. Thats ok. I hope nobody else use it.

Again your opinion. Not everybody has the ability to learn or make something useful in other high or low level languages (be that C, C++, E, asm). If someone wanted to use the engine to make something that is their choice. You don't have to download or play around with it.

Quote:

Nobody made worth playing game in it, in last thirty years.

Again - that is your opinion, and there will be many others who disagree. Valhalla and Jetstrike / Jetstrike AGA didn't do too badly considering they were made in AMOS, and they didn't play too badly on original hardware.

There is no need to be so harsh towards this project from Saimo just because you see no merit or use from it.

_________________
Test sig

@saimo

Quote:

1 bitplane less = half the number of colors available -> most of the times, not worth it (especially OCS/ECS). MLS is layers-oriented, so it makes little sense to sacrifice layers for sprites. For the moment being, they're out.

Ah ok, yes can cause damage to the pallette. Well, apparently the Atari ST had no sprites, so it isn't always needed. They went from an 80's stable to a decline towards the 90's.

Quote:

16 pixels is too coarse a resolution: it causes scrolling to be way too jumpy and/or too fast. On AGA, to benefit from the 4x fetch mode, that's even worse: 64 pixels.

Ouch. That would be no good. Not much can be done there.

Quote:

That slows hugely everything down. Anyway, if the programmer doesn't (need to) care about the frame rate, MLS doesn't stop him from using the Blitter.

It would for a whole screen. I typed is some ASM code from an Abacus book that demonstrated a scrolling blitter plane. It was fast and smooth on my A500. For ECS, with six planes and two hardware scrolling, four would need blitter scrolling. For AGA with 8 planes, six would need it. Fully independent planes, depth 8, AGA would need 8 whole screen blits. That could get slow.

But with parallax, not all planes would need to scroll at once, at the same speed. The fastest planes would use the scroll position registers, using the odd and even positions, if they can be used outside of dual playfield mode. Then it would go down the line, the next fastest being blittted, to the slowest in turn. Taking into account hardware positions.

A repeating pattern could speed it up. It could also be a whole screen across or two. Best would be a pattern of limited lines. Likely copper would be needed for modulo control and possibly switching bitmap patterns, so bitmap is a smaller block, but repeated on display. Another idea, is using prerendered scroll bitmaps, to simulate scrolling. Speed at the expense of space.

Quote:

Cross-fading is possible also on OCS/ECS, it's just that there are less colors available and the color resolution is inferior. And yes, it's exactly the same effect: calculating the palette so that the colors "mix".

It was hard to tell if it was HAM or another trick. Dual playifeld could do it with a copper list. I don't know what mode they used.

@Hypex

Quote:

Quote: That slows hugely everything down. Anyway, if the programmer doesn't (need to) care about the frame rate, MLS doesn't stop him from using the Blitter. It would for a whole screen. I typed is some ASM code from an Abacus book that demonstrated a scrolling blitter plane. It was fast and smooth on my A500. For ECS, with six planes and two hardware scrolling, four would need blitter scrolling. For AGA with 8 planes, six would need it. Fully independent planes, depth 8, AGA would need 8 whole screen blits. That could get slow. But with parallax, not all planes would need to scroll at once, at the same speed. The fastest planes would use the scroll position registers, using the odd and even positions, if they can be used outside of dual playfield mode. Then it would go down the line, the next fastest being blittted, to the slowest in turn. Taking into account hardware positions.

Even blitting a single plane eats a lot bus cycles, especially on OCS/ECS machines. It's a huge expense. Again, if that fits the program's timing, the programmer is free to use that solution.

Quote:

A repeating pattern could speed it up. It could also be a whole screen across or two. Best would be a pattern of limited lines. Likely copper would be needed for modulo control and possibly switching bitmap patterns, so bitmap is a smaller block, but repeated on display.

The Copper can't help overcome the fact that the modulo registers must be the same for all bitplanes.

Quote:

Another idea, is using prerendered scroll bitmaps, to simulate scrolling. Speed at the expense of space.

Yes, but that, except for very special cases, it's just too unpractical.

Quote:

Quote: Cross-fading is possible also on OCS/ECS, it's just that there are less colors available and the color resolution is inferior. And yes, it's exactly the same effect: calculating the palette so that the colors "mix". It was hard to tell if it was HAM or another trick. Dual playifeld could do it with a copper list. I don't know what mode they used.

No HAM: again, it's just a matter of calculating the palette. The Dual Playfield does not help and, actually, would make the effect impossible (if one needs all the bitplanes, that is). The Copper isn't strictly necessary and, actually, it would make the CHIP bus busier and thus slow everything down (the advantage of using the Copper is that it frees the CPU from synchronizing with the raster beam, but in some cases it's best to do things with the CPU).

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

Even blitting a single plane eats a lot bus cycles, especially on OCS/ECS machines. It's a huge expense. Again, if that fits the program's timing, the programmer is free to use that solution.

I suppose it comes down to what works in the given limitations. The CPU could also be used but that would be rather inefficient. And real classic Amiga games didn't spend time redrawing the whole screen.

Quote:

The Copper can't help overcome the fact that the modulo registers must be the same for all bitplanes.

No, so they would need to be linked up.

Quote:

Yes, but that, except for very special cases, it's just too unpractical.

It could be. Given the data is in effect shifted across between each frame, it would be somewhat redundant. The only reason I can think to really use it is to generate a 3d scrolling effect on a graphic block. Basically animating a graphic really. So it looks more realisitic.

Quote:

No HAM: again, it's just a matter of calculating the palette. The Dual Playfield does not help and, actually, would make the effect impossible (if one needs all the bitplanes, that is). The Copper isn't strictly necessary and, actually, it would make the CHIP bus busier and thus slow everything down (the advantage of using the Copper is that it frees the CPU from synchronizing with the raster beam, but in some cases it's best to do things with the CPU).

Okay, but how do you fade between two different images by just calculating a palette? They would have had to be using at least 8-bit depth. Since they were fading from one real picture to another. It needed lots of colours to begin with.

@Hypex

Quote:

It could be. Given the data is in effect shifted across between each frame, it would be somewhat redundant. The only reason I can think to really use it is to generate a 3d scrolling effect on a graphic block. Basically animating a graphic really. So it looks more realisitic.

Unless I misunderstood, your initial idea was having prerendered frames to simulate scrolling by simply changing the planes pointers, right? So, yes, it's simply an animation. As such, the animation can be used for just about everything (memory constraints aside). For example, think of the tunnel sections in (Super) Stardust.

Quote:

Okay, but how do you fade between two different images by just calculating a palette? They would have had to be using at least 8-bit depth. Since they were fading from one real picture to another. It needed lots of colours to begin with.

You put a picture on a given number of planes, then the other picture on the remaining planes, and recalculate the values to write to the COLORxx registers according to the pictures palettes and the degree of opacity of the front picture. Executing the effect boils down to changing the opacity from 100% to 0% while recalculating the palette at each step.
(Sorry, I can't go into the details because I just don't have the time to.)

Last edited by saimo on 02-Aug-2020 at 05:37 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Horizontal scrolling: certain kind of backgrounds can be scrolled smoothly even if from hw side you only have possibility to set it's start in 16 pixel steps. Think of the background layer in Amiga game "Rock n Roll". If the gfx used 17x17 pixel sized pattern instead of 16x16 then depending on which start address for the planes you set, you get different horizontal shifting. So you would have a single extra wide stripe (~ (320+16*16) width x 17 pixel height) in memory and set plane pointer to (plane + (viewx % 17) * 2).


1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG
^...............^...............^...............^...............^...............^....

@Georg

Quote:

Horizontal scrolling: certain kind of backgrounds can be scrolled smoothly even if from hw side you only have possibility to set it's start in 16 pixel steps. Think of the background layer in Amiga game "Rock n Roll". If the gfx used 17x17 pixel sized pattern instead of 16x16 then depending on which start address for the planes you set, you get different horizontal shifting. So you would have a single extra wide stripe (~ (320+16*16) width x 17 pixel height) in memory and set plane pointer to (plane + (viewx % 17) * 2). 1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG1234567890ABCDEFG ^...............^...............^...............^...............^...............^....

That's true, but those are very specific cases, but maybe they are not worth the extra clutter in the code. I mean, at the moment there is just a single procedure that sets the X offset for all the layers. If I were to allow per-layer offsets, there should be (also) a procedure that sets the fine X offset (0 ... 15|63) for all the layers, and a procedure for the coarse X offsets (0, 16|64, 32|128, ...) for each layer: that would be quite uncomfortable (especially for the less expert programmers); alternatively, the single procedure could be changed to affect the fine X offset globally and the coarse X offset on a per-layer basis, but this could be again confusing for the less expert programmers. On top of everything, handling per-layer X offsets has also a little impact on performance, as a vector of values needs a bit more computing than a single value - but it's a marginal performance hit, indeed.
I'm not sure whether to add this feature. I have to ponder on it.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Quote:

Unless I misunderstood, your initial idea was having prerendered frames to simulate scrolling by simply changing the planes pointers, right? So, yes, it's simply an animation. As such, the animation can be used for just about everything (memory constraints aside). For example, think of the tunnel sections in (Super) Stardust.

Yes, you understood fine, that was the idea. I was just thinking, if some kind of scrolling was to be effected by animating in place, might as well think outside the box and use it for extra effect. So I thought an animated 3d panned image would look good. Like the old 3d copper effect, but with more depth, and chip ram of course.

Quote:

You put a picture on a given number of planes, then the other picture on the remaining planes, and recalculate the values to write to the COLORxx registers according to the pictures palettes and the degree of opacity of the front picture. Executing the effect boils down to changing the opacity from 100% to 0% while recalculating the palette at each step.

That sounds reasonable. I just didn't know how it was done, with a limited palette, where both images look like real HAM images. I'm going from memory so might not have looked as good as I remember.

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 edited by saimo on 08-Sep-2020 at 04:48 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

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

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

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 edited by saimo on 16-Sep-2020 at 03:19 PM.

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

That is really cool!
Reminds me of the technique used in Banshee for Fog/Laser transparency, but more advanced.

I can totally see this "Mask" technique to be used for low cost Lighting or Water/Glass transparency effects. Excellent job!

_________________
God created Paula so that Allister Brimble and Dave Whittaker could do music

Check my Amiga gameplays (ITA)!

@ErikBauer

Quote:

That is really cool! Reminds me of the technique used in Banshee for Fog/Laser transparency, but more advanced.

Indeed technically the concept is the same.

Quote:

I can totally see this "Mask" technique to be used for low cost Lighting or Water/Glass transparency effects. Excellent job!

Yes, those effects are definitely the most obvious one (in fact, I used it for the glass panes in SkillGrid), but much more can be achieved with it (check out the other videos, if you haven't done it already)

_________________
RETREAM - retro dreams for Amiga, Commodore 64 and PC

@saimo

Nice!

Incredibile AMOS possa ancora dire la sua nel 2020! How amazing AMOS has still something to tell in 2020!

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

bravo!!

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@saimo

Looks nice. I played with Amos Pro many years ago before shifting into PC's Visual Studio C++ and VB.NET.

_________________
Ryzen 9 7900X, DDR5-6000 32 GB RAM, GeForce RTX 4080
Amiga 1200 (rev 1D1, KS 3.2, TF1260, 68060 @ 63 Mhz, 128 MB)
Amiga 500 (rev 6A, KS 3.2, PiStorm/RPi3a/Emu68)