@cdimauro

Quote:

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.

I'm a coder for certain law professional software.

Quote:

And we also know that you do NOT read/understand what people write and, especially,

Fuck you. Your constant attack on me is fucking bullshit.

Based on this Hamulet's HAM engine https://www.youtube.com/watch?v=szbr7xhiwQc

Hamulet's HAM engine is good enough for top-down static placement building/houses, static placement animated trees/vegetation objects, static placement animated dragons, static placement animated water bodies, static placement animated hazards and 'etc'.

Hamulet's HAM engine shows movement in vertical and horizontal scroll.

https://eab.abime.net/showpost.php?p=1662898&postcount=29
From is Hamulet's HAM engine's programmer's statements

I'll answer the tech questions here:
1) As guessed by ovale and jobbo, the ham bobs include the background, so in their current state, they are mostly stationary. It would be possible however to have a moving bob with some clever restrictions on the background. But at this stage, this was mostly just a test of HAM animation.

2) With the proper background, for example a large 'boss enemy' moving over a transparent sky gradient background, the HAM bob could move freely both vertically and horizontally.

3) Memory-wise, probably only 'large bosses' would potentially use a HAM bob. The other idea I had (for possibly a future project) would be on the CD32: using the CD as a massive storage for animated HAM bobs.

4) Oh no, for Hamulet I either bought or commissioned some of the pixel art, and here for this HAM bob test, I used graphics from the game Bzzzt, from the game Super Mutant Alien Assault, from Pixilart, and from Metal Slug.

-----------------

My comments
1. Don't expect Street Fighter 2 from this engine, but other game types can be possible.

2. To minimize HAM artifacts, color palette selection rules need to be followed.

3. There are other non-HAM Copper-driven methods to increase displayed colors as shown in the Metro-Siege example.

Last edited by Hammer on 02-Feb-2024 at 01:45 PM.
Last edited by Hammer on 02-Feb-2024 at 01:37 PM.
Last edited by Hammer on 02-Feb-2024 at 01:15 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)

@Hammer

Protip: Professional software engineers never describe themselves as a "coder" in relation to their day job.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @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

I agree. There isn't a perfect colours space (which is the reason why we've son many): everyone has its particolar strong and weak points.

But specifically, talking of HAM and, in general, encoding colours information, RGB was certainly the worse choice.

@Hammer

Quote:

Hammer wrote: @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.

I know, Mr. Obvious. But I "just" (!) wanted to seek for some gaming matching this definition, since I had no one particular in my mind. Got it now?
Quote:

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/

I've watched videos for all of them and I reveal you secret: NONE of them can be implemented (AS THEY ARE) using HAM. Read again: NO-NE!

I mean, if you do NOT want (A LOT OF) fringing in the screen because you had the "so good" (!!) idea to implement the NPCs as BOBs (the main character can be usually implemented with sprites).

Which is exactly the reason why almost all games AVOIDED using HAM.
Quote:

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.

LOL: Chaos Engine?!? In HAM? ARE YOU NUT?!?
Quote:

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

I'm not aware of it and at this point I'm not even interested to see another castrated game to fit the HAM requirements, or fringing over the screen.

Do you know what? I'm a professional: I've worked on DEVELOPING (NOT just playing) AAA games at the time on Amiga (and I was also available for porting the games to PC), and I know very well the limits of the hardware, what could be possible and, all over, what MADE SENSE to implement to get a product GOOD FOR THE MARKET.

Viceversa, you're a daydreamer that is living on a parallel universe, since you've no clue at all of the above.
Quote:

Hammer wrote: @cdimauro Quote: 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. I'm a coder for certain law professional software.

Sure. And I'm Donald Trump wearing a Che Guevara T-shirt...
Quote:

Quote: And we also know that you do NOT read/understand what people write and, especially, Fuck you. Your constant attack on me is fucking bullshit.

Constant?!? On you FIRST comment I've replied with this:

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.

Which should have been clear enough, right? But no: you decided to completely IGNORE it and REPEAT like a PARROT your complete non-sense.

What else do you expect from me? A prize for your load of balls?
Quote:

