![]() |
What good is cake if you can't eat it too? - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1) +--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3) +---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10) +---- Thread: What good is cake if you can't eat it too? (/showthread.php?tid=3477) |
What good is cake if you can't eat it too? - Pete - 02-21-2025 Input then in the routine, press backspace to rerun, Esc to quit, or any other inkey$ recognized key to toggle from active to idle and back. Background dims when idle. Code: (Select All)
So what doesn't seem possible when working with _Display and an image in SCREEN 0 is to have a way to show both the image and the flashing SCREEN 0 cursor, when idle, without having to constantly put the image to the screen every loop. I know in graphics we need to make a cursor routine, that's a given, but has anyone found a workaround other than constantly putting the images to display through the loop? If not, no biggie, because to get both, we just _PutImage and _Display constantly in a loop. Pete RE: What good is cake if you can't eat it too? - SMcNeill - 02-21-2025 The issue here is one that you can learn about in the wiki. (I know, I know, that's an EVIL place to go to try and learn about commands and keywords, but it has to be brought up sometimes...) https://qb64phoenix.com/qb64wiki/index.php/AUTODISPLAY Note the very first thing it tells you: Quote:_AUTODISPLAY is on by default and displays the screen at around 30 frames per second (normal vertical retrace speed). So you set a limit to 10... That means you're only going to be putting your hardware image to the screen 10 times per second. Yet, you have an AutoDisplay set that updates the screen 30 times per second. Hardware images display and then flush themselves out of the queue. They don't hang around forever like software images do. (Which is why you have to putimage them again before the next _DISPLAY.) So what your program is doing is: _Putimage: _AutoDisplay 'it shows here! _AutoDisplay 'nope, not here! _AutoDisplay 'nope, not here! _PutImage: _AutoDisplay 'yet. it's here! _AutoDisplay 'not here _AutoDisplay 'not here See that flicker in effect? You're used to ON TIMER type events... Internally, QB64 basically has the screen events set on their own independent ON TIMER thread. AutoDisplay calls that thread 30 times per second to display your screen. When your Limit is below that, you're only going through your program at (whatever the limit is), so you're going to skip frames and flicker. Thus how you're getting rid of the flicker with a limit higher than 30 -- you're updating the screen 120 times in a second (with Limit 120), but only seeing those changes pushed out 30 times a second with _AutoDisplay. Basically, a limit 120 would be like: _PutImage _PutImage _PutImage _PutImage _AutoDisplay _PutImage _PutImage _PutImage _PutImage _AutoDisplay _PutImage _PutImage _PutImage _PutImage _AutoDisplay Now you're working your buns off updating that display multiple times in the background, without the changes being pushed out the screen but every few cycles. Your best bet? Like you discovered -- just use _DISPLAY and update the screen at your own leisure. It's the best way to make certain that you keep things in sync as much as possible. RE: What good is cake if you can't eat it too? - Pete - 02-21-2025 Yeah, these is no way around not constantly updating the putimages if you want to keep the cursor active. I just wanted to make sure, before continuing my WIP buttons in SCREEN 0 project. Here is all the demos I put together to test these various components... Code: (Select All)
Well that was $1020 well... SPENT! ![]() Pete - If Clippy got $3 per word, he'd probably still abbreviate What the **** |