[5.22 LTS] WindowEvent() destroys graphics

[heartbone]

That simple code should work AFAIK (maybe you could try 24 instead of 32 for BPP).
It works in my Linux VM, nothing wrong with that.
What's the problem you experienced ?
Anyway with the canvas it's a lot more difficult to encounter compatibility problems, opening a full screen, considering all the linux distributions and all the possible different version of libraries involved it's a more delicate operation

Setting 24 or 16 bits makes no difference.
Instead of showing the expected results, the top 800x600 of my dektop is displayed full screen.
Thankfully the system is reset to the correct desktop display upon exit.
Perhaps the inability to correctly create a fullscreen display is an UBUNTU problem.

LinuxVM?
I often learn about something for the first time on this forum.
PureBasic on a mainframe, I'm impressed!!!

[BasicallyPure]

It seems like something is wrong here.
I run this code using PB 5.22 (x64) with Ubuntu 13.10.
When run as is with debugger on the text is displayed as expected.
If I run with debugger off, or include the delay in the event loop or both,
the text disappears and the windowed screen is white, not gray as it should be.

Code: Select all

; run with debugger off and text will not display
If OpenWindow(0,0,0,800,600,"",#PB_Window_ScreenCentered | #PB_Window_SystemMenu)
   If InitSprite() And OpenWindowedScreen(WindowID(0),0,0,800,600)
      
      ClearScreen($808080) : FlipBuffers()
      
      StartDrawing(ScreenOutput())
         DrawText(100,200," TEXT MESSAGE ONE ",RGB(200,200,0))
         DrawText(100,250," TEXT MESSAGE TWO ",RGB(200,200,0))
      StopDrawing()
         
      FlipBuffers()
      
      Repeat
         ;Delay(1) ;<-- include this and text will not display
      Until WaitWindowEvent() = #PB_Event_CloseWindow
   EndIf
EndIf

End

[heartbone]

It seems like something is wrong here.
I run this code using PB 5.22 (x64) with Ubuntu 13.10.
When run as is with debugger on the text is displayed as expected.
If I run with debugger off, or include the delay in the event loop or both,
the text disappears and the windowed screen is white, not gray as it should be.

Your system works well compared to mine.
In PB 5.22 (x86) with Ubuntu 13.10 we don't even get to see the text no matter what.

However changing your demo code to use the canvas gadget as suggested by luis, results in a well behaved program.

Code: Select all

If OpenWindow(0,0,0,800,600,"",#PB_Window_ScreenCentered | #PB_Window_SystemMenu)
   If InitSprite() And CanvasGadget(1, 0, 0, 800, 600)
      StartDrawing(CanvasOutput(1))
      Box(0,0,800,600,$808080)
      DrawText(100,200," TEXT MESSAGE ONE ",RGB(200,200,0))
      DrawText(100,250," TEXT MESSAGE TWO ",RGB(200,200,0))
      StopDrawing()
      Repeat
      Until WaitWindowEvent() = #PB_Event_CloseWindow
   EndIf
EndIf

End

I predict that rendering to the ScreenOutput() in a windowed execution environment will soon be deprecated in PureBasic for Linux.

[heartbone]

luis, here is the code from the first post in this thread modified to use the canvas gadget.

Code: Select all

Procedure RWB(X)
   StartDrawing(CanvasOutput(1)) 
   DrawingFont(FontID(1))
   DrawText(X,200,"RED",RGB(255,0,0))
   DrawText(X,300,"WHITE",RGB(255,255,255))
   DrawText(X,400,"BLUE",RGB(0,0,255))
   StopDrawing() 
   Delay(500) 
EndProcedure

LoadFont(1,"Arial",24,#PB_Font_Bold|#PB_Font_HighQuality)
LoadFont(2,"Arial",12,#PB_Font_Bold|#PB_Font_HighQuality)
If InitSprite()=0 : End : EndIf
#FLAGS= #PB_Window_ScreenCentered|#PB_Window_MinimizeGadget
If OpenWindow(0,0,0,800,600,"SOFTWARE",#FLAGS)=0 : End : EndIf
If CanvasGadget(1, 0, 0, 800, 600)=0 : End : EndIf
StartDrawing(CanvasOutput(1)) : Box(0,0,800,600,$000000) : StopDrawing() 
RWB(100) : RWB(200) : RWB(300) : RWB(400) : RWB(500)
StartDrawing(CanvasOutput(1)) : DrawingFont(FontID(2))
DrawText(150,500,"NOW A 3 SECOND DELAY BEFORE CALLING WindowEvent()",RGB(192,192,0))
StopDrawing() 
If Not FULL
   Repeat 
      X= WindowEvent() 
      If X = #PB_Event_CloseWindow : End : EndIf  ; EXECUTED WHEN USER CLICKS THE WINDOW CLOSE X ICON   
   Until X = 0   
EndIf   
Delay(3000)
DRAWFLAG= 1
DRAWTIME= ElapsedMilliseconds()+1000
Repeat
   If DRAWFLAG And DRAWTIME < ElapsedMilliseconds()
      DRAWFLAG= 0
      StartDrawing(CanvasOutput(1)) : DrawingFont(FontID(2))
      DrawText(150,550,"AFTER 1 SECOND OF WindowEvent() CALLS",RGB(192,192,0))
      StopDrawing()      
   EndIf
   Delay(2)
Until WindowEvent()= #PB_Event_CloseWindow
End

So far the code works like it's in the WindowedScreen environment within Windows without having to resort to those event timers.
Using those timers will not be necessary for my trivial program, but the graphical stability of the canvas gadget environment in Linux is.
After I see this canvas gadget working with transparent sprites, then I'll be confident that I can create my little project on Linux without a major roadblock.

[heartbone]

[ERROR] OpenScreen() or OpenWindowedScreen() must be called before using any Keyboard commands.
[ERROR] OpenScreen() or OpenWindowedScreen() must be called before using any Mouse commands.

Well that was some short lived enthusiasm for the CanvasGadget making the system work properly.
It looks like I can open a zero sized WindowedScreen to allow the keyboard to be used,
but I think that will probably whack out the sprites.
Am I going wrong here?
Is there already a recommended solution?

[luis]

It seems like something is wrong here.

You are not processing the events before doing the flipbuffers(), there is no guarantee it would work this way.

Your event loop is wrong, you need to process all the events at each frame, as stated in the doc:
http://www.purebasic.com/documentation/ ... creen.html

So when you see graphic/gui glitch in a program written like the ones you written above, there is no way to be sure there is a bug in PB, until you write a proper message loop.

Your system works well compared to mine.
In PB 5.22 (x86) with Ubuntu 13.10 we don't even get to see the text no matter what.

He's not processing the messages. It can happen.

Well that was some short lived enthusiasm for the CanvasGadget making the system work properly.

I was about to reply to your previous messages: "as long you only need to use the drawing commands and not the other commands requiring a screen, you can use the canvasgadget."
And I was about to add "Keep in mind your use of delay and while:wend to empty the queue is the wrong way to do it".

Do I have to open another Window & WindowedScreen to use the keyboard?

To use the keyboard library unfortunately in PB you need to use the screen, to simply get if a key is pressed in a normal window you can use AddKeyboardShortcut()

[heartbone]

Well that was some short lived enthusiasm for the CanvasGadget making the system work properly.

I was about to reply to your previous messages: "as long as you only need to use the drawing commands and not the other commands requiring a screen, you can use the canvasgadget."

LOL. Now you tell me.

And I was about to add "Keep in mind your use of delay and while:wend to empty the queue is the wrong way to do it".

I agree. These snippets are merely for bug demonstrations and are not optimized code.
Although in my case I only need to check for the #PB_Event_CloseWindow while emptying the queue.

Code: Select all

   Repeat 
      QE= WindowEvent() 
      If QE = #PB_Event_CloseWindow : End : EndIf     
   Until QE = 0  

Do I have to open another Window & WindowedScreen to use the keyboard?

To use the keyboard library unfortunately in PB you need to use the screen, to simply get if a key is pressed in a normal window you can use AddKeyboardShortcut()

Thanks for the pointer about AddKeyboardShortcut.
I will spend a bit of time to see if having a CanvasGadget and WindowedScreen within the same Window will serve my needs.
I'm thinking that if I can get the transparent sprites to work, then this may be a viable way to do my Linux implementation.
Wish me luck.

[luis]

BTW, all the code I saw in this thread worked as expected using Ubunto 14 when written as documented, suggested by fred and explained by me later on.

I don't know what to add to those recommendations

There are many bugs waiting to be fixed in linux but I didn't see one here, up to this point, maybe there is, but again it can be proved only by writing the code as documented first.

[heartbone]

BTW, all the code I saw in this thread worked as expected using Ubunto 14 when written as documented, suggested by fred and explained by me later on.

I don't know what to add to those recommendations

There are many bugs waiting to be fixed in linux but I didn't see one here, up to this point, maybe there is, but again it can be proved only by writing the code as documented first.

I can run anything else in Linux or Windows fine, so I doubt if there is a hardware problem with my system.
That simple OpenScreen example in post #14 does not work on my system, but it works on yours.
I'm running U13, you U14.
That must be the difference.

This is BasicallyPure's code with the change that you assert will correct the problem.
It does not fix the graphics destruction on my system.

Code: Select all

; run with debugger off and text will not display
If OpenWindow(0,0,0,800,600,"",#PB_Window_ScreenCentered | #PB_Window_SystemMenu)
   If InitSprite() And OpenWindowedScreen(WindowID(0),0,0,800,600)
     
      ClearScreen($808080) : FlipBuffers()
     
      StartDrawing(ScreenOutput())
         DrawText(100,200," TEXT MESSAGE ONE ",RGB(200,200,0))
         DrawText(100,250," TEXT MESSAGE TWO ",RGB(200,200,0))
      StopDrawing()
         While WindowEvent() : Wend 
      FlipBuffers()
     
      Repeat
         ;Delay(1) ;<-- include this and text will not display
      Until WaitWindowEvent() = #PB_Event_CloseWindow
   EndIf
EndIf

End

Although it works better, now sometimes the text shows up, the bug is still there.

Also I can assure you that if you run the code in the first post,
making your suggested changes to empty the event queue appropriately,
under UBUNTU 13 then you will still see these bugs.
These graphics destruction bugs are real in U13.x, but based on your experience running these examples in U14,
I have a strong feeling that these graphic anomalies are due to the OS and not the compiler.

If I change his code to add another empty queue after the clearscreen, then the text reliably shows up but on a white, not the programmed grey background.

Code: Select all

; run with debugger off and text will not display
If OpenWindow(0,0,0,800,600,"",#PB_Window_ScreenCentered | #PB_Window_SystemMenu)
   If InitSprite() And OpenWindowedScreen(WindowID(0),0,0,800,600)
     
      ClearScreen($808080) : While WindowEvent() : Wend
      FlipBuffers()
     
      StartDrawing(ScreenOutput())
         DrawText(100,200," TEXT MESSAGE ONE ",RGB(200,200,0))
         DrawText(100,250," TEXT MESSAGE TWO ",RGB(200,200,0))
      StopDrawing()
         While WindowEvent() : Wend
      FlipBuffers()
     
      Repeat
         ;Delay(1) ;<-- include this and text will not display
      Until WaitWindowEvent() = #PB_Event_CloseWindow
   EndIf
EndIf

End

No matter what, the Linux executables work substantially differently from the Windows compilations, and that is a real problem.
Thankfully up until now the PureBasic Windows compiler still works as a traditional BASIC should, whereas this Linux compiler seems somewhat "special", as in handicapped.
I'm sure that you know that I think that all this queue processing to generate simple graphics code is ridiculous, and is very unBASIC like.
Hopefully it will remain UNECESSARY to have to muck around with the event queue that much to create useful simple game software with the Windows compiler.

[luis]

This is BasicallyPure's code with the change that you assert will correct the problem.

Well, I said iyou can't tell if there is a bug until you write the code as should be written according to the specifics.

Also I can assure you that if you run the code in the first post,
making your suggested changes to empty the event queue appropriately,
under UBUNTU 13 then you will still see these bugs.

OK then, in that case there is a problem (doesn't happen to me).

I have hope that these graphics errors are due to the OS and not PB.

Can depend on so many things, maybe the xorg server specific to your graphic card, maybe doesn't happen with a closed binary driver from nvidia (my case), or if PB uses sdl to open a screen (I don't know) the problem can be there...

If it does happen to you with proper message processing then it should be investigated, not an easy thing to do on linux.

And now that I remember it, you also mentioned a problem with changing mode to full screen. That should also be investigated.

But again, if you use the screen and flipbuffer, you would better off doing the same thing games do, and I'm quite sure at least all your refresh problems would go away.

Something like this:

Code: Select all

Procedure Render()
  ClearScreen($808080)
 
  StartDrawing(ScreenOutput())
     DrawText(100,200," TEXT MESSAGE ONE ",RGB(200,200,0))
     DrawText(100,250," TEXT MESSAGE TWO ",RGB(200,200,0))
  StopDrawing()    
EndProcedure

If OpenWindow(0,0,0,800,600,"",#PB_Window_ScreenCentered | #PB_Window_SystemMenu)
   If InitSprite() And OpenWindowedScreen(WindowID(0),0,0,800,600)
     
      Repeat
          
        Render() ; build the whole contents here, updated to the current situation you want to display
          
        Repeat
         
          Event = WindowEvent()
     
          Select Event
            Case #PB_Event_CloseWindow
                Quit = 1
            EndSelect
           
        Until Event = 0
        
        
        FlipBuffers()   ; NOW you can flip
   
        Delay(16) ; limit to 60 fps
       
    Until Quit
   
  EndIf
EndIf

If yours it's not a game, you can reduce the FPS and the fact start/stop drawing it's not very efficient I'm sure it would not be a problem. At least this way you process events, the refresh is constant, and should work the same way in win and linux. Consider it. You just have to build the screen contents based on the current program status and not by appending output to it, it's not so difficult to do, you just have to think a little different.
The alternative is to do all with canvasgadget, but no sprites, etc.

[heartbone]

Your pseudocode has pretty much nailed how I structure the main process loop for my games.
Of course we would add the user input collection and updates to the game state variables in between your Repeat and Render() statements.
And of course no forced Delay(16) but a hold based on a comparison to the loop timer variable.
I'm sure you inserted that Delay(16) just to emphasize the point about FPS, right?
What you implemented is a <60 FPS maximum.

luis, the real news for me is the NEED to empty the event queue before issuing the FlipBuffers in a window.
It's simply amazing to me that that vital information is not in the docs in the appropriate place and emphasized!
(I just realized it's probably not emphasized because it's probably not a problem in the other OSes.)

The other lesson learned in this thread is the use of the CanvasGadget, and the consistent (in UBUNTU 13) graphics results in Linux obtained with it.
So far I have not got around to checking out the AddKeyboardShortcut() function, but I will. Thanks for the direction.

I am wondering why you have mentioned, now twice, how to best program the screen updates?
It would be a mistake for you to extrapolate my programming style from a code snippet generated to demonstrate a bug.
However how else can I interpret your stress on how to program, and now you've even supplied a rudimentary game loop template?
Thanks I appreciate it, but believe me it was not even close to necessary.
But I do sincerely appreciate your intention.

I would consider updating deltas only if resources were a problem.
But nowadays with GHz processing combined with my tiny 800x600 screen size,
it's far easier to program the main loop to redraw everything each update based on the variables
than to try and keep track of what needs to be changed.
It used to be considered a waste and lazy, but now it makes sense.

These are real code execution bugs on my system, not caused by invalid event programming.

I'm not trying to switch topics because the following does not have to do with the event queue, but since you are not seeing the bugs luis, my suspicions are shifting to the OS.
For sure the results (the first 800x600 of the desktop showing) as I've reported from running that simple 10 liner in post #14 should demonstrate an incompatibility to anyone.
By this point I had hoped that another UBUNTU 13 user would have posted with some observations.
More and more I am thinking that the OS is the source of the graphics malfunctions.
That 10 line code example in post #14 which fails on my system should be a trivial place to start the compatibility checking.
Does it fail on anyone else's Linux?

[BasicallyPure]

@luis;
Ok, I see now where I went wrong with the example I posted.

This is BasicallyPure's code with the change that you assert will correct the problem.
It does not fix the graphics destruction on my system.
(code deleted)
Although it works better, now sometimes the text shows up, the bug is still there.

Using it with heartbone's modifications it works fine on my system, I don't see any bugs with it.

Luis, the code you posted also works without problems on my system.
I see that it continuously updates the screen even though the content is not changing.
I thought it should be possible to draw the screen and flipbuffers only once and have it stick.
I was able to successfully do that but in the process I uncovered another little bit of knowledge.
I had assumed that it was only flipbuffers() that had to come after all events were processed but
I found that it is also not a good idea to draw on the screen before all events are processed.
This code as written gives me only a gray screen without text. If I move the call to Render() after
all events are processed then it works fine.

Code: Select all

Procedure Render()
  ClearScreen($808080)
 
  StartDrawing(ScreenOutput())
     DrawText(100,200," TEXT MESSAGE ONE ",RGB(200,200,0))
     DrawText(100,250," TEXT MESSAGE TWO ",RGB(200,200,0))
  StopDrawing()   
EndProcedure

count = 1


If OpenWindow(0,0,0,800,600,"",#PB_Window_ScreenCentered | #PB_Window_SystemMenu)
   If InitSprite() And OpenWindowedScreen(WindowID(0),0,0,800,600)
      
      Render() ;<-- doesn't work here, I get gray screen but no text.
      
      Repeat
         
        Repeat ; process all events
           event = WindowEvent()
           Select event
              Case #PB_Event_CloseWindow
                 Quit = #True
           EndSelect
        Until Event = 0
        
        If count > 0
           count - 1
           ;Render() ;<-- works ok here
           FlipBuffers()
        EndIf
   
        Delay(1)
       
    Until Quit
   
  EndIf
EndIf

I don't believe the Delay(16) in luis' code is necessary as the default frame rate is 60 and
FlipBuffers() should take care of that. It has been my observation that as long as a loop
executes FlipBuffers() on every pass there is no CPU overloading even without Delay().
I know why he chose Delay(16) because 1/60 = 16.666 mS.

Heartbone, you mention that you are running (x86) version of PureBasic.
By any chance is your version of Linux (x86) as well or is it (x64) OS.
The reason I ask is because I never was able to get (x86) PureBasic to run with my (x64) Linux OS.
If your OS is (x64) maybe you should try the (x64) version of PureBasic and see if that helps.

BP.

[luis]

Your pseudocode has pretty much nailed how I structure the main process loop for my games.
Of course we would add the user input collection and updates to the game state variables in between your Repeat and Render() statements.
And of course no forced Delay(16) but a hold based on a comparison to the loop timer variable.

Ok, so you already know about that, but I didn't know you knew or I would have saved some typing.
Anyhow i consider what written on the forum beneficial to others too, so maybe someone can find useful or at least consider it.
Then everyone is free to follow his own ideas.

I'm sure you inserted that Delay(16) just to emphasize the point about FPS, right?
What you implemented is a <60 FPS maximum.

It just limits FPS to 60 on a system able to draw that render code in a loop at more than 60 FPS. Considering what's in there, I would hope 99,9% of the PC out there.
Does only bad things if the system is slower than that since add delay to its slowness.

It was the bare minimum to show what I wanted to show, not saying it's always the right thing to do in a real game, just a starting point. It can be ok, or not. Depends.
And as BP says later, if PB already limit it to 60 FPS by default, or if it successfully uses vsync (good luck with that), etc then it's not needed, I'm not very familiar with PB screen commands.

luis, the real news for me is the NEED to empty the event queue before issuing the FlipBuffers in a window.

I understand.

I am wondering why you have mentioned, now twice, how to best program the screen updates?
It would be a mistake for you to extrapolate my programming style from a code snippet generated to demonstrate a bug.

I'm not trying to rate you or anyone else based on a bug report, I'm just trying to point out a bug report should at least try to follow the language specifics to reliably show there is a bug somewhere in PB and not in the way the test was coded. And again, I don't know what you have in your head, so I must base my suggestions on the code you posted here or your clarifying words on the subject.

I thought it should be possible to draw the screen and flipbuffers only once and have it stick.

Theoretically is possible, the problem is the self-persistency of the opengl surface. Sometime it can survive to an overlap, rarely can survive to a resize, and much more rarely (as in never) can survive to a screen mode change... usually that invalidate the RC context too (not always). So when the surface contents are damaged you have to respond to that events and re-render the surface contents.
If and when that happens could depend on the underlying PB code I don't have access to, on the OS, and on the driver implementation.
Not having enough control on it is *one* of the reasons why it I decided to not use PB screen commands and write my own, at least I know how they work and I can hopefully debug/modify them if needed without waiting months or maybe forever for someone else to do it.

Your observation about the need to move the render too after the event processing it's interesting and good to know even if for the reasons expressed above... who knows why ?
Anyway can make more sense since nothing more is about to happen (all events are processed) and so maybe it's a better spot to put it, just before the swap.
Sincerely I don't know.

What's clear is with PB the screen surface on linux it's a lot more delicate than on windows for whatever reason, and I don't think we can expect this to change anytime soon, so better find another approach and update it often to alleviate all these sync problems you are encountering.

[heartbone]

You guys are great.

@luis;
Ok, I see now where I went wrong with the example I posted.

Using it with heartbone's modifications it works fine on my system, I don't see any bugs with it.

BP, I'm running Linux on a 32 bit processor which probably explains the differences in our observations.
I still see the bugs with my modifications.
Running the first modified version of your code yields a grey screen only, the second modded snippet yields the text on a white background.

Can I assume that the full screen snippet in post #14 also works as expected on your 64 bit PB compiler running in 64 bit U13.10?

BP I am hoping that your strategic bit of information about the queue clearing placement will correct this misbehavior in my 32 bit compiler.
My first test using your strategy yields the correct result, so your approach looks very promising.

It reaffirms my initial analysis that WindowEvent() destroys graphics.
Not just the FlipBuffers call, but graphics need to be created after the event processing.

If using your method truly fixes this problem, then this graphics destruction not a bug, but a problem in the currently recommended programming methodology.

Thanks to both of you for the excellent help in debugging this situation.

[heartbone]

After taking all that I have learned in this thread into account, I have modified my problem code from post #1.
A very small change produced big results.

Code: Select all

Procedure CLEARQUEUE()
   Repeat
      E= WindowEvent()
      If E = #PB_Event_CloseWindow : End : EndIf     
   Until E = 0 
EndProcedure

Procedure RWB(X)
   CLEARQUEUE()
   StartDrawing(ScreenOutput()) 
   DrawingFont(FontID(1))
   DrawText(X,200,"RED",RGB(255,0,0))
   DrawText(X,300,"WHITE",RGB(255,255,255))
   DrawText(X,400,"BLUE",RGB(0,0,255))
   StopDrawing() : FlipBuffers()
   Delay(500)
EndProcedure

LoadFont(1,"Arial",24,#PB_Font_Bold|#PB_Font_HighQuality)
LoadFont(2,"Arial",12,#PB_Font_Bold|#PB_Font_HighQuality)
If InitSprite()=0 : End : EndIf
#FLAGS= #PB_Window_ScreenCentered|#PB_Window_MinimizeGadget
If OpenWindow(0,0,0,800,600,"SOFTWARE",#FLAGS)=0 : End : EndIf
If OpenWindowedScreen(WindowID(0),0,0,800,600,#True,0,0)=0 : End : EndIf
RWB(100) : RWB(200) : RWB(300) : RWB(400) : RWB(500)
CLEARQUEUE()
StartDrawing(ScreenOutput()) : DrawingFont(FontID(2))
DrawText(150,500,"NOW A 3 SECOND DELAY BEFORE CALLING WindowEvent()",RGB(192,192,0))
StopDrawing() : FlipBuffers()
Delay(3000)
DRAWFLAG= 1
DRAWTIME= ElapsedMilliseconds()+1000
Repeat
   If DRAWFLAG And DRAWTIME < ElapsedMilliseconds()
      DRAWFLAG= 0
      StartDrawing(ScreenOutput()) : DrawingFont(FontID(2))
      DrawText(150,550,"AFTER 1 SECOND OF WindowEvent() CALLS",RGB(192,192,0))
      StopDrawing() : FlipBuffers()     
   EndIf
   Delay(2)
Until WindowEvent()= #PB_Event_CloseWindow
End

It now works properly!
(Just like the code in post #1 does in the more forgiving Windows OS.)

My takeaway from this encounter with PureBasic:

MAIN GAME LOOP START
------- COLLECT USER INPUT
------- UPDATE VARIABLES
------- PROCESS EVENT QUEUE
------- RENDER SCREEN
------- FLIP BUFFERS
------- FPS LIMIT HOLD
MAIN GAME LOOP END

BasicallyPure, thanks a million.
Based on the title of this thread alone, I should have been the one to sort this out, not you.
"WindowEvent() destroys graphics" is not a bug, just a fact.
Maybe this thread should be moved?