Tech demo of my game

[Toni Wilen]

Very nice colors

Audio issue

Looks like sometimes AUDxPT is updated, audio DMA started, then AUDxPT is updated again, before Agnus/Alice has got first DMA request from Paula (which also copies AUDxPT to internal pointer), causing audio DMA to start from "updated again" pointer, skipped the original one. This delay is up to 1 scanline due to way audio DMA requests works.

WinUAE by default in fast CPU modes "fix" these problems (and logs messages) because audio DMA wait problems are too common. chipset_hacks=8 in config file disables audio fixes.

[Gzegzolka]

Very impressive demo, I hope You will manage to finish it

[jotd]

Looks like 24-bit colors! very well done. I wonder why we didn't get those kind of colors in games back in the day (yes, we were told that HAM was only for pictures)

[ross]

Originally Posted by jotd

Looks like 24-bit colors! very well done. I wonder why we didn't get those kind of colors in games back in the day (yes, we were told that HAM was only for pictures)

Because moving objects in these conditions is a nightmare

And I'm not just talking about blitter objects that should be built exactly like the tiles in this demo, but also sprites that are restricted in movement if they want to be recolored (and amount per line limitations..).

Instead this engine is PERFECT for such a game, but only for this genre, it's not a small condition.

[TCD]

Originally Posted by ross

Instead this engine is PERFECT for such a game, but only for this genre, it's not a small condition.

I guess games like Chaos Engine and Smash T.V. would be possible in this way?

[ross]

Originally Posted by TCD

I guess games like Chaos Engine and Smash T.V. would be possible in this way?

I don't think so, too many things that move freely and overlap.
But I'll be happy if it proves to be otherwise

[TCD]

Okay, let's see what remz will create then

[remz]

Originally Posted by Toni Wilen

Very nice colors



Looks like sometimes AUDxPT is updated, audio DMA started, then AUDxPT is updated again, before Agnus/Alice has got first DMA request from Paula (which also copies AUDxPT to internal pointer), causing audio DMA to start from "updated again" pointer, skipped the original one. This delay is up to 1 scanline due to way audio DMA requests works.

WinUAE by default in fast CPU modes "fix" these problems (and logs messages) because audio DMA wait problems are too common. chipset_hacks=8 in config file disables audio fixes.

Thank you Toni, much appreciated any insight of this: I tried and failed to debug this issue yesterday: Indeed in Winuae I am seeing tons of DMA hack warnings n the log whenever I used an amiga faster that A500. I will investigate more and find the problem!

[Evillord68]

Wow, it looks very good. Great job.

[DisasterIncarna]

Originally Posted by ross

Because moving objects in these conditions is a nightmare

And I'm not just talking about blitter objects that should be built exactly like the tiles in this demo, but also sprites that are restricted in movement if they want to be recolored (and amount per line limitations..).

Instead this engine is PERFECT for such a game, but only for this genre, it's not a small condition.

Wonder if the old Valhalla games from Vulcan could have worked using this kind of method? They were pretty basic topdown rpg/adventure games with pretty much nothing moving around except the player.

[carlosgod]

Originally Posted by ross

Because moving objects in these conditions is a nightmare

And I'm not just talking about blitter objects that should be built exactly like the tiles in this demo, but also sprites that are restricted in movement if they want to be recolored (and amount per line limitations..).

Instead this engine is PERFECT for such a game, but only for this genre, it's not a small condition.

Okay, I've been really fascinated with this project ever since it was first posted in August last year, and had a hard time grasping how all this was achieved and why it couldn't be done with other amiga games.

So I get that each of the 16*16 tiles are in HAM 6 bitplane (greyscale) and presumably blitted across the screen, and the tiles are arranged in such way to avoid fringing effects and there is some sort of shading trick depending on light source...

But what I don't get is how there could be so many sprites (104 max) - some of them animated. I presume this is heart of the innovation of this engine.

But there has to be another reason why other tile-based top-down OCS games (Gauntlet, Alien Breed etc) don't do this... For example, does this engine require that all the sprites (except the main character) have to stay stationary. If they are made to move then the whole thing falls apart? If so then it would limit the use case of this game engine.

Thanks and would appreciate if anyone can clarify!

[Tigerskunk]

Love this project.
Shows how innovative you can still get with the good old OCS hardware.

