Interleaved graphics in Blitz

[earok]

I'm starting to plan out some sort of system for interleaved graphics in Blitz. Before I dive too deep into it I wanted to check if there are any glaring holes in my general thought process.

- First, I'd need to recalculate the values for both the bitplane pointer offsets and the linemod settings for the screen bitmap to make sense for interleaving (setting the values in the bitmap newtype directly).

- Secondly, I'd need to configure a "virtual" bitmap (using CludgeBitmap) that points to the same memory space and is the same size, but is only a single bitplane. This would be used for the built in Blit functions.

- Thirdly, I'd need to come up with a function that converts shape objects into a single bitplane, but with an extended repeating cookie. When I blit these shapes I'd need to multiply the Y value by the number of bitplanes so that it blits to the right place.


My main concern is maybe scrolling won't work with DisplayBitmap, given that it's designed to be used with non-interleaved bitmaps - Should I try it and see?

[ReadOnlyCat]

Originally Posted by earok

- First, I'd need to recalculate the values for both the bitplane pointer offsets and the linemod settings for the screen bitmap to make sense for interleaving (setting the values in the bitmap newtype directly).

Yup, the offsets between bitplanes would be only one line wide (or more depending on your scrolling needs) and the line modulos need to be as many lines wide as you have bitplanes minus one (if one bitplane : zero, if two : one line wide, if three: two lines wide, etc.).

Originally Posted by earok

- Thirdly, I'd need to come up with a function that converts shape objects into a single bitplane, but with an extended repeating cookie. When I blit these shapes I'd need to multiply the Y value by the number of bitplanes so that it blits to the right place.

Yup, you also need to adjust that depending on which bitplanes you want to modify, not all blits will modify all bitplanes.

In order to speed up operations you may still want to operate selectively on bitplanes. For example if a blitter object (BOB) only needs to be drawn on bitplane 3 and have all other bitplanes masked you will have to do at least two blits: one cookie cutter for bitplane 3 (4 channels blit) and one "cookie cutter clearing" for the other bitplanes (3 channels blits this time).

Originally Posted by earok

My main concern is maybe scrolling won't work with DisplayBitmap, given that it's designed to be used with non-interleaved bitmaps - Should I try it and see?

Vertical/horizontal scrolling will work just like for non interleaved bitmaps.

Exotic modulos already work just fine with any type of scrolling, as long as you are pre-drawing the parts of the bitmap which are not yet visible on screen, it does not matter which bitplane they belonged to before the scrolling.

The hardware does not make any difference between interleaved bitmaps or regular ones, it just obeys the modulos in all cases and interleaved bitmaps are just regular bitmaps with larger modulos.

[earok]

Thanks @ReadOnlyCat, I gave it a go and it seems to work as expected!

If anyone's interested, I've pushed a rudimentary demo to my github - https://github.com/earok/BlitzBasicDemos

[Daedalus]

Nice, I'll check it out! The lowest depths of chipset access have always been something I haven't really got to grips with.

[earok]

Originally Posted by Daedalus

Nice, I'll check it out! The lowest depths of chipset access have always been something I haven't really got to grips with.

Cheers

There isn't anything that lowlevel with what I've done, I've basically just tricked Blitz into supporting interleaved by changing the _linemod (difference in bytes between lines) and _data (difference in bytes between bitplanes) settings of the bitmap newtype.

Actually, I'll go into a bit more detail here, in case anyone was interested in the ins and outs of the setup -

With the regular Blitz graphics setup (ALBM), each bitplane is contiguous in memory. So if you have a four bitplane bitmap, an abstract representation would be like.

11111111
11111111
11111111
11111111
22222222
22222222
22222222
22222222
33333333
33333333
33333333
33333333
44444444
44444444
44444444
44444444

If you were to blit a shape to it, it'd be something like -

11111111
1______1
1______1
11111111
22222222
2______2
2______2
22222222
33333333
3______3
3______3
33333333
44444444
4______4
4______4
44444444

So, Blitz would use the blitter four times to blit the shape since there's a gap between the memory usage.

With interleaved graphics, each bitplane is rendered line-by-line rather than contiguously. So something like:

11111111
22222222
33333333
44444444
11111111
22222222
33333333
44444444
11111111
22222222
33333333
44444444
11111111
22222222
33333333
44444444

If we were to blit the same shape, it'd be something like -

11111111
22222222
33333333
44444444
1______1
2______2
3______3
4______4
1______1
2______2
3______3
4______4
11111111
22222222
33333333
44444444

So we only need to use the blitter once - a longer blit, but since we're not engaging the CPU to set up four separate blits, it'll be faster. The downside (and I suspect this is why Blitz isn't configured like this by default) is that it massively increases cookie size, so you'd need to take more care with chipram.

(Edit - I haven't tested extensively but it seems Blitz still will blit a non-interleaved shape to an interleaved bitmap correctly. What this means is that you could keep your shapes non-interleaved to cut down cookie size, but still have your tiles interleaved for a little more efficiency with the block/blockscroll functions)

What my rough implementation on the git repo does is:
- Convert a regular bitmap to interleave
- Create a "virtual" bitmap (with cludgebitmap) that's only one bitplane, but the height is multiplied so it uses the same memory space as the regular bitmap.
- Convert a regular shape to a 1-bitplane interleaved equivalent
- Blits that shape to the virtual bitmap (multiplying the Y by the number of bitplanes)

[carrion]

I think I'll use this method in my current project. But wanted to make some things clear.
With this setup of bitmaps do I still use Blitz's blotting commands? QBlit? BBlit? Block? Scroll? Or do I have to implement mine? I confused a bit.
TIA.

btw Earok:
Your's Kiwi game and Alar City... are they developed in Blitz 2.1?

[earok]

Originally Posted by carrion

I think I'll use this method in my current project. But wanted to make some things clear.
With this setup of bitmaps do I still use Blitz's blotting commands? QBlit? BBlit? Block? Scroll? Or do I have to implement mine? I confused a bit.
TIA.

btw Earok:
Your's Kiwi game and Alar City... are they developed in Blitz 2.1?

Yes to all of that. you can still use all of those commands. The way I handle interleaved bitmaps is pretty much identical to handling regular bitmaps, except I treat it like it's a really tall, single bitplane bitmap (so a 320*128*5 bitplane bitmap would be treated as though it's a 320*640*1 bitplane bitmap).

It's not very intuitive to explain but hopefully the demos make things clear.

There's one downside to interleaved graphics in that, if you're blitting your bobs in interleaved format, it's extremely chipram heavy since the size of your mask is identical to the entire size of your core graphic (rather than just being the size of a single bitplane). But of course that's not a disadvantage for tiles, and you can still blit regular bobs to an interleaved bitmap.