English Amiga Board


Go Back   English Amiga Board > Main > Retrogaming General Discussion

 
 
Thread Tools
Old 15 January 2021, 18:02   #121
Gilbert
Registered User
 
Join Date: Sep 2008
Location: UK
Posts: 314
Quote:
Originally Posted by Old_Bob View Post
2mb actually isn't much, dude. At least, not if you're expecting 256 or even 128 colour games. A game like SF2 would devour that fairly quickly. The only real option that leaves is realtime decompression of assets as they're needed. Definitely not great for framerate. Especially if you're doing it all in Chip RAM.

B
That's a fair point. Can the extra power of the 32 bit 14Mhz CPU be leveraged? SF2 probably only needs 6Mhz - 8Mhz of that to run the basic game code when optimized for the Amiga. Maybe the chip ram barrier is too much - but you could store the first 3 frames of animation of every non standard move in memory, and then start to decompress the rest of the frames after the player initiates that move. It could probably be done because you'd have a fair number of frames delay to decompress the data before it was needed. Is this possible?

Also there is the vanilla option of using a different 16 colours for each fighter - one can use sprites and the other the blitter. If you were being super adventurous - you could effectively blit over sprites or put some sprites over a blitter object to get the same 32 colours for each character. Would still look a lot better than standard Amiga version and you could probably get all the frames in memory. The arcade would use 4 bitplanes I imagine but be tile based. I still would guess not a huge number of different colours used per fighter in the arcade. I would actually guess at 32 max but I have been wrong before here

EDIT : Have just done a test on the arcade (SF2) sprites and they use 16 colours per fighter The SNES also has 16 colours per fighter but the sprites are slightly weedier (not as beefy) and it misses a few animation frames out.

Arcade sprite for Guile (looks wider here because CPS1 has narrow width pixels)


Arcade Sprites here:
https://www.spriters-resource.com/ar...treetfighter2/

Problem is number of sprites. Guile has 237 animation frames (facing one way) +24 for win poses (can be halved by only loading one win pose per round) + 7 for projectile animation (sonic boom). Wonder how much memory this would take up?

Quote:
Originally Posted by mcgeezer View Post
£30,000 is cheap, you should see how much they pumped into that new fangled Cyber Punk game ... BIIIIIIILLLIONS.

If you took the Arcade version of Ghouls and Ghosts and ported it to the CD32, not worrying about Resolution you could achieve 50frames per second.

But the resolution would be something like 128px X 128px.
I'm definitely up to contribute £50. The rest of the CD32 userbase - it's up to you!

Last edited by Gilbert; 15 January 2021 at 18:36.
Gilbert is offline  
Old 15 January 2021, 20:14   #122
Old_Bob
BiO-sanitation Battalion

Old_Bob's Avatar
 
Join Date: Jun 2017
Location: Scotland
Posts: 114
Quote:
Originally Posted by Gilbert View Post
That's a fair point. Can the extra power of the 32 bit 14Mhz CPU be leveraged?
It certainly doesn't hurt. As you correctly point out, the overhead for the logic code driving everything would be fairly minimal in comparison to everything else and a 68020 would rip through that part fairly quickly. But you're always going to bump up against the limits of CD32's ball achingly slow Chip RAM. And, if your decompression routine is running while the blitter's going it'll be slowed down even more.

Quote:
Originally Posted by Gilbert View Post
Also there is the vanilla option of using a different 16 colours for each fighter
Even if you're only using 16 palette entries for each fighter, you'd still need to blit in to all the active bitplanes, which means you're hitting the next limiting factor which is the slow blitter.



The two timing bars here illustrate just how much of a problem this is. It's taking almost a complete frame to merely blit two fighters. Adding an erase step pushes this deep in to 25fps territory and a decompression step would add yet more pain. The test program this is taken from uses a 128 colour background with 64 separate colours for each fighter.

I think the best approach for a game like SF2 on CD32 would be using large AGA hardware sprites. There is a post somewhere on the board with a Blitz Basic (I think) demo doing just that. Add two scrolling 16 colour background layers in dual playfield mode, or ditch the parallax and have a single, but much nicer, 128 colour background.

Quote:
Originally Posted by Gilbert View Post
Problem is number of sprites. Guile has 237 animation frames (facing one way) +24 for win poses (can be halved by only loading one win pose per round) + 7 for projectile animation (sonic boom). Wonder how much memory this would take up?
A lot. Even using hardware sprites, which would be the most memory efficient option. And, remembering that we can't trivially flip them in hardware so we require left and right copies for each frame means that, even with compression, a fair amount of frames would likely have to be ditched. And there's also the audio samples on top of that which also must fit in Chip RAM somewhere. These take up a surprising amount of memory. Even at a reduced quality 11khz sample rate. Realistically, the only thing the CD32 has to its advantage in this scenario is CD music.