I had a go at HAM mode a few years ago when I was still working deeply on Inviyya, but it never went anywhere unfortunately.
Want to create a little game demo, but then other things happened and never went back to it.

Happy though you pulled this off. Looks amazing!

[Tigerskunk]

Originally Posted by carlosgod

But there has to be another reason why other tile-based top-down OCS games (Gauntlet, Alien Breed etc) don't do this... For example, does this engine require that all the sprites (except the main character) have to stay stationary. If they are made to move then the whole thing falls apart? If so then it would limit the use case of this game engine.

I think this has more to do with the sprite sizes plus the palette recoloring of all these objects.

Doing this in a dynamic copperlist that gets rendered each frame and where you have to do an y pos sort is quite CPU intensive if you want to have these many objects on screen.

I am using only a lame bubble sort in my sprite multiplexer, but with that this gets exponentially more heavy in CPU load when you have more objects.

There are sort methods that are much more efficient for this, though.

But then, you still have to render that huge copperlist each frame.

[JoeJoe]

A really very impressive technical demo. I'm already looking forward to the finished game. I would have one small comment though. Couldn't you display the font from top to bottom.

[ross]

Originally Posted by DisasterIncarna

Wonder if the old Valhalla games from Vulcan could have worked using this kind of method? They were pretty basic topdown rpg/adventure games with pretty much nothing moving around except the player.

Yes, most likely this engine could be used.

Originally Posted by carlosgod

But what I don't get is how there could be so many sprites (104 max) - some of them animated. I presume this is heart of the innovation of this engine.

Not that in the Amiga there are any limits in the use of sprites, as long as they are not more than 8 on the same video line, so if you limit their vertical movement and set a maximum per line...

[Samurai_Crow]

Re:sprites
HAM mode doesn't use all of the palette registers so the sprites have the second bank of color registers to themselves. The copper helps even more as a result.

[remz]

Originally Posted by ross

Yes, most likely this engine could be used.


Not that in the Amiga there are any limits in the use of sprites, as long as they are not more than 8 on the same video line, so if you limit their vertical movement and set a maximum per line...

And even that limit of "8 sprites per video line" is not entirely accurate. The copper is fast enough to 'reset' sprites during the line, allowing you to reuse a sprite several times on the same line.

As an example, one of my early iterations on this tech demo was displaying 340 sprites on the screen, with up to 48 colors each. See this screenshot:



You can see it explained in great detail here in this video by Dutch Retro Guy where the copper is 'racing the beam' horizontally to render a fullscreen layer of sprites:
[ Show youtube player ]

[Samurai_Crow]

Re:horizontal sprite mux
To multiplex sprites horizontally takes so much bandwidth that there's nothing left for the CPU unless there's real fast RAM or no blitter usage. That's one of the reasons BitBeamCannon used the effect so sparingly on Metro Siege and limited the display to 4 bitplanes.

[ross]

Originally Posted by remz

And even that limit of "8 sprites per video line" is not entirely accurate.

Yeah, I should have added 'with data fetched by a DMA channel'.

But I deliberately avoided mentioning the possibility of using horizontally multiplexed sprites (and I very well know how to use them ).
I simply didn't want a general user to think that miraculous things can be done with your engine.

It's already as good as it is and for what it has to do it's excellent, let's not exaggerate.
The limitations with horizontal multiplexing are too many to use extensively in a game for objects with freedom of movement (background or some overlay panel are not a problem and are used in many games).
And in fact you didn't rightly use it in the demo you posted.

The screenshot with the screen full of sprites is nice but nothing more

[remz]

Originally Posted by ross

Yeah, I should have added 'with data fetched by a DMA channel'.

But I deliberately avoided mentioning the possibility of using horizontally multiplexed sprites (and I very well know how to use them ).
I simply didn't want a general user to think that miraculous things can be done with your engine.

It's already as good as it is and for what it has to do it's excellent, let's not exaggerate.
The limitations with horizontal multiplexing are too many to use extensively in a game for objects with freedom of movement (background or some overlay panel are not a problem and are used in many games).
And in fact you didn't rightly use it in the demo you posted.

The screenshot with the screen full of sprites is nice but nothing more

You are absolutely correct. I had to make a choice between smooth horizontal scrolling and horizontally multiplexing sprites at some point.