How do I erase part of the Bitmap on Dual Playfield ?

[Shatterhand]

Let's say I want to erase a part of my bitmap the quickest way possible while displaying it on the foreground of my dual playfield display.

I thought I could create a shape with all its pixels in color 0, then just blit (or block or whateve) that shape on the area I want to delete.

Except transparents pixels are just "ignored". They aren't drawn on the bitmap, thus they don't erase anything.

Is there any way to do this? I know the Queue function, but that's not what I want to do. I also know CLS but I don't want to clear the WHOLE bitmap.

I tried using "Blitmode Erasemode" but that didn't do anything

Thank you in advance!

EDIT: Never Mind... just figured it out.

If you create a shape from a bitmap you just used CLS it won't work. But if you create a shape from a loaded bitmap with transparent pixels, it works.

Go figure.

[E-Penguin]

I wonder whether you could use blitter fill mode?

http://amigadev.elowar.com/read/ADCD.../node0122.html

[Zener]

You can just try using Boxf with color 0

[Shatterhand]

Originally Posted by Zener

You can just try using Boxf with color 0

Boxf is kinda slow though.

[roondar]

Interesting... What kind of Blitter command are you using in Blitz to clear the bobs?

See, it rather surprises me that the 'colour' matters - a restore/clear blit should not use any mask at all, it should just draw whatever is in the buffer. Only a 'cookie-cut' or mask blit should do that and they're much slower.

Makes me wonder if Blitz accidentally uses one of those more expensive operations.

[Master484]

Let's say I want to erase a part of my bitmap the quickest way possible while displaying it on the foreground of my dual playfield display.

Are you trying to find a method that is faster than the normal "Qblit-UnQueue" process?

I have tried to do this myself, with a custom made "dirty rectangles" method, using "Blits" to draw my objects and "Blocks" to clean them. And I got quite close to the speed of "Qblit-UnQueue", but still, the Qblit-UnQueue was clearly faster, and much easier to use. And I'm quite convinced that it's the best option to clear graphics in Blitz dual PF if you want a 50 FPS game.

But if you somehow manage to find a drawing-erasing method that beats QBlit-Unqueue in speed, then tell me, so that I can use it in my next project.

Interesting... What kind of Blitter command are you using in Blitz to clear the bobs?

In a dual playfield game where front playfield is used only to display moving objects, Bobs are usually drawn with "Qblit" and erased with a simple "UnQueue" command. And these commands are very fast.

Qblits use "Queues", which I think store the positions/areas covered by each blit. And when the "Unqueue" command is given, all these areas are then cleared. And the clear happens in 16 pixel horizontal strips. So I think the whole process uses some kind of "dirty 16 pixel strips" to mark the areas that need to be cleared, and the clear itself is a fast blitter operation, as fast as the fastest Blitz drawing command "Block", or even faster.

But if you want to erase graphics without using the "Qblit/Unqueue" method, then the next best choice is to draw a shape with "BlitMode" set to "Erasemode", just as Shatterhand mentioned.

I have tested this in the past, and I think that after Blitmode is set to erasemode, the drawn shape will then erase all those pixels that are "solid" in the shape that you use for the erasing. Pixels of color 0 will not cause an erase, but all other colors will. So if you want a box shaped "erasing tool", fill the whole shape with some other color than 0, and it should work.

Also I think there is a command called "autocookie ON/OFF" or something, which can be used to create shapes without a transparency mask. This should make shapes faster to draw, and also now the color 0 should erase all pixels under it, just like the "Block" command does. But I haven't tested this command so much.

[roondar]

Thanks for the explanation of queue/unqueue. One of the drawbacks of primarily using assembly is that you don't always know the method used by other environments like Amos/Blitz. So, queue/unqueue does not actually restore, but simply clears the previously occupied rectangles when unqueue is run?

Because that does sound like what Shatterhand might want to use/need. Even though he says he doesn't - he probably has his reasons I suppose. I learned a long time ago not to assume I know better than the programmer of a project itself

