Cho Ren Sha 68K

[AnimaInCorpore]

Originally Posted by Master484

I don't know how many colors the Atari Falcon or the X68000 version has, but for me 16 color background + another 16 colors for the moving objects would be enough, with some more colors coming from sprites and copper effects.

Some numbers:

Cho Ren Sha 68k on the X68000: 16 palettes (with 16 colours each) for the sprites and a background comprised of two layers which can choose colours from a palette of 256. So the total number of simultaneous visible colors may exceed 256.

Cho Ren Sha 68k on the Atari Falcon 030: 16 bit "direct colour" display for everything. The sprites are being drawn in original quality by emulating the sprite display of the X68000.

In this early alpha version you can see that the background on the Atari Falcon can be quite colourful (up to 65536 colours):
[ Show youtube player ]

And in this early test version the sprites are being shown as quadratic boxes so you get an idea how the bigger sprites are being composed. Please note that even those are animated by moving parts:
[ Show youtube player ]

This is why I said that it is almost impossible to create bigger Blitter Objects out of the composed objects. Of course you can scrap many things for performance but I think especially this dynamic animated gameplay in combination with the fluid rotations is an important part of this game.

BTW of talking of big sprites:
[ Show youtube player ]

Another BTW: the maximum number of sprites to be drawn is 512 because the X68000 version uses a sprite multiplexing technology. Occasionally this number will be reached and no: even the X68000 isn't able to handle this properly.

[saimon69]

Originally Posted by Master484

The Atari Falcon seems quite powerful:

I know only one Amiga shooter that really takes advantage of the speed of 2 bitplane playfields, and that is the PD shooter "Blaster":

[ Show youtube player ]

In this video the game is played on "Easy" mode, where the aliens don't shoot at all, but on "Hard" mode they shoot, and the screen is full of bullets, but still the game runs at a solid 50fps on a standard A500.

Maybe this technique could be used, but with a 4 bitplane (16 color) back playfield for game objects and a 2 bitplane (4 color) front playfield for bullets and explosions?

Powder used interleaving too turning on and off planes at need: ok was running at 25fps but if that guarantees a 5h17l06d of stuff on the screen then why not?
look here around 25:30 :
[ Show youtube player ]

[Amiga1992]

If you can replicate the ACTION of Cho Ren Sha 68K on an A1200, I wouldn't mind the color count to be less. You could maybe use copper color changing to get some interesting effects.

But as I said I don't think this kinda game is possible on an A1200 at all. Anybody willing to prove me wrong go ahead and shut my mouth

[Master484]

In this early alpha version you can see that the background on the Atari Falcon can be quite colourful (up to 65536 colours):
[ Show youtube player ]

And in this early test version the sprites are being shown as quadratic boxes so you get an idea how the bigger sprites are being composed. Please note that even those are animated by moving parts:
[ Show youtube player ]

Those are some very interesting videos, especially the one that shows the sprites as green boxes.

I now see what the problem is; doing that many Blitter operations per frame would definitely cause massive slowdown.

From my own experience with Blitz Basic game projects, I have noticed that it's almost always faster to Blit one big object, than to split it into many parts and blit the small parts separately. This is because the Blit command itself is costly, and doing many small Blits add up quite quickly.

---

So clearly a total drawing mechanism redesign would be needed for the Amiga conversion.

I think I would simply use big BOBs for all enemies, and if moving parts are needed, then 2 or 3 separate parts should be the maximum. And the rotating enemies should be either be pre-calculated, or dropped out if that takes too much RAM.

And for the backgrounds, I'm afraid that 16 colors is the maximum for them if 16+16 dual playfield is to be used...there would be some quality drop when colors go from 256 to 16 but maybe converting the images to grayscale (16 shades of gray) would save the day? And the backgrounds aren't even so important, because the game doesn't seem to have any real scrolling levels.

In a bullet rain game like this, the amount of on-screen action makes the game, everything else is secondary. Most likely the A1200 can't handle a 256 color or 64 color furious action game, just like the A500 can't handle 64 colors HAM or even a 32 color action game...and those few A500 examples that do use 32 color mode usually don't run at 50fps.

And if everything else fails, then we could even use 8 + 8 color dual playfield on an A1200. Surely that would boost speed quite a lot? And even this doesn't need to mean a bad looking game; many of the best looking Amiga games, like Lionheart and Shadow of the Beast, used the 8 + 8 color dual playfield technique, and boosted the colors with copper and sprite tricks.

---

Also it's good to remember that the Amiga already has one game in which on-screen action comes pretty close to the "bullet rain" definition: Mega Typhoon.

In this thread I made a short analysis of how Mega Typhoon works on the A500:
http://eab.abime.net/showthread.php?t=83866&page=2

It uses 8+8 color dual playfield, and according to the ReadMe it has 64 BOBs and 48 sprites on screen at a constant 50fps without any slowdown. And it even has many rotating enemies, with multiple moving parts. If the standard A500 can do that, then surely the A1200 should be capable of the same, and a little bit more?

