05 July 2020, 15:26 | #1 |
Registered User
Join Date: Feb 2009
Location: london/england
Posts: 1,347
|
Good explanation why half-brite is too slow for game engines?
I was searching for something I would assume was going to be an easy result to get out of Google but turns out there really isn't a thread on it anywhere I could find. I searched for extra half brite on here too as a title only search and got nothing.
I know you are manipulating 6 bitplanes and so it would be 1/5 additional CPU time or chipset time to finish graphic operations but I am reasonably certain that was not the only drawback of using EHB to try and do a 50fps scrolling game engine with blits all over the place (like an EHB version of SF2 would require). Does anybody know of a site that goes into technical details about this sort of issue? (I should probably search for that EHB arcade style game Bullfrog released but then again Bullfrog were no Shaun Southern/Adrian Edmonson class of Amiga 68k hardware bashing coders). |
05 July 2020, 16:13 | #2 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,534
|
Quote:
To put it simply (it is more complex than that, but it is to give a general idea): with 6 bitplanes the processor access to shared memory (chip ram) occurs at half speed compared to when there are 4 bitplanes. Furthermore, also the blitter has fewer cycles available to move more data. And unlike the double playfield mode, which uses also 6 bitplanes, much more data need masking because there is no separation in the color table. So yes, half-brite mode is very slow. |
|
05 July 2020, 23:08 | #3 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,894
|
And if you’ve fast memory?
|
05 July 2020, 23:25 | #4 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
To add a bit to what ross posted, consider looking at it in terms of how much memory is involved. See, at it's core, it's all a question of how much data needs to be updated to draw something to the screen and how much data needs to be read from memory to show the screen.
An example might help here:
Hopefully this helps explain it a bit. --- Adding fast memory does help the CPU, it will run at full speed regardless of the screenmode when the code & data are in fast memory. This won't help the Blitter though. And the Blitter is what is usually the bottleneck for games. |
06 July 2020, 02:38 | #5 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,678
|
And that's why Sandruzzo had to cut down to 256 width for its Rygar test, to have in EHB a number of bytes equivalent to that of a 16 color screen to read, right?
However it should still be usable in 25FPS on paper |
06 July 2020, 10:27 | #6 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
I can't recall what Sandruzzo wrote about Rygar's DMA use, but it seems a logical conclusion.
As for 25FPS, well - it's still going to be considerably slower than 5BPL or 4BPL running at 25FPS. But sure, you might be able to create something nice with it that way. |
07 July 2020, 16:47 | #7 |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,345
|
I had to resuce to 256*192 pixel to have more free cycles to move more objects. We're talking about balance between colors' and screen size. If only commodore made trap door ram, outside bitplanes' bus...
|
07 July 2020, 23:16 | #8 | |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,678
|
Quote:
|
|
07 July 2020, 23:27 | #9 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Dynamically switching bitplanes on and off is such a neat and Amiga specific trick. I should really look at Powder to see what the end result looks like. Makes me wonder if more games did that?
Thinking about it some more, if you don't need the 6th bitplane for anything but shadows/transparencies you would be able to save a big part of the cost (i.e. you could get away with blitting only 5 planes for your objects). You'd still lose out compared to doing straight 5 bitplanes, but not by as much as full EHB. The downside would be that you'd have to have a pretty static 6th bitplane for that to work well. Interesting idea though. Might also work for 5 bitplane screens. |
08 July 2020, 03:08 | #10 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,678
|
This image was one of the work anim for an unused enemy ship; you can see in the bottom right the available palettes that were usable turning on or off some bitplanes toghether with masks beside the full 16 colors palette
|
08 July 2020, 07:15 | #11 |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,806
|
EHB could be used for stuff like point'n click adventure games, but for fast paced action games that need a lot of objects on screen it's not really suited.
|
08 July 2020, 10:34 | #12 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
The Amiga OCS chipset is (IMHO anyway) pretty clearly optimized for two modes in particular: 4 bitplanes and Dual Playfield. Both have the full sprite palette available for sprite-only use and both perform around the same level in terms of how many BOBs you can push. On top of that, 4 bitplanes also maximizes CPU throughput. Action games do best (again, IMHO) when they focus on one of these two modes. Using 5 bitplanes is often problematic because of the speed penalty to blits. Moving to EHB makes that even worse. |
|
08 July 2020, 15:45 | #13 |
Registered User
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 6,415
|
Indeed, I don't think it's the case that EHB itself is slow, but more simply due to dealing with 6 bitplanes. I'm working on a game at the moment that originally used EHB, but was simply too slow for what I needed to do. With a very minimal impact on the artwork, reducing it to 32 colours and constructing a palette with strategically-placed half-brightness shades, I was able to achieve the very same effect with 5 bitplanes - blitting to the 5th bitplane created a shadow effect, and the difference in speed was enough to get what I needed out of the game. 4 bitplanes would be even better speed-wise of course, but then the significantly reduced colours would impact the artwork more than I would like.
|
07 July 2021, 23:57 | #14 |
Registered User
Join Date: Feb 2009
Location: london/england
Posts: 1,347
|
Very sorry, I should really keep track of my sporadic thread posting! My day to day memory is pretty shafted since the whole CV-19 stuff.
I wish people wouldn't mention 16 colour mode, the ST is a 16 colour computer not the Amiga so it is NOT an option Let's stick to 32 colours for example. But I think I get what you all mean, more data to move AND less DMA time with each bitplane added so it's not just the extra 320x200x1/8byte per screen. It is not just 40kb vs 48kb of screen data to be updated that is the hit and that was sort of what I remember people talking about, other implications above the 20% increase in demand on chipset bandwidth and/or 20% decrease in DMA time for those graphic operations. To be fair EHB is a free bonus, combined with the Copperlist it is a nice screen mode (I assume you can change all 32 palette registers in the time it takes for 1 scanline to be traversed by the CRT gun?) and anything you can do with it is a bonus. Of course there are plenty of crap coded arcade game engines I do like, they sit inside things like Rocket Ranger or It Came from the Desert and not inside arcade conversions/knock-offs. Defender of the Crown is indeed CDTV EHB game and not a CD32 AGA game. I would like to know of anything with Reflections/Magnetic Fields level of coding skill that was written to use EHB to see what the theoretical maximum would be. Like I said Bullfrog were C coding sandal freaks and of zero interest for me back then personally so I never checked out Fusion beyond the coverdisk demo. Perhaps FAST RAM would help, perhaps just forgetting the masking and doing blind blits of everything on the screen...dunno as I am not an ASM coder or expert on the Amiga Hardware Reference Manual. There are lots of implications to consider and some I still don't know technically in relation to other functions of the chipset required Biggest problem is there is a HUGE difference between 32 and 64 EHB color modes. Maybe one day I will share my Amiga Alien Syndrome stuff I was working on before CV-19 but for those sort of lush subtle palettes you need EHB, forget 16 colours for the quality feel of arcade graphics as even 32 colours looks a bit too dithered and compromised most of the time except with things like Gradius with a lot of solid black background layer, which you can bring down to 32 colour mode. |
08 July 2021, 00:47 | #15 | |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,034
|
Quote:
Takes a good graphics artist and a good coder than can articulate what colours can change so they can be altered throughout a level, but it can be effective. Then if you largely have a static screen when it comes to bosses, then maybe change to EHB. |
|
08 July 2021, 16:01 | #16 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,447
|
Supercars 2 uses EHB for some static images and also for the main game. Notice the shades everywhere: it's because of the extra plane
Besides, it uses blitter for scrolling, and still manages to be smooth enough. Quite a performance. Then I adapted it to AGA using EHB "emulation" with one extra plane (I had to use 7 planes to benefit from more colors). My palette is 64 colors + 64 dimmed colors. The shades are still working, but the game is slower even on a A1200/060 + fastmem and some 020 opts. Blitter is indeed the bottleneck. (plus the game uses blitter interrupts to parallelize blitter computations/clips with actual blitter operations, which is very smart but since it doesn't use interleave mode, that means 7 blits for each object + scenery = 7 interrupts...) Last edited by jotd; 08 July 2021 at 16:20. |
09 July 2021, 13:11 | #17 |
cheeky scoundrel
Join Date: Nov 2004
Location: Spijkenisse/Netherlands
Age: 43
Posts: 7,104
|
When you describe it like that it almost sounds like the earliest version of a pixel shader
|
09 July 2021, 13:23 | #18 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
|
09 July 2021, 13:30 | #19 | |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,034
|
Quote:
|
|
09 July 2021, 13:55 | #20 |
Moderator
Join Date: Apr 2006
Location: Germany
Age: 44
Posts: 4,042
|
Wasn't the Lionheart spider cave level EHB?
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
which game made the best use of half bright mode? | donnie | Retrogaming General Discussion | 66 | 18 April 2022 15:31 |
Converting a given palette to Extra Half-Brite | roondar | Coders. General | 19 | 11 July 2020 06:33 |
Query about Extra Half-Brite (EHB) | Foebane | Amiga scene | 15 | 13 September 2015 12:18 |
How do pseudo-3D racing game engines work? | absence | Coders. General | 2 | 29 May 2010 00:05 |
[half OT] Good news! Winamp 5.0x no longer interferes with WinUAE (fullscreen)! | andreas | support.WinUAE | 2 | 22 August 2004 02:26 |
|
|