Based on this Hamulet's HAM engine https://www.youtube.com/watch?v=szbr7xhiwQc Hamulet's HAM engine is good enough for top-down static placement building/houses, static placement animated trees/vegetation objects, static placement animated dragons, static placement animated water bodies, static placement animated hazards and 'etc'. Hamulet's HAM engine shows movement in vertical and horizontal scroll. https://eab.abime.net/showpost.php?p=1662898&postcount=29

I really don't know why Mother Nature was so evil with you, because... my first article (linked to the the last one of this thread) talked EXPLICITLY of Hamulet's engine (TECHNICALLY), showing HOW it's working, its INTRISIC LIMITS and, so, WHY it CANNOT be used for other games (unless they share exactly the same limits).

You've accused me above that I continuously attack you because of this sentence:

And we also know that you do NOT read/understand what people write and, especially

which, as can be clearly seen, it's simply... TRUE. Because either you do NOT read what people write (articles included. Which WERE MENTIONED) and/or you do NOT understand what was written.

Are you odd, slow, or what else, since I've not written in Oxford English my articles (the first, in Italian, can be easily translated in English. DeepL gives an excellent version)?
Quote:

From is Hamulet's HAM engine's programmer's statements I'll answer the tech questions here: 1) As guessed by ovale and jobbo, the ham bobs include the background, so in their current state, they are mostly stationary. It would be possible however to have a moving bob with some clever restrictions on the background. But at this stage, this was mostly just a test of HAM animation. 2) With the proper background, for example a large 'boss enemy' moving over a transparent sky gradient background, the HAM bob could move freely both vertically and horizontally. 3) Memory-wise, probably only 'large bosses' would potentially use a HAM bob. The other idea I had (for possibly a future project) would be on the CD32: using the CD as a massive storage for animated HAM bobs. 4) Oh no, for Hamulet I either bought or commissioned some of the pixel art, and here for this HAM bob test, I used graphics from the game Bzzzt, from the game Super Mutant Alien Assault, from Pixilart, and from Metal Slug.

Obviously I've read this BEFORE writing my articles. Do you have some idea about such "clever restrictions on the background"? Because I've some (of course). However, I'm curious to know what's YOUR opinion, dear "coder"...
Quote:

----------------- My comments 1. Don't expect Street Fighter 2 from this engine,

CLAP CLAP CLAP, Mr. Obvious!
Quote:

but other game types can be possible.

Which ones? List them! I'm also curious to see what other things you'll write.
Quote:

2. To minimize HAM artifacts, color palette selection rules need to be followed.

CLAP CLAP CLAP, Mr. Obvious! This is ALREADY THE BASE thing to do when talking about HAM.
Quote:

3. There are other non-HAM Copper-driven methods to increase displayed colors as shown in the Metro-Siege example.

What's not clear to you that the entire topic is ONLY about HAM and NOTHING ELSE?

@Karlos

Quote:

Karlos wrote: @Hammer Protip: Professional software engineers never describe themselves as a "coder" in relation to their day job.

Hasta la victoria, siempre!

@cdimauro

Quote:

I've watched videos for all of them and I reveal you secret: NONE of them can be implemented (AS THEY ARE) using HAM. Read again: NO-NE!

I didn't claim a pixel-perfect port when there's a massive gap between Amiga's raster performance and modern PC's.

https://youtu.be/xlWW7mATbZw?t=339
HAMULET WIP HAM mode as a top-down hack-n-slash/puzzle crawler. The map is heavily tiled.

The natural direction with the recent HAMULET demo is about reducing the repetitive tiled presentation i.e. improving artwork diversity.

RPG adds "go fetch" story plots and rock-and-paper scissor stats gameplay.

Quote:

I mean, if you do NOT want (A LOT OF) fringing in the screen because you had the "so good" (!!) idea to implement the NPCs as BOBs (the main character can be usually implemented with sprites).

Considering HAM6 mode's limitations, it depends on the gameplay type.

HAM's 16-color baseline should cover the expected color range.

You made a big deal about the Metal Slug 3 truck asset's HAM color fringing, but this issue is not a big issue when this minor HAM color fringing is exploited as an extra "random" color shade. Don't expect pixel color perfection in the real world.

