Fastest way to blit things on screen

[Shatterhand]

I've been playing a little bit with Blitz Basic... I've made a small test, inserting a new blob on screen per second, to see how long the blitter starts chugging...

I was surprised (maybe not *that* surprised ) that it didn't take long before it didn't manage to draw everything, and then begun droping frames.

I am using the qbit method to blit them on screen, and cleaning the queue before each frame.

Is this the fastest way to do it?

I still have to see to make a doublebuffer, which will probably speed-up things.

my code is below. feel free to make any suggestions or point anything really wrong or stupid on my code, since I am just beginning with Blitz Basic, I need to hear this kind of stuff



EDIT
this is a picture of the code running:

[Daedalus]

There doesn't look like there's much wrong with your code really. Are you running it with the debugger turned on? That slows down the code a lot, so once you have your code working properly you can turn it off to let it run at full speed.

QBlits are slower than normal Blits, so it could be sped up by just using the standard Blit command. Of course, you lose the ability to track and erase your previous blits so that's not always ideal.

Bear in mind as well that it's possible you don't need to blit every object every frame. Maybe only blit the first 20 items in the first frame, the next 20 items in the 2nd frame and so on. It needs a little bit more coordination, but it means you should be able to have a large number of items under control on the screen without slowdown.

[Shatterhand]

Yeah, I thought about this, blitting half of objects in odd frames and other half in even frames.

I really wanted to do a vertical shoot'em up, but not being able to blit that many objects will hinder my plans a lot.

This was an executable, I don't even have Blitz Basic on my Amiga. I code on PC and then transfer the file to my 68k A600

[Daedalus]

Fair enough Yeah, I think that might be the way to go alright. Remember that some objects in a vertical scroller wouldn't have to be redrawn every frame - if they're moving down at the same speed as the bitmap they can be ignored, so maybe a routine to take that into account might help with the efficiency. You're right though, you do need to keep it as smooth as possible for a game like that!

[Shatterhand]

I'd think having no background would be faster, since you wouldn't have to worry about redrawing the background when the object moves.. I don't know if Qblit is trying to do that even if there's no background behind (it's still a bitmap after all I guess, I am not sure that's how it works)... my initial idea was to have a shmup completely on space, that's why I was using a black bakground for initial tests.

Your idea of having stuff scrolling with the background is pretty good too

[Daedalus]

Well, QBlits will erase the background - to replace the background you really need to use Buffered Blits (BBlit command), and that's even slower. However it 100% replaces anything you blit over so very useful for moving over backgrounds. You're right - having no background would be faster indeed.

Another alternative is to use dual playfields and have the background on one playfield, with your blits on the top one. That means you won't be able to do the scrolling trick, but you can use QBlits, or even standard blits for speed if you erase them manually. The two playfields are two separate bitmaps and blitting on one has no effect on the other.

[Shatterhand]

Yeah, I read about that, and I even did a parallax scroller with dual playfield when I first installed Blitz Basic, but I didn't try to blit anything over it. Using dual playfield seems to be a logical step then... for some reason I thought that would actually be slower, but now it doesn't seem to be the case.

And good to know QBlit deletes everything below the blob, I thought it would replace the background automatically... so I was right, it would be faster anyway. A standard blit that I erase manually would be faster than a Qblit erased on a queue? I'd think the speed would be the same.

[Cylon]

You can speedup the thing a little bit by assigning most variables an integer type.
You are now using quick, which is a kindof float - this is "slow".
As long as your shps coords and speed variables are integer you should use .w (or .l if you use multiplications to calculate big number values inbetween).

DEFTYPE.w from the top of source will do this for all unassigned variables, if you like.

Also:
Whenever you use a boolean test like OR, both of the tests are being tested everytime, nomatter what the previous result returns.
It is better to avoid this. Here is a (bad) example, to give you an idea.
Note: The more time the CPU needs to calculate the result in those OR arguments, the more time you lose everytime your routine is called.

;if a=x OR b=x then gosub whatever
atest:
if a.w=x.w
  gosub whatever
  pop if:goto skipbtest    ;stack cleanup with POP, then skip over second test
endif
btest:
if b.w=x
  gosub whatever
endif
skipbtest:
...

;if a=x OR b=x then gosub whatever
if a.w=x.w
  gosub whatever
else
  if b.w=x
    gosub whatever
  endif
endif
...

In general, you should avoid those situations by constructing your games logic in advance to not allowing variables having "fuzzy" conditions.

[idrougge]

You can also keep a third buffer containing the background graphics to be used to restore the background when you unqueue your qblits.

[Shatterhand]

Cylon, I understood all the code you wrote, thank you, but I would have no idea of what POP does (I understood from your code), and I usually avoid using gotos which can make code understanding a mess.... though it's can be really hard to avoid with Basic (I am managing to do it so far ). Also, thank you with the DEFTYPE.w tip, it's something that should be obvious by reading the manual, yet I didn't do it neither here or on the other project that I am actually working on

