Hamulet test - Large HAM bobs

[Jobbo]

This looks really nice!

I'm curious how you've handled the blitting so it avoids fringing.

Normally the right edges would start a fringe unless the background pixel is using an indexed color.

So one approach is to just use indexed colors only for the background. But this doesn't look to be so limited?

The alternative most general solution requires fixing up the right most edges somehow.

Anyway, would be interested to learn about the details.

[roondar]

This looks awesome!
Great stuff

[carlosgod]

Originally Posted by remz

Hello coders,

While still working on Hamulet, I was experimenting with the possibility of drawing HAM bobs and wondering if this has been attempted before:
I captured a short video snippet at 50 fps to show a sort of proof-of-concept, running on Amiga 500 OCS (1MB chip) here.

One of main concern of HAM bobs is the large amount of chip memory they require, but also how to manage fringing. You can see in my video that the fringing is barely noticeable. However, my 'bobs' are not moving: they are stationary. In this state, their usage in a game would be mostly for animated stationary objects, or other innovative ideas.

Amazing work as always - though this goes to a whole different level! I genuinely thought that I was looking at a SNES or PCE game when I first saw the video, before noticing your trademark Hamulet character Amy. If only Commodore had the brains to market this capabilities to game developers back in 1985...

Having said that, I have a few questions after seeing this demo:

1. I'm curious how you solve the fringing issue for Blitter vs background... is it because they are manually positioned in such way that it doesn't fringe with the background? Or you can place those Blitters anywhere and your program automatically solve the fringing problem?
2. Does your HAM6 Blitter have the same movement restriction as your multiplexed sprite (i.e. they can only move sideways?) Or do you think you'll be able to move them around the screen with no issues at all?
3. What are your plans on dealing with all the memory that these gigantic HAM6 Blitter gobble up?
4. Do you do all the artwork yourselves? That's some really amazing pixel art skills!

Thank you and again, really great work. Glad to see someone is still pushing the limits of the OCS Amiga instead of skipping over to AGA (which a lot of people seem to be doing nowadays, sadly)

[sovenyimre]

You are using indexed colors to ourtline bobs(right side)?...then you can use HAM inside the outlined bob. If the (playabe area of the) background is outlined as well with the same 16 color .... it will not fringe at all when you move around?
Am I geting it right?

[ovale]

My best guess is that the animated ham bobs include the background. The background is optimized to do not fringe. This is why they do not fringe and cannot be moved. Indeed, the only place where it fringes is where the index color is changed by the copper and this is not baked into the animation. Player and small objects are sprites.

[Jobbo]

Originally Posted by ovale

My best guess is that the animated ham bobs include the background. The background is optimized to do not fringe. This is why they do not fringe and cannot be moved. Indeed, the only place where it fringes is where the index color is changed by the copper and this is not baked into the animation. Player and small objects are sprites.

That makes sense. And if so then since those are just copy blits they're not going to be super expensive.

[earok]

I had this idea for moving the ham bobs around without (much) fringing that's pretty crazy *but* could possibly work in very limited scenarios.

Say the same effect for covering up fringes on the left side of the screen is used for covering up fringes on the right side of bobs. Which is to say, just the right 16x pixels of the animated actors is actually a sprite.

There are a bunch of obvious problems with this, which include:
- The limited number of sprites available
- The limitations on sprite colors which would to some degree defeat the purpose of having a HAM bob at all (but this would only be restricted to the right most 16 pixels regardless of how big the bob is, and you could alternatively make it so the sprite was only the right border and a few more pixels than that)
- Unless the sprite had a completely flat edge, less than 16 pixels would be covered on at least some parts of it.

Again, some big limitations there, but I could see it working in very well controlled and designed scenarios where there's a big bob moving around with the right edge made out of a sprite.

[Gzegzolka]

Looks very colourful, I wonder could action be build on that or all power was already used to display those stuff.

[remz]

Originally Posted by carlosgod

Amazing work as always - though this goes to a whole different level! I genuinely thought that I was looking at a SNES or PCE game when I first saw the video, before noticing your trademark Hamulet character Amy. If only Commodore had the brains to market this capabilities to game developers back in 1985...

Having said that, I have a few questions after seeing this demo:

1. I'm curious how you solve the fringing issue for Blitter vs background... is it because they are manually positioned in such way that it doesn't fringe with the background? Or you can place those Blitters anywhere and your program automatically solve the fringing problem?
2. Does your HAM6 Blitter have the same movement restriction as your multiplexed sprite (i.e. they can only move sideways?) Or do you think you'll be able to move them around the screen with no issues at all?
3. What are your plans on dealing with all the memory that these gigantic HAM6 Blitter gobble up?
4. Do you do all the artwork yourselves? That's some really amazing pixel art skills!