B
Old_Bob is offline  
Old 15 January 2021, 22:44   #123
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,693
Quote:
Originally Posted by Gilbert View Post
Thank you, This is a very great response roondar. 17 or 12 fps is actually faster than I was expecting Can you lose a bitplane to make it 128 colours? That would work on Ghouls N Ghosts I think. The most colours I could get on screen on the first level was 112 for the arcade version.
You can certainly use a bitplane less, but this won't really help that much - this will get you no more than a 12% increase in performance at best. Which likely won't translate to a higher frame rate.

As for 12/17FPS, this is really not enough for good gameplay for games like this. Even 25FPS usually doesn't feel "right" when playing, 17 or 12 FPS starts to feel like moving through muck. These games really do kind of need 50FPS to truly feel right.
Quote:
"32+8 colours "brute force" dual layer screen IIRC" I don't fully understand this. Does that mean 32 color screen + a sprite layer? or something else?
It means using all 8 bitplanes (normally this gives you a 256 colour screen) and then using the Blitter to update the background 3 bitplanes (which give 8 colours) while having the front 5 bitplanes (which give 32 colours) scroll through the hardware.
Quote:
Maybe also we could use less colours and then do palette changes with the copper when you reach a scan line? I'm pretty sure you could make it look 98% like the arcade with 60% the number of colours-on screen for example
This is certainly possible, but won't be as flexible as the arcade is. It's quite difficult to make this work with anything other than the static (i.e. background) graphics. Using it to make the enemies change colour is a lot harder unless you restrict them vertically.
roondar is offline  
Old 16 January 2021, 12:02   #124
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 462
Quote:
Problem is number of sprites. Guile has 237 animation frames (facing one way) +24 for win poses (can be halved by only loading one win pose per round) + 7 for projectile animation (sonic boom). Wonder how much memory this would take up?
The memory use of Amiga graphics can be calculated with this formula: (Width / 8) * Height * Bitplanes

Width is always rounded up to the nearest power of 16. So for example if something is 50 pixels wide, it actually consumes 64 pixels worth of Chip RAM. And if the graphic is a blitter object (bob), then the Bitplanes also need a "mask", which adds one extra bitplane. So 16 color bobs means 4 bitplanes + 1 bitplane for the mask. But Sprites don't have the mask cost.

So for example if we take the normal standing pose of the SNES version of Zangief, that frame is of size 64*93 pixels.

So if it was a bob, it would consume (64 / 8) * 93 * 5 = 3720 bytes = 3,72 kb

Now, let's assume that the character has 200 frames of animation. This would be 3,72 kb * 200 = 744 kb.

But that is only the "facing right" frames. If we want the mirrored frames also in RAM, then it consumes double the 744 kb, which is 1,48 megs.

So right away we can see that the whole game can never fit into memory; only this one character eats 75 % of the 2 Megabytes that we have.

And this is just the SNES version character. In the arcade version, even the smallest fighters have much bigger graphics than anything found in the SNES version.
Master484 is offline  
Old 16 January 2021, 12:46   #125
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 891
The first thing you do is think "how do we flip the frames, so we only have to store half"

You could use the CPU... with a 64k word flip buffer

But how can we optimise the flip?

Well.. the solution is to take each frame, and only flip one half of it. So whichever way the character wants to face, you either flip the top half or the bottom half. This reduces your flip CPU cost to around 50%

Of course, there is also a way to flip image data using the blitter in several passes. Again, we'd only need to flip the half of the sprite that needs flipping.

Now I would also hazard a guess, that many characters do have a lot of blank space in their frames. You'd want to really try to avoid storing some of that blank space.

A simple way would be to slice the frames into 16 pixel wide vertical strips, and remove space from top and bottom. This would surely save some memory on quite a few frames.

There are other ways that you could save memory too, by slicing the frames up slightly differently, but I'll leave that for someone else to figure out


And just to add.. if you used one 16 colour playfield for the background, and one 16 colour playfield for one character, and hardware sprites for another character, you would not need to store any masks for the character frames, and you would use very simple D = A blitter modes to draw them (either to the playfield, or into the sprite data)
DanScott is offline  
Old 16 January 2021, 12:57   #126
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 891
Of all the games we talk about, i think that SF2 could translate really well to A1200 / CD32 and produce a version that is not too far from perfect
DanScott is offline  
Old 16 January 2021, 13:13   #127
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,911
Quote:
Originally Posted by DanScott View Post
But how can we optimise the flip?

