Hamulet test - Large HAM bobs

[carlosgod]

Originally Posted by Tsak

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



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

Yeah, I suppose I was overreaching a bit. I would love to see a bullet hell HAM game on the Amiga one day though.

Amiga pixel art was interesting in the sense that there wasn't as much quality control as the Japanese counterpart. So you had really nice stuff coming from the likes of Team 17 Project X pr Psygnosis Shadow of the Beast series (which is almost on par with SNES or Arcade shooters/platformer) to say Street Gang or Guardian Angel which looks like it was drawn by a child.

I personally blame Commodore for not doing as much as they could have done to help out Amiga game developers make the best use of their machine and create good quality games that is unique to the platform. Although Nintendo was extremely demanding on game makers that uses its platform, it also does a lot to help them push out good products.

Still, thanks to latest advancement in pixel art techniques and developers generally being more resourceful and knowledgeable nowadays, and people like Remz developing with new technical tricks, the 2020's could be a new golden age for Amiga gaming - a good thirty+ years after the fact!

[lmimmfn]

This has a lit of potential in Gauntlet style games, where the blocks don't need to be overplayed with player characters or enemies, and additionally even better would be some end of level bosses in a game, ideally with scrolling and turning white/yellow when a hit impacts.
Looks fantastic BTW, I love evolving the use of HAM, back in the day it was thought to be too expensive in games, let's orove them wrong!!!

[albino]

I was wondering which 16 bit machines, could display so many colors on screen in ideo games at that time?

[tygre]

Truly awesome!

[carlosgod]

Originally Posted by albino

I was wondering which 16 bit machines, could display so many colors on screen in ideo games at that time?

No 16 bit machine can do this, except the Neo Geo which was touted as 24 bit though it's really 16 bit main CPU + 8 bit add on auxilary. The Neo GEO can do 4096 colors with a lot of restriction out of a palette of 65536

https://en.wikipedia.org/wiki/Neo_Geo_(system)

In reality though - and this is my personal take - having thousands of colors on the screen at the same time may work well for say paintings, photoscan (Amiga HAM parrot / HAM scarf woman) or pixel art of complex scenery or objects , but for 2D games there's a point of diminishing return. I think that optimal number is probably somewhere close to 1,000. Beyond that it starts to become a bit too much - otherwise the pixel artist needs to really know what he/she is doing with all these colors. Take Lionheart for example, which uses copper and other neat trick to display upto 600 colors at the same time (supposedly) - that's probably as colorful a 2D game as you can get away with without cluttering the screen. Hamulet keeps everything nice and clean too and I'm sure that took a lot of effort.

Of course, HAM mode would work wonders for those Amiga point and click adventure games - provided there is enough storage available to store all those massive pictures. Myst in OCS HAM mode would be interesting!

[rabidgerry]

Originally Posted by 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.

Well there is this game which I believe is using Ham Modes. Looks pretty good to me, and quite smooth. I wish there was an English version though.


[ Show youtube player ]

[pixie]

I think AB3D also used HAM

[Karlos]

Originally Posted by pixie

I think AB3D also used HAM

Not exactly. It was a pseudo RGB mode based on copper tricks. Nevertheless, it was 4096 colours still.

[jotd]

HAM modes are often noticeable by the bleeding. Not here. Superb job.

[Photon]

The reason why HAM hasn't been used much is because most developers have a game idea, and implementing it means they have to move objects. HAM means a mostly static world; leaves no visual processing room for much more than scenery.

However, if you change or limit the game idea instead, to not require much movement and make objects in the game less interactive, you can blit changes when the animations change, as opposed to every frame, and use only sprites and scrolling for the rest, as in e.g. Marble Madness or most fighting games.

Do you blit the objects in this demo?

[pixie]

Originally Posted by Karlos

Not exactly. It was a pseudo RGB mode based on copper tricks. Nevertheless, it was 4096 colours still.

Well, that even more impressive still!

[Karlos]

Originally Posted by pixie

Well, that even more impressive still!

Quite, though the resolution was understandably limited. It's also one of the reasons that the 2MB version of TKG doesn't look as good, since I believe it's still restricted to 256 colours.

[buzzybee]

Originally Posted by carlosgod

In reality though - and this is my personal take - having thousands of colors on the screen at the same time may work well for say paintings, photoscan (Amiga HAM parrot / HAM scarf woman) or pixel art of complex scenery or objects , but for 2D games there's a point of diminishing return. I think that optimal number is probably somewhere close to 1,000. Beyond that it starts to become a bit too much - otherwise the pixel artist needs to really know what he/she is doing with all these colors. Take Lionheart for example, which uses copper and other neat trick to display upto 600 colors at the same time (supposedly) - that's probably as colorful a 2D game as you can get away with without cluttering the screen. Hamulet keeps everything nice and clean too and I'm sure that took a lot of effort.

Lots of colors also benefit dynamic shading and lighting. But again, this works best with a versatile graphics subsystem. On AGA, using 16 color regs for the main palette, and the remaining colors regs as alpha channel works well for displaying clean visuals with beautiful animated shading. What would be possible with HAM or even HAM8 is certainly worth exploring.

[vulture]

@rabidgerry

Yeah Ubek! Supports both HAM6 and HAM8 iirc! Played it a little when it came out on my 030 A1200, it was great looking back then!

[nonarkitten]

In ECS/OCS for moveable HAM bobs:

For all background tiles ensure every other pixel is a palette colour. If you want to be a little fancy, you could checkerboard it. Pick a really good base 16-colour palette that covers a good range of the spectrum.

This gives you 15 * 15 * 3 = 675 colours for the background plus one for a copper list. So potentially 1000-ish colours? Just for the background. Yes, there's fringing, but at worst it should be only one pixel and shouldn't be too noticeable.

For foreground bobs you KNOW will not be drawn over, you don't have to follow this limitation, so those can utilize the full 12-bit range. This would have the same DMA load at any other 6-bitplane screen.

If you want to squeeze out some more DMA you could use the 7-bitplane trick. But I don't think the loss of chip RAM and colours makes it worth the 100% boost to blitter time.

[nonarkitten]

If you're going AGA, go hires HAM6, set the control bits to repeat the same line that's just the RGBG pattern over and over. This means it's only really using 4 bitplanes for everything and even though you're hires, with the FMODE cranked, you're using less DMA than 6 bitplanes on ECS. The trick is that you need four copies of every sprite in each shifted pattern, so X&3 = 0:RGBG, 1:GBGR, 2:BGRG, 3:GRGB.

Then you just do everything normally. This gives you a full 4096 colour HAM screen with very little fringing (no compensation needed) and the possibility of adding all sorts of special blending effects. And being hires it hides a lot of the fringing as well -- it's basically a 12-bit lowres mode.

Caveat: obviously, you're also potentially blitting a lot more data around. So even if the screen is using less DMA, your blits could still choke.

[rabidgerry]

Originally Posted by vulture

@rabidgerry

Yeah Ubek! Supports both HAM6 and HAM8 iirc! Played it a little when it came out on my 030 A1200, it was great looking back then!

It is very smooth also! But I struggle using a translator app on my phone to try and translate the text on screen I also have an issue making Ham 8 full screen, it turns into a postage stamp for me.

[Karlos]

If you want to see what HAM8 can do with enough CPU power, I recommend Mateusz Staniszew's "funtime raycaster"...

[ Show youtube player ]

RGB, Mip Mapping and shadow maps.

I'd like to see that on a PiStorm.

[Thorham]

Very impressive

[alexh]

Impressive

Originally Posted by Karlos

I'd like to see that on a PiStorm.

https://github.com/mateusz83/msRay