Thank you and again, really great work. Glad to see someone is still pushing the limits of the OCS Amiga instead of skipping over to AGA (which a lot of people seem to be doing nowadays, sadly)

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.

Thank you everyone for your comments and ideas! Now, back to work..

p.s.: Regarding Gzegzolka's question: This test is a bit of a 'stress test' to stretch the limit. The metal slug truck is so big (144x170 pixels: that's 18360 bytes per frame) that it can make the game skip a frame when horizontal scrolling.

p.p.s: trivia: the truck is 170 pixel tall, because this is the tallest vertical size that the Amiga blitter can do in HAM interleaved mode

[abu_the_monkey]

AMAZEBALLS!

[Tsak]

Great stuff @remz!

Honestly I see this and I feel a platformer would be a perfect match really. I.e. something with lush backgrounds and verticality. Instead of being shooter focused or with many moving-enemies on screen, it could be a course with hazards or stationary baddies (or ones with a short animation loop) with the main protagonist having loads of mobility and being able to perform a plethora of actions to get around (dashes, double jumps e.t.c.).

In regards to ram, I think levels don't need to be huge either, it could -as well- be just the size of what is showcased here, or have each level split to several similar screens (load in between) or even have single screens with no scrolling at all. Then depending on the available ram/performance in each scenario you could allocate resources accordingly to variation and eye-candy or animated obstacles and enemies.

Overall what is shown in the video also covers nicely what you can do with the moving stuff (using exclusively HAM bobs). F.e.

• Having animations in the background itself (no brainer and usable only as an eye candy, but really cool nonetheless).
• Having things the player can interact with, levers, doors opening/closing e.t.c. all these could be done with the Ham bobs being stationary.
• Having stationary or floating enemies with very short action and anim loops. Same for stationary animated hazards.

Other ideas you could try (not showcased):