Modern 3D games are exploiting less-than-perfect variable shader resolution and fake pixels via motion vector-temporal pixel reconstruction. Hollywood's MPEG to H.265 is not about pixel-perfect i.e. in motion, it's less noticeable.

Quote:

Which is exactly the reason why almost all games AVOIDED using HAM.

For most games in the late 1980s and early 1990s, Amiga's joint game development with Atari ST is a major factor. Games from Bitmap Brothers have Atari ST's 16-color artwork optimization baseline.

Amiga's Links Golf game did NOT factor in Atari ST i.e. this game is only PC VGA and Amiga HAM6 consideration. Amiga's Links Golf game is not pixel-perfect with PC's VGA version, but it's a good enough approximation.

Many Amiga's point-and-click adventure games have Atari ST artwork consideration.

PiStorm-Emu68 CPU enhanced Amiga's HAM6 mode Quake is not pixel-perfect with PC's Quake 256 color VGA, but it's a closer approximation when compared to the 64-color EHB version. It's known IBM VGA (1987) is very slow despite throwing 1.8 Ghz K7 Athlon XP 2200+ at it.

https://en.wikipedia.org/wiki/Hold-And-Modify
Amiga HAM is considered to be pixel compression like JPEG and MPEG.

Last edited by Hammer on 03-Feb-2024 at 02:11 AM.

_________________
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

Quote:

Sure. And I'm Donald Trump wearing a Che Guevara T-shirt...

Your assertion is nonsense. You started the personal attack instead of focusing on the issue at hand.

Quote:

