English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. Blitz Basic

 
 
Thread Tools
Old 17 September 2019, 17:07   #1
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Triple Buffering Example



Here is a small Triple Buffering demo, which shows how this useful technique looks like in a running game. System requirements: A500, 512K.

ADF file is in the attachment of this post, and Blitz source code is included on the disk. You can use the code freely in your own programs.

This is basically an improved version of my earlier collision demo program, which was posted in an other thread some months ago. In addition to Triple Buffering this version has both 16*16 and 32*32 size objects, and "hit flashes" done with "QBlitMode SolidMode" and some animations. Also collisions are now handled with "Point" instead of "BlitColl".

So there are 3 bitmaps, "DisplayBitmap" runs from a VBLANK interrupt, and the main loop draws stuff as fast as it can to the 3 bitmaps. VWAIT never happens in the main loop. Instead the VBLANK interrupt does the "VWAIT stuff", and communicates with the main loop through simple variables.

Triple Buffering also makes it possible to show a new frame on screen, even if some stuff has still not been done. So first the demo moves the objects, checks collisions and draws the BOBs. And at this point it gives the "frame ready signal" to VBLANK, and then continues to finish the less important stuff. And so a new frame can be shown, even if some stuff is still not finished.

Also there are other optimizations, that you can find out in the source code. It's all well documented and well structured. The whole program runs from a nice list of Gosubs that fit in one editor screen.

Performace on A500, without Fast RAM and Cycle Exact ON:

16 Enemies vs 15 Bullets at 50 FPS.
10 Enemies vs 25 Bullets at 50 FPS.

Max amount of 16*16 Enemies at 50 FPS: 26
Max amount of 32*32 Enemies at 50 FPS: 15
Max amount of 8*8 Bullets at 50 FPS: 45

(bullets are 4 color BOBs, so they are cheap to draw)

So 50 FPS performance is slightly better than in the earlier versions of this demo. But the main difference is that thanks to triple buffering slowdown now happens gradually. So instead of dropping directly to 25 FPS, we start getting those "in-between FPS", like 45 FPS and 40 FPS, and so on. And only if the whole 2nd frame too is spent drawing the graphics, then it drops to full 25 FPS slowdown.

So in practice, this creates the illusion that the game engine seems to able to draw much more at 50 FPS, because the slowdown at 40 FPS doesn't look so bad, and it's hard to notice.
Attached Thumbnails
Click image for larger version

Name:	TriBufferDemoV208_001.png
Views:	306
Size:	13.4 KB
ID:	64491  
Attached Files
File Type: zip TriBufferDemoV209.zip (40.4 KB, 43 views)

Last edited by Master484; 17 September 2019 at 21:25. Reason: Uploaded new program version
Master484 is offline  
Old 17 September 2019, 21:28   #2
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Uploaded a new version of the demo: V209.

The previous version had a crash bug: it crashed if you made more than 200 objects, thanks to a non-working object amount limiter. But this has now been fixed.
Master484 is offline  
Old 18 September 2019, 01:27   #3
Raislin77it
Zone Friend
Raislin77it's Avatar
 
Join Date: Jan 2005
Location: italy
Age: 42
Posts: 232
Quote:
Originally Posted by Master484 View Post
Uploaded a new version of the demo: V209.

The previous version had a crash bug: it crashed if you made more than 200 objects, thanks to a non-working object amount limiter. But this has now been fixed.
thanks, i will study it
Raislin77it is offline  
Old 18 September 2019, 02:35   #4
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,372
Cool, what's Point ? your using for collision?

Looks like another brilliant demo
Retro1234 is offline  
Old 18 September 2019, 06:55   #5
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 36
Posts: 3,430
Hey, you used the graphics you draw for my game. That makes me happy

I'll surely take a look at your demo. I am not doing nothing amiga related for the next 4 weeks because I got an extra temp job, so free time is nearly zero those days. But as soon as this job ends, I'll be back full-power on doing stuff with my Amiga, then I'll surely check the code for this, I'm really interested.
Shatterhand is offline  
Old 18 September 2019, 10:06   #6
carrion
Registered User

carrion's Avatar
 
Join Date: Dec 2016
Location: Warsaw area
Posts: 97
Oh wow. This look interesting. I will take closer look at this today. A vertical chump is something is on my mind for long time.

Oh and... Thanks for making the source code free for use
carrion is offline  
Old 18 September 2019, 14:35   #7
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Quote:
Cool, what's Point ? your using for collision?
Point is a command that checks the color of a pixel at a certain XY position.

And this I use for collisions in the following way:

All enemies are drawn first. And after them all bullets. But BEFORE each bullet is drawn I make a Point (X,Y) color check at the bullets center XY location.