Everyone who thinks that this sort of game can't be done on Amiga should try out Mega Typhoon...I think that the game engine is revolutionary, it's a "next generation" A500 shmup engine, that was sadly only used once in that partially unfinished, almost unknown game.

[kovacm]

@anima what is peak in MB of data that Falcon can transfer from RAM (sprite in memory) to RAM (on screen video)? And how much % you manage to squezze graphics by precompiling sprites?

Is it possible to have precompiled sprites on Amiga in same manner to spare bandwidth?

[AnimaInCorpore]

Ok, I will make it clear now: it is not about talking but doing. So if you really want to do a serious port please let me know. I will help but you need to be confident that you are able to do it. Just think about it.

[Amiga1992]

Originally Posted by Master484

I now see what the problem is; doing that many Blitter operations per frame would definitely cause massive slowdown.

This is what I was saying all along, no matter how much CPU power you have, if you use the Amiga's chipset that will be your bottleneck.

[ovale]

If I'm not wrong, the port uses all the features of the Atari Falcon: 030@16mhz, DSP@32mhz, 14MB 16bit@16mhz RAM, chunky 16bit framebuffer.

I don't see why people are suggesting a port for the stock A1200. It is obvious the HW cannot compare.

... and software wise Anima is a top programmer so no much space for further optimizations.

IMO a possible target is a a1200 with 030@50mhz or more with all the rendering done in fast RAM and then converted in HAM. But then... it is no Amiga-ish anymore, just crunching MIPS like any x86.

[frank_b]

Devil's advocate time. Why not just target an Amiga RTG system with a 16 bit per pixel framebuffer? If you want to get funky, there are 56k DSP cards around for the Amiga too. I don't think you're doing this on a stock 1200 any time soon however!

[AnimaInCorpore]

Originally Posted by kovacm

@anima what is peak in MB of data that Falcon can transfer from RAM (sprite in memory) to RAM (on screen video)? And how much % you manage to squezze graphics by precompiling sprites?

Is it possible to have precompiled sprites on Amiga in same manner to spare bandwidth?

I'll have to take a look on that. Actually there's a total number of 1885 sprites which can be flipped horizontally and vertically so the exact number of sprites being compiled is 7560. However, not all of them will be flipped horizontally or vertically but you don't know that before. The background is not really important so it can be replaced by a star field for example. So the main memory consumption results from the compiled sprites.

[kovacm]

^
I refer not to disk/RAM size of sprites but on bandthwidth needed to copy sprites every frame to framebuffer! How much bandwidth you manage to save using precompiled sprites vs raw sprites.
And is it possible to use precompiled sprites on Amiga with bitplane modes?

[Thorham]

Originally Posted by ovale

I don't see why people are suggesting a port for the stock A1200. It is obvious the HW cannot compare.

Blatantly obvious. You can do some kind of bullet hell shoot'm up, but nothing like this.

Originally Posted by ovale

IMO a possible target is a a1200 with 030@50mhz

That sounds like a more suitable candidate indeed.

Originally Posted by ovale

or more with all the rendering done in fast RAM and then converted in HAM. But then... it is no Amiga-ish anymore, just crunching MIPS like any x86.

HAM is VERY 'Amiga-ish', of course, but you'd waste a lot of cycles doing the conversion to HAM. It's just not a real option. Best mode for this is dual play field + sprite layer (which is also VERY 'Amiga-ish').

Originally Posted by kovacm

And is it possible to use precompiled sprites on Amiga with bitplane modes?

Of course, they're still just sprites. Just about every Amiga game uses them.

[AnimaInCorpore]

Originally Posted by kovacm

^
I refer not to disk/RAM size of sprites but on bandthwidth needed to copy sprites every frame to framebuffer! How much bandwidth you manage to save using precompiled sprites vs raw sprites.
And is it possible to use precompiled sprites on Amiga with bitplane modes?

Sorry, I missed the point.

The traditional approach for drawing sprites would be simply copying the data. However, due to the fact that the sprite pixel colours refer to a palette dynamically, the drawing is done by using simple "move d0,(a0)+" instructions instead. For small sprites the whole code fits into the instruction cache and so that's quite fast but for the overall performance I cannot give you exact numbers. Probably I'll do some profiling to see what time is spend on that part.

Edit: I am not sure if precompiling sprites on the Amiga would be helpful at all. The plane based graphics does not allow using a dynamic palette for the sprites so I guess you have to stick with the standard "cookie cut" method. I am not sure either if it's faster to do this in the fast RAM and copy the result to the chip RAM because I know that the Amiga 1200 Blitter is not as fast as it could have been.

[dlfrsilver]

basically you're saying that Cho Ren Sha 68k is using chunky bitmap and not planar ?

can you enlight us on that matter ?

[AnimaInCorpore]

Originally Posted by dlfrsilver

basically you're saying that Cho Ren Sha 68k is using chunky bitmap and not planar ?

can you enlight us on that matter ?

Exactly. On the Atari Falcon it uses the 16 bit colour "chunky" graphics mode.