+- 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: _DISPALY and company (/showthread.php?tid=3588)
Pages:
1
2
_DISPALY and company - krovit - 04-05-2025
I would like to limit myself... and go crazy for just a day or two a month with code review... but now I need you because I am beyond the breaking point...
Considering that there are no _PRINTMODE instructions and only some _DISPLAY and _AUTODISPLAY (in thousands of lines), I now notice that, suddenly, when I use LOCATE or _PRINTSTRING, the data (in the same position), when it updates, does NOT replace the previous one but overlaps with an unacceptable optical effect that makes it unreadable.
What could have happened??
On a side note... can you explain to me in simple words the use of _DISPLAY and _AUTODISPLAY because every time it seems to give me different effects.
Grazie!
RE: _DISPALY and company - bplus - 04-05-2025
_Display is for showing at the screen at the time it is called ONLY so all other prints and graphics are not updated again until code sees _Display again usually at the start or end of a loop.
_Autodisplay turns off _Display and so every instruction like print or graphics change are updated immediately on screen.
So once you use _Display, you must tell code everytime if you want screen update with another _Display command and again, _AutoDisplay turns off that mode.
Now Locate and Print DO NOT WORK same as _PrintString!!!
Locate "locate" at row, col of Character cell and _printstring "locates" at (x, y) PIXEL
row, col is like (y*16, x*8) pixels notice y comes first and x comes second.
RE: _DISPALY and company - Petr - 04-05-2025
The description - in my experience - may not be entirely accurate.
_Display:
First you have everything drawn in the order you want it on the screen, first the background, then the things in the back and gradually you paint it up to the things in the front that are on top and visible. None of it will be shown to you, only when it is placed in the video memory in the order in which you wrote it will it throw the result on the monitor. That is why you cannot see the flickering and redrawing. If you use _Display once, then until you use _Autodisplay, nothing new will be shown - it waits for you to throw it on the monitor with the _Display command.
_AutoDisplay turns off the _Display mode and draws everything on the monitor immediately in the order in which you programmed it, that is why the redrawing is sometimes visible.
_PrintMode _KeepBackground - basically sets the background color of the text to transparent, that is all
_PrintMode _FillBackground - sets the text background color that you have defined in the program as the background color, the default color is black.
Be careful with Printmode, the third parameter sets which image the command should be applied to. Another complication is if you use multiple virtual screens, you have to make sure you are on the desired page (commands and functions _Dest and _Source)
RE: _DISPALY and company - Pete - 04-05-2025
Try and limit the use of _Display. I like to have my routines flow through back to the main, so I strive for just one _Display statement whenever possible.
Now the overlap effect to me means you are using color with transparency in your program. Overlapping also occurs when using hardware images.
Sometimes the only way to narrow things down are to compare the program to a build that did work correctly. Check for changes and additions until you find the culprit.
Also, funny that your title is "_Dispaly" instead of _Display. Nice to know I'm not the only one who's typing transposes the a and l more times than I care to admit.
If you can post the part of the project that replicates the problem, we might be able to help. That might even be possible with the entire program, but sure 1000 of lines makes that less likely because it takes so long just to get familiar with the program flow and usage.
Pete
RE: _DISPALY and company - DSMan195276 - 04-06-2025
In addition to what others have mentioned, I'd note that `_PRINTMODE` is not the only way to get the behavior you're describing, it can also happen if your background color has a 0 Alpha value (making it transparent). You should check any `COLOR` lines you have, especially ones that set the background color, they need to use a 32-bit RGBA color rather than the text-screen color numbers.
In particular, `COLOR , 0` will set the background color to a transparent black, resulting in `_PrintString` not having a background at all. What you really want to use in that situation is `COLOR , _RGB32(0, 0, 0)`, which is still black but is not transparent (has a 255 alpha value).
RE: _DISPALY and company - bplus - 04-06-2025
+1 DSMan195276
Quote:What could have happened??
Maybe you replaced a color background from something to nothing. Like
Black = _RGB32(0,0,0)
...
Color ,Blak ' a typo on Black
Blak has 0 value and will make your background transparent and printovers overlap instead of 2nd blocking out the previous print.
RE: _DISPALY and company - SMcNeill - 04-06-2025
(04-06-2025, 01:00 PM)bplus Wrote: +1 DSMan195276
Quote:What could have happened??
Maybe you replaced a color background from something to nothing. Like
Black = _RGB32(0,0,0)
...
Color ,Blak ' a typo on Black
Blak has 0 value and will make your background transparent and printovers overlap instead of 2nd blocking out the previous print.
An even simpler mistake is to use a default SINGLE variable to try and hold information on colors instead of a LONG or _UNSIGNED LONG. The loss of precision can really screw up your color of choice. *Always* use _Unsigned Long as the variable type for any color.
RE: _DISPALY and company - SMcNeill - 04-06-2025
And here's a second thing to keep in mind with _DISPLAY:
Code: (Select All)
For i = 1 To 3
For j = 1 To 3
Print Time$, i, j
_Delay 1
Next
_Display
_Delay 1
Next
_AutoDisplay
Print "Press <Any Key> to end"
Sleep
System
If you run the above, watch closely. You'll see that the first time we run the loop, we print to the screen with each print statement. For the second and third pass however, the screen doesn't update one line at a time; it only updates once the _DISPLAY is called.
The reason for this is very simple -- by default, AUTODISPLAY is set. The first run through, i = 1, j = 1 to 3, and those print statements are going to print and display as soon as we call them. _AutoDisplay will automatically update the display and make certain to update the screen at... 60 FPS, I think?
Then we execute that _DISPLAY statement. That now turns _AUTODISPLAY off. It says that the screen will no longer update until we call _DISPLAY once again. The second run, i = 2, j = 1 to 3, and those statements print but we don't see them *UNTIL* that _Display statement is called once again. Same with the third pass of that i loop.
_DISPLAY turns OFF AUTODISPLAY and *only* updates your screen once it's called.
AUTODISPLAY updates your screen at a set FPS (60 FPS, I really and truly think).
The major purpose of _Display is to stop screen flickering in your programs. Let's say you have a program that runs at 61 loops per second. _AutoDisplay updates the screen at 60 frames per second. Isn't it fairly obvious that those two aren't going to match up perfectly? There's going to be a loop that gets overwritten somewhere and not display as you can only display 60 frames per second and not 61. Manually updating the screen yourself will prevent that flicker and skip, and that's basically what manual _DISPLAY is for.
RE: _DISPALY and company - TempodiBasic - 04-06-2025
Hi Krovit
here a demo showing the difference among SCREEN 0 and SCREEN Graphic (used in the demo 32bit colors)
and the effects of _PRINTMODE, COLOR and Alpha channel color (_RGBA32) which sets the saturation or intensity of a color (0% = transparent to background surface, 50% = half transparent to background surface, 100% = opaque to the background surface).
Code: (Select All)
Screen 0
_Title "Demo PRINT and PRINTMODE in SCREEN 0 and SCREEN Graphic"
Dim k As Integer
k = 0
On Error GoTo error1
Do
Cls
Locate 1, 1: Print "Press 0 for SCREEN 0 demo, press 1 for SCREEN graphic 32 demo"
Print " press 2 for SCREEN graphic 32 alpha, press Escape to quit"
k = _KeyHit
Select Case k
Case 48
GoSub screen0
Case 49
GoSub screen32
Case 50
GoSub Screen32Alpha
Case 27
End
End Select
_Delay .5
Loop
End
screen0:
Screen 0
Cls
Print " Screen 0"
View Print 2 To 11
Cls , 3
Color 14, 2
Print " Screen 0"
Dim a As Integer
For a = 1 To 10
Print "Hello world by QB64pe in SCREEN 0"
Next
View Print 12 To 23
Cls , 4
Color 15, 0
Print "_PRINTMODE activated"
Color 14, 1
_PrintMode _KeepBackground ' this has no effect on SCREEN 0 and this line of code makes an error warning
For a = 1 To 10
Print "Hello world by QB64pe in SCREEN 0"
Next
Color 15, 0
Print "press a key to continue"
View Print
Sleep
_KeyClear
Return
screen32:
Screen _NewImage(800, 600, 32)
Print " Screen graphic 32 standard"
Dim M As String
M = ""
View Print 2 To 11
Line (1, 1 * 16)-(800, 16 * 12), _RGBA32(150, 172, 200, 255), BF
Color _RGBA32(255, 255, 11, 255), _RGBA32(55, 255, 127, 255)
Print " Screen graphic 32"
For a = 1 To 10
Print "Hello world by QB64pe in SCREEN graphic 32"
Next
View Print 12 To 25
Line (1, 14 * 16)-(800, 18 * 16), _RGBA32(255, 11, 127, 255), BF
Line (1, 19 * 16)-(800, 25 * 16), _RGBA32(78, 11, 127, 255), BF
Color _RGBA32(255, 255, 255, 255), _RGBA32(0, 0, 0, 255)
Print "_PRINTMODE activated. the 1st OnlyBackground, the 2nd KeepBackground, the 3rd FillBackground"
_PrintMode _KeepBackground: M = "the 1st"
Color _RGBA32(255, 255, 11, 255), _RGBA32(55, 255, 127, 255)
For a = 1 To 10
If a = 5 Then _PrintMode _OnlyBackground: M = "the 2nd"
If a = 8 Then _PrintMode _FillBackground: M = "the 3rd"
Print "Hello world by QB64pe in SCREEN graphic 32"; M
Next
Color _RGBA32(255, 255, 255, 255), _RGBA32(0, 0, 0, 255)
Print "press a key to continue"
View Print
Sleep
_KeyClear
Return
Screen32Alpha:
Screen _NewImage(800, 600, 32)
Print " Screen graphic 32 alpha channel 100% and 50%"
View Print 2 To 11
Line (1, 1 * 16)-(800, 16 * 12), _RGBA32(150, 172, 200, 255), BF
Print " Screen graphic 32 100% foreground and 50%background and vice versa"
For a = 1 To 10
If a < 6 Then
Color _RGBA32(255, 255, 11, 255), _RGBA32(55, 255, 127, 125)
Print "Hello world by QB64pe in SCREEN graphic 32 alpha 50% background"
Else
Color _RGBA32(255, 255, 11, 125), _RGBA32(55, 255, 127, 255)
Print "Hello world by QB64pe in SCREEN graphic 32 alpha 50% foreground"
End If
Next
View Print 12 To 25
Line (1, 14 * 16)-(800, 18 * 16), _RGBA32(255, 11, 127, 255), BF
Line (1, 19 * 16)-(800, 25 * 16), _RGBA32(78, 11, 127, 255), BF
Color _RGBA32(255, 255, 255, 255), _RGBA32(0, 0, 0, 255)
Print "alpha channel before 0% foreground and then 0% background"
Color _RGBA32(255, 255, 11, 0), _RGBA32(55, 255, 127, 255)
For a = 1 To 10
If a = 6 Then Color _RGBA32(255, 255, 11, 255), _RGBA32(55, 255, 127, 0)
If a < 6 Then
Print "Hello world by QB64pe in SCREEN graphic 32 alpha 0% foreground"
Else
Print "Hello world by QB64pe in SCREEN graphic 32 alpha 0% background"
End If
Next
Color _RGBA32(255, 255, 255, 255), _RGBA32(0, 0, 0, 255)
Print "press a key to continue"
View Print
Sleep
_KeyClear
Return
Return
error1:
Resume Next
Return
Of course _PRINTMODE is a graphic instruction so it triggers an error warning in SCREEN 0 so I must use an error manager for this.
About _DISPLAY and _AUTODISPLAY and _DISPLAYORDER
from the wiki you can learn that
_AUTODISPLAY is default and it draws the window of application on each 30 seconds
_DISPLAYORDER says in what order the indipendent surfaces must be drawn on the screen output (software is graphic made using standar QB64pe functions, Hardware are images managed via hardware acceleration (GPU I think), and GLrender is the surface for the output of OpenGl keywords. Talking about hardware images and GLgraphic I must stress that these are too fast towards CPU standard graphic so if you want see the output on the screen you must use _DISPLAY to force the adjournment of the output on the screen.
Another must for using _DISPLAY , as already suggested by Pete, Petr, Bplus, Steve, DSman195276, is when you want see at once the output of your CPU graphic instructions. So you decide using _DISPLAY in any kind of loop that adjourn the screen after all the changements on the screen are completed.
RE: _DISPALY and company - krovit - 04-07-2025
Thanks to all of you,
your contributions have helped me fill some gaps in my understanding of QB64's behavior, which I had previously overlooked too casually.
I have always used SCREEN 0 mode because it seems to me the right compromise between colors, backgrounds, and transparencies. I still can't see the advantage of using other modes, but it does seem that some benefits can be obtained with the other modes.
Regarding _DISPLAY, I believe I have finally understood how it works.
I understand that it may seem simple, but from time to time I feel like I observe inconsistent effects, and for this reason, I have always approached _DISPLAY with a certain caution (although, in some cases, it is indispensable for to avoid unwanted flickering).
Regarding the problem I brought to your attention, I discovered — thanks to SMcNeil; it would have taken me many more days to find the problem... — that the error is a mere % instead of & (a typo) in a remote corner of the code. However, the discussion has been very useful because all the other issues suggest certain improvements to the code that I am already implementing.
I noticed that there are many banned users on the list: what on earth did they do? They must have really messed up because it seems truly impossible not to receive collaboration, kindness, and responses from you!
Thanks again!