06 July 2018, 12:11 | #541 | ||||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,430
|
Quote:
Yeah, that is what you get when people expect more on the Amiga than perhaps is reasonable (as in, 50Hz updates, 32 colour graphics + sprite layer background + extra copper effects + great sound and running in 512KB please). Note that this is more about people's expectations than platform capability. The Amiga can do some pretty impressive stuff if you use it in 16 colour mode and add some sprites. The problem is that people tend to want 32 colour (or more) ports and that is where you start to lose quite a bit of performance on OCS due to memory contention and the like. Quote:
Quote:
Quote:
A simple use of these would be to have the player character and his weapons be sprites which would save a bit of time. Depending, of course, on the amount of 'bullets' the knight gets. However, if you didn't mind putting in the extra effort, you could also use those sprite channels as a part of the boss. This would, essentially, give you a 64 pixel wide band* of the boss that doesn't need any masking or restoring at all and uses virtually no DMA bandwidth to draw (sprites are insanely fast compared to the Blitter). Since the game runs in 16 colours, this doesn't pose any problem for sprite colour register usage. *) I am, of course, assuming that a 16 colour boss is what is desired Last edited by roondar; 06 July 2018 at 12:27. |
||||
06 July 2018, 12:53 | #542 | |
CaptainM68K-SPS France
|
Quote:
such big games need to be splitted per program parts and level parts. The original need 12 mb of ram because everything is a huge single block. |
|
06 July 2018, 13:00 | #543 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Performance gains from using sprites won't help. The issue is the memory usage required and the performance hit from buffering from fast to chip on a 68k machine. I already gave some rough estimates for this on the thread.
What I'd like to know is: a) how much of the graphics is from tile data. CPU can handle that from fast as there's no need for shifting. b) How much masked data there is per level which needs to be handled by the blitter The STe has a *huge* addressing range on its blitter compared to the Amiga. 24 bit with 12 meg of that coming from addressable RAM. If all masked data fits in 2 mb it's doable on ECS with decent performance. If not.....better target the 1200 and accept it isn't feasible on a 500 without crippling the frame rate. Last edited by frank_b; 06 July 2018 at 13:05. |
06 July 2018, 14:21 | #544 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
That said you could probably get away with storing all the sprite data for the player in fast RAM. CPU could just copy into the chip ram buffer and adjust the positing via control words. That would save chip RAM and not be too expensive.
Another question then. How much memory does the player sprite use up per level? |
06 July 2018, 15:14 | #545 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
It's an interesting challenge this one so I've had a quick look at the boss assets and using the dual play field method that I would take to doing it.
There's 976 16x16 tiles that make up the boss sprite which I would squeeze down into using 8 colours (1 transparent). So 96 bytes per tile using up 93,696 bytes of chip ram, I'd probably double that for masking as many of the tiles overlap so 188Kb. Then you're looking at the screen buffers and I'd probably triple buffer this one because the boss doesn't move every frame giving you enough time to build up the other buffers ready for display, so around 100K for that too. The main player sprite is 48x48, so I would be opting for using 6 hardware sprites there, possibly using the remaining two sprites for the fireball the boss breathes out. Another 60Kb on top for the foreground screen buffers, and maybe 40Kb for the tile data. Remember , I'm just considering the end of level boss here but you are looking at least 1mb of chip ram... but 50fps?... definitely. |
06 July 2018, 15:16 | #546 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
Quote:
|
|
06 July 2018, 15:22 | #547 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
|
06 July 2018, 15:23 | #548 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
|
06 July 2018, 15:31 | #549 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
|
06 July 2018, 15:42 | #550 | |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
Quote:
Ghosts 'N Goblins on the otherhand is beautiful and a very faithful port |
|
06 July 2018, 16:22 | #551 |
Registered User
Join Date: Dec 2016
Location: Finland
Posts: 168
|
If one wants to have something more high-end, then one should use an accelerator board with an A1200, and draw most object graphics with the CPU, because the blitter is way too slow. I did some tests with a 68030/50 MHz on an A1200, and its about 5 times faster at making cookie cut operations and bit shifting than the blitter (for making similar blitter objects), despite you need to copy the graphics into chip ram.
Since one can have up to 128 MB of fast ram on accelerator boards, there will be enough memory for graphics. Then you also have the AGA sprites. With this sort of performance, it starts to be feasible to also use SuperVGA-style graphics, maybe 640x512 and 32 colors, in AGA 4x fetchmode bitplane bandwidth requirements will be about same as in OCS 320x256 and 32 colors, so there's some slowdown for CPU access into chipram. But these VGA/DBLPAL modes also eat up sprites and horizontal scrolling, so a vertical shooter works best with these settings. But on AGA screenmodes are also fully programmable, so you could have some very nonstandard displaymodes and refresh rates to save sprites and scrolling. |
06 July 2018, 16:27 | #552 | |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Quote:
BTW the really exciting thing about this project is it isn't limited to one game. Street Fighter II anyone? |
|
06 July 2018, 16:30 | #553 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,344
|
Quote:
|
|
06 July 2018, 16:41 | #554 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,345
|
I think that given the current mood in the Amiga community, a GnG port requiring 4 MB of RAM would not be well-received. There is a certain quality in a port running on vanilla hardware, even if it inferior.
For the STE, it's different because every machine can be expanded to 4 MB of RAM — but on the Amiga 500, requiring 4 MB is tantamount to requiring 12 MB on the ST, and you still don't get the advantages you have on the STE since chip RAM is still limited. |
06 July 2018, 16:57 | #555 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
A full 68k bus master blitter, with the same register interface as the Amiga would be a hell of a nice USP for new ACA 500 cards.
Would do wonders for fblit too. |
06 July 2018, 17:35 | #556 | |
Registered User
Join Date: Dec 2016
Location: Finland
Posts: 168
|
Quote:
|
|
06 July 2018, 18:42 | #557 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Cho ren sha has up to 4000 sprites on screen or something equally crazy. Forget about that on a non 060 1200. I'm talking about the arcade ports here. That's more feasible.
|
06 July 2018, 20:07 | #558 |
Registered User
Join Date: May 2017
Location: AmigaLand
Posts: 459
|
|
06 July 2018, 21:18 | #559 | |
Registered User
Join Date: Dec 2016
Location: Finland
Posts: 168
|
Quote:
http://shmuplations.com/chorensha68k/ |
|
06 July 2018, 21:49 | #560 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Ok I will do the math for 500 16*16 sprites at say 16 colours with the CPU.
You're reading 2 bytes per line per plane * 16 for the sprite: 2*4*16 = 128 bytes. The mask takes 2 bytes per line * 16 = 32 bytes You're reading an extra column on the destination to take account for shifting the source. The destination being the screen. So that's 4*4*16 = 256 bytes You also have to read and restore the screen buffer. Let's say you have a third buffer containing a copy of the screen as a source. So that's another 256*2 bytes (read and write). A single 16*16 sprite costs the CPU 128 + 32 + 256 + 512 bytes.. that's 928 bytes worth of bandwidth. Now lets multiply that by 500. That's 928 * 500 = 464,000 bytes per frame worth of reads/writes!!!! This is excluding overhead and actual game logic. How on earth is that going to run acceptably on a 1200? Even with fast RAM and an accelerator! I'd go down the chunky pixel route, use compiled sprites if I was doing it. I'd not be targeting a stock 1200! Last edited by frank_b; 06 July 2018 at 21:54. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Japanese Console/Computer RPG discussions | Retro-Nerd | Retrogaming General Discussion | 2 | 02 April 2009 01:32 |
Given the recent Scanlines discussions... | DamienD | request.UAE Wishlist | 26 | 26 April 2007 17:36 |
Wii Virtual Console / Xbox Live Arcade? | killergorilla | HOL suggestions and feedback | 2 | 06 March 2007 17:20 |
Landover's Amiga Arcade Conversion Contest | Frog | News | 1 | 28 January 2005 23:41 |
|
|