Good explanation why half-brite is too slow for game engines?

[ImmortalA1000]

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).

[ross]

Originally Posted by ImmortalA1000

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).

It depends on how the Amiga architecture works.

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.

[kamelito]

And if you’ve fast memory?

[roondar]

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:

• A 320x256x4 (16 colour) screen takes 40960 bytes of memory, which Denise needs to read every frame
• A 32x32 BOB drawn to a 4 bitplane (16 colour) screen requires reading, masking and updating 3072 bytes in memory (plus reading and updating another 1536 bytes in memory to erase it later)
• A 320x256x6 (EHB/64 colour) screen takes 61440 bytes, which Denise needs to read every frame
• A 32x32 BOB drawn to a 6 bitplane (EHB) screen requires reading, masking and updating 4608 bytes in memory (plus reading and updating another 2304 bytes in memory to erase it later)

Basically, this all means that moving from 16 colours to 64 colours and drawing a BOB means the Blitter has to do 1,5x as much work to draw the same object in 16 colour mode. On top of that, Denise has to read 1,5x as many bytes from memory to display the screen. And while Denise is reading from memory, the Blitter and CPU can't access chip memory.

Hopefully this helps explain it a bit.

---

Originally Posted by kamelito

And if you’ve fast memory?

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.

[saimon69]

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

[roondar]

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.

[sandruzzo]

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...

[saimon69]

Originally Posted by roondar

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.

In 1988 me and a friend of mine were dreaming to create an R-Type inspired shooter in EHB; am still not a coder wonder if combined with interleaving and masking like powder did use at 16 colors should be possible to have some nice stuff, or maybe just 32 with a touch of EHB for traqnsparencies...

[roondar]

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.

[saimon69]

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

[Tigerskunk]

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.

[roondar]

Originally Posted by Steril707

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.

Yeah, I tend to agree.

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.

[Daedalus]

Originally Posted by roondar

Interesting idea though. Might also work for 5 bitplane screens.

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.

[ImmortalA1000]

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.

[Galahad/FLT]

Originally Posted by ImmortalA1000

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.

EHB isnt really needed, subtle dynamic changing of a palette can really help a game with colour, something like Alien Syndrome can benefit from it.

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.

[jotd]

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...)

[gimbal]

When you describe it like that it almost sounds like the earliest version of a pixel shader

[roondar]

Originally Posted by gimbal

When you describe it like that it almost sounds like the earliest version of a pixel shader

I've read an interview with a NVidia engineer ages ago who said that one of the inspirations for pixel shaders was the Amiga's Copper chip

[Galahad/FLT]

Originally Posted by jotd

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...)

How big are the actual levels, is it not possible to change to blitting the entire map in memory and having a restore copy?

[viddi]

Wasn't the Lionheart spider cave level EHB?