HAM game with sprites - Proof of concept

[remz]

Hello Amiga hardware programmers!
After asking around a bunch of questions on the Copper, timing, etc., I've decided to come up with a proof-of-concept and I would like to share and get your insights of what you think about it.
The goal:
- Imagine a game that would leverage the power of the HAM mode
- Game should run on a plain unexpanded Amiga 500/1000/2000
- Using Copper to recycle sprites and change sprite colors

Here's how I would see it:
- The background, in HAM, would be made of 16x16 tiles.
- Since every tile would have their leftmost pixel always using a Palette color, no HAM fringing would occur, as long as the horizontal scrolling is done in increment of 16 pixels (i.e.: basically, jumping from one tile to another, so no smooth scrolling*)
- *Note: smooth scrolling could be possible by using a 16-pixel wide "black sprite" which would mask off the 16 leftmost pixels of the screen to hide any HAM fringing, but for now I am not considering doing that.
- The HAM color palette is composed of a simple grayscale ramp (from black to white, 16 shades)
- This palette would allow semi-realtime shadows: basically, any scanline of a tile on the screen could be tinted in realtime by subtracting a value from 0 to 15 to all its pixel values: whether that pixel represents an index-color OR a R-G-B modify value, the tinting would work by making the shade darker.
- It is almost equivalent to consider the screen a 'true-color' mode in a way.

- The sprites are set using DMA to be all enabled, position outside the visible display, and go from 0 to 255 lines (so spanning the whole screen vertically)
- Using the copper, every 16 pixels, a sprite is repositioned. So any sprite can appear anywhere on the screen, and even multiple times, per scanline. This is thanks to the fact that using 6 bitplanes, the copper has exactly just enough cycles to perform one CopMove every 16 pixels.
- During hblank, the Copper sets all of the 12 color palettes for the sprites. There is about just barely enough time to do that.
- It means that all sprites are composed of many colors. See the attached screenshot to view my current test sprite sheet.

The 3rd screenshot is running in WinUAE:
In total currently this proof of concept is showcasing:
- a background with 1243 colors (in HAM)
- 320 simultaneous sprites on the screen, using a total of 533 colors

(Technically the maximum possible would be 4096 colors for the background, and 3072 colors for the sprites).
During the screen display, the CPU is pretty much completely starved by display DMA and copper, so only the Vblank period would be usable for game logic, scrolling, blitter, etc.