Constant?!? On you FIRST comment I've replied with this: No, it doesn't: read carefully the article (and the first one, albeit it's in Italian. But you can easily translate it).

Presenting your argument in the expected language is your problem.

Quote:

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. Which should have been clear enough, right? But no: you decided to completely IGNORE it and REPEAT like a PARROT your complete non-sense. What else do you expect from me? A prize for your load of balls?

You assumed and you're wrong.


Quote:

Obviously I've read this BEFORE writing my articles. Do you have some idea about such "clever restrictions on the background"? Because I've some (of course). However, I'm curious to know what's YOUR opinion, dear "coder"...

You made a big deal about the Metal Slug 3 truck's HAM color artifacts when pixel-perfect replication is not mandatory. The goal was to display more colors.

HAM is a lossy compression and there's a cost for it i.e. there's no such thing as a free lunch.

There are different thresholds for acceptable color artifacts.

From my POV, the Metal Slug 3 truck's HAM color artifacts are minor, and it has unique "retro Amiga" characteristics like an LP record. Amiga retro scene makes the Amiga market alive.

Most Amiga users have a modern PC, an Android, or an Apple iOS/MacOS X device.

With HAM color compression, I don't expect pixel-perfect replication.

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

@Karlos

Quote:

Karlos wrote: @Hammer Protip: Professional software engineers never describe themselves as a "coder" in relation to their day job.

Useless semantics.

Last edited by Hammer on 03-Feb-2024 at 03:57 AM.

_________________
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
"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)."

That was it, now I remember! And he didn't dedicate too much time to it ...

_________________

José

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: I've watched videos for all of them and I reveal you secret: NONE of them can be implemented (AS THEY ARE) using HAM. Read again: NO-NE! I didn't claim a pixel-perfect port when there's a massive gap between Amiga's raster performance and modern PC's.

A pixel-perfect conversion is impossible by definition when talking about HAM, so it was implicit.
Quote:

https://youtu.be/xlWW7mATbZw?t=339 HAMULET WIP HAM mode as a top-down hack-n-slash/puzzle crawler. The map is heavily tiled. The natural direction with the recent HAMULET demo is about reducing the repetitive tiled presentation i.e. improving artwork diversity.

I've already, fully analyzed it on the first article that I've written.
Quote:

RPG adds "go fetch" story plots and rock-and-paper scissor stats gameplay.

It's not only about how RPGs are: it's all about how many things they FREELY (that's THE main point!) move in the screen, which severely limits what's possible in HAM mode.

For those objects/NPCs, the only way is to use the Amiga sprites. But you've only 8 x 16 pixels wide and in 4 colours (3 + transparency), which aren't that useful this way and they are "combined" (attached) to get 4 x 16 pixels wide 16 colours (15 + transparency).

Talking about horizontal scrolling (which almost always used on the kind of games that you want), it means that you've one less sprite (because the display takes its slot for fetching the graphic to be displayed).
So, in the end you've only 3 x 16 pixels wide 16 colours + 1 x 16 pixels wide 4 colours (which on Hamulet is used for the vertical bar to the left to display a small panel for the purpose of hiding the great fringing that happens when you horizontal scroll an HAM screen).

Those are THE limits when using the HAM mode with FREELY movable objects.

Now you've enough information for picking any game that you want and see if it matches those limits. As I've said before, all games that you mentioned do NOT fit them and cannot be ported to Amiga/HAM.
Quote:

Quote: I mean, if you do NOT want (A LOT OF) fringing in the screen because you had the "so good" (!!) idea to implement the NPCs as BOBs (the main character can be usually implemented with sprites). Considering HAM6 mode's limitations, it depends on the gameplay type. HAM's 16-color baseline should cover the expected color range.

16-colours for the entire screen (which is much wider than 320x200/256, since the map is much bigger) isn't enough. Unless you want to greatly castrate the graphic assets.
Quote:

You made a big deal about the Metal Slug 3 truck asset's HAM color fringing,

Absolutely not. On the first article (which deeply analyzed Hamulet) it was MS3 was NEVER mentioned.

I've talked about it on the second article only because the author used one of its assets on the new demo. And, BTW, it was NOT only about the fringing but this example was used also for showing OTHER HAM limits. Read the article and you'll why.
Quote:

but this issue is not a big issue when this minor HAM color fringing is exploited as an extra "random" color shade. Don't expect pixel color perfection in the real world.

See above: never expected.
Quote:

Modern 3D games are exploiting less-than-perfect variable shader resolution and fake pixels via motion vector-temporal pixel reconstruction. Hollywood's MPEG to H.265 is not about pixel-perfect i.e. in motion, it's less noticeable.

HAM introduces WAY WORSE artifacts. Anyway, see above.
Quote:

Quote: Which is exactly the reason why almost all games AVOIDED using HAM. For most games in the late 1980s and early 1990s, Amiga's joint game development with Atari ST is a major factor. Games from Bitmap Brothers have Atari ST's 16-color artwork optimization baseline.

It's not only about the colour palette: FREELY movable objects is the MAIN issue with HAM.
Quote:

Amiga's Links Golf game did NOT factor in Atari ST i.e. this game is only PC VGA and Amiga HAM6 consideration. Amiga's Links Golf game is not pixel-perfect with PC's VGA version, but it's a good enough approximation.

That's the only exception because you've only ONE object (the player) which is being displayed, and very likeky using the sprites for it (see above).
Quote:

Many Amiga's point-and-click adventure games have Atari ST artwork consideration.

Those could be ported in HAM, because usually they have just one freely movable object around (the player + the mouse pointer).
Quote:

PiStorm-Emu68 CPU enhanced Amiga's HAM6 mode Quake is not pixel-perfect with PC's Quake 256 color VGA, but it's a closer approximation when compared to the 64-color EHB version. It's known IBM VGA (1987) is very slow despite throwing 1.8 Ghz K7 Athlon XP 2200+ at it.

PiStorm wasn't available at the time.
Quote:

https://en.wikipedia.org/wiki/Hold-And-Modify Amiga HAM is considered to be pixel compression like JPEG and MPEG.

I know very well HAM, JPEG and MPEG.

BTW I've written a JPEG 2000 decoder in (castrated) C (to be implemented in hardware) for STMicroelectronics for my internship + thesis when I got my degree in CS. I know very well the topics and the literature about all this stuff (BTW, my decoder was super resilient to errors in images. Both the references, JASPER and the Validation Model, had many severe failures and the latter even crashed with some image).
Quote:

Hammer wrote: @cdimauro Quote: Sure. And I'm Donald Trump wearing a Che Guevara T-shirt... Your assertion is nonsense. You started the personal attack instead of focusing on the issue at hand.

What's not clear to you that I started giving you ALL relevant information but you CONTINUED to write non-sense?
Quote:

Quote: Constant?!? On you FIRST comment I've replied with this: No, it doesn't: read carefully the article (and the first one, albeit it's in Italian. But you can easily translate it). Presenting your argument in the expected language is your problem.

Again, the last article was IN ENGLISH. ENGLISH! Only the first one was in Italian and even a complete idiot nowadays can easily translate it in English with VERY GOOD quality (e.g.: DeepL. Which I've SUGGESTED).
Quote:

Quote: 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. Which should have been clear enough, right? But no: you decided to completely IGNORE it and REPEAT like a PARROT your complete non-sense. What else do you expect from me? A prize for your load of balls? You assumed and you're wrong.

I judge what I see, what you've written.
Quote:

Quote: Obviously I've read this BEFORE writing my articles. Do you have some idea about such "clever restrictions on the background"? Because I've some (of course). However, I'm curious to know what's YOUR opinion, dear "coder"... You made a big deal about the Metal Slug 3 truck's HAM color artifacts when pixel-perfect replication is not mandatory. The goal was to display more colors.

See above: already replied.
Quote:

HAM is a lossy compression and there's a cost for it i.e. there's no such thing as a free lunch.

There are different thresholds for acceptable color artifacts. [/quote]
Sure, and my first article has already exploited all topic. Care to finally read it?
Quote:

From my POV, the Metal Slug 3 truck's HAM color artifacts are minor, and it has unique "retro Amiga" characteristics like an LP record. Amiga retro scene makes the Amiga market alive.

If a graphic artists like to see his/her work deformed this way...
Quote:

Most Amiga users have a modern PC, an Android, or an Apple iOS/MacOS X device. With HAM color compression, I don't expect pixel-perfect replication.

Me neither, but it has OTHER, BIG limits (e.g.: FREELY movable objects).

Now you've ALL technical information: you can pick any game and check yourself what game could be converted or not.

Hint: Laisure Suit Larry VGA. I had a discussion with an Italian guy on FB about it, and after deeper technical analysis it looks feasible (e.g. main character = sprites + mouse pointer).

@Karlos

Quote:

Karlos wrote: @Hammer Protip: Professional software engineers never describe themselves as a "coder" in relation to their day job.

That depends entirely on context. As a person who professionally assign people to projects that also involve “software engineering� (whatever that really means), someone who calls himself a “coder� stands out in the vast masses of “software engineers�, “programmers� and “developers�. Good honest “sysadms� also stand out among all “solution architects� and whatnot. :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

What’s your purpose with all this? Prevent that anyone waste their precious time attempting to accomplish something "impossible�, because math? Maybe boost your CV with online articles? And whatever your purpose is… are you succeeding?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I've yet to meet any software engineer who described themselves as a coder, beyond how they started off writing software in their bedroom. Obviously context matters, a forum isn't a job interview, but it still sounds rather amateur to describe yourself as a "coder", especially if you work on something serious like legal software.

_________________
Doing stupid things for fun...

@cdimauro

The demos people have created using HAM mode are quite impressive considering HAM mode's limitations. It's nice to see people still coming up with new ways to use it.

Ages ago I was also thinking about how to use HAM mode in a game. I came up with a few ideas which I never had time to try out.

First, HAM bobs could be made whose left-most pixels use the base palette (left-most in the shape, not the rectangular region). To stop the smearing on graphics underneath, you'd need an additional bitplane marking the pixels on the right-side of the bob shape. This would be used to replace any pixels below with the closest base palette colours to minimise the errors. Yes, this means that all imagery would need to have a second copy using the base palette. You'd need a lot more RAM and some additional processing power to pull this off. The memory and processing power required could be reduced a bit by storing the base palette version without the control bit-planes (you can use the right-side mask to set the control bits to the right value).

Next idea: Use superhires mode, and treat every 3-4 pixels as one super-pixel (either GRB, or base-colour & then GRB). The graphics could be created at full superhires resolution, but everything would move at a multiple of the "super-pixels" to minimise any colour errors. The control bitplanes would be fixed to the pixel colour pattern, so only 4 bitplanes would need to be stored for imagery (or 6 if you dare to try HAM8). Hopefully the squished horizontal pixels would make colour errors less obvious. Oh, and you'd need to hope that superhires doesn't eat up too much of the chip-RAM bandwidth.

EDIT: Updated the colour channel order to GRB, which puts them in order of decreasing eye sensitivity. Also, the 4 pixel mode using the base colour probably isn't a good idea.

With the scheme above I'd actually prefer to use a bayer pattern to minimise visible vertical lines, but I'm not sure how practical that would be. Maybe if you used super-hires interlaced mode, then you could have different control-bit patterns on alternate lines.

Hans


P.S., I remember reading that they did originally use YUV when developing the original chipset, but switched to RGB late in the design because it was becoming the de-facto standard. They left HAM mode in, but thought it was rendered useless (i.e., they didn't expect people to use it).

Last edited by Hans on 05-Feb-2024 at 06:14 AM.
Last edited by Hans on 03-Feb-2024 at 12:11 PM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@kolla

Quote:

kolla wrote: @cdimauro What’s your purpose with all this?

Fun.
Quote:

Prevent that anyone waste their precious time attempting to accomplish something "impossible�, because math?

Sure. When I become god I'll add the 11th commandment: "Don't use the HAM mode!". And if you do it, then you'll be burned by the renewed "Saint" Inquisition.

In the meanwhile and thanks to my generous magnanimity, I allow people to do whatever they want: even creating games using HAM (what a blasphemy!)...
Quote:

Maybe boost your CV with online articles?

Have you read it? Do you think that my CV needs anything else to be added? And, specifically, references to articles like those?
Quote:

And whatever your purpose is… are you succeeding?

I'll tell you once I become god.

Then I can read the minds of people and see if coders (!) are still thinking about using HAM for games and also customers that are daydreaming about such HAM games.

I'll create nice charts with statistics reported about such infidels and I share to you, for your happiness...

@Hans

Quote:

Hans wrote: @cdimauro The demos people have created using HAM mode are quite impressive considering HAM mode's limitations. It's nice to see people still coming up with new ways to use it.

Indeed. Albeit... demos... are demos: that can do fancy things that impress people, but once they are done... it's over.

This is why I always preferred games to them.
Quote:

Ages ago I was also thinking about how to use HAM mode in a game. I came up with a few ideas which I never had time to try out. First, HAM bobs could be made whose left-most pixels use the base palette (left-most in the shape, not the rectangular region). To stop the smearing on graphics underneath, you'd need an additional bitplane marking the pixels on the right-side of the bob shape. This would be used to replace any pixels below with the closest base palette colours to minimise the errors. Yes, this means that all imagery would need to have a second copy using the base palette.

Unfortunately this will stil produce fringing, and sometimes quite evident, because the pixels starting just to the right (letting X being the position of the pixel just after the right border of the BOB) of this one are "linked" to the background colour at position X.

Ideally you need 4 more copies of the background to sort out those issues, each one with a different starting point for the base colour (plus the 3 following pixels handling the smooth transition to colour at pixel position X + 4. They can either change a colour component or setting a new base colour, depending on the specific context / part of the image).

To go more on details, you need a "map/copy 0" where you've a base colour at (position % 4) == 0. "map 1" have a base colour at (position % 4) == 1, etc. for maps 2 and 3.

For the BOB you don't need an additional mask, but an array of bytes (depending on the height of the BOB) telling the x coordinate (offset inside the BOB, in reality) where the base colour should be changed (so, it's the above mentioned "X" coordinate).
Once you calculate X, then you can select the proper map (X % 4) and you can finally do a cookie-cut operation starting from position X and going to position X + 3, just copying the content of the selected map to the framebuffer. You don't need a mask in this case, because it can be generated on the fly (you need to copy 4 subsequent pixels starting at a certain position).

This allows a much smoother transition from the right border of the BOB. However it's very expensive memory wise.
The good thing is that it requires just one cookie-cut operation (once you've selected the copy) but... per scanline. Because you've to repeat the operation for each scanline, because the pixel at right border of the BOB usually changes. So, it's CPU-intensive.

That's not the best solution, of course, but the one which comes closer.

The best is the usual one: you've to calculate the 3 pixels that make the transition, starting from X, but using the BOB's colour at position X - 1. The solutions are expensive, both memory and CPU-wise.
Quote:

You'd need a lot more RAM and some additional processing power to pull this off. The memory and processing power required could be reduced a bit by storing the base palette version without the control bit-planes (you can use the right-side mask to set the control bits to the right value).

Yes, that requires less memory. But, as I've said before, this solution will still present artifacts, even evident ones, because just setting a new base colour at position X doesn't take into account the original background colour at the position, and the 3 pixels following will be affected by it.
Quote:

Next idea: Use superhires mode, and treat every 3-4 pixels as one super-pixel (either RGB, or base-colour & then RGB). The graphics could be created at full superhires resolution, but everything would move at a multiple of the "super-pixels" to minimise any colour errors. The control bitplanes would be fixed to the pixel colour pattern, so only 4 bitplanes would need to be stored for imagery (or 6 if you dare to try HAM8). Hopefully the squished horizontal pixels would make colour errors less obvious.

That's what I've stated replying to someone in FB: using high resolution the fringing is less evident. With super-hires, even less, of course.

However SHRES is a monster to handle (see below).
Quote:

Oh, and you'd need to hope that superhires doesn't eat up too much of the chip-RAM bandwidth.

In HAM8 basically you've no slots available when displaying the screen. With HAM you've at least 25% of them.

This means that there's really too little bandwidth for producing something usable, if you consider that you've to move quadruple the graphics compared to the LORES.
Quote:

With the scheme above I'd actually prefer to use a bayer pattern to minimise visible vertical lines, but I'm not sure how practical that would be.

It's not practical, because it requires properly shifting horizontally the graphics to be cookie-cut, and this should be done per scanline.

However and since the Bayer pattern repeats (I don't recall now if it's after 2 or 3 pixels), then you need only 2 or 3 blits in total for having the work done.
Quote:

Maybe if you used super-hires interlaced mode, then you could have different control-bit patterns on alternate lines.

I would strongly avoid using interlace mode with games: I care about people's eyes.
Quote:

Hans P.S., I remember reading that they did originally use YUV when developing the original chipset, but switched to RGB late in the design because it was becoming the de-facto standard. They left HAM mode in, but thought it was rendered useless (i.e., they didn't expect people to use it).

That's a pity. Yes, RGB was becoming the standard, but YUV would have given to the Amiga a net advantage.

BTW, YUV is still supported, even with HDMI. Let the monitor/TV handle the conversion to RGB, since it can already do it.

P.S. No time to read again.

@Karlos

To me, "software engineer" is a quite vague and wide term, while "coder" suggest someone who has quite particular skill in a particular field, often very close to the hardware and with very limited resources. Web frontends and apps are software engineers, while firmwares and device drivers for the OT market is more "coder" material.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I've worked on everything from embedded systems, device drivers, application software, distributed systems enterprise software. You don't have to be a self professed "coder" to write software that runs in kilobytes on a tiny MCU or a cloud solutions architect to write distributed auto scaling systems that run "in the cloud". You just need to be a good engineer.

_________________
Doing stupid things for fun...

@cdimauro

How does a software engine work? I image it most be tiny to fit inside a computer.

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

@Karlos

Working on support, talking to engineers, and other people working on mechanical things, I’m quite use to people pulling cables destroying plugs, they normally have little knowledge about electronics.

so I do not really understand why software developers are being called engineers, after all it has nothing to do with engines.

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

@kolla

It seems to me titles are mostly used to discredit people with different educations or experience,
the title is not required to be a developer, there self-taught developers, and people background in electronics or come from background with economics. Sure, education is an advantage, but its experience, the number of hours you practice, and if you have the skillset that a developer should have. To progress as developer people must be willing to acquire new knowledge, be logical, being interested in math’s, being good at understanding your customer, if you do not understand criticism or feature requests, you are not going to produce a good product. You need to be a good team player if you are a professional developer, you can’t always be right. And know the tools of your craft.
Developers comes in many shapes and forms, and many languages, designed for different things.

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