Waiting for the blitter...

[jayminer]

Me and a friend did some tests today and a very simple program that just moved around some objects over a background could only move around ~18 (16x16 pixel 5 bitplane) objects before it started to lag on a 68000 machine (on my A2000 with 030 it started lagging with about 30 objects, I'm a bit puzzled why the 030 is so much faster when it's mainly the blitter that is doing all the work).

It seems all the commands for blitting stuff in Blitz Basic are waiting for the blitter to finish before they move on with the code. Does anyone here know if there is any (easy) way to queue up blits and let the main program continue running without spending most of it's time waiting for the blitter?

Hi fellow Amiga fans!
@jayminer: I too did some extensive testing the last few days with BOBs in Blitz. I wanted to make a very simple 50fps shooter for classic Amigas.

Before I dive into it keep in mind that im in no way an advanced Blitz programmer or anything like that. only as of late Ive started to seriously sink my teeth into Blitz.

Anyway here it goes:
My screen setup is a lores dbl buffered 4 bplanes copperlist and Im using QBlits.

The program thus far is a bunch of 12x12 animated BOBs on a black bg moving @ different speeds and headings bouncing off the edges of the screen to the opposite direction. Pretty simple stuff.

Im using inline assembly the only fast way I know off by accessing and manipulating global vars from the a5 register for all main loop math computations including a 16.16 fixed point math routine(again in assembly) for the bob movements. plus Im using constants wherever I can.

The result is max ~35/40 objects before fps drops below 50 on the default A1200 "basic non-expanded configuration" in WinUAE 3.1 (sorry no real hardware to test on atm) which is kinda disappointing tbh and is simply not enough performance for the kind of game i want to make. Ive seen games running with more objects @ 50 fps on a mere unexpanded A500 and at 5 bplanes with larger sprites(16x16) and moving background starfields!

I think I might be doing something wrong here or there exist other optimizations I can make perhaps idk? eg is there a better/faster way of using the inline assembler or perhaps there's a faster external blitting library we can use? or is this in the end all that Blitz can handle? (although I highly doubt that)

[Cylon]

Nobody can give you help without looking into the source code. Expecting high frame rates and being let down by the machines results might caused by your src?
E.g. fixedpoint math instead of word/lword math?

You give the hint for free:

Originally Posted by jayminer

...(on my A2000 with 030 it started lagging with about 30 objects, I'm a bit puzzled why the 030 is so much faster when it's mainly the blitter that is doing all the work).

It's the code!

Originally Posted by Cylon

Nobody can give you help without looking into the source code. Expecting high frame rates and being let down by the machines results might caused by your src?
E.g. fixedpoint math instead of word/lword math?

You give the hint for free:

It's the code!

Hi Cylon
I dont understand. Fixed point math is floating point calculations using only integers. so yes in my case (16.16) lwords.
Anyway do you think its possible to get a better performance out of Blitz than the one I mentioned above?

[jayminer]

Originally Posted by Cylon

Nobody can give you help without looking into the source code. Expecting high frame rates and being let down by the machines results might caused by your src?
E.g. fixedpoint math instead of word/lword math?

You give the hint for free:

It's the code!

Well, I don't have the source on this machine but it was a very simple loop that I don't think should strain the CPU much at all, I'm using words (.w) for all my variables (deftype .w)

The code was basically this:

deftype .w

dim ox(50), oy(50), oxd(50), oyd(50)

I put some randomized start-values into these, ox/oy = object x/y, oxd/oyd = object x/y direction
I also make 3 bitmaps, 2 to use for double-buffering and one that is used with unqueue to repaint the background, the main loop looked like this:

while something
  for loop=0 to max
    ox(loop)=ox(loop)+oxd(loop)
    oy(loop)=oy(loop)+oyd(loop)
    if ox(loop)=320 then oxd(loop)=-1
    if ox(loop)=0 then oxd(loop)=1
    if oy(loop)=256 then oyd(loop)=-1
    if oy(loop)=0 then oyd(loop)=1
    qblit db,1,ox(loop),oy(loop)
  next
  unqueue db,2
;  doublebufferstuff here
wend

I also read two keyboard-keys to be able to change max to add and remove objects, and see where it starts lagging

[Cylon]

Quick review shows:
You are blitting ALWAYS, even if nothing changed.
You check xcoords on the right, even if the coords have been confirmed to be left, and vice versa. Dito for vertical.
Means: You check everything everytime. And blit, everytime. Change that.

[jayminer]

Well since this was a test to see how many objects I can move around I want to blit them all each frame, and the cpu cycles wasted by those extra tests should be negligable, wouldn't they, an object would only get a hit in X every 320 frames so most of the frames both checks would have to be done anyway.

But my original question wasn't about optimizing my really quick and dirty test-code, but I was wondering if there's an somewhat easy way to not halt the program waiting for the blitter to finish at each and every blit. I would like to build up some queue of blits to be done and let blitz handle those while the rest of my program continues to run. Is something like this possible? Any extension that can help?

[idrougge]

Originally Posted by RiskyW

The result is max ~35/40 objects before fps drops below 50 on the default A1200 "basic non-expanded configuration" in WinUAE 3.1 (sorry no real hardware to test on atm) which is kinda disappointing tbh and is simply not enough performance for the kind of game i want to make. Ive seen games running with more objects @ 50 fps on a mere unexpanded A500 and at 5 bplanes with larger sprites(16x16) and moving background starfields!

16 pixels (one word) is the smallest width the Blitter can handle, so whether you're using 12x12 objects or 16x12 objects, the load on the Blitter is the same.

Originally Posted by RiskyW

Im using inline assembly the only fast way I know off by accessing and manipulating global vars from the a5 register for all main loop math computations including a 16.16 fixed point math routine(again in assembly) for the bob movements. plus Im using constants wherever I can.

How do you access global vars from A5 register?

[idrougge]

Originally Posted by Cylon

Quick review shows:
You are blitting ALWAYS, even if nothing changed.
You check xcoords on the right, even if the coords have been confirmed to be left, and vice versa. Dito for vertical.
Means: You check everything everytime. And blit, everytime. Change that.

While that could help his demo, it won't help for the purposes of his shmup, as long as there is a possibility that more than 30 objects move at the same time.