21 September 2016, 22:28 | #21 | |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 232
|
Quote:
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. |
|
21 September 2016, 22:49 | #22 | |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,558
|
Quote:
look here around 25:30 : [ Show youtube player ] Last edited by saimon69; 21 September 2016 at 22:54. |
|
21 September 2016, 22:52 | #23 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,646
|
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 |
22 September 2016, 13:37 | #24 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 525
|
Quote:
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. |
|
22 September 2016, 14:22 | #25 |
Banned
Join Date: Jan 2012
Location: Serbia
Posts: 275
|
@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? |
22 September 2016, 14:29 | #26 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 232
|
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.
|
22 September 2016, 15:30 | #27 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,646
|
|
22 September 2016, 18:43 | #28 |
Registered User
Join Date: Jun 2014
Location: milan / italy
Posts: 174
|
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. |
22 September 2016, 19:01 | #29 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
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!
|
22 September 2016, 20:15 | #30 | |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 232
|
Quote:
|
|
22 September 2016, 20:51 | #31 |
Banned
Join Date: Jan 2012
Location: Serbia
Posts: 275
|
^
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? |
22 September 2016, 21:20 | #32 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,797
|
Quote:
That sounds like a more suitable candidate indeed. Quote:
Of course, they're still just sprites. Just about every Amiga game uses them. Last edited by Thorham; 22 September 2016 at 21:25. |
||
23 September 2016, 11:45 | #33 | |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 232
|
Quote:
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. Last edited by AnimaInCorpore; 23 September 2016 at 11:51. Reason: Answer extended |
|
23 September 2016, 17:46 | #34 |
CaptainM68K-SPS France
|
basically you're saying that Cho Ren Sha 68k is using chunky bitmap and not planar ?
can you enlight us on that matter ? |
23 September 2016, 23:27 | #35 | |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 232
|
Quote:
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Optimizing SHA-256 crypto hash. | Thorham | Coders. Asm / Hardware | 8 | 21 June 2015 08:11 |
anyone have super Cho Aniki ? Was it released? | marcfrick2112 | request.Old Rare Games | 2 | 18 November 2011 22:27 |
ScummVM 0.9.1 68k | Paul | News | 28 | 20 August 2010 02:36 |
CRC32 , MD5 , SHA - 1 Curiosity | Kyon | support.Other | 38 | 09 June 2009 10:08 |
WTD:Ren & Stimpy Slideshow | AmigaWorld | request.Demos | 0 | 22 February 2008 23:46 |
|
|