and idrougge, that's a pretty good idea indeed, but I also don't know how to do it with Blitz Basic... I am still get the hang of it

Thank you for all your help, it encourages me to keep trying to learn more about blitz basic and do better

I don't know if you guys saw this, but I posted a video of what I managed to do so far, it's on this thread:

http://eab.abime.net/showthread.php?t=78006&page=4

[idrougge]

@Shatterhand, there is an optional argument to Unqueue that points to a bitmap from which to overwrite the bob you're removing from the screen:

Syntax : UnQueue Queue#[,BitMap#]

UnQueue is used to erase all 'remembered' items in a queue. Items are
placed in a queue by use of the QBlit command. Please refer to Queue
for a full explanation of queues and their usage.

An optional BitMap# parameter may be supplied to cause items to be
erased by way of 'replacement' from another bitmap, as opposed to the
normal 'zeroing out' erasing.

http://amiga.sourceforge.net/amigade...eyword=UnQueue

[ImmortalA1000]

Sorry if this is way out of line but you guys clearly know about this (and it has been 20 years since I used Blitz at all).

What is the fastest blitter operation in Blitz bar none?

Let's say I just want to blit a 32x32 pixel 32 colour bitmap onto the 320x256x32col screen...how many times could you blit this bitmap repeatedly in 1/50th of a second?

(I don't care about storing backgrounds or anything, fully destructive blits that overwrite everything and just replace it with a 32x32 pixel bitmap BUT colour zero must be transparent so it will not overwrite that pixel with a new pixel of colour zero if that makes sense...a bit like a transparent paste operation in a simple pixel art paint program like Dpaint 2)

[ReadOnlyCat]

Originally Posted by Shatterhand

I still have to see to make a doublebuffer, which will probably speed-up things.

Double buffering does not actually speed things up. Its purpose is to avoid tearing artifacts which appear when the rendering code is not fast enough to update the screen ahead of the electron beam.

It can be used to smoothen updates, that is allow solid 50 FPS updates even if the rendering sometimes take more than one frame as long as the frame before and after are shorter. But the average frame rate will be the same with and without double buffering.

Originally Posted by ImmortalA1000

Sorry if this is way out of line but you guys clearly know about this (and it has been 20 years since I used Blitz at all).

Actually, it is probably better to create a dedicated thread for that question.

Originally Posted by ImmortalA1000

What is the fastest blitter operation in Blitz bar none?

If Blitz blitting functions are properly implemented then the answer is not really dictated by Blitz but by the Blitter itself.

Also, as for every question as broad as this one the answer is "it depends".
It depends what you mean by "fast": time or resources?

If it is time, then either "copy" or "clear" are the fastest, they take the same amount of time to complete (because of the way the Blitter works).
If resources used is the criterion then "clear" is the most efficient since it uses only one DMA slot per two bytes written versus two DMA slots for "copy"

Originally Posted by ImmortalA1000

Let's say I just want to blit a 32x32 pixel 32 colour bitmap onto the 320x256x32col screen...how many times could you blit this bitmap repeatedly in 1/50th of a second?

(I don't care about storing backgrounds or anything, fully destructive blits that overwrite everything and just replace it with a 32x32 pixel bitmap BUT colour zero must be transparent so it will not overwrite that pixel with a new pixel of colour zero if that makes sense...a bit like a transparent paste operation in a simple pixel art paint program like Dpaint 2)

Note that the conditions "destructive" and "transparent" are contradictory. If you preserve the background via transparency then the operation is not destructive.

The copy-with-transparency operation is actually the slowest operation the Blitter can perform because it requires 4 DMA channels:
- Channel A: the image to copy.
- Channel B: the background to preserve.
- Channel C: the transparency mask of the image (says which pixels are transparent).
- Channel D: the destination of the copy.

Compare with "clear" (I do not know the exact name in Blitz) with one channel:
- Channel D: the destination to clear.

Or "copy" with two channels:
- Channel A: the image to copy.
- Channel D: the destination of the copy.

Unfortunately I do not know the names of these operations in Blitz but I am sure that 10 minutes spent perusing the Blitz manual (available online) will allow you to find them.

Hope this helps.

[Daedalus]

The Block command is the fastest blitting command in Blitz. It has restrictions though (presumably due to the implementation used), specifically that the shapes blitted must be a multiple of 16 pixels wide, and their position must be 16 pixel aligned horizontally. Height and vertical position can be anything.

I can't remember now though whether it uses a cookie cut (i.e., preserves the background in the colour 0 areas). Worth experimenting with anyway.

Edit: If it doesn't preserve the background, standard blits using the Blit command are the next fastest method, followed by QBlit and then BBlit.