Conversion Capers: Rygar

[roondar]

Originally Posted by Trachu

Ladies and gentlemen

If I understood you correctly using 16colours BOBs on 5 bitplane screen saves us only 2 colour clocks per word blit.
IF we consider our bobs are 32x32 this means we are saving thanx to this technique 2x2x32=128 colour clocks on drawing each BOB.
Using EHB this would mean we saved 256 colour clocks.

Oh man! I screwed it up
Sorry, my calculations are wrong!

What happened is that I mixed up colour clocks and CPU cycles and subtracted something instead of adding it, so all numbers are wrong.

So here are the (hopefully) correct ones, with the formulas so people can check!

Blitter cycles, according to the HRM:

• 4 cycles for a 1 destination action (clear) (note only 2 cycles are used while clearing)
• 4 cycles for a 1 source/1 destination action (copy)
• 6 cycles for a 2 source/1 destination action (mask)
• 8 cycles for a 3 source/1 destination action (cookie cut)

The HRM measures these in 68000 cycles and not in colour clocks. Converting 68000 cycles to colour clocks = divide the numbers by 2.

Ok, so on to the calculation (cc = colour clock):
To blit a bob, we normally need to use cookie cut mode for all planes to draw it. To erase it again, we need to use copy mode for all planes. So, you'd get the following for a one word/one plane blit: 1*4cc + 1*2cc, or 6cc total for a word.

For 5 planes you then get 30cc per word and for 6 planes you get 36cc per word.

Now, Sandruzzo is proposing to optimize this by drawing only 4 planes on a 5 bitplane screen. This would seem to mean we can use 4*4cc + 4*2cc. However, we obviously need to do something about the remaining plane.

We can't use copy or clear mode because this would leave a big hole in the background. So, we use the mask mode (this is possible). This uses 3cc per word. Also we need to restore the 5th plane, so add another 2cc.

In total, it then takes 4*4cc+1*3cc + 5*2cc = 29cc per word. Saving 1 colour clock per word (3.4% faster than standard).

For 6 bitplanes, it becomes 4*4cc + 2*3cc + 6*2cc = 34cc. This saves 2 colour clocks per word (5.9% faster than standard).

However, there is one more thing to note: blitting something to the screen takes one more word (per plane, per line) if the blit is not aligned to a 16 pixel boundary. This essentially means that a 16x16 blit is actually a 32x16 blit in most cases, a 32x32 is actually a 48x32 one, etc.

And again, note that I'm not counting the extra cost for restarting the blitter.

-----
So, on to your examples. If I didn't screw up again, they'd look like this:

Originally Posted by Trachu

According to your calculations to draw 32x32 sprites on the screen we need:

1. Using 4 hardware sprites it costs us 8x32=256clocks

2. Using 4 bitplane BOB on 4 bitplane screen - 2x40x32=2560clocks (10 Times more??)

3. Using 4 bitplane BOB on 5 bitplane screen - 2x48x32=3072clocks

4. Using 5 bitplane BOB on 5 bitplane screen - 2x50x32=3200clocks

5. Using 4 bitplane BOB on 6 bitplane screen - 2x56x32=3584clocks

6. Using 5 bitplane BOB on 6 bitplane screen - 2x58x32=3712clocks

7. Using 6 bitplane BOB on 6 bitplane screen - 2x60x32=3840clocks

8. Using 3 bitplane BOB on 3 bitplane screen - 2x30x32=1920clocks (Dual playfield mode)

1. Correct, a sprite indeed fetches 2 words per scanline = 256cc
2. Using 4 bitplane BOB on 4 bitplane screen - 3x20x32=1920cc
3. Using 4 bitplane BOB on 5 bitplane screen - 3x29x32=2784cc
4. Using 5 bitplane BOB on 5 bitplane screen - 3x30x32=2880cc
5. Using 4 bitplane BOB on 6 bitplane screen - 3x34x32=3264cc
6. Using 5 bitplane BOB on 6 bitplane screen - 3x35x32=3360cc
7. Using 6 bitplane BOB on 6 bitplane screen - 3x36x32=3456cc
8. Using 3 bitplane BOB on 3 bitplane screen - 3x18x32=1728cc (Dual playfield mode)

So you can see that if at all possible, use sprites. They are vastly more efficient than the blitter ever is. It's a mighty big shame the Amiga's sprites are pretty much relegated to bullets and special effects - they just don't cover enough pixels in regular use!

