Problem when using GetWindowPos (screencontrol) without a sleep after SetWindowPos

[Tourist Trap]

Hello,

I'm a little confused by this behaviour that may be a bug of the 1.06 or something caused by win10.

Code: Select all

#include "fbgfx.bi"
screenres 600,400
screencontrol fb.set_window_pos, 100, 400
'sleep 1000
screencontrol fb.set_window_pos, 333, 222

dim as integer x, y
screencontrol fb.get_window_pos, x, y
? x, y


It's a minimalistic version of my code. For me, without the sleep I don't get the new position.

Thanks

[badidea]

Not sure what happens on your system, but probably the same issue here (linux, fbc 1.0.5 32 bit & 64 bit):
screencontrol fb.set_window_pos, 333, 222 sometimes works, sometimes is does not (without the sleep 1000).
Also the first set(screencontrol fb.set_window_pos, 100, 400) fails, with screen ending top-left corner.
After each screencontrol fb.set_window_pos a sleep of ~10 ms is needed here.
I guess some (internal) graphics update is needed before the window is actually moved.

This does seem to work ok here:

Code: Select all

#include "fbgfx.bi"
screenres 600,400
screencontrol fb.set_window_pos, 100, 400
screensync
screencontrol fb.set_window_pos, 333, 222
screensync
dim as integer x, y
screencontrol fb.get_window_pos, x, y
? x, y
sleep


[Tourist Trap]

Not sure what happens on your system, but probably the same issue here (linux, fbc 1.0.5 32 bit & 64 bit):
screencontrol fb.set_window_pos, 333, 222 sometimes works, sometimes is does not (without the sleep 1000).
Also the first set(screencontrol fb.set_window_pos, 100, 400) fails, with screen ending top-left corner.

For now, here, the setwindowpos of screencontrol works. But the get fails. If I put a sleep, the get returns the correct newest value. Anyway my windows move, and this is very disappointing that for you its worse. I never noticed this before.
I'm working at my contest game so it's critical ahah!

[badidea]

I'm working at my contest game so it's critical ahah!

No stress, there is nearly always a solution or workaround. One suggestion added to previous post.

[Tourist Trap]

I'm working at my contest game so it's critical ahah!

No stress, there is nearly always a solution or workaround. One suggestion added to previous post.

I think I'll need more than a workaround to deliver something. I'm in one of those period where I do everything slowly with no inspiration... It's more about the participation award anyway. I think I've enough knowledge to deliver something, which (just finishing) is challenging enough at my level :)

Another stone in the shoe, I used to do music with Bigboss6 a very old shareware that is really easy to use. But there is a core component in it that just can't run in 64bits. I'll have to find something else.

[badidea]

This code make the program hang here (most of the time):

Code: Select all

#include "fbgfx.bi"
screenres 600,400
screencontrol fb.set_window_pos, 100, 400
'screensync '<-- test
dim as integer x, y
screencontrol fb.get_window_pos, x, y
while not (x = 100 and y = 400)
   screencontrol fb.get_window_pos, x, y
   sleep 1
wend
? x, y
sleep


screensync seems to fix it

[badidea]

I think I'll need more than a workaround to deliver something. I'm in one of those period where I do everything slowly with no inspiration... It's more about the participation award anyway. I think I've enough knowledge to deliver something, which (just finishing) is challenging enough at my level :)

Still working on the game engine here :-)

Another stone in the shoe, I used to do music with Bigboss6 a very old shareware that is really easy to use. But there is a core component in it that just can't run in 64bits. I'll have to find something else.

I haven't even thought about music. I normally turn it off anyway in a game :-)

[Tourist Trap]

Screensync fixes my initial issue casually (50% of the time). Not clear what it does in depth.

Still working on the game engine here :-)

I personally have no real engine, I will base everything on animated sprites. I don't know if it won't be playable at all.

I haven't even thought about music. I normally turn it off anyway in a game :-)

