The presentation of a new demo that makes use of it brings us back to HAM mode... and its limitations (which remain intact):
English: https://www.appuntidigitali.it/21886/no-the-limits-of-ham-have-not-vanished/
Italian: https://www.appuntidigitali.it/21812/no-i-limiti-dellham-non-sono-svaniti/

@cdimauro

I implemented 8-bit chunky HAM 555 in MC64K. 3 control bits and 5 gun bits. You get 32 palette colours and can then set any combination of the guns to the modify value. This means you get the 32 grey scale for free, they just have all 3 control bits set to 1.

It works and has all the dubious fringing you know and love when you start scrolling the viewport.

https://youtu.be/PoS_LF8Ik2s?si=-dn6qkvF44ZKV8sp

The colour pulses are fringing artefacts.

Last edited by Karlos on 31-Jan-2024 at 09:03 PM.

_________________
Doing stupid things for fun...

@Karlos: I see. I recall that you've mentioned it, some time ago, but you finally have implemented it.

However RGB isn't the best colour space for HAM/-like modes. It might be worth to use another one, like YUV, for example: results should be much better.

@cdimauro

I added it ages ago but I've not been doing anything with it since as I've only enough free time to spin half a plate when it comes to pet projects.

You are correct that there are better colour spaces in theory, but in practise it's a lot easier to manipulate RGB values and get a consistent result.

_________________
Doing stupid things for fun...

@Karlos: not in this case. Luminance (Y) is the most important component in a colour space and having the possibility to just change it in one shot gives way better results than changing one of the RGB components at the time.

For this reason HAM mode should have been implemented as YUV or something like that: certainly not like RGB. Even TVs didn't work with RGB, but with YUV-like colour spaces.
Using RGB was a great mistake.

@cdimauro

Quote:

cdimauro wrote: The presentation of a new demo that makes use of it brings us back to HAM mode... and its limitations (which remain intact): English: https://www.appuntidigitali.it/21886/no-the-limits-of-ham-have-not-vanished/ Italian: https://www.appuntidigitali.it/21812/no-i-limiti-dellham-non-sono-svaniti/

While HAM has limitations, Hamulet engine HAM6 demo has the potential for a top-down JRPG or Putty Squad-like platform game. https://www.gamesthatwerent.com/2013/12/putty-squad-amiga-released/

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

You would think so but they aren't. The reason is that *good* YUV schemes in a limited word size give more bits to the important components to increase their resolution accordingly. HAM schemes have the same precision for each component. I experimented with it but found the results aren't great for my ham555 model and the colour space itself is not intuitive for a basic framebuffer.

It is noteworthy nonetheless that Jay Minor's original concept was based on such a scheme. Brightness and saturation are useful for shading basic polygons (saturation changes can help with specular highlights) as he was thinking of flight simulators.

_________________
Doing stupid things for fun...

@Karlos

Quote:

I implemented 8-bit chunky HAM 555 in MC64K. 3 control bits and 5 gun bits. You get 32 palette colours and can then set any combination of the guns to the modify value. This means you get the 32 grey scale for free, they just have all 3 control bits set to 1.

OCS HAM and Chunky mode, it has to be all what ppcamiga1 has been dreaming all this time long! xD

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

Isn’t AGA HAM way better? Why use the original version in 2024?

_________________
Sent from my Quantum Computer.

@DiscreetFX

Why use HAM at all when people have had RTG for years? An obvious reason you might want to use HAM6 is to be more compatible beyond AGA. Or, you might want to do something that benefits from having only six bitplanes to update. You might want to do something where a reduced colourspace is acceptable. There are lots of reasons, to be honest.

I implemented a HAM-inspired mode in my virtual machine as a pure experiment for no other reason than I could and I was curious what could be done if you had the ability to updated more than one component at once and if you had chunky pixels. I liked the symmetry of it; 32 colour palette, 32 greyscale and the ability to modify any combination of the channels at once in a single pixel.

_________________
Doing stupid things for fun...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: The presentation of a new demo that makes use of it brings us back to HAM mode... and its limitations (which remain intact): English: https://www.appuntidigitali.it/21886/no-the-limits-of-ham-have-not-vanished/ Italian: https://www.appuntidigitali.it/21812/no-i-limiti-dellham-non-sono-svaniti/ While HAM has limitations, Hamulet engine HAM6 demo has the potential for a top-down JRPG or Putty Squad-like platform game. https://www.gamesthatwerent.com/2013/12/putty-squad-amiga-released/

No, it doesn't: read carefully the article (and the first one, albeit it's in Italian. But you can easily translate it).

Then check the Conclusions.

Finally, check the videogame that you like and think about if it fits with the HAM limits.

Almost all of the times you'll see that it doesn't.

@Karlos