And if the color found is greater than zero, then we know that the bullet has collided with something. And only in this case the engine does the time consuming "bullet vs all enemies" check, doing a standard bounding box collision check for each enemy.

The Point method is a very fast way of checking collisions, because most of the time the bullets don't collide with anything, and the color check returns zero. So for most bullets in the screen a simple color check is enough to rule out a collision.

This color checking method works best in dual playfield where the Front PF is used only for moving graphics.

But it can be used in 16 color mode single playfield too, if the non-collidable background graphics are made with certain colors only. For example make the BG graphics with the first 4 colors, and walls and enemies with the remaining 12 colors, and then check the color with " IF Point (X,Y) > 4 then collision happened". Also walls could have their own specific colors at the top of the palette, making collision checks with them super fast ( If Point (X,Y) > 12 then destroy bullet ).

---

The only downside of the Point method is inaccuracy; it checks only one pixel. So it only works for small bullets.

But for bigger objects you can use virtual "BlitColl" collision objects, that can be of any size, for example a small 8*8 BlitColl box can provide quite accurate collision check for a 16*16 object (8*8 hitbox in the center of a 16*16 object). The smaller the BlitColl object, the faster it is. Also on a single playfield 16 color game you can make a separate 1 bitplane "collision bitmap", and check all collisions there using 1 bitplane BlitColl objects. But I don't know how fast or slow this would be, I have only read about it, but haven't tested it myself.

---

And indeed, you can freely use the source code for anything. You can even just directly take the code, and build your own game on top of it.
Master484 is offline  
Old 18 September 2019, 23:50   #8
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,372
I think you need to get all your sources together in one place.
Retro1234 is offline  
Old 19 September 2019, 18:48   #9
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Quote:
I think you need to get all your sources together in one place.
Yeah, maybe in the future I'll gather the most useful ones, and put them all into some place.
Master484 is offline  
Old 21 September 2019, 13:25   #10
carrion
Registered User

carrion's Avatar
 
Join Date: Dec 2016
Location: Warsaw area
Posts: 97
@Master484
This is really nice piece of code to analyze and learn. Thanks again!
Now I have few question.
1. Did you make any tests how it will behave with BBlit instead of Qblit? How much slower?
2. CustomSprites command? I cannot find it in the manal. Is it from other non standard library? how does it exactly work and will it behave the same on AGA?
TIA
carrion is offline  
Old 21 September 2019, 14:18   #11
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,928
CustomSprites Coplist#,CCOffset,YPos,NumSprites

CustomSprites inserts a copper list that reinitialises the sprites hardware at a
certain vertical position in the display. These lower sprites are assigned sprite
numbers of 8..15. CustomCops required = 4 x numsprites + 2
idrougge is offline  
Old 21 September 2019, 14:51   #12
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 409
Quote:
1. Did you make any tests how it will behave with BBlit instead of Qblit? How much slower?
I haven't tested BBlit directly in this program.

But I have tested it previously, and found out that BBlits on a 16 color screen are 25 % slower than QBlits on a 8+8 color Dual Playfield screen.

Usually I don't use BBlit at all, partly because it's so slow, and partly because I don't like the "Buffers" that the command needs.

So I almost always use Qblits, which can be used in single playfield games too if you make an external third bitmap that contains a clean copy of the background GFX, and then use the command "Unqueue, Source Bitmap" to clean your blits.

---

Also I have found out that CPU operations are 20 % faster on a 16 color screen than on a Dual Playfield screen. But if the system has Fast RAM, then CPU operations speed is equal on both Single PF and Dual PF. This is one reason why fast collision detection code is so important in a 8+8 Dual PF game.

Quote:
2. CustomSprites command? I cannot find it in the manal. Is it from other non standard library? how does it exactly work and will it behave the same on AGA?
CustomSprites is a standard Blitz command, and it should be in the newest version of the classic Blitz 2.1 manual.

And as you can see from idrougges post, with it you can duplicate the 8 sprites exactly once at some Y-line. So you can get a maximum of 16 sprites to screen.

And it works exactly in the same way both on AGA and OCS.
Master484 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Double Buffering MartinW Coders. C/C++ 8 11 October 2017 01:20
Latency tests - No difference between "No buffering" and "Double buffering" Dr.Venom support.WinUAE 6 24 September 2017 11:18
Cons & Pros of buffering vs no buffering ED-209 support.WinUAE 9 27 February 2016 09:47
Triple buffering atchoo support.WinUAE 29 30 November 2011 12:58
lha buffering source support.Apps 7 18 July 2011 17:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:10.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.08344 seconds with 14 queries