Amiga1200 Danmaku WIP

[Daytona675x]

Hi fellow shmuppers,

this is Daytona675x (aka Hornet600S, almost two decades ago at shmup-dev.com).
We are currently developing the first real bullet hell shmup for the good old Commodore Amiga 1200 (and compatibles, including the Commodore CD32 console).
"We" are

Gfx - Crome
Music - Triace^Desire
Code - myself, Daytona675x^GoldenCode

Also, I bought some gfx from Matt Walkden over at itch.io and somewhat adjusted them for our needs.

The game runs on basic stock A1200 configurations:

• CPU: 14 MHz 68EC020
• RAM: 2 MB Chip RAM (= slow RAM, shared between CPU and the custom chips)
• Display: PAL lores, 304 x 256, 50 Hz

It's coded using C/C++ and 68k assembly.
Apart from some bug fixes and things like even more optimizations and stuff like a score-screen and a nicer highscore section, the engine is pretty much complete; it's fully playable.
So the major work now will be level / enemy / pattern design.

Right now it still contains some placeholder gfx as Crome is currently concentrating on the 1st levels tileset.
Due to the pretty hefty hardware limitations and "exotic" engine features, this is not an easy task.
Some of those hardware limitations are:

• background only 16 colors (plus palette changes per tile-row, with other restrictions, of course).
• foreground (bullets and floating enemies) only 15 colors (plus per enemy palette changes, if not overlapping).
• bg/fg is done using the hardware's dual-playfield mode (2x 4 bitplanes), which happens to be the only way to get the bullets on top of the hardware-sprites.
• 8 hardware sprites (players, player-shots and all explosions are made with those), heavily manually multiplexed.
  The hardware groups them into pairs (0/1, 2/3, 4/5, 6/7).
  Each pair can either have the same 3 colors. Or a pair can be "attached", then it becomes effectively 1 sprite with 15 colors - but all such attached sprites have the same colors.
  Also, due to DMA restrictions, the hardware will start to lose sprite DMA when you start using horizontal softscrolling, because then the display DMA needs to fetch extra bitmap data (the incoming additional set of pixels) and it "steals" that DMA time from the sprite hardware.
  The common remedy is to lower the horiz. resolution and to move the display's start to the right - well, we tricked us around that

The hardware also features Blitter and Copper hardware.
The blitter can copy and or/and bitplane data, the copper is a mini processor (three commands), synced with the display, to adjust hw register contents at certain screen positions (not at every pixel, of course). Both are heavily used.

The game is still without a name. An earlier prototype, made with another graphician who left the team, was named "Hyperborea", but this is past.
Anyway, our goal is to have it all done until by mid 2025 so that we're ready for release during the upcoming Amiga40 event in Germany

Here's the latest WIP video:
https://youtu.be/YeinozOIxeA

Cheers,
Daytona675x

[Verticen]

Appears to be a brilliant well-crafted engine; bravo! My knowledge of the Amiga platform is limited, but I find it quite impressive how many onscreen sprites and particles that are displayed without suffering from noticeable FPS drops or slowdown that appear in several other Amiga titles.
Provided your explanation I imagine you must have done some serious software witchcraft to overcome the sprite hardware limitations of the A1200.

I think the graphics on display are overall rather good. I especially liked the detailed background graphics in the WIP 3 video. Are the cyborg pumpkins placeholder enemies? They appear to stylistically clash with the style of the other graphics.

Hope development goes well & it impresses at Amiga40.

[Daytona675x]

Thanks for the flowers
To be fair, R-Type 2, which you linked to, is an A500 game whereas this here is for A1200.
The A1200's CPU runs twice as fast and there are some gfx hardware improvements (most of all more colors and wider sprites), however unfortunately the blitter has not been improved at all and doesn't even run faster (only indirectly by using 64bit fetches for the display's bitplanes, which frees more DMA cycles for the blitter).
That blitter crap is probably the main reason why many other stock A1200 shmups run at 25 fps.

Anyway, the toughest part wasn't the sprite-taming but to get so many bullets on screen.
Most Amiga shmups use sprites for the bullets. This is convenient because it's pretty easy and cheap to do, but you can only have 8 such sprite bullets on the same horizontal screen area under best circumstances. If you try to overlap more than 8, then sprite bullets will just vanish / flicker. So with sprite-bullets you are limited to very simple bullet patterns.

This is of course a no go for a true bullet hell game, which is why here the bullets are drawn using CPU and blitter and the sprites are used for players and explosions. If there are many many explosions at the same time you can occasionally witness explosion-sprites being half-drawn only but in contrast to flicker-bullets this doesn't really hurt

That "style clash", yes, you're absolutely right. This is simply because at the moment all enemies are just placeholders and the background itself is WIP too. Will take some more time until it looks all homogenous

[Ms. Tea]

Wow, this looks really cool. Echoing what Verticen said about the bullets - I'm really impressed with the performance you're getting out of this. Those are some great looking bullet patterns.