Quote:

Karlos wrote: @cdimauro You would think so but they aren't. The reason is that *good* YUV schemes in a limited word size give more bits to the important components to increase their resolution accordingly.

You've to compare YUV and RGB with the same number of bits used, of course.
Quote:

HAM schemes have the same precision for each component. I experimented with it but found the results aren't great for my ham555 model and the colour space itself is not intuitive for a basic framebuffer.

Do you mean the YUV colour space?
Quote:

It is noteworthy nonetheless that Jay Minor's original concept was based on such a scheme. Brightness and saturation are useful for shading basic polygons (saturation changes can help with specular highlights) as he was thinking of flight simulators.

Then it's strange that he has decided to go for RGB, especially considering that no TVs at the time were working using RGB.

@cdimauro

Yes, I mean the YUV colour space is not a very intuitive framebuffer format to work with, such is the ubiquitous nature of RGB. To clarify, I experimented with RGB and YUV for this ham555 mode because it was my understanding that the original HAM was intending to have luminance and saturation modification.

I also thought about a scheme having just basic RGB colour pallete and having the modify behaviours specifically modify the effective luminance and saturation. This works, but as it turned out, 32 levels isn't great and there's the hidden cost of all the transformation in the code. In the end, RGB mode was a lot less bothersome.

As for actual HAM, I believe it was basically a feasibility experiment that was too much effort to remove from the chip design so it got left in.

Last edited by Karlos on 01-Feb-2024 at 10:29 PM.
Last edited by Karlos on 01-Feb-2024 at 10:29 PM.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

No, it doesn't: read carefully the article (and the first one, albeit it's in Italian. But you can easily translate it). Then check the Conclusions. Finally, check the videogame that you like and think about if it fits with the HAM limits. Almost all of the times you'll see that it doesn't.

Yes it does. Example https://www.youtube.com/watch?v=wYppHOT0jEQ

Open World ARPG Top Down Zelda like.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro
"Then it's strange that he has decided to go for RGB, especially considering that no TVs at the time were working using RGB."

My memory might be failing me but I think I remember seing an interview with him once where he said he considered not implementing it at all. It was about production time and there was some space left on the chips so he implemented it as a small trick or something...
But yes, being able to change luminance and chrominance would have been way usefull... I imagine that would have made wonders for the amiga iff anim format in a time when the Amiga was being used with video editing together with genlocks...
Then again AAA, if it had come earlier as planned would have had a 32 bit copper with individual pixel resolution instead of 4 pixels... That together with a genlock for video effects (plasma etc...) would have conquered the video world easily... Sometimes I wonder if Commodore's incompetence was not instead sabotage ...

Last edited by Jose on 02-Feb-2024 at 03:20 AM.

_________________

José

@Karlos

Quote:

Karlos wrote: @cdimauro Yes, I mean the YUV colour space is not a very intuitive framebuffer format to work with, such is the ubiquitous nature of RGB. To clarify, I experimented with RGB and YUV for this ham555 mode because it was my understanding that the original HAM was intending to have luminance and saturation modification. I also thought about a scheme having just basic RGB colour pallete and having the modify behaviours specifically modify the effective luminance and saturation. This works, but as it turned out, 32 levels isn't great and there's the hidden cost of all the transformation in the code. In the end, RGB mode was a lot less bothersome.

I think that the main problem here is that we're too much used to RGB.

Artists, for examples, find more natural different colour spaces (HSV).

However the benefits of such colour spaces in terms of "better encoding" the information is known and, in fact, it's used by standards like JPEG, MPEG, etc..
Quote:

As for actual HAM, I believe it was basically a feasibility experiment that was too much effort to remove from the chip design so it got left in.

Yes, I've read something like that.

