Qbasicnews.com
September 28, 2021, 02:27:51 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: FLICKER  (Read 6348 times)
RRystrom
New Member

Posts: 2


« on: April 15, 2006, 04:23:08 PM »

I wrote a program that draws a circle, paints it, then clears the screen and draws a -3 smaller circle, paints it, etc.  It's doing what I want, but because of the CLS, it's VERY flickery.  Is there a way to get the same result without the flicker?  Thanks, Richard
Logged
KiZ
__/--\__
*****
Posts: 2879


WWW
« Reply #1 on: April 15, 2006, 05:30:58 PM »

http://faq.qbasicnews.com/?blast=DoubleBufferingGeneral

;)

If it confuses you, scroll all the way down to the bottom and have a look at the example. Try it out yourself, then try play with it a bit.
Logged
NovaProgramming
Been there, done that
*****
Posts: 1025



« Reply #2 on: April 15, 2006, 07:00:10 PM »

One thing that you could do (that is less confusing than double buffering)...

Just make a black box around the circle that you want to delete:

Line (x,y)-(x2,y2),0,BF

then it's like clearing the screen but it only blots out what you don't want, reducing flicker.  It's not perfect, and it's not as nice as double-buffering, but it works quite well for simple stuff.
Logged

ovaProgramming.

One night I had a dream where I was breaking balls.  The next morning, BALLSBREAKER was born.

Quote from: "Haye, Phillip J."
 Excellent.  Now you can have things without paying for them.

BALLSBREAKER 2
~-_-Status Report-_-~
Engine: 94%
Graphics: 95%
Sound: 100%
A Severe Error has crippled BB2 for the time being... I have to figure it out, but until then you won't see much of it Sad.
-----------------------------
Anonymous
Guest
« Reply #3 on: April 15, 2006, 07:22:15 PM »

put this before your loop repeats


Code:
Wait &H3da, 8
Wait &H3da, 8, 8
Logged
RRystrom
New Member

Posts: 2


« Reply #4 on: April 15, 2006, 07:34:09 PM »

Thanks for the suggestions!
Logged
anarky
Been there, done that
*****
Posts: 1231


The Blobworld Comics King


« Reply #5 on: May 04, 2006, 08:49:54 AM »

cha0s, might I suggest telling him what this piece of code does?

What it does is waits for your monitor to clear the current cycle and start afresh, so your program is drawing with the monitor on it's cycle than having it draw 1 frame over two monitor cycles, or two over 1 cycle...

Insert that into your loop right before you start drawing. Using this in combination with double buffering, ie: before the page flip, makes things a whole lot smoother.

Good luck.
Logged

Screwing with your reality since 1998.
Anonymous
Guest
« Reply #6 on: May 04, 2006, 11:25:45 AM »

search the forum gfor my name and that code snippet.

you can only say the same thing so many million times, so... you can do it now ^^
Logged
Z!re
*/-\*
*****
Posts: 4599


« Reply #7 on: May 04, 2006, 03:01:31 PM »

UPPERCASE
Logged
Anonymous
Guest
« Reply #8 on: May 04, 2006, 07:40:08 PM »

...come again? o.o
Logged
Z!re
*/-\*
*****
Posts: 4599


« Reply #9 on: May 05, 2006, 08:48:50 AM »

Quote from: "cha0s"
...come again? o.o
Topic title.
Logged
torstum
Member
*
Posts: 62


« Reply #10 on: June 15, 2006, 04:07:51 PM »

I've been using the WAIT &H3DA, 8 command for years, but I've never used it consecutively. What does the second command( WAIT &H3DA, 8, 8 )do differently from the first one?
Logged
Anonymous
Guest
« Reply #11 on: June 16, 2006, 02:31:55 AM »

i think the first one waits for the crt to finish, the second waits for it to jump back to the beginning (smallll pause between the two). I might be way off. it would make sens tho, i think ;p
Logged
RyanKelly
Forum Regular
**
Posts: 109



WWW
« Reply #12 on: June 17, 2006, 07:43:13 PM »

Quote from: "cha0s"
i think the first one waits for the crt to finish, the second waits for it to jump back to the beginning (smallll pause between the two). I might be way off. it would make sens tho, i think ;p


That's right.  The vertical retrace flag merely indicates that a retrace is in progress, but there is practically no way to know if it just began or is about to end, so the common technique is to test for a retrace and, if one is currently taking place, to wait for it to end and then begin blitting after the next retrace starts to ensure that the program has enough time to finish before the next display frame.
All of this is problematic on a machine running NT, because that retrace flag is emulated and the frequency at which it toggles is.... retarded (actually it's at the mercy of the proccess scheduler).
Logged
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #13 on: June 18, 2006, 12:01:09 PM »

You all have to check the FAQ more, guys Wink

http://faq.qbasicnews.com/?blast=VerticalRetraceGeneral
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
RyanKelly
Forum Regular
**
Posts: 109



WWW
« Reply #14 on: June 20, 2006, 12:11:12 AM »

Quote from: "na_th_an"
You all have to check the FAQ more, guys Wink

http://faq.qbasicnews.com/?blast=VerticalRetraceGeneral


I realize now I didn't notice the exact commands that were referenced.  Those two wait commands do work as described in the faq, but this does not seem like a good method for reducing flicker.  The vertical retrace is the period of time during which the CRT moves back to the top of the screen.  This is the period during which you want to blit a buffer to the screen, not after the retrace has ended.  The loop described in the faq would need an additional wait statement to catch the begining of the next retrace..
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!