That said, it doesn't quite explain why Shatterhand needs to use a specially prepared Blitter object for his 'clear' blits though (given he doesn't actually use queue/unqueue). It still seems very odd to me that a clearing/restoring blit differentiates between transparant and solid pixels as this is not how that would work in assembly unless a more expensive blit is done than is needed.

[Shatterhand]

Originally Posted by Master484

Are you trying to find a method that is faster than the normal "Qblit-UnQueue" process?

I have tried to do this myself, with a custom made "dirty rectangles" method, using "Blits" to draw my objects and "Blocks" to clean them. And I got quite close to the speed of "Qblit-UnQueue", but still, the Qblit-UnQueue was clearly faster, and much easier to use. And I'm quite convinced that it's the best option to clear graphics in Blitz dual PF if you want a 50 FPS game.

But if you somehow manage to find a drawing-erasing method that beats QBlit-Unqueue in speed, then tell me, so that I can use it in my next project.

In a dual playfield game where front playfield is used only to display moving objects, Bobs are usually drawn with "Qblit" and erased with a simple "UnQueue" command. And these commands are very fast.

Qblits use "Queues", which I think store the positions/areas covered by each blit. And when the "Unqueue" command is given, all these areas are then cleared. And the clear happens in 16 pixel horizontal strips. So I think the whole process uses some kind of "dirty 16 pixel strips" to mark the areas that need to be cleared, and the clear itself is a fast blitter operation, as fast as the fastest Blitz drawing command "Block", or even faster.

But if you want to erase graphics without using the "Qblit/Unqueue" method, then the next best choice is to draw a shape with "BlitMode" set to "Erasemode", just as Shatterhand mentioned.

I have tested this in the past, and I think that after Blitmode is set to erasemode, the drawn shape will then erase all those pixels that are "solid" in the shape that you use for the erasing. Pixels of color 0 will not cause an erase, but all other colors will. So if you want a box shaped "erasing tool", fill the whole shape with some other color than 0, and it should work.

Also I think there is a command called "autocookie ON/OFF" or something, which can be used to create shapes without a transparency mask. This should make shapes faster to draw, and also now the color 0 should erase all pixels under it, just like the "Block" command does. But I haven't tested this command so much.

I was actually trying to use BLOCK on objects that are always aligned on 16 pixels increments in the X Axis, even though they are not background. But there's no queue for Blocks so I would need to manually erase those objects from screen. The quickest way I found out was to block an empty shape on the spot before doing the block on its new position. I wanted to know if this would be faster than thq qblit/unqueue method.

It worked on 68040 Winuae... on my 68k A600 it didn't. And it was much hassle to keep a list of objects that I would draw with Block and another list with objects I would draw with Blit/QBlit so I kinda just gave up.

You gave some very valuable tips there

[Master484]

So, queue/unqueue does not actually restore, but simply clears the previously occupied rectangles when unqueue is run?

Yes. Unqueue simply clears pixels, erasing the shape and all other contents of the bitmap at that spot.

This is why it's often used on a dual playfield where the front PF doesn't have any background graphics.

But it can be used in a normal single playfield too, by using the commands alternative form: "Unqueue, source bitmap". And now instead of erasing the command will restore background graphics from an external "restore bitmap" which holds a "clean copy" of the background graphics. And this is almost as fast than the erase operation.

There is also another 3 command set: BBlit/Buffer/Unbuffer, which works in the same way, except that this one always copies the background under the shape and then restores it. No extra bitmap needed, but instead it needs "Buffers", which you must give a size in bytes. And all image data needed for the restore goes into those buffers, and then when "Unbuffer" is called, all stuff is restored.

But BBlits are about 30 % slower than QBlits. And if you draw too much, then a buffer overflow will happen, causing random memory corruption. So this command is basically just the easiest way to crash Blitz. QBlit with the "Unqueue source" restore is a much better and faster alternative.

It still seems very odd to me that a clearing/restoring blit differentiates between transparant and solid pixels as this is not how that would work in assembly unless a more expensive blit is done than is needed.