Again, sorry for all the confusion.

[Trachu]

Originally Posted by roondar

1. Correct, a sprite indeed fetches 2 words per scanline = 256cc
2. Using 4 bitplane BOB on 4 bitplane screen - 3x20x32=1920cc
3. Using 4 bitplane BOB on 5 bitplane screen - 3x29x32=2784cc
4. Using 5 bitplane BOB on 5 bitplane screen - 3x30x32=2880cc
5. Using 4 bitplane BOB on 6 bitplane screen - 3x34x32=3264cc
6. Using 5 bitplane BOB on 6 bitplane screen - 3x35x32=3360cc
7. Using 6 bitplane BOB on 6 bitplane screen - 3x36x32=3456cc
8. Using 3 bitplane BOB on 3 bitplane screen - 3x18x32=1728cc (Dual playfield mode)

So you can see that if at all possible, use sprites. They are vastly more efficient than the blitter ever is. It's a mighty big shame the Amiga's sprites are pretty much relegated to bullets and special effects - they just don't cover enough pixels in regular use!

Again, sorry for all the confusion.

Thanx for explanation. From what i see there is a huge difference (almost 50%) between 4 bitplane sprites on 4 bitplane screen vs 4 bitplane sprites on 5 bitplane screen.
There is a rather huge cost of this, even compared to 6 bitplanes. Why is that???

I believe there is a huge difference in playfield perception between 64px and 128px wide background, so making the ryggar bob is not a cost of blitter, but a cost of having wider paralax effect.
From my perspective it does not matter, which version you used as it is only the relocation of colours and ryggar redrawn on which i am already working on.

[roondar]

Originally Posted by Trachu

Thanx for explanation. From what i see there is a huge difference (almost 50%) between 4 bitplane sprites on 4 bitplane screen vs 4 bitplane sprites on 5 bitplane screen.
There is a rather huge cost of this, even compared to 6 bitplanes. Why is that???

I believe there is a huge difference in playfield perception between 64px and 128px wide background, so making the ryggar bob is not a cost of blitter, but a cost of having wider paralax effect.
From my perspective it does not matter, which version you used as it is only the relocation of colours and ryggar redrawn on which i am already working on.

This is mostly due to me writing 20cc instead of the correct 24cc (4*6cc <> 20 )
So it should've been 3x24x32=2304cc.

[Trachu]

Originally Posted by sandruzzo

Frames are ok. If I have to make rygar bob, I need left and right frame, so I'll spare to flip them during loading time.

We have to take some choice: to go for 32color and background like you've great done. Or go for rygar made by sprite and only 4 sprite for background like it wa before. We can even have only 64 px parallax but with 16 colors

We can even try to go for 64 color and see how it'll look. Just to do some test.

Since under rygars' feet don't get a lot of action, we can spare that grounds' colors, and use them for gfx. We'll do the right color with color, and save some bit plane there. What do you think?

Sorry for background

OK, I have repainted Ryggar completelly. Now it is in universal form using only 10 colours and can be used either as hardware or as bobs.

Final colour relocation is like this:

5 bitplane foreground, 4 bitplane BOBs, Ryggar as BOB, 128px wide background made using hardware sprites 0-7
Bitplanes - colour register
00000 - 00 copperised sprite colour 0
00001 - 01 Foreground, Ryggar, BOBs
00010 - 02 Foreground, Ryggar, BOBs
00011 - 03 Foreground, Ryggar, BOBs
00100 - 04 Foreground, Ryggar, BOBs
00101 - 05 Foreground, Ryggar, BOBs
00110 - 06 Foreground, Ryggar, BOBs
00111 - 07 Foreground, Ryggar, BOBs
01000 - 08 Foreground, Ryggar, BOBs
01001 - 09 Foreground, BOBs
01010 - 10 Foreground, BOBs
01011 - 11 Foreground, BOBs
01100 - 12 Foreground, Ryggar, BOBs
01101 - 13 Foreground, BOBs
01110 - 14 Foreground, BOBs
01111 - 15 Foreground, BOBs
10000 - 16 Foreground
10001 - 17 background sprite colour 1
10010 - 18 background sprite colour 2
10011 - 19 background sprite colour 3
10100 - 20 background sprite colour 1
10101 - 21 Foreground
10110 - 22 Foreground
10111 - 23 Foreground
11000 - 24 background sprite colour 2
11001 - 25 Foreground
11010 - 26 Foreground
11011 - 27 Foreground
11100 - 28 background sprite colour 3
11101 - 29 Foreground
11110 - 30 Foreground
11111 - 31 Foreground

