Is it possible to use HAM8 on AGA-Amigas to archive a Pinball-Game like Pinball Dreams, Fantasies, Slamilt..etc.

As we know the Scrolling on Pinball-Games are only vertical, so we avoid the HAM8-Pixel-Bleeding that happen when scrolling it horizontal.
Are Sprite(Multiplexer) over HAM8 working without that Pixel-Bleeding?

So in 320x200(256 in Overscan) LORES we don´t need all vertical lines for calcualtion, because on top or bottom we have the Scorebar which must not HAM8.

Is a stock A1200 (68EC020/14 Mhz, 2 MB Chipram) powerful enough for this in theory?

Last edited by fingus on 25-Oct-2021 at 11:51 AM.
Last edited by fingus on 25-Oct-2021 at 11:47 AM.

_________________
I´m back in 2023 on Classic Amiga with my A1200/Blizzard1230IB@50Mhz, 32MB RAM, AmigaOS3.2 and ROMs, Indivision AGA MK3, Author of Amiga-Flipclock (OS4)

@fingus
Interesting idea. In theory this should be possible but not easy.
There's usually lots of blinking stuff which you cannot do with simple color register changes anymore (only true if you want to exploit HAM8 colors to the max, see EDIT), so you'd have to redraw / blit quite some stuff which may become a) performance problem and b) tricky to draw to avoid HAM artefacts. This is also true for animations like bumpers and the flippers. If you are a good enough artist to overcome the artefacts problems then you can probably get around the performance issues by intelligently split all the blits over several frames, so instead of redrawing 20 blinking elements in frame A, you'd draw 5 in frame A, another 5 in frame A+1 and so on.
IIRC there are no particular issues with sprites in HAM8. You could probably even do some flipper-elements with 16 color 64-pixel-wide sprites and thus get around some of the abovementioned headaches.
To be fair, I can't estimate how much performance will be left for flipper physics and other game logic once you add music and sound, but I asume it's all possible.

EDIT:
you could only use let's say 32 HAM base colors and still have 32 more for color cycle or blink effects.

Last edited by FairBoy on 26-Oct-2021 at 06:13 AM.

@fingus

Re:stock configuration

The stock A1200 is so limited when using all Chip RAM, it's not worth using at all without Fast RAM. The CPU will run easily twice as fast as soon as you add Fast RAM.

EDIT: I do remember one way around it: writing the game loop to fit into 256 bytes and making it cache row aligned so that the entire game loop fits in the code cache of the '020.

EDIT2:
Re:Base Palette entries
Ham8 always uses exactly 32 base entries. The other palette entries can be used by the sprites only and 15 per frame even then.

Last edited by Samurai_Crow on 26-Oct-2021 at 04:52 PM.
Last edited by Samurai_Crow on 26-Oct-2021 at 04:50 PM.

Ham8 used 64 base colors.

_________________

José

@Samurai_Crow
Quote:

The stock A1200 is so limited when using all Chip RAM, it's not worth using at all without Fast RAM.

That depends on what you want to achieve and fingus' project here seems to fit inside his self-imposed hardware restrictions.

Quote:

Ham8 always uses exactly 32 base entries

That's wrong. It's 64 base colors.

Quote:

The other palette entries can be used by the sprites only...

You can chose which color banks to use for the sprites. Therefore you can use totally different colors than those used to define the 64 HAM8 base colors.

Quote:

... and 15 per frame even then.

Yes, it's 15 colors plus transparency for 4bpl sprites. But "per frame"? What do you mean by that? That doesn't make sense to me. While it's true that all 15+1 color sprites share the same color bank, you can easily switch the bank itself or the individual colors down the display.

@FairBoy and Jose

If what you say is true, everything I've been told about the AGA chipset is wrong. In HAM8 there are 3 bitplanes to select red, green, and blue individually or in groups, using the other 5 bitplanes for relative changes to the RGB. The triads are different from HAM6 with its pairs. This leaves 5 bitplanes for the base triad palette entries, meaning it has 32 colors for palette entries. How could this be 64-colors? Does it use pairs like HAM6?

AGA's bank selector was supposedly on a master-slave configuration so it couldn't be changed except during the VBlank. The palette entries can still be changed mid-screen though. Also, using 3-color sprites is per-sprite if the even and odd sprite banks are different from each other. I hope you're right about the bank selection though.

@fingus
After thinking about it a bit more, I guess you have to forget about using sprites for general flipper elements other than the ball and equally tinted flipper elements like the flippers and other metallic things.
The reason is that the ball (or up to at least three balls when in multiball mode) have to be sprites, really good looking sprites to be exact. So you'll likely need all 15 colors only for that purpose. Sprite color bank or color switching to get more colors for other items at different locations won't work then because you're forced to stick to that ball palette throughout the whole screen because the balls can be pretty much everywhere.