The music is rated if I read well. A software like Bigboss was just a keyboard with different instruments, including laser buzz, or organons. That gives easily funny effects. I'll try to find something else on sourceforge.

[dodicat]

Perhaps sleep the refresh rate.
Gives me 100% here.

Code: Select all

#include "fbgfx.bi"


screenres 600,400

dim as integer refreshrate
screencontrol  fb.set_window_pos, 100, 400
screeninfo ,,,,,refreshrate
sleep refreshrate

dim as integer x, y


screencontrol  fb.get_window_pos, x, y
print x,y,refreshrate
sleep


 

[badidea]

Perhaps sleep the refresh rate.
Gives me 100% here.

There is no logic in that. Refresh rate seems to be in Hz (1/s), sleep is in ms (1000 / Hz).

Another suggestion. Keep setting window position until successful:

Code: Select all

#include "fbgfx.bi"

dim as integer x, y
screenres 600,400,32
do
   screencontrol  fb.set_window_pos, 100, 400
   screencontrol  fb.get_window_pos, x, y
   print x, y
   sleep 1
loop until x = 100 and y = 400
sleep

[dodicat]

Perhaps 1000/refreshrate is more logical and it seems to work.
The idea would be to sleep for at least one frame to wait for fbgfx to return the new values.

edit
This only seems to work if the sleep resolution is 1 millisecond.

[badidea]

The behavior is a bit weird. This code:

Code: Select all

#include "fbgfx.bi"

dim as integer x, y
screenres 600,400,32
print "set window at 100, 400"
do
   screencontrol  fb.set_window_pos, 100, 400
   screencontrol  fb.get_window_pos, x, y
   print x, y
   sleep 1
loop until x = 100 and y = 400
print "set window at 300, 300"
do
   screencontrol  fb.set_window_pos, 300, 300
   screencontrol  fb.get_window_pos, x, y
   print x, y
   sleep 1
loop until x = 300 and y = 300
print "Done"
sleep

Can produce the following here:

Especially the position (9, 113) on the second set window position is weird.
Results differ each time. E.g. another run gives:

[D.J.Peters]

You know a Window managers works event driven and you should know the fbgfx thread run's (by default at 60 Hz) in the background also.

So imagine your self what happens if you call set window position followed by a get window position without Sleep() !

Is it save in all cases without a call to Sleep() between this two calls ?

Do you tried Screencontroll with POLL_EVENTS between both calls ?

Do you tried to disable the 60Hz thread before ?

test 1:
set window position
screencontroll POLL_EVENTS
get window position

test 2:
set window position
screenlock : screenunlock
get window position

test 3:
set window position
sleep 500,1
get window position

test 4: (combine test 1 and test 2)
set window position
screencontroll POLL_EVENTS
screenlock : screenunlock
get window position

Joshy

[Tourist Trap]

[quote="D.J.Peters]

Do you tried to disable the 60Hz thread before ?

test 1: NOK
set window position
screencontroll POLL_EVENTS
get window position

test 2: NOK
set window position
screenlock : screenunlock
get window position

test 3: OK
set window position
sleep 500,1
get window position

test 4: (combine test 1 and test 2) NOK
set window position
screencontroll POLL_EVENTS
screenlock : screenunlock
get window position

How to disable 60hz constraint?

For now the sleep goes ok. About what value is necessary for the sleep at minimum, dodicat might well have answered even if I don't know how to force the sleep resolution.
The polling until success by badiea is quite a good idea too.

What surprises me is that, if Setscreenpos (screencontrol) doesn't retun any error, then FB should know it and is able to assign the good values by advance to Getscreenpos. Or otherwise the behaviour would have to be documented, screencontrol being here not perfectly consistent from the simplest user view.

[badidea]

I also tried screencontroll POLL_EVENTS and screenlock : screenunlock without success.
It seems that both set window position and get window position can fail or return wrong results.