5 bitplane foreground, 4 bitplane BOBs, Ryggar as hardware sprite 0-3, 64px wide background made using hardware sprites 4-7
(Please notice that the second from the left bitplane is always 0 in case of BOBs, hence cookiecut technique can be used on it)
Bitplanes - colour register
00000 - 00 copperised sprite colour 0
00001 - 01 Foreground, BOBs
00010 - 02 Foreground, BOBs
00011 - 03 Foreground, BOBs
00100 - 04 Foreground, BOBs
00101 - 05 Foreground, BOBs
00110 - 06 Foreground, BOBs
00111 - 07 Foreground, BOBs
01000 - 08 Foreground
01001 - 09 Foreground
01010 - 10 Foreground
01011 - 11 Foreground
01100 - 12 Foreground
01101 - 13 Foreground
01110 - 14 Foreground
01111 - 15 Foreground
10000 - 16 Foreground, BOBs
10001 - 17 Foreground, Ryggar, BOBs
10010 - 18 Foreground, Ryggar, BOBs
10011 - 19 Foreground, Ryggar, BOBs
10100 - 20 Foreground, Ryggar, BOBs
10101 - 21 Foreground, Ryggar, BOBs
10110 - 22 Foreground, Ryggar, BOBs
10111 - 23 Foreground, Ryggar, BOBs
11000 - 24 Foreground, Ryggar
11001 - 25 background sprite colour 1
11010 - 26 background sprite colour 2
11011 - 27 background sprite colour 3
11100 - 28 Foreground, Ryggar
11101 - 29 background sprite colour 1
11110 - 30 background sprite colour 2
11111 - 31 background sprite colour 3

[sandruzzo]

Originally Posted by Trachu

OK, I have repainted Ryggar completelly. Now it is in universal form using only 10 colours and can be used either as hardware or as bobs.

Final colour relocation is like this:

5 bitplane foreground, 4 bitplane BOBs, Ryggar as BOB, 128px wide background made using hardware sprites 0-7
Bitplanes - colour register
00000 - 00 copperised sprite colour 0
00001 - 01 Foreground, Ryggar, BOBs
00010 - 02 Foreground, Ryggar, BOBs
00011 - 03 Foreground, Ryggar, BOBs
00100 - 04 Foreground, Ryggar, BOBs
00101 - 05 Foreground, Ryggar, BOBs
00110 - 06 Foreground, Ryggar, BOBs
00111 - 07 Foreground, Ryggar, BOBs
01000 - 08 Foreground, Ryggar, BOBs
01001 - 09 Foreground, BOBs
01010 - 10 Foreground, BOBs
01011 - 11 Foreground, BOBs
01100 - 12 Foreground, Ryggar, BOBs
01101 - 13 Foreground, BOBs
01110 - 14 Foreground, BOBs
01111 - 15 Foreground, BOBs
10000 - 16 Foreground
10001 - 17 background sprite colour 1
10010 - 18 background sprite colour 2
10011 - 19 background sprite colour 3
10100 - 20 background sprite colour 1
10101 - 21 Foreground
10110 - 22 Foreground
10111 - 23 Foreground
11000 - 24 background sprite colour 2
11001 - 25 Foreground
11010 - 26 Foreground
11011 - 27 Foreground
11100 - 28 background sprite colour 3
11101 - 29 Foreground
11110 - 30 Foreground
11111 - 31 Foreground