What do you think of my idea? I'm eager to hear from you amiga experts!
(I've added a screenshot of the DMA debugger to show the screen is packed; I do not know what the colors mean however since I never used that WinUAE feature before)

Thank you,
Rem

[khph_re]

There are a couple of HAM games out there, Pioneer Plague is one of them,
most are slower paced RPG style affairs.
The demo HAM Eager by Platon really shows HAM strutting it's stuff.
I guess there are not so many HAM games as it is technically challenging, and rather slow.

Looking forward to seeing what you achieve, looking great so far!

[roondar]

Very interesting stuff, thanks for making this proof of concept. I've always wondered how you could do a HAM game with more flexibility than what Pioneer Plague is doing, so this is nice to see

I do wonder a little bit about the Sprite multiplexing you suggest.
How do you see this working with freely moving Sprites?

At a guess, I'd say that this would require not just Sprite repositioning, but also reloading the Sprite data. If you also need per-pixel movement horizontally, that would mean doing 4 Copper moves per Sprite channel reloaded/positioned, or 64 pixels worth of 'space' between each reloaded Sprite channel given that each Copper move takes 16 pixels. Makes me wonder how easy/hard that would get with multiple freely moving objects on the screen.

As for the Visual DMA debugger of WinUAE, it's a great tool to see the use of the various DMA sources and the CPU in Chip RAM. Each 'pixel' in the Visual Debugger represents a DMA cycle in Chip RAM and the colours each represent a DMA or CPU source.

Here's a small list of colours used:
Magenta = Sprites
Yellow/Dark yellow = Copper
Red = audio
Dark Red & Gray = CPU (read/write)
Dark gray = memory refresh
Cyan/Green/Light blue-green = Blitter
Blue = Bitplanes
White = Disk

[Jobbo]

I really like this! Love to see a novel approach!

I especially like the idea of using three color sprites but changing their palette every line. You see that a lot for backgrounds but I don't think I've seen it used for sprites so effectively.

You might consider scaling back your ambitions for the sprites and only multiplexing them vertically. That would still allow for 8 sprites on a line and would free up more DMA slots for the CPU or blitter to use. That might be more practical for a real game system.

With 6 planes for the screen and tiles you'll likely run into memory constraints on an OCS A500 so you might want to plan on the background remaining single buffered and arranging blits so they race the beam.

Anyway, great stuff!

[roondar]

Yeah, using only 8 sprites per line would make this a whole lot easier for sure

[malko]

Really interesting concept as well as nice and cute gfx.
Hope to see some animated gif or video soon.

[remz]

Originally Posted by roondar

I do wonder a little bit about the Sprite multiplexing you suggest.
How do you see this working with freely moving Sprites?

Yes the "rogue-like / dungeon crawler" type of game I have in mind would be pretty much tile-based, 16x16, so I was hoping to not require moving sprites smoothly across the tile. They would basically 'jump' from tile to tile, a bit like Crypt of the Necrodancer: [ Show youtube player ]

Also you are correct, normally in a dungeon there would never be 320 objects on the screen at the same time, so there would be some spare cycles for allowing two objects on the same tile (for example, the Hero jumping on a Coin to collect it, or the Hero walking past a Torch hanging on the wall).

I also wanted to have door archways that the Hero can walk underneath, so sprite numbering for priorities would also be considered carefully.

Next step I'll attempt to implement basic character movement and more realistic sprite multiplexing to see how feasible it could be. And then provide an ADF disk file here so in can be tested on various configs.

About memory: I was intending to use a single buffer for the HAM display 48KB, and possibly a single copper list (if possible) to save on memory. The copper list is quite big at about 17KB. Plus 8KB of sprite DMA data.
So figuring out maybe 48KB of tile graphic data, and 32KB of sprites data (so total of around 153KB out of 512KB). Some space needs to be available for music and sounds, that part I haven't looked at all so far.

For horizontal scrolling, I was thinking of simply moving the starting address of the bitmap by 16 pixels (2 words), so only one tile column needs to be drawn at the right edge.
For vertical scrolling, it would be resetting the address of the bitmap at the appropriate point.
(I haven't completely investigated how scrolling would be done, but I was heading toward scrolling only by 16x16 tile increment)

[Pyromania]

Interesting concept, why not use AGA HAM8?

[remz]

Originally Posted by Pyromania

Interesting concept, why not use AGA HAM8?

It would be a different challenge and surely interesting too.
But I wish to have something that would work on unexpanded original trio 500/1000/2000 models.

[stevelord]

This is going to sound weird, but I think this look would also work really well for a sokoban-type game. It'd also let you play with the game mechanics a bit without having to push too hard (no pun intended).

For an RPG this looks amazing and I would love to try it. I'd be a little concerned the RPG scope might be a bit too big to build, fit into an A500 and get out of the gate depending on how much time you have for it. Would you be interested in maybe trying something smaller first to get a basic full game working then expanding?

I really love the approach though. The 16x16 tile model works far better than I ever thought it might.

We definitely need more OCS/ECS HAM games. I've been playing LINKS lately and I'm surprised there are so few HAM games out there.

[roondar]

Originally Posted by remz

Yes the "rogue-like / dungeon crawler" type of game I have in mind would be pretty much tile-based, 16x16, so I was hoping to not require moving sprites smoothly across the tile. They would basically 'jump' from tile to tile, a bit like Crypt of the Necrodancer: [ Show youtube player ]

This is a very neat idea, really. If the movement is more jump-like and really only from tile to tile, it doesn't matter nearly as much as when it needs to be freely moving everywhere. Makes me think something like this should definitely be possible.

Cool stuff

Next step I'll attempt to implement basic character movement and more realistic sprite multiplexing to see how feasible it could be. And then provide an ADF disk file here so in can be tested on various configs.

Looking forward to it

About memory: I was intending to use a single buffer for the HAM display 48KB, and possibly a single copper list (if possible) to save on memory. The copper list is quite big at about 17KB. Plus 8KB of sprite DMA data.
So figuring out maybe 48KB of tile graphic data, and 32KB of sprites data (so total of around 153KB out of 512KB). Some space needs to be available for music and sounds, that part I haven't looked at all so far.

If you can get away with single buffering the screen that would be a very good way to limit memory use. Single Copper list might get tricky, I've not had good experiences updating Copper lists in real time unless I timed that carefully, made it all fit in the vertical blank area or used a double buffered Copper list.

[Torti-the-Smurf]

Bill Williams Knights of the Crystallion was HAM only and did run on a Standard A500.

https://hol.abime.net/2597

and also Pioneer Plague

https://hol.abime.net/1068

But i guess you already knew those

[khph_re]

I often wondered If Heroes of Might and Magic: Clash of Heroes could be done in such a HAM format, with AGA+ resembling (vaguely) the big boy version in 640x512, and OCS looking like the DS one in 320x256.

360/PS3/Android (Quick resize to 640x512)


Nintendo DS

[Pyromania]

I would love to see a HAM8 platform game for some strange reason.

[rothers]

Originally Posted by Pyromania

I would love to see a HAM8 platform game for some strange reason.

I think a slightly scrolling one could be possible if it was laid out right.



Or maybe something along the lines of bubble bobble is more feasible.


That sprite multiplexer would have to be top notch.

[Pyromania]

We need more HAM games. Only Bill Williams created a couple of them years ago. He was a very talented developer that was lost unfortunately. It would be exciting for more HAM games to be developed. The Amiga has those unique and interesting features like HAM for example that give it character.

[Havie]

Originally Posted by Pyromania

We need more HAM games. Only Bill Williams created a couple of them years ago. He was a very talented developer that was lost unfortunately. It would be exciting for more HAM games to be developed. The Amiga has those unique and interesting features like HAM for example that give it character.

Be careful what you wish for...

[ Show youtube player ]

[TCD]

Originally Posted by Havie

Be careful what you wish for...

[ Show youtube player ]

Or: http://hol.abime.net/4968/screenshot

[rothers]

Does the nighmare fest that is top banana use HAM mode? Some of the later levels are pushing some really weird colour depths. Or is it just hammering the blitter in 32/64 colour mode? It's an odd one.

[ Show youtube player ]

[DisasterIncarna]

if stuff not moving around too much or at all is a requirement, then maybe imitating something like the Valhalla adventure games?