• With smart usage of the tileset and setting up repeating background patters in places (and supposed the bobs are baked into said pattern) you can easily create the illusion of smooth horizontal (or vertical) movement if you also bake the actual object moving (as it animates) within this tile. Think f.e. a pit which repeats its background pattern every 48 pixels, you could add a rotating chainsaw disk into it, moving freely left and right just with a few frames of animation and by activating adjacent tiles as the disk moves. Same principle could be used with enemies as well, say the walking green monster you used. If he was baked into a background which can be seamlessly tiled horizontally, instead of animating it stationary, you could animate him moving leftwards within this tile. In which case he could cost the same amount of ram as he does now for a complete walk cycle (double if you'd like to turn him around).
• Same method can be used to expand the stuff your monsters could perform (with minimal frames upkeep as well), but you are forced to perform such actions from predefined positions only. Say f.e. a fast dash attack (3 frames cost), monster starts from the middle of the pattern and ends at the middle of the next pattern.
• Having more interactions with such tile based enemies is also not entirely out of the question. Like killing a moving enemy. Restrictions are the same as above, i.e. the death anim can only trigger from and to predefined positions. However it can be a legit method if you accept the delay in the reaction (depending on how the enemy moves and how he reacts, this delay could possibly be masked). Or it could be masked gameplay wise. Say f.e. again with this green enemy you use, moving around. He can only be killed if you push a large rock over his head. In this case the player is required to actually time his action and this happens in a specific place, so you only need a single animation of the monster getting crashed by the rock in this specific spot.
• Last idea is having some/selected enemies in actual blank backgrounds instead of them be pre-baked (just in front of your gradient or mono color). This can be done in specific small corners or platforms of the map, left intentionally blank. Depending on how large the actual enemy is and the amount of movement you want him doing (and the decoration around his movement area) it should be doable to make the fact he is only moving where there is no background not that obvious.

Overall I think all the above combined (and despite the restrictions) can cover a ton of cases for varied gameplay or gameplay mechanics. And this without even having to touch on sprites yet. You could use the sprites then exclusively for the player or for effects or even additional attached enemies (so there is not a massive rendering difference between sprites and HAM bobs). On the matter of platforming, enemies can also easily (and naturally) be placed to specific platforms/elevation and restricted there, plus (usually) you don't need a lot of them at the each screen, so multiplexing and using copper for more variation can get you a lot of mileage.

[carlosgod]

Originally Posted by remz

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.

Ah that makes sense. Yes, I guess you could have an a big helicopter or a dragon that's floating in the sky. I think someone mention lining up the Bob with sprite to hide the smudging effect if you can't stick to a plain color or gradient background.

https://www.arcadequartermaster.com/mslug/m1.1.png

Or may be something more basic like 1944 Loop Master - so the part where your P-47 Thunderbolt has to fight against a gigantic battle ship or tank - which is basically just moving up and down vertically.

[ Show youtube player ]

Wow, imagine that, a 1985 Amiga OCS doing a perfect arcade conversion of 1944 Loop Master - a game that came out on in 2000!

Originally Posted by remz

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.

True... CD32 would help solve that problem - though please don't abandon OCS - that's where the challenge/fun is!

Originally Posted by remz

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.

Ah that explains why it makes me think of those platforms!

[Rochabian]

Originally Posted by remz

I'll answer the tech questions here:

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.

+1 for this, would be great to see a good usage of the CD32 capacity to store & stream data. Only Microcosm has used it AFAIK.

Your work is incredible

[alexh]

Originally Posted by remz

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.

Sounds interesting. But why limit to CD32? This is 21st century and so being able to run from Floppy disk isn't a requirement these days. Most (all?) users will run from mass storage (HDD/CF/SD).

Even last generation OCS Amiga games (94) were intended to run from HDD (Ambermoon, Lucas Arts adventures etc.)

[AlphaAmiga]

Bobs like this would look amazing in some form of turn based JRPG game as they wouldn't need to move around inside the battle screen OR a deck building rogues that you see on consoles/PCs like Slay the Spire or Darkest Dungeon

[Predseda]

Originally Posted by alexh

Sounds interesting. But why limit to CD32? This is 21st century and so being able to run from Floppy disk isn't a requirement these days. Most (all?) users will run from mass storage (HDD/CF/SD).

Even last generation OCS Amiga games (94) were intended to run from HDD (Ambermoon, Lucas Arts adventures etc.)

I second that.

[DisasterIncarna]

Originally Posted by AlphaAmiga

Bobs like this would look amazing in some form of turn based JRPG game as they wouldn't need to move around inside the battle screen OR a deck building rogues that you see on consoles/PCs like Slay the Spire or Darkest Dungeon

heck even a more modern version/recreation of something even more simple and less demanding like Klondike Deluxe could benefit, always liked that game, hated the fact the game cant be promoted to rtg or more modern screenmodes/aspects.

if you also look at "modern" games that intentionally go with the retro look/feel then you could even maybe do something like BackPack Hero, Darkest Dungeon, Gunpoint, Shadows/West of Loathing, FTL, Plague Inc, Geometric Sniper, Let Them Come, Soda Dungeon and probably countless more less screen intense games that may be possible.

[Tsak]

Originally Posted by carlosgod

[ Show youtube player ]

Wow, imagine that, a 1985 Amiga OCS doing a perfect arcade conversion of 1944 Loop Master - a game that came out on in 2000!

Shooter games like that are not a good match for such an engine as they require moving a ton of objects over the background and have them at random positions with full interactivity. While it could probably do the backgrounds fine, sprites simply are not enough to render everything else (player, enemies, bullets, effects e.t.c.) and looking as good.

In general whatever game assumes/requires many high color-objects moving over an equally colorful background freely is a hard 'no' here (unfortunately).

Originally Posted by DisasterIncarna

if you also look at "modern" games that intentionally go with the retro look/feel then you could even maybe do something like BackPack Hero, Darkest Dungeon, Gunpoint, Shadows/West of Loathing, FTL, Plague Inc, Geometric Sniper, Let Them Come, Soda Dungeon and probably countless more less screen intense games that may be possible.

I was looking today at @remz's example and realized just how much more impressive it becomes when using actual good art. Damn, how freaking awesome Amiga was and how ahead of its time really? I mean HAM was a very known feature but extremely underappreciated/underused. The few games that used it (say Knights of Crystalion) are really lacking in the artistic department, which undersells the tech severely. In reality the machine could easily host gfx that are technically above what VGA could do, or even reaching 2D gfx quality from Neo-Geo to PS1 and Saturn. Even modern, high color pixel and digital art.

Makes you realize that one of the platform's biggest issues was not actually technical, but lacking on artistic talent, manpower and big budgets which would be necessary to produce high level gfx and animations like that (and loads of them).

[saimon69]

Originally Posted by Tsak

Makes you realize that one of the platform's biggest issues was not actually technical, but lacking on artistic talent, manpower and big budgets which would be necessary to produce high level gfx and animations like that (and loads of them).

The tools count too: not too sure on OCS (i think Photon Paint used that principle) but on AGA programs like TrueBrilliance and Photogenics were game changers for manipulate HAM pictures by working in 24 bit; i remember trying to do stuff on Digipaint and the fringing was making me go crazy -_-

[vulture]

I suppose a first person dungeon crawler could also be made out of this, since foes tend to be basically big, static and animated.