5 bitplane foreground, 4 bitplane BOBs, Ryggar as hardware sprite 0-3, 64px wide background made using hardware sprites 4-7
(Please notice that the second from the left bitplane is always 0 in case of BOBs, hence cookiecut technique can be used on it)
Bitplanes - colour register
00000 - 00 copperised sprite colour 0
00001 - 01 Foreground, BOBs
00010 - 02 Foreground, BOBs
00011 - 03 Foreground, BOBs
00100 - 04 Foreground, BOBs
00101 - 05 Foreground, BOBs
00110 - 06 Foreground, BOBs
00111 - 07 Foreground, BOBs
01000 - 08 Foreground
01001 - 09 Foreground
01010 - 10 Foreground
01011 - 11 Foreground
01100 - 12 Foreground
01101 - 13 Foreground
01110 - 14 Foreground
01111 - 15 Foreground
10000 - 16 Foreground, BOBs
10001 - 17 Foreground, Ryggar, BOBs
10010 - 18 Foreground, Ryggar, BOBs
10011 - 19 Foreground, Ryggar, BOBs
10100 - 20 Foreground, Ryggar, BOBs
10101 - 21 Foreground, Ryggar, BOBs
10110 - 22 Foreground, Ryggar, BOBs
10111 - 23 Foreground, Ryggar, BOBs
11000 - 24 Foreground, Ryggar
11001 - 25 background sprite colour 1
11010 - 26 background sprite colour 2
11011 - 27 background sprite colour 3
11100 - 28 Foreground, Ryggar
11101 - 29 background sprite colour 1
11110 - 30 background sprite colour 2
11111 - 31 background sprite colour 3

I'll go for rygar bob, and see what happen. What would you prefer?

[saimon69]

Originally Posted by sandruzzo

I'll go for rygar bob, and see what happen. What would you prefer?

[tryingtobefunny]
so now we have its first name: Bob Rygar :P
[/tryingtobefunny]

[sandruzzo]

@Trachu

If you can do some kind of miracle and reduce rygar to 8 colors we'll spare one more coockie cut operation! Maybe we can do the same with enemies.

Gfx tiles are the oldest wrong... On my google drive the correct file is: Level_1_16x16_Tiles.iff

[aros-sg]

sprite or bob: there's a third option: make it partly sprite, partly bob. Biggest part should be sprite. Leave some transparent pixels which you will fill in using a bob to add more/additional colors. If bob parts are small it may be better to draw them using cpu, not blitter.

[sandruzzo]

Originally Posted by aros-sg

sprite or bob: there's a third option: make it partly sprite, partly bob. Biggest part should be sprite. Leave some transparent pixels which you will fill in using a bob to add more/additional colors. If bob parts are small it may be better to draw them using cpu, not blitter.

We have even another option. Doing Rygar with only 8 colors, but having 2 set of animation, and change them on screen and cross colors. We'll have at least 16 color with some flickering

And if we allow to use 1mb of real fast ram we can do a lot more

[Trachu]

Originally Posted by sandruzzo

@Trachu

If you can do some kind of miracle and reduce rygar to 8 colors we'll spare one more coockie cut operation! Maybe we can do the same with enemies.

Gfx tiles are the oldest wrong... On my google drive the correct file is: Level_1_16x16_Tiles.iff

Miracles are my speciality, however from what i can see this cookiecut operation does not save us a lot of cycles, so i Wonder how useful is it...

Originally Posted by aros-sg

sprite or bob: there's a third option: make it partly sprite, partly bob. Biggest part should be sprite. Leave some transparent pixels which you will fill in using a bob to add more/additional colors. If bob parts are small it may be better to draw them using cpu, not blitter.

90% of ryggar sprite will fit into 16px wide, the rest is minimal. In this way we could allocate 6 sprites for 96px wide background. IMHO interesting option.
After some rethinking i see a potential problemm here. Our BOBs would have to use 14+1 colours instead of 15+1, due to colour register association to certain sprites.

[sandruzzo]

Originally Posted by Trachu

Miracles are my speciality, however from what i can see this cookiecut operation does not save us a lot of cycles, so i Wonder how useful is it...



90% of ryggar sprite will fit into 16px wide, the rest is minimal. In this way we could allocate 6 sprites for 96px wide background. IMHO interesting option.
After some rethinking i see a potential problemm here. Our BOBs would have to use 14+1 colours instead of 15+1, due to colour register association to certain sprites.

If rygar is only 16px wide we can go for sprite HW. Opened to all options. That rygar is great! With only 8 colors we cand do it by bob. I know that 2 cycles aren't too much, but since rygar is more or less 16 to 20 px height, we have 4*16 wich give us 64 spared cycles! Not bad!

4 cycles = 2 bitplanes saved

If you provide me .iff file I'll add Rygar as bob. What do you think to have "only" 64 wide background but with 16 colors?

Since I use triple buffer to speed up blitter operation, if we can use only 16 colors for enemies and rygar, we can spare another 4*16 cycles for each gfx tile, which give us at least 64 more cycles, since I'll use only 4 planes third buffer