Well.. the solution is to take each frame, and only flip one half of it. So whichever way the character wants to face, you either flip the top half or the bottom half. This reduces your flip CPU cost to around 50%
This is so easy that its genius. Wow.
Thanks for that, will come in handy with my next game.
Steril707 is offline  
Old 16 January 2021, 13:37   #128
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 891
Quote:
Originally Posted by Steril707 View Post
This is so easy that its genius. Wow.
Thanks for that, will come in handy with my next game.
I learned that one at Core from Simon Phipps. I think they used this method on the main character in Wolfchild.
DanScott is offline  
Old 16 January 2021, 14:53   #129
rare_j
Zone Friend

rare_j's Avatar
 
Join Date: Apr 2005
Location: London
Posts: 1,051
Quote:
Originally Posted by DanScott View Post
I learned that one at Core from Simon Phipps. I think they used this method on the main character in Wolfchild.
Ha ha, that is sneaky. I like it a lot. Took me a minute to figure it out.
rare_j is offline  
Old 16 January 2021, 15:21   #130
Old_Bob
BiO-sanitation Battalion

Old_Bob's Avatar
 
Join Date: Jun 2017
Location: Scotland
Posts: 114
Quote:
Originally Posted by DanScott View Post
The first thing you do is think "how do we flip the frames, so we only have to store half"

You could use the CPU... with a 64k word flip buffer

But how can we optimise the flip?

Well.. the solution is to take each frame, and only flip one half of it. So whichever way the character wants to face, you either flip the top half or the bottom half. This reduces your flip CPU cost to around 50%
I'd also like to say that this is a beautifully sneaky solution. I simply *have* to have a little fiddle around with this...

Quote:
Originally Posted by DanScott View Post
Of course, there is also a way to flip image data using the blitter in several passes. Again, we'd only need to flip the half of the sprite that needs flipping.
At a guess, I think using the CPU would be the best option of the two? Given that the blitter could be drawing one fighter while the 020 chews on the flip for the other?

B
Old_Bob is offline  
Old 16 January 2021, 15:35   #131
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 891
oops.. my bad.. it would be a 128k word flip table, and that would require shifting the original word up to get a long word offset into the table... might be better working with bytes in that case (a 256 byte table)
DanScott is offline  
Old 16 January 2021, 15:47   #132
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 891
Let's compare byte vs. word (just the main flipping of 16 bytes of data in a simple way), assuming a0 points to our source, a1 points to our destination, and a2 points to our flip table:

using a byte flip table (256 bytes):

move.b (a0)+,d0 ;8 cycles
move.b (a2,d0.b),-(a1) ;18 cycles
move.b (a0)+,d0 ;8 cycles
move.b (a2,d0.b),-(a1) ;18 cycles
; total 52 cycles per word


using a word flip table (128kb):

moveq #0,d0 ;4 cycles
move.w (a0)+,d0 ;8 cycles
add.l d0,d0 ;8 cycles
move.w (a2,d0.l),-(a1) ;18 cycles
; total 38 cycles per word
DanScott is offline  
Old 16 January 2021, 15:55   #133
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 891
I wonder if this would work for a 64k table:

Code:
move.w (a0)+,d0  ; 8
add.w d0,d0          ; 4
move.w (a2,d0.w),d0 ;14
addx.w d0,d0       ;4
move.w d0,-(a1)  ;8

38 cycles again.. but table can be 64k... essentialy you are flipping the low 15 bits, and the addx moves the leftmost bit to the right
DanScott is offline  
Old 16 January 2021, 16:29   #134
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,693
On A1200/CD32 it may actually be more effective to run the flipping on the CPU with a small routine that fits in the cache. You could run (part of) the flip while you blit the non-flipped part. Key would be to do the flipping into registers as much as possible and only read/write in 32 bit chunks to keep memory accesses low.

Not tested this, but it does intuitively feel like a reasonable approach.
roondar is offline  
Old 16 January 2021, 16:51   #135
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 891
Quote:
Originally Posted by roondar View Post
On A1200/CD32 it may actually be more effective to run the flipping on the CPU with a small routine that fits in the cache. You could run (part of) the flip while you blit the non-flipped part. Key would be to do the flipping into registers as much as possible and only read/write in 32 bit chunks to keep memory accesses low.

Not tested this, but it does intuitively feel like a reasonable approach.
Definitely!
DanScott is offline  
Old 16 January 2021, 19:32   #136
Gilbert
Registered User
 