@Samurai_Crow
Quote:

In HAM8 there are 3 bitplanes to select red, green, and blue individually or in groups

I guess they say "RTFM" in such a case. Short version: 6 bits color index / rgb-mod, 2 bits mode selection (4 possible values which are index, R-mod, G-mod, B-mod).

Quote:

AGA's bank selector was supposedly on a master-slave configuration so it couldn't be changed except during the VBlank

That's wrong. You can switch color banks mid screen, no problem at all.

Last edited by FairBoy on 26-Oct-2021 at 06:15 PM.

@FairBoy

Quote:

FairBoy wrote: @Samurai_Crow Quote: In HAM8 there are 3 bitplanes to select red, green, and blue individually or in groups I guess they say "RTFM" in such a case. Short version: 6 bits color index / rgb-mod, 2 bits mode selection (4 possible values which are index, R-mod, G-mod, B-mod).

That's disappointing. I guess Fingus will be stuck with shading only with primary colors using the HAM8 mode.

Re:RTFM
There was never a HRM for AGA. The RKRMs were only ECS or older. All that's available for AGA is some hodgepodge of reverse engineered stuff for the most part.

Quote:

Quote: AGA's bank selector was supposedly on a master-slave configuration so it couldn't be changed except during the VBlank That's wrong. You can switch color banks mid screen, no problem at all.

Now that's encouraging. Though with pinball, the balls will indeed need to be 15 grayscale.

Re:Blinking elements
Since I've been so wrong about AGA's capabilities up until now, am I at least correct in thinking as long as there are no more than 16 blinking lights of solid colors horizontally from each other, that 16 palette entries changed by the copper mid-screen will allow 48 base palette entries?

@Samurai_Crow
Quote:

There was never a HRM for AGA

That's why I didn't write RTFHRM.

Quote:

All that's available for AGA is some hodgepodge of reverse engineered stuff for the most part.

I hope you don't want to play down the achievements of all those brave guys who wrote all those very detailed (and correct) AGA chipset online manuals and youtube coding lessons for us?
Correct and fairly detailed AGA register / chipset information is just some keypresses away.

Quote:

am I at least correct in thinking as long as there are no more than 16 blinking lights of solid colors horizontally from each other, that 16 palette entries changed by the copper mid-screen will allow 48 base palette entries?

Nobody forces you to use all 64 HAM8 base colors for the actual HAM effect. You can decide to use an arbitrary number of base colors in index-mode only, so you can do the usual color change tricks without getting artefacts. The price is color variance, of course. So yes, you could decide to use such a 48 / 16 color setup to achieve 16 independently blinking lights on the same vertical display area.

@fingus
I thought about it a bit more. Using the sprites for anything else besides the balls will probably be impossible.
If we asume that there will be up to 3 balls at once and if we further asume that you want to asure zero sprite flicker for the balls then there's just 1 15+1-color-sprite left for the flippers.
If you still want to use this 1 sprite for the flippers then you'll have to reposition and reload it with the copper at the bottom area (and everywhere else where multiple flippers share the same vertical space).
That means that you cannot use 32 or 64 pixel wide sprites because it's impossible to manually reload those that way.
Therefore you'll have to stick to 16 pixel wide sprites because those can be reloaded. 16 pixels should just be enough for the balls, for the flippers you'll have to "race the beam".
Unfortunately you really have to reload and reposition 2 hardware sprites to handle this one 15+1 color sprite. So this means that you have to rewrite at least SPR6DATA, SPR6DATB, SPR6POS and SPR7DATA, SPR7DATB, SPR7POS all during the display of 16 pixels to get a gap-free flipper image. That won't work, the copper simply isn't fast enough. Your only option would be to stick with 3 color sprites for the flippers, but that would be far too ugly.

Conclusions:

a) use all 8 hardware sprites to form 4 15+1 color sprites to get up to 4 nice looking flicker free balls and do everything else with blitting, even the flippers.

xor

b) limit yourself to 2 simultan balls and you're free to use 64 pixel wide sprites and you can do all the flippers with the other 2 15+1-color sprites (asuming 64 pixels width is enough for one flipper and asuming that you dont have more than two flippers at the same vertical area somewhere on your pinball map).

xor

c) use 3 combined sprites for up to 3 balls and use the remaining 1 64-pixel-wide combined sprite for one flipper (and additional vertically seperated single flippers on the map) and blit the 2nd one only.

I'd recommend (c)

Last edited by FairBoy on 28-Oct-2021 at 08:38 AM.
Last edited by FairBoy on 27-Oct-2021 at 02:33 PM.
Last edited by FairBoy on 27-Oct-2021 at 12:15 PM.