[sandruzzo]

Just a Thought. Are we sure that blitter is faster than 68000 even with coockie cut operation, since cpu can cache mask and bliter can't?

[roondar]

Originally Posted by sandruzzo

If rygar is only 16px wide we can go for sprite HW. Opened to all options. That rygar is great! With only 8 colors we cand do it by bob. I know that 2 cycles aren't too much, but since rygar is more or less 16 to 20 px height, we have 4*16 wich give us 64 spared cycles! Not bad!

4 cycles = 2 bitplanes saved

If you provide me .iff file I'll add Rygar as bob. What do you think to have "only" 64 wide background but with 16 colors?

I really don't want to be negative here (really, I'm seriously hoping for a good version of Rygar and you seem to be making progress), but you aren't forgetting that saving those 64 odd cycles means you have to start/set up the blitter twice instead of once?

Even if you can get away with only setting four registers (minterm, source, destination, blitsize) and you've got all needed info in data registers you're already using on the order of 56 cycles/28 colour clocks.

(2*move.w dx,dn(ax) + 2*move.l dx,dn(ax) - movem.x would not be faster as the registers are not all sequential in memory)

However, you probably would need to fetch the pointers from somewhere instead of having them ready in data registers and that would add to this time. Not to mention needing an additional blitter wait as well.

If you ask me, the 4+1 trick is mostly useful on larger blits because the gain is quite small and you do need an additional blitter start.

Again, I'm not trying to criticize here - but it seems the optimization you gain will be quite small. It may even end up being eaten up by needing the extra blit.

Not like your idea for using a triple buffer, which will indeed give a massive gain (blitting is some 25% faster compared to using a restore buffer).

Since I use triple buffer to speed up blitter operation, if we can use only 16 colors for enemies and rygar, we can spare another 4*16 cycles for each gfx tile, which give us at least 64 more cycles, since I'll use only 4 planes third buffer

I think I'm not understanding your ideas on triple buffering and the masking of the 5th bitplane.
In my view, it would work something like this:

• Buffer 1 = current shown screen
• Buffer 2 = screen we are building to show next frame
• Buffer 3 = background to restore from when we remove the bobs

If this is true, you'll always need as many planes in all three buffers as you have for the screen, even using your 4 bitplanes drawn/1 bitplane masked idea.

My reasoning is simple: to restore the area which we masked out, we still must have the original data that was there, even though we could mask it out cheaper.

Yet you keep talking about only needing 4 planes for the third buffer. So my question is: how do you actually plan to do this?

I could learn something new here, so I'm curious

Just a Thought. Are we sure that blitter is faster than 68000 even with coockie cut operation, since cpu can cache mask and bliter can't?

Generally, the 68000 will always lose to the blitter. Especially at more complicated stuff like cookie-cut operations or masking and drawing lines/filling.

However, the blitter has a (fixed) startup cost - all those blitter registers need to be set. In some cases it is indeed faster to use the CPU. Extremely small blits might have such a big startup cost that the slower CPU can still end up being faster.

Now do note that even then the blit has to be really small for it to be worthwhile.

An example: the blitter can mask in 6 CPU cycles and cookie cut in 8 CPU cycles per word.

By comparison, for masking the CPU would need to load two sets of data (mask + source) and write to a destination. Even if all these things are in a register and only the result is in memory, you're still looking at a minimum of 2*4+1*8 (=16) CPU cycles* - and that assumes we only use the move instruction, all data is in registers already and no and/or/shifting/etc is used - in reality you'll use more cycles than this.

For cookie cut there is an extra operation so you're looking at 3*4+1*8 (=24) CPU cycles* minimum (again, just looking at memory access here - no and/or/shifting/etc - so the real figures will be higher).

But like I said, if the blit is small enough the CPU can win by virtue of not needing to set a bunch of registers.

*) you could operate on memory directly as well using and/or/etc but this will not make things really any faster.

[sandruzzo]

Originally Posted by roondar

I really don't want to be negative here (really, I'm seriously hoping for a good version of Rygar and you seem to be making progress), but you aren't forgetting that saving those 64 odd cycles means you have to start/set up the blitter twice instead of once?

Even if you can get away with only setting four registers (minterm, source, destination, blitsize) and you've got all needed info in data registers you're already using on the order of 56 cycles/28 colour clocks.

