Blitzmax NG SDL mouse events not registering on MacOS

Started by Ashmoor, August 24, 2020, 15:04:49

Previous topic - Next topic

Ashmoor

If MouseHit() is used before changing graphics, the following MouseHit() is ignored. It is as if the window loses focus and a click must be made to regain mouse input. If a key triggers graphics change, mouse works fine.

BRL graphics works fine so it's not a general MacOS issue, just a SDL issue. It happens on Windows as well but not as often as on Mac. On Mac every other click is registered, on windows about 7 out of 10 are registered.

Check code below. Am I doing something wrong or is it a problem with the module?

Code (blitzmax) Select


Framework SDL.gl2sdlmax2d
Import brl.jpgloader
Import BRL.PNGLoader
Import brl.Random


Global fullscreen%=0
Global width:Int=1110
Global height:Int=619


Graphics width,height,fullscreen
Global mouse_hit_nbr
Repeat

Cls
SetColor (150,50,20)
DrawRect (0,0,width,height)
SetColor(255,255,255)
DrawMouseCoords()
Flip

If KeyHit (KEY_ESCAPE) Or AppTerminate() Then End
If KeyHit (KEY_3) Then
fullscreen=Not(fullscreen)
EndGraphics()
ReInitGraphics()
EndIf

If MouseHit(1) Then
fullscreen=Not(fullscreen)
EndGraphics()
Local w= 500+Rnd(500)
Local h= 300+Rnd(300)
Graphics (h,w)
mouse_hit_nbr:+1
Print "mouse hits : "+mouse_hit_nbr
EndIf

Forever

Function ReInitGraphics()
If fullscreen=1 Then
Graphics 1920,1080,32
Else
Graphics width,height,0
EndIf

EndFunction


Function DrawMouseCoords()
Local x%, y%, vx%, vy%
Local yOffset:Int=200

x=MouseX()
y=MouseY()
vx=VirtualMouseX()
vy=VirtualMouseY()

SetScale(2.0,2.0)
DrawText("rm:"+x+","+y,10,10+yOffset)
DrawText("vm:"+vx+","+vy,10,40+yOffset)
SetScale(1,1)

EndFunction


Derron

Happens on Linux too... will raise an issue with your example (added brl.randomdefault as import).


bye
Ron

iWasAdam

well... (my spidy senses are tingling)
mouse and keyboard are events, so... you need to respond to the event system

hit(anything) is not responding to the event system but is tracking a 'moment' in time

so any system that isn't using an event loop as it's main loop will not function correctly (as you thought it might)

hit(anything)is meant for testing is a key or mouse or button is being pressed at the time it is executed. also be aware that keyboards are very strange creatures - some can only register a certain amount of keys pressed at any single time. these are stored and fired through events.

simples :)

Derron

No Adam,

the apps are "polling" for new events ... and then react to it. Eg an SDL event for mouse button is relayed to the "brl system" listener (so that it works for brl and sdl driven apps).
But the SDL event system does NOT see the first mouse button event after the graphics change.

So dunno ... maybe the sdl module does something special during graphics changes ...


bye
Ron

iWasAdam

Actually Derron you are wrong!

I've been into the code and looked at pollinput to see exactly what is going on:

1. MouseHit and Keyhit are just simple arrays
2. when (behind the scenes) an event occurs, the responding array position is filled true or false
3. at some stage (which ive not bothered to track down) both arrays will be cleared

so at NO stage is the user actually responding to an event. just to the cumulative (internal) events that are filling in the arrays.

Ashmoors program code proves this: the main loop has no event system, just hitkey and hitmouse

how and when the actual events are cleared and stored is being handled by some form of event thread behind the scenes somewhere.

The original question also was mentioning that mouse click (and potentially key presses) were being missed on ALL platforms. this suggests that the (hidden) event framework system is doing what it was programmed to do - it just wasn't programmed well.

To answer Ashmoors correctly (as stated)
you NEED (<-read MUST) be basing your main loop on an event loop. or YOU WILL LOOSE clicks and other events!

OR...

your (hidden) framework loop correctly handles the events and allows the end user to correctly use them.
Such a system would look something like:

setup graphics
programloop()
end

onmousehit() - respond to mouse

onkeyhit() - respond to key

onrender() - draw to screen