Well, I would have preferred to have the transistors used for implementing different / more useful things, but there's no time machine and we got HAM...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: No, it doesn't: read carefully the article (and the first one, albeit it's in Italian. But you can easily translate it). Then check the Conclusions. Finally, check the videogame that you like and think about if it fits with the HAM limits. Almost all of the times you'll see that it doesn't. Yes it does. Example https://www.youtube.com/watch?v=wYppHOT0jEQ Open World ARPG Top Down Zelda like.

This is exactly the first result which I got when I've searched "Top Down JRPG". And I confirm again what I've said before: NO, it's not possible to implement it in HAM (at least as it is).

However, we know that you aren't a coder, right? And we also know that you do NOT read/understand what people write and, especially, TECHNICAL articles.
What I don't know is why you continue insisting. Really.

Now, and to be short: take the above game and convert it to Amiga in HAM mode. According to you it's doable, right? Then go ahead and SHOW IT to me.

In the meanwhile a prepare a huge pile of pop corns...

@Jose

Quote:

Jose wrote: @cdimauro "Then it's strange that he has decided to go for RGB, especially considering that no TVs at the time were working using RGB." My memory might be failing me but I think I remember seing an interview with him once where he said he considered not implementing it at all. It was about production time and there was some space left on the chips so he implemented it as a small trick or something...

What I recall is a statement like: if he had to remove it, then Denise would have had a huge hole in the chip. But maybe my memory is failing (getting older).
Quote:

But yes, being able to change luminance and chrominance would have been way usefull... I imagine that would have made wonders for the amiga iff anim format in a time when the Amiga was being used with video editing together with genlocks...

Not only for video editing. YUV, HSV, LAB, etc. allow to better encode the colour information.

RGB is comfortable only because you're more used to mix such "base colours". But it isn't the best colour space.
Quote:

Then again AAA, if it had come earlier as planned would have had a 32 bit copper with individual pixel resolution instead of 4 pixels...

There are three problems here.

The first is the format used for the Copper WAIT and SKIP instructions: there are not enough bits in the 32 bits for encoding X and Y coordinates. Unfortunately many of them were used for masking bits, which is not the most common thing. I would have removed (or severely limited) the masking bits and just used the bits for allowing bigger X and Y coordinates.

The second issue is related to how many free slots are available for the Copper for fetching its data. With AGA more are free, but aren't enough for making fancy stuff with the Copper.

Third, the Copper was left 16 bit. Not only it would have been possible to fetch 32 bits at the time, but even 64 bit and then holding 2 instructions. Here, again, Commodore engineers have shown how short minded they were...
Quote:

That together with a genlock for video effects (plasma etc...) would have conquered the video world easily... Sometimes I wonder if Commodore's incompetence was not instead sabotage ...

Incompetence at all levels: management AND engineers.

@cdimauro

The main reason YUV type schemes were used in television is because it was a logical colour extension from greyscale, allowing existing monochrome receivers to continue working with colour broadcasts. It's certainly not better than RGB for analogue video purposes, considering the cameras captured RGB data and colour TVs used RGB guns (from which the term gun for channel arises), meaning signal conversion at both ends. But better that than require everyone replace their TV sets, which were an expensive deal back then.

Digital YUV is used in image and video because it allows lossy compression by taking advantage of the perception of colour by the eye.

In digital graphics RGB is much simpler to manipulate, especially colour mixing. To mix colours quickly, sum their the gun values. To mix colours accurately, square their gun values, sum, and take the root. These can all be done using integer operations.

Colour mixing in other colour spaces requires matrix type operations and floating point with lots of odd empirically derived constants and biases

Last edited by Karlos on 02-Feb-2024 at 01:33 PM.

_________________
Doing stupid things for fun...

@cdimauro

Quote:

cdimauro wrote: This is exactly the first result which I got when I've searched "Top Down JRPG". And I confirm again what I've said before: NO, it's not possible to implement it in HAM (at least as it is). However, we know that you aren't a coder, right? And we also know that you do NOT read/understand what people write and, especially, TECHNICAL articles. What I don't know is why you continue insisting. Really. Now, and to be short: take the above game and convert it to Amiga in HAM mode. According to you it's doable, right? Then go ahead and SHOW IT to me. In the meanwhile a prepare a huge pile of pop corns...

"Top Down JRPG" refers to gameplay layout and artwork.

https://www.youtube.com/watch?v=1rzyENB_Zws
Zelda 2D JRPG example.

https://www.craiyon.com/image/YIqi-f_oSpSkUftJ3OjZlg
Top-down view of a village.

Other JPRG examples
Phantasy Star 3 (Sega Genesis)

Phantasy Star 4 (1993,Sega Genesis, later multiplatform without the Amiga)

Illusion of Gaia (SNES)

Golden Sun (SNES)

----
Cosmic Star Heroine, https://store.steampowered.com/app/256460/Cosmic_Star_Heroine/

Sea of Stars, https://store.steampowered.com/app/1244090/Sea_of_Stars/

Chrono Trigger, https://store.steampowered.com/app/613830/CHRONO_TRIGGER/

The basic idea is to combine a top-down Chaos Engine with an RPG story and cute artwork.

The Amiga can do mindless blasting top-down Chaos Engine.

I'm aware of Kang Fu's HAM mode implementation and I didn't like its artwork.

Last edited by Hammer on 02-Feb-2024 at 01:55 PM.
Last edited by Hammer on 02-Feb-2024 at 01:42 PM.
Last edited by Hammer on 02-Feb-2024 at 01:05 PM.
Last edited by Hammer on 02-Feb-2024 at 12:54 PM.
Last edited by Hammer on 02-Feb-2024 at 12:45 PM.
Last edited by Hammer on 02-Feb-2024 at 12:44 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)