(2*move.w dx,dn(ax) + 2*move.l dx,dn(ax) - movem.x would not be faster as the registers are not all sequential in memory)

However, you probably would need to fetch the pointers from somewhere instead of having them ready in data registers and that would add to this time. Not to mention needing an additional blitter wait as well.

If you ask me, the 4+1 trick is mostly useful on larger blits because the gain is quite small and you do need an additional blitter start.

Again, I'm not trying to criticize here - but it seems the optimization you gain will be quite small. It may even end up being eaten up by needing the extra blit.

Not like your idea for using a triple buffer, which will indeed give a massive gain (blitting is some 25% faster compared to using a restore buffer).



I think I'm not understanding your ideas on triple buffering and the masking of the 5th bitplane.
In my view, it would work something like this:

• Buffer 1 = current shown screen
• Buffer 2 = screen we are building to show next frame
• Buffer 3 = background to restore from when we remove the bobs

If this is true, you'll always need as many planes in all three buffers as you have for the screen, even using your 4 bitplanes drawn/1 bitplane masked idea.

My reasoning is simple: to restore the area which we masked out, we still must have the original data that was there, even though we could mask it out cheaper.

Yet you keep talking about only needing 4 planes for the third buffer. So my question is: how do you actually plan to do this?

I could learn something new here, so I'm curious



Generally, the 68000 will always lose to the blitter. Especially at more complicated stuff like cookie-cut operations or masking and drawing lines/filling.

However, the blitter has a (fixed) startup cost - all those blitter registers need to be set. In some cases it is indeed faster to use the CPU. Extremely small blits might have such a big startup cost that the slower CPU can still end up being faster.

Now do note that even then the blit has to be really small for it to be worthwhile.

An example: the blitter can mask in 6 CPU cycles and cookie cut in 8 CPU cycles per word.

By comparison, for masking the CPU would need to load two sets of data (mask + source) and write to a destination. Even if all these things are in a register and only the result is in memory, you're still looking at a minimum of 2*4+1*8 (=16) CPU cycles* - and that assumes we only use the move instruction, all data is in registers already and no and/or/shifting/etc is used - in reality you'll use more cycles than this.

For cookie cut there is an extra operation so you're looking at 3*4+1*8 (=24) CPU cycles* minimum (again, just looking at memory access here - no and/or/shifting/etc - so the real figures will be higher).

But like I said, if the blit is small enough the CPU can win by virtue of not needing to set a bunch of registers.

*) you could operate on memory directly as well using and/or/etc but this will not make things really any faster.

Thanks for explanation. Third buffer is used to pick up baground data so we spare one opertation:

from

01) save screen
02) blit bob
03) restore screen

to

01) blit bob
02) restore screen

Third buffer, since it's used to restore bobs' from, if they use only 4 plane, I can keep it at 4 planes, since it's not used to display data on screen

this will give us extra power when we have enemies on screen. If we gaine a litte power from only 3 plane blit, we can use interleaved bitplane and save cpu cicles. But we have to be sure that its' the better coiche

[roondar]

Originally Posted by sandruzzo

Thanks for explanation. Third buffer is used to pick up baground data so we spare one opertation:

from

01) save screen
02) blit bob
03) restore screen

to

01) blit bob
02) restore screen

Third buffer, since it's used to restore bobs' from, if they use only 4 plane, I can keep it at 4 planes, since it's not used to display data on screen

this will give us extra power when we have enemies on screen. If we gaine a litte power from only 3 plane blit, we can use interleaved bitplane and save cpu cicles. But we have to be sure that its' the better coiche

Ok, thanks for the explanation.
But that does make me wonder: how do you deal with restoring the planes behind the bob?

Say you have a 4 plane bob on a 5 plane screen. If you just blit 4 planes, whatever was on plane 5 stays on plane five, which would screw up your graphics as some or all pixels of the bob you just drew on screen won't have the right colours.

So, you pretty much need to mask out the 5th plane with a second blit.

Now when you restore the bob, you then also need to restore the 5th plane or you'll have a hole in the background.

You don't store this information in your third buffer, it can't be restored from the buffer you are restoring to either. And using the buffer you're currently showing wouldn't work either because you don't know if the 5th plane is intact there.

It still seems to me you'd need that 5th plane in the third buffer?
Or am I missing something really obvious here?