I think that is because the "BlitMode erasemode" in Blitz is just a command that gives "extra behaviour" to the next blitting command. Some other "BlitModes" besides "erasemode" are "solidmode", "invertmode" and so on. But these aren't direct drawing commands, they just alter the way how the actual drawing commands like QBlit and BBlit work.

And I quess that therefore, when "erasemode" is set, the commands still operate in the same fashion as when blitting shapes, and this is why they care about transparent pixels and so forth.

I was actually trying to use BLOCK on objects that are always aligned on 16 pixels increments in the X Axis, even though they are not background. But there's no queue for Blocks so I would need to manually erase those objects from screen. The quickest way I found out was to block an empty shape on the spot before doing the block on its new position. I wanted to know if this would be faster than the qblit/unqueue method.

I think I got similar results when I tried to do my own "dirty blocks" routine. Both "Blit" and "Block" should theoretically be faster than "QBlit". But I quess it's all that extra code needed that slows things so much that they can't beat Qblit+Unqueue. Some Blitz commands are slow, but Qblit+Unqueue is clearly very optimized for speed. Which is great.

[Shatterhand]

Yeah, I've been noticing the problem with Blitz Basic its not how fast it draws stuff or hits the hardware, but its basically with the program flow. Arrays and lists, for example, are very slow. So you need to take a lot of care with program logic.

[Retro1234]

I maybe very wrong I thought I read Earok just redraws the Blocks/Tiles to restore the background is this not the fastest method? - not in reference to Dual Playfield really.

[Master484]

I maybe very wrong I thought I read Earok just redraws the Blocks/Tiles to restore the background is this not the fastest method? - not in reference to Dual Playfield really.

Yes, I think he used this method in the platformer Kiwi's Tale. But I think this was because of the advanced scrolling method; "Blit" and "ClipBlit" were the best commands for it, and these then required a manual screen restore with Blocks. So it was done not to gain speed, but because there was no other choice.

[Retro1234]

Say you clear using block

What about if your sprites are made out of Blocks is this going to be really slow or what problems?

[Master484]

Say you clear using block

What about if your sprites are made out of Blocks is this going to be really slow or what problems?

If you draw moving objects with Blocks and clear with Blocks too, then the drawing operations will be very fast.

And you wouldn't even need to use Arrays to keep a list of "dirty blocks"; you can just progress through the object list, and do this: First erase the object in it's current (old) XY position, then move the object to new XY, and then draw it with Block.

And if your game also uses Qblits in addtion to these Block objects, then the drawing order process goes like this: First Unqueue Qblits, then clear and draw Block objects, and then draw Qblits.

The only problem is that Blocks don't have transparency, so if 2 Block objects overlap they'll erase each other. And also Blocks can only be drawn to X positions that are multiples of 16, so moving objects horizontally is a little bit tricky.

But in a space invaders style of game this can work well. Long rows of aliens can be drawn with Blocks, and then the whole row can be moved horizontally using the "Scroll" command. I think Insectoids 2 used this method to get some 40 enemies on screen at 50 FPS.

[Retro1234]

Shit No transparentcy

Is there anything similar to Block but without the limitations but similar speed to Block?(I thought I remember another command starting with B)
Edit; Probably Blit command


Yeah Space Invaders, The Puks In PacMan or Background Animations or Blocks in Mario etc etc

[Master484]

Is there anything similar to Block but without the limitations but similar speed to Block?

No.

"Blit" is the next fastest Blitz drawing command. And it has no limitations and it's faster than QBlit.

But the problem with "Blit" is that there is no "easy and fast" way to clean the blits. Although you could do the same thing as with Blocks, doing 2 Blits; first Blit cleans the old Shape and second Blit draws the new one. But Blits are a lot slower than Blocks, so I believe that this would be slower than for example using the normal QBlit + Unqueue.

Yeah Space Invaders, The Puks In PacMan or Background Animations or Blocks in Mario etc etc

And also big boss enemies that don't move horizontally. For example the second level boss in Turrican 2 with it's few animating parts could have been drawn with Blocks.