Join Date: Sep 2008
Location: UK
Posts: 314
You guys know your stuff! I'm not a proper coder but I thought flipping sprites was fairly common on the Amiga? - even AMOS on A500 had flipping for both sprites and Bobs and it didn't seem to slow it down if at all.

I agree it seems hard to fit all the graphics into memory but we can use the decompression method. I read what Bob wrote about it being hard but I still think the extra power of the CD32's CPU could do it - esp with sprites and dual playfield mode being used to get a close - but not arcade perfect version. The SNES version missed out some animation frames from the arcade and no one really noticed.

I would also say the original Arcade version of Streetfighter is just over 7Mb (it's 58 Megabit) and that has 12 fighters in there. So I think the sprites could take up less space than you think? Maybe we are overestimating? Unless 58 Megabit is wrong - but it is way larger than both the SNES and Megadrive carts.

Quote:
Originally Posted by DanScott View Post
Of all the games we talk about, i think that SF2 could translate really well to A1200 / CD32 and produce a version that is not too far from perfect
I agree but I also think a close version of Ghouls N Ghosts, Strider, Area 88 (UN Squadron) etc are very possible - as shown by the 16 bit consoles.

Quote:
Originally Posted by roondar View Post
You can certainly use a bitplane less, but this won't really help that much - this will get you no more than a 12% increase in performance at best. Which likely won't translate to a higher frame rate.

As for 12/17FPS, this is really not enough for good gameplay for games like this. Even 25FPS usually doesn't feel "right" when playing, 17 or 12 FPS starts to feel like moving through muck. These games really do kind of need 50FPS to truly feel right.
It means using all 8 bitplanes (normally this gives you a 256 colour screen) and then using the Blitter to update the background 3 bitplanes (which give 8 colours) while having the front 5 bitplanes (which give 32 colours) scroll through the hardware.
This is certainly possible, but won't be as flexible as the arcade is. It's quite difficult to make this work with anything other than the static (i.e. background) graphics. Using it to make the enemies change colour is a lot harder unless you restrict them vertically.
Thanks for this roondar. I do think 25fps games feel pretty good if you run the control and logic code at 50fps but then draw everything only every 25fps. I'm sure Rainbow Islands and R-Type on Amiga are both 25fps for example. These would have probably been bad conversions if they ran them at 50fps - less things on screen, maybe smaller screen etc
Gilbert is offline  
Old 16 January 2021, 19:52   #137
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 44
Posts: 3,205
Quote:
Originally Posted by DanScott View Post
using a word flip table (128kb):

moveq #0,d0 ;4 cycles
move.w (a0)+,d0 ;8 cycles
add.l d0,d0 ;8 cycles
move.w (a2,d0.l),-(a1) ;18 cycles
; total 38 cycles per word
On a 68020 you can just do this:
Code:
    move.w  (a0)+,d0
    move.w  (a2,d0.w*2),-(a1)
That *2 is free.
Thorham is offline  
Old 16 January 2021, 20:01   #138
sokolovic
Registered User

sokolovic's Avatar
 
Join Date: Aug 2013
Location: Marseille / France
Posts: 304
Well surprinsgly this dead end thread is becoming very interesting with all the technicall comments of many.
sokolovic is offline  
Old 16 January 2021, 20:35   #139
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Tier 5
Posts: 891
Quote:
Originally Posted by Thorham View Post
On a 68020 you can just do this:
Code:
    move.w  (a0)+,d0
    move.w  (a2,d0.w*2),-(a1)
That *2 is free.
yes of course, I forgot totally about that My vanilla 68k/OCS head seems to be permanently switched on
DanScott is offline  
Old 17 January 2021, 01:10   #140
S0ulA55a551n
Registered User
S0ulA55a551n's Avatar
 
Join Date: Nov 2010
Location: Rhondda, Wales
Age: 43
Posts: 687
Sorry for the slight O/T but people have mentioned just playing on mame. This might interest some

https://www.nintendo.com/games/detai...tadium-switch/

and this

https://www.eurogamer.net/articles/2...intendo-switch
S0ulA55a551n is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
SNES/MD Games Versus The CD32 Versions Gilbert Retrogaming General Discussion 16 14 June 2020 23:45
Why Demos run in perfect resolution in WinUAE but not on real NTSC Amigas? c0dehunter support.Demos 14 04 December 2017 17:11
CD32 compilation Games run on 2mb only..why can't WHDLoad games run on 2mb spannernick support.Games 2 12 July 2017 18:15
WHD games AGA or CD32 versions? fatboy support.Games 5 09 October 2014 14:34
Were CD32 Games Different 2 the Original Amiga Versions? skywalka support.Games 6 11 July 2005 14:32

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 04:13.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.15350 seconds with 15 queries