[sandruzzo]

Originally Posted by roondar

Ok, thanks for the explanation.
But that does make me wonder: how do you deal with restoring the planes behind the bob?

Say you have a 4 plane bob on a 5 plane screen. If you just blit 4 planes, whatever was on plane 5 stays on plane five, which would screw up your graphics as some or all pixels of the bob you just drew on screen won't have the right colours.

So, you pretty much need to mask out the 5th plane with a second blit.

Now when you restore the bob, you then also need to restore the 5th plane or you'll have a hole in the background.

You don't store this information in your third buffer, it can't be restored from the buffer you are restoring to either. And using the buffer you're currently showing wouldn't work either because you don't know if the 5th plane is intact there.

It still seems to me you'd need that 5th plane in the third buffer?
Or am I missing something really obvious here?

my pleasure. You're right, i did saw it! Back buffer will be always 5 plane. So we left with direct bob cycle spare. It seems few, but I think when we'll have a lot of them on screen we can save a lot.

Like I said, we can even try all 5 planes, and see if we can affort it. I'll go for interleaved planes and see How it works.

Just waiting for right tiles.

[sandruzzo]

Originally Posted by Trachu

Miracles are my speciality, however from what i can see this cookiecut operation does not save us a lot of cycles, so i Wonder how useful is it...



90% of ryggar sprite will fit into 16px wide, the rest is minimal. In this way we could allocate 6 sprites for 96px wide background. IMHO interesting option.
After some rethinking i see a potential problemm here. Our BOBs would have to use 14+1 colours instead of 15+1, due to colour register association to certain sprites.

Mate, I would like to go with interleaved bitplanes, so feel free to use the whole 32 colors as you like.

[Trachu]

Originally Posted by sandruzzo

Mate, I would like to go with interleaved bitplanes, so feel free to use the whole 32 colors as you like.

I am not sure did i understood everything here.
So you have found out that lowering the planes for bobs is not quite beneficial like you think it is?

What i know for sure is Amiga architecture is an ancient version of multicore systems we use today. It has 3 CPUs - Motorola, Blitter and copper sharing the same memory subsystem. The most optimal way is to use them all together in the same time, which is not easy because they requie the same memory subsytem.
What i am saying is it is true that Blitter is almost always faster than CPU, however it is also true that Blitter alone is slower than Blitter and CPU working together at the same time.
This means it is not a bad idea to use CPU to draw for example Ryggar, while Blitter can draw others (no nasty bit)

[sandruzzo]

Originally Posted by Trachu

I am not sure did i understood everything here.
So you have found out that lowering the planes for bobs is not quite beneficial like you think it is?

What i know for sure is Amiga architecture is an ancient version of multicore systems we use today. It has 3 CPUs - Motorola, Blitter and copper sharing the same memory subsystem. The most optimal way is to use them all together in the same time, which is not easy because they requie the same memory subsytem.
What i am saying is it is true that Blitter is almost always faster than CPU, however it is also true that Blitter alone is slower than Blitter and CPU working together at the same time.
This means it is not a bad idea to use CPU to draw for example Ryggar, while Blitter can draw others (no nasty bit)

Spare 2 cycle per planes is a good Idea, and even if they seems not so much we have to think that 2 * bob height. If we can have 16 colors for enemies and rygar but only 8 at the time used for bob would be great. But if we have to sacrifice to much visual quality, we change way.

i did a test and seems that we can have 20 bobs 32*32 at full 50hz.

Btw, how is going on with tiles?

[Trachu]

Originally Posted by sandruzzo

Spare 2 cycle per planes is a good Idea, and even if they seems not so much we have to think that 2 * bob height. If we can have 16 colors for enemies and rygar but only 8 at the time used for bob would be great. But if we have to sacrifice to much visual quality, we change way.

i did a test and seems that we can have 20 bobs 32*32 at full 50hz.

Btw, how is going on with tiles?

We can have Ryggar alone in 3 bitplanes as it seems it does not affect him visually lowering the colours from 10 to 8, there is however small difference if you compare original 12 vs 8. It is just a difference, dunno to tell which one is better as i have redrawn some of its elements to accomodate to the situation.

Also most of Ryggar poses can fit into 16px wide, only for some i would requie additional 16px

BOBs must stay like they are now (4 bitplanes), each colour reduction will have its visual cost.

tiles are on its way ;-)