32 color shmup demo

[Daedalus]

That's more or less it really. I don't know if you're a reader of Amiga Future, but these are the very topics I'm covering at the moment in the Blitz tutorial series - blitting methods and double buffering are coming up in the next issue, with scrolling, dual playfields and sprites the following issue. But the basics are:

0: n = 0
1: Draw graphics required to bitmap n
2: Wait for vertical blank
3: Display bitmap n
4: n = 1 - n ; swap n between 0 and 1
5: Goto 1

In this way, you never draw to the bitmap that's actually displayed on screen. This means you can take as long as you like drawing the next frame, and when it's ready put it on display and redraw the first one. You don't need separate screens to do this - just bitmaps, and using a variable (n in my example) means you don't have to have two separate bits of code for drawing the two frames; just Use Bitmap n and then draw as you need.

Triple buffering adds another buffer to the cycle so that your program can draw ahead without waiting for the second buffer to become displayed. But this is of limited use for typical Amiga games which generally run in sync with the vertical blank. Alternatively (and I think this is what idrougge is talking about), a third bitmap can be used to provide "fill-in" data when QBlit is used - sections of the third bitmap are copied back to the currently used bitmap when shapes are erased and re-blitted. This is similar to a buffered blit but gives you a bit more control.

[idrougge]

Start a new thread and we'll talk.

[madaxe]

Originally Posted by Daedalus

0: n = 0
1: Draw graphics required to bitmap n
2: Wait for vertical blank
3: Display bitmap n
4: n = 1 - n ; swap n between 0 and 1
5: Goto 1

Sorry to ask @Daedalus, but it should not be


3: n=1-n
4: Display bitmap n


Instead?

[Daedalus]

No... Well, you can do it that way too, but you also need to adjust the other steps to suit. Specifically, you need to draw to bitmap 1-n then instead of bitmap n, since displaying bitmap n then drawing to it will defeat the whole purpose of doing double buffering.

[rcman]

Originally Posted by Daedalus

That's more or less it really. I don't know if you're a reader of Amiga Future, but these are the very topics I'm covering at the moment in the Blitz tutorial series - blitting methods and double buffering are coming up in the next issue, with scrolling, dual playfields and sprites the following issue. But the basics are:

0: n = 0
1: Draw graphics required to bitmap n
2: Wait for vertical blank
3: Display bitmap n
4: n = 1 - n ; swap n between 0 and 1
5: Goto 1

In this way, you never draw to the bitmap that's actually displayed on screen. This means you can take as long as you like drawing the next frame, and when it's ready put it on display and redraw the first one. You don't need separate screens to do this - just bitmaps, and using a variable (n in my example) means you don't have to have two separate bits of code for drawing the two frames; just Use Bitmap n and then draw as you need.

Triple buffering adds another buffer to the cycle so that your program can draw ahead without waiting for the second buffer to become displayed. But this is of limited use for typical Amiga games which generally run in sync with the vertical blank. Alternatively (and I think this is what idrougge is talking about), a third bitmap can be used to provide "fill-in" data when QBlit is used - sections of the third bitmap are copied back to the currently used bitmap when shapes are erased and re-blitted. This is similar to a buffered blit but gives you a bit more control.

Have anything posted to your tutorials?

RC

[madaxe]

Originally Posted by Daedalus

No... Well, you can do it that way too, but you also need to adjust the other steps to suit. Specifically, you need to draw to bitmap 1-n then instead of bitmap n, since displaying bitmap n then drawing to it will defeat the whole purpose of doing double buffering.

Thanks
I thought that was something like:

.Loop
Draw objects in BitMap 0
Wait for vertical blank
Display BitMap1
Draw objects in BitMap 1
Wait for vertical blank
Display BitMap 0
Goto Loop

When using a Dual PlayField the method is the same?

[Daedalus]

Originally Posted by rcman

Have anything posted to your tutorials?

Not sure what you mean there... I covered double buffering in the Amiga Future tutorials a good while back, issue 128 if that's what you mean?

Originally Posted by madaxe

Thanks
I thought that was something like:

.Loop
Draw objects in BitMap 0
Wait for vertical blank
Display BitMap1
Draw objects in BitMap 1
Wait for vertical blank
Display BitMap 0
Goto Loop

When using a Dual PlayField the method is the same?

That's very similar, but you don't want to be drawing shapes to a bitmap that's currently displayed. It will work fine if you're running smoothly at 50fps, but if any frame takes longer than a frame to draw, you'll get flicker and jitter in your shapes.

[rcman]

Originally Posted by Daedalus

Not sure what you mean there... I covered double buffering in the Amiga Future tutorials a good while back, issue 128 if that's what you mean?



That's very similar, but you don't want to be drawing shapes to a bitmap that's currently displayed. It will work fine if you're running smoothly at 50fps, but if any frame takes longer than a frame to draw, you'll get flicker and jitter in your shapes.

Sorry I've never heard of the Futures Tutorials. I looked that up, it comes up with a magazine. Is that what you're talking about?
RC

[madaxe]

Originally Posted by Daedalus

That's very similar, but you don't want to be drawing shapes to a bitmap that's currently displayed. It will work fine if you're running smoothly at 50fps, but if any frame takes longer than a frame to draw, you'll get flicker and jitter in your shapes.

Ahhhhhh, ok, that really makes sense
Thanks for your explanation @Daedalus, now I understand the concept about dual buffer