HAM game existing ? possible ?

[thellier]

Do you know is there Amiga game(s) in Ham mode ?

Yes I know the limitations (fringing,etc..) BUT it is theorically possible to correct the bad pixels with the CPU (like photon paint did) in real time

Typically a game like Street Fighter may be done in HAM
- A simple background picture in HAM
- Two big (not hard) "sprites" that will have fringing on their right side but only this right "edge" will need a fix on a 100-200 pixels height so possible


Alain Thellier (Wazp3D)

[demolition]

AFAIK HAM modes use most of the CPU power just to display the picture, so there wouldn't be much left to actually run the game. Perhaps some kind of board game could work?

[Leffmann]

No CPU overhead to displaying HAM, it's a real graphics mode implemented entirely in hardware. The CPU would never be able to calculate all that in realtime.

There's a game called Kang Fu that supposedly uses HAM for the background graphics:

http://hol.abime.net/2545

[zipper]

Some Aminet games do use HAM FMV videos. HAM is used here: http://main.aminet.net/pub/aminet/ga...c/anoid.readme
HAM gfx are used in several games, card etc.
More: http://eab.abime.net/looking-game-na...-ham-mode.html

[bubbob42]

There has been one HAM game made in 1987 or 1988. I can't remember the name, something with P...

HAM6 had been used throughout the whole game, not just intro screen.

[lilalurl]

http://hol.abime.net/hol_search.php?..._quickmatch=81

[demolition]

Originally Posted by Leffmann

No CPU overhead to displaying HAM, it's a real graphics mode implemented entirely in hardware. The CPU would never be able to calculate all that in realtime.

Great, then I learned something new today as well.
But surely it would be difficult to modify this HAM image in realtime if you wanted to use it for more than a background.

I remember using DPaint in HAM on a 500+ and while in that mode, you could almost see it draw each individual pixel one by one, that's how slow it was. I do remember seeing a video of someone being able to do FMV in HAM mode with 10+ fps on a plain 68k.

[s2325]

Thank you, these trees in golf game is proof that HAM mode in games may not be the best idea.

[Rebel-CD32]

Those trees looked pretty messy in the 256 colour PC version as well, so it's not really a problem with using HAM. The bloke is using sprites, so he doesn't have any HAM fringing. I think Links is a great example of how to use HAM properly. Also check out The Labyrinth of Time, which is installable on hard drives and runs on OCS Amigas in HAM mode. It's free and can be downloaded from Aminet: http://aminet.net/package/game/role/LABAMIGA

[s2325]

Zool CD32 have intro in HAM mode: http://s3.img.suchar.net/FiLrjeiZRFx...WvrNBWlQuZ.jpg

[robinsonb5]

Originally Posted by demolition

Great, then I learned something new today as well.
But surely it would be difficult to modify this HAM image in realtime if you wanted to use it for more than a background.

Yes, it's difficult, mostly because the data's in planar format. I think the most practical way to achieve this would be to have the sprite and background data stored in both chunky and planar formats, to draw most of the sprite using the blitter, then recalculating the rightmost part of the sprite in chunky format, and chunky-to-planar converting just that region of the screen. Damn, now I wish I had time to try it out!

Also, it's possible to do a low-resolution true-colour chunky screen in HAM mode, by setting the control planes to a repeating pattern of "modify-red, modify-green, modify-blue", and doing 4-bit chunky-to-planar on just the data planes. The result is a little blurry, but can be effective.

[mc6809e]

It's too bad hardware sprites are so limited. It would be nice to have larger and more colorful sprites on top of a HAM background. No fringing with that.

It might be possible to get five or six 16-color sprites per scanline in HAM if the CPU does a MOVEM into the sprite registers at the right time after DMA driven sprites are displayed. I think 14 sprites per line are possible if one is willing to use 3-color sprites.

Positions of the sprites become somewhat limited, though.

[NovaCoder]

I was trying to code a shoot'em up using HAM8 at one point. I realized a few things about HAM.

1) You need to fill up the whole raster line with color for it to work
2) The CPU hit is in working out what to the color values should be, not in the actual rendering.
3) To maintain the original chunky screen resolution you need to open a screen which is 4 times wider.
4) Working with HAM8 is painful

I spent a few weeks on this and didn't really get anywhere so I did the decent thing and just gave up on the project

[lost_loven]

