English Amiga Board


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

 
 
Thread Tools
Old 13 September 2019, 21:59   #1
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 437
Not using Vwait

So I'm trying out lots of ways to speed up my Doodle Jump game and after spending a couple of weeks playing with Vsprites I have decided that this library is too slow for my purposes.

I have gone back to my original code and use the Block command and some Blits. When I try out on various configs using Amiga Forever - 1200+ is fine but 500/600 slows down when there are 3 or more blits on the screen (I can't believe that it does but it does).

If I remove the Vwait command then it runs really well on 500/600 but screen colours allover the place due to lack of sync.

My question is 'Why is it faster without Vwait and is there a way to run code without Vwait and control the speed of the programme?'
Havie is offline  
Old 13 September 2019, 23:10   #2
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,880
It is faster because it doesn't wait.

If the time required to blit exceeds one frame, if so only by a microsecond, a VWait will introduce a delay of an entire frame.

You will want to VWait or the program will behave differently on an A500 and an accelerated machine.
idrougge is offline  
Old 13 September 2019, 23:14   #3
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 437
Quote:
Originally Posted by idrougge View Post
It is faster because it doesn't wait.

If the time required to blit exceeds one frame, if so only by a microsecond, a VWait will introduce a delay of an entire frame.

You will want to VWait or the program will behave differently on an A500 and an accelerated machine.
I think I see - I have never really worried about timings or 50fps/25fps.

When i use the poke command to see how much of frame is being used - how can I tell. I get a blue border of various heights or sometimes no border at all?
Havie is offline  
Old 13 September 2019, 23:38   #4
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,352
Ive done it in Amos and I didnt really see a problem but when Bobs were at the top of the screen they flickered but in the end I waited for the blitter.

but it's probably not running faster but skipping frames without you knowing or something like that.

Why not make your main Character a sprite then moving platforms Bobs etc.

Last edited by Retro1234; 13 September 2019 at 23:50.
Retro1234 is offline  
Old 14 September 2019, 11:40   #5
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 437
I have worked through various options and at the moment I am using the Block command for static blocks (as it is not 16 pixel limited vertically) and this is the fastest way of putting stuff on the screen. It does lack transparency but with a care design this does seem to be a problem.

I am then using Blit for moving platforms but as soon as there are 2 or more on screen it starts to slow down on the A500/600 (1200 seems fine). Not really sure why a few Blits should slow it down so much?

Currently my jump routing (applied to all platforms) does use floats for acceleration so this may be a bit slow? I will have a think about how to re-code it using integers as this may help.

Other optimisations I have thought of are:

1. Use the block command for all the moving platforms and have 8 or 16 pre-shifted graphics to all smooth movement.

2. Use a hardware scrolling technique for all static blocks but this may not help with the moving Blits slowing the game down?

3. Revisit collision code to make it more efficient.

4. Reduce colours to 8 (currently 16) and possibly then use dual playfield?

The only other thought I have that makes it slow (but probably not as it's fine with Blocks only) is I clear the screen every frame by Blocking in the background.

The background does not currently scroll but I may add this if I get the rest working.

My final option is just to accept the slowdown but it seems silly on what looks like quite a simple game!

I will upload an adf of current progress this weekend for people to test.
Havie is offline  
Old 14 September 2019, 12:33   #6
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,352
One thing I would like to know is why skipping the Blitter wait is considered so bad? and what is the correct way to get a similar speed increase/frame skipping?

If the screen has a scrolling effect but done by clearing the screen and redrawing I expect this is very slow.
Retro1234 is offline  
Old 14 September 2019, 13:49   #7
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 437
When I get a chance, I'll upload one with and without Vwait so you can see difference it makes.

No scrolling at all yet just faked byovimg objects
Havie is offline  
Old 14 September 2019, 14:33   #8
Retro1234
Boo

Retro1234's Avatar
 
Join Date: Jun 2006
Location: 5150
Posts: 4,352
Yeah that would be interesting yeah I know I've done it and the speed increase appears to be significant and I'm wondering why this is frowned upon so much?
Retro1234 is offline  
Old 14 September 2019, 15:01   #9
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 36
Posts: 3,342
Quote:
The only other thought I have that makes it slow (but probably not as it's fine with Blocks only) is I clear the screen every frame by Blocking in the background.
This may be your problem.

Blocks are fast when compared to Blit, Qblit, etc, but it's not like they don't take time. You can't block a FULL screen and still expect things to run on a single frame.

Do not clear the screen, clear just the "dirty" areas where stuff is moving.
Shatterhand is offline  
Old 14 September 2019, 15:44   #10
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 407
Quote:
I clear the screen every frame by Blocking in the background.
Yes, In all likelyhood this is the number one cause for the slowdown.

Clearing the whole screen with Block, BlockScroll or CLS is very slow. Doing this eats almost all time that you have in a frame, leaving only a little bit for other tasks. And this is why you can Blit only a few Bobs before slowdown happens.

A better alternative to this "Block clear + Blits" would be to use QBlits and then do "UnQueue" using the "Unqueue, Source bitmap" way. So have a separate bitmap which contains a "clean copy" of the background, which has only the non-moving platforms, and then when doing the "UnQueue" you put this bitmaps ID number after the command like this: "UnQueue, restore bitmap ID" .

So draw all non-moving platforms to the background only once, and then scroll the screen using hardware scroll. And when the level progresses and you draw new platforms, then just remember to draw the new platforms to the "Unqueue source" bitmap too.

Doing this should speed up the program a lot.

Quote:
One thing I would like to know is why skipping the Blitter wait is considered so bad?
Skipping the VWAIT is bad because you'll then switch bitmaps and start making the next frame to the same bitmap that the display beam is still drawing to the screen.

This can cause graphics flicker, and on a fast Amiga this switch can happen many times during a frame, causing everything to move too fast.

Quote:
is there a way to run code without Vwait and control the speed of the programme?
Yes, by using Triple Buffering and doing "Show / DisplayBitmap" in a VBLANK interrupt routine.

So instead of using 2 bitmaps for drawing ( Double Buffering ), you use 3 bitmaps ( Triple Buffering ).

This way you can start drawing the next frame without getting "stuck" at VWAIT. Although you'll still need a VWAIT command, but you do this only when you run out of "free bitmaps". So adding that third bitmap means that you can "skip" one VWAIT, and the engine can use 2 full frames 100% for drawing stuff, without making a VWAIT between the frames.

But this is possible only if the VBLANK routine does the "Show / DisplayBitmap", and not your main loop code.

Although you'll still get slowdown, but the slowdown happens gradually. So if drawing operations take a little bit too long, instead of instantly dropping from 50 FPS to 25 FPS, you might get something like 40 FPS, which looks almost as fast as 50 FPS. And the "full 25 FPS slowdown" will only happen if you draw so much that the second frame too is entirely used.

---

In practice Triple Buffering can create an illusion that your game runs some 20 % faster. The same old slowdown is there, but because it happens gradually, it's much harder to notice, especially in shoot'em ups.

I think I'll post an example program soon that shows how to do this in the right way, because this is a really good method to improve performance.
Master484 is offline  
Old 14 September 2019, 17:06   #11
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 36
Posts: 3,342
Quote:
Originally Posted by Master484 View Post
Yes, In all likelyhood this is the number one cause for the slowdown.

Clearing the whole screen with Block, BlockScroll or CLS is very slow. Doing this eats almost all time that you have in a frame, leaving only a little bit for other tasks. And this is why you can Blit only a few Bobs before slowdown happens.

A better alternative to this "Block clear + Blits" would be to use QBlits and then do "UnQueue" using the "Unqueue, Source bitmap" way. So have a separate bitmap which contains a "clean copy" of the background, which has only the non-moving platforms, and then when doing the "UnQueue" you put this bitmaps ID number after the command like this: "UnQueue, restore bitmap ID" .

So draw all non-moving platforms to the background only once, and then scroll the screen using hardware scroll. And when the level progresses and you draw new platforms, then just remember to draw the new platforms to the "Unqueue source" bitmap too.

Doing this should speed up the program a lot.

Skipping the VWAIT is bad because you'll then switch bitmaps and start making the next frame to the same bitmap that the display beam is still drawing to the screen.

This can cause graphics flicker, and on a fast Amiga this switch can happen many times during a frame, causing everything to move too fast.

Yes, by using Triple Buffering and doing "Show / DisplayBitmap" in a VBLANK interrupt routine.

So instead of using 2 bitmaps for drawing ( Double Buffering ), you use 3 bitmaps ( Triple Buffering ).

This way you can start drawing the next frame without getting "stuck" at VWAIT. Although you'll still need a VWAIT command, but you do this only when you run out of "free bitmaps". So adding that third bitmap means that you can "skip" one VWAIT, and the engine can use 2 full frames 100% for drawing stuff, without making a VWAIT between the frames.

But this is possible only if the VBLANK routine does the "Show / DisplayBitmap", and not your main loop code.

Although you'll still get slowdown, but the slowdown happens gradually. So if drawing operations take a little bit too long, instead of instantly dropping from 50 FPS to 25 FPS, you might get something like 40 FPS, which looks almost as fast as 50 FPS. And the "full 25 FPS slowdown" will only happen if you draw so much that the second frame too is entirely used.

---

In practice Triple Buffering can create an illusion that your game runs some 20 % faster. The same old slowdown is there, but because it happens gradually, it's much harder to notice, especially in shoot'em ups.

I think I'll post an example program soon that shows how to do this in the right way, because this is a really good method to improve performance.
Is this how Lotus 2 works?

This is really interesting and I hadn't thought about doing this.
Shatterhand is offline  
Old 15 September 2019, 13:40   #12
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,880
Quote:
Originally Posted by Havie View Post
Currently my jump routing (applied to all platforms) does use floats for acceleration so this may be a bit slow? I will have a think about how to re-code it using integers as this may help.
Use quicks instead.
idrougge is offline  
Old 15 September 2019, 15:55   #13
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 407
Quote:
Is this how Lotus 2 works?
It could be. I haven't played Lotus 2 for a while.

But when you have a game that runs at 50 FPS, and never seems to get slowdown, then it's possible that it uses Triple Buffering.

I believe that Overkill on the A1200 uses this technique, judging by the way how slowdown happens in it. It runs at 50 FPS, but never drops to 25 FPS, instead you just get small "hiccups" when the screen gets crowded. And it's very hard to even notice it, unless you stare at the sprites, trying to spot the moment when they start slowing down.

In comparison for example in Turrican 2 slowdown always happens with direct drops from 50 FPS to 25 FPS, and it's very easy to notice. So in all likelyhood it uses normal Double Buffering, just like most other games do.

Also I suspect that Mega Typhoon, Elfmania, and other "rock solid 50 FPS" games are possibly using Triple Buffer to hide the slowdowns.

The only downside of Triple Buffering is the Chip RAM use; you need an extra bitmap for it. And I think this is why not many A500 games use it. But some games detected how much RAM the machine has, and if 1 MB was found, then they used Triple Buffering instead of Double Buffering. I read somewhere that Fire & Ice at least did this.
Master484 is offline  
Old 15 September 2019, 21:28   #14
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 437
As promised, I have uploaded two versions of game - one with VWait and one without. They are both in The Zone. Links below:

http://eab.abime.net/zone/Doodle.adf
http://eab.abime.net/zone/Doodle%20-%20No%20VWait.adf

Speed increase in No VWait version would imply that triple buffering might make a difference. We shall see...
Havie is offline  
Old 15 September 2019, 21:36   #15
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 437
Also tried a version without Blocking the background. Obviously very messy but much faster so you guys are right - time to be a bit more efficient. hadn't realised that this would take too much time as Block command is quick...lesson learned!
Havie is offline  
Old 15 September 2019, 23:07   #16
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 437
whoops - just realised that I was Usepath(ing) twice in a loop and we know that TYPES can be a little slow so doing this twice in one loop wasn't very sensible.

Code slightly broken but much faster...looking promising again.
Havie is offline  
Old 16 September 2019, 04:27   #17
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 36
Posts: 3,342
Quote:
Originally Posted by Master484 View Post
It could be. I haven't played Lotus 2 for a while.

But when you have a game that runs at 50 FPS, and never seems to get slowdown, then it's possible that it uses Triple Buffering.

I believe that Overkill on the A1200 uses this technique, judging by the way how slowdown happens in it. It runs at 50 FPS, but never drops to 25 FPS, instead you just get small "hiccups" when the screen gets crowded. And it's very hard to even notice it, unless you stare at the sprites, trying to spot the moment when they start slowing down.

In comparison for example in Turrican 2 slowdown always happens with direct drops from 50 FPS to 25 FPS, and it's very easy to notice. So in all likelyhood it uses normal Double Buffering, just like most other games do.

Also I suspect that Mega Typhoon, Elfmania, and other "rock solid 50 FPS" games are possibly using Triple Buffer to hide the slowdowns.

The only downside of Triple Buffering is the Chip RAM use; you need an extra bitmap for it. And I think this is why not many A500 games use it. But some games detected how much RAM the machine has, and if 1 MB was found, then they used Triple Buffering instead of Double Buffering. I read somewhere that Fire & Ice at least did this.
The drop from 50 to 25 fps is a lot worse than the drop from 60 to 30, at least to me. That's one small disadvantages on PAL displays IMO.
Shatterhand is offline  
Old 16 September 2019, 23:31   #18
Havie
Registered User
 
Join Date: Mar 2012
Location: UK
Posts: 437
Code now fixed and using Bblits is now running in one frame on A500. Using the peek I get a blue line running at about 60% of the screen so I guess this represents how much a frame has been used up. Looks like there is plenty left!

I am now thinking that VSprites may not have been as slow as I thought? Sticking with Blits now as I was still having trouble with colours and running on 68000 using VSprites.

Full steam ahead with the game now...

Last edited by Havie; 17 September 2019 at 00:45.
Havie 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
VWait bloodline Coders. Blitz Basic 6 07 April 2019 13:07

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 09:30.


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