I am very fast coming to the conclusion that NG as a language works, but that is all. To make it work proper almost all the mods should be dumped, stripped and rewritten with a clear concept.

Derron

As you correctly stated:
MouseHit reads from an array
An array which is filled by events
Events which are processed "in the background"
Events which SDL "hands in"...

Events which SDL _should_ hand in ...!

it __SHOULD__ do so ... but doesn't do (currently) for the first mouse hit after a graphics change.


It is not a "hidden framework system" which is flawed, but somehow SDL does not receive the event, maybe the sdl window context whatever thing is not set correctly or whatever it is ... it is not a flawed event system "BlitzMax" which uses.


Just use "brl.glmax2d" instead of "sdl.gl2sdlmax2d" (so brl, not sdl) ... and it works:

Code (Blitzmax) Select

SuperStrict

'Framework SDL.gl2sdlmax2d
Framework brl.glmax2d
Import Brl.StandardIO
Import brl.jpgloader
Import BRL.PNGLoader
Import brl.Random
Import Brl.RandomDefault

Global fullscreen%=0
Global width:Int=1110
Global height:Int=619


Graphics width,height,fullscreen
Global mouse_hit_nbr:Int
Repeat

        Cls
        SetColor (150,50,20)
        DrawRect (0,0,width,height)
        SetColor(255,255,255)
        DrawMouseCoords()
        Flip
       
        If KeyHit (KEY_ESCAPE) Or AppTerminate() Then End
        If KeyHit (KEY_3) Then
                fullscreen=Not(fullscreen)
                EndGraphics()
                ReInitGraphics()
        EndIf

        If MouseHit(1) Then
                fullscreen=Not(fullscreen)
                EndGraphics()
                Local w:Int= 500+Rnd(500)
                Local h:Int= 300+Rnd(300)
                Graphics (h,w)
                mouse_hit_nbr:+1
                Print "mouse hits : "+mouse_hit_nbr
        EndIf 
               
Forever

Function ReInitGraphics()
        If fullscreen=1 Then
                Graphics 1920,1080,32
        Else
                Graphics width,height,0
        EndIf

EndFunction


Function DrawMouseCoords()
        Local x%, y%, vx%, vy%
        Local yOffset:Int=200
       
        x=MouseX()
        y=MouseY()
        vx=VirtualMouseX()
        vy=VirtualMouseY()
       
        SetScale(2.0,2.0)
        DrawText("rm:"+x+","+y,10,10+yOffset)
        DrawText("vm:"+vx+","+vy,10,40+yOffset)
        SetScale(1,1)

EndFunction



There is no need to have event driven system  - you can, but it is not an requirement.



PS: @Ashmoor

Graphics() returns TGraphics ... which has an Resize() method (see below - ResizeGraphics).
Graphics() also calls "EndGraphics()" for you already (no need to do twice)

ResizeGraphics() can be used to resize the current graphics window (for now only working with render backend supporting it).

So not much of use for you now (except for the "EndGraphics" hint).


bye
Ron

iWasAdam

to quote you Derron:
QuoteThe issue with the brl modules on mac is ... that opengl is more or less deprecated and so ... we need to handle that soon anyways. Dunno if there is much benefit in fixing stuff in "brl" if SDL works.

QuoteJust use "brl.glmax2d" instead of "sdl.gl2sdlmax2d" (so brl, not sdl) ... and it works:

So you are saying. "brl doesn't work so use sdl" but "use brl because sdl doesn't work"???

And you then say:
QuoteIt is not a "hidden framework system" which is flawed, but somehow SDL does not receive the event, maybe the sdl window context whatever thing is not set correctly or whatever it is ... it is not a flawed event system "BlitzMax" which uses.

and
Quoteit __SHOULD__ do so ... but doesn't do (currently) for the first mouse hit after a graphics change.


so.... to recap....
Which to use as they are both fully working and both completely not working?

Can you see how end users are starting to complain or can't work out why something that should work... doesn't?

Derron

I just said, that - if you used brl.glmax2d, the issue is gone. So it is not the "blitzmax event system" ("the thing in the background") which has a bug ... it is somewhere in sdl.mod
So I used the brl max2d driver to find out if it was a generic issue (eg in max2d) or an sdl one ... seems it only affects sdl ...


I did not say "use brl.glmax2d instead of sdl.glsdlmax2d for your applications".


bye
Ron