I loved links back in the day! gonna have to check it out again!

lost

[Thorham]

Originally Posted by thellier

Typically a game like Street Fighter may be done in HAM
- A simple background picture in HAM
- Two big (not hard) "sprites" that will have fringing on their right side but only this right "edge" will need a fix on a 100-200 pixels height so possible

That's perfectly feasible. A 25 Mhz 68020/68030 with some fastmem can do that.

Originally Posted by NovaCoder

1) You need to fill up the whole raster line with color for it to work

You don't. You only have to correct the right edge of blocks of pixels you paste. You need to set at most two HAM pixels per edge for that.

Originally Posted by NovaCoder

2) The CPU hit is in working out what to the color values should be, not in the actual rendering.

Indeed. In good quality that will work out to about 120 cycles per pixel on a '030. Seeing how you only need to correct edges, this might not be a problem, though.

Originally Posted by NovaCoder

3) To maintain the original chunky screen resolution you need to open a screen which is 4 times wider.

Only if you use 4x1 pixel modes. When you do edge corrections, you only need 1x1.

Originally Posted by NovaCoder

4) Working with HAM8 is painful

It's not so bad when you know what you're doing

[NovaCoder]

Hiya Thorham,

Yes I've looked at your 1x1 HAM picture viewer code, you sent it to me once

The best ever realtime HAM8 conversion I've seen is still the good old STORM dither from MooVid/Action. You can see it in this video at 5:20 -> [ Show youtube player ]

[thellier]

@NovaCoder

In fact I already have a solution about the "right edge fringing" :

Lets expose the idea:
A game like Street Fighter in HAM
- A simple background picture in HAM
- Two big (not hard) "sprites" in HAM that will have fringing on their right side but only this right "edge" will need a fix on a 100-200 pixels height so possible
The "sprites" will be all outlined with black
so assume we have a line like this after we have drawn a sprite

bbbbbbbbbbbBssssssBfffbbbbb

b = background
B = sprite black outlining
s = sprite pixels
f = "right edge fringing"

As the "sprite" was designed with the black outline builtin so there is no "left edge fringing"
So there is only a "right edge fringing" from black to current background color because black is too different from removed pixel
But this fringing may be fixed by using an HOLD palette color for this pixel (approximating the removed pixel)

So the method
==> for each background color pixel have the better "HOLD palette color" for this pixel
<==> have a "correction map" maded with only "HOLD palette color"

So draw a sprite
Have a (pre-made) list of left edge pixels (x1 y1,x2 y2,x3 y3...) for this sprite
for (all pixels in edge)
copy the pixel at x y from "correction map" to background image so fix all defaillant pixels

"Et voilà un jeu en HAM"

Alain Thellier (Wazp3D)

[Thorham]

Originally Posted by thellier

bbbbbbbbbbbBssssssBfffbbbbb

b = background
B = sprite black outlining
s = sprite pixels
f = "right edge fringing"

You're forgetting that only two pixels will fringe, because the third HAM pixel will set the third gun color and have exactly the right color if the previous two pixels set the other two gun colors

I like that sprite idea to mask the fringing pixels As said, you only need to correct two pixels (really!). You can set the sprite colors in the border to be exactly the same as what those two fringing pixels have to be, and get perfect masking for all fringe pixels... or is that what you meant?

[thellier]

>only two pixels [...] if the previous two pixels set the other two gun colors
You talk about a special case : a picture made like this hamr,hamg,hamb,hamr,hamg,hamb,hamr,hamg,hamb,...

With a "standard" ham image n pixels may fringe
But n is not important: most important is WHY it fringe ?
= Because the right edge color has been removed
So if the first fringing pixel is replaced with the "nearer" palette color then fringe will be minimized


Alain

[hooverphonique]

but if you just replace the first fringing pixel with the "nearest" palette color, the rest of the scanline will be slightly off, and this will be very visible and degrade the quality of the background to the right of the sprite significantly..

An idea might be to have the background only use 15 palette colors and then reserve the last for the first fringe pixel, calculating and setting this palette color each scanline.. that way, you can restore the color of the first fringe pixel to the exact same color it had originally, and then you don't even have to modify the right edge pixel data dynamically. This solution only works for 1 sprite per scanline, of course, but you could reserve more colors or modify the reserved color several times per scanline (presuming non-overlapping sprites).