teichgraf's picture

How to get GameWindow.Location ?

Hello again.

Is it possible to get the current location of the GameWindow on screen?
Something like:

System.Windows.Forms.Form.Location;

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

No. What do you need this functionality for?

The current plan is to have GameWindow startup centered in the relevant monitor (taking multi-monitor systems into account) - the user will be able to move the window to another position, if he so chooses. Unless there is a solid argument for being able to get/set the location, this functionality won't be part of GameWindow (it's not meant to emulate the whole Form API!)

teichgraf's picture

What do you need this functionality for?

I am coding a little demo and it would be nice to get the change of the window position, to simulate the inertia of the objects in the window, when it moves.

the Fiddler's picture

Cool :D

I took the time to check what's needed and it looks GameWindow is already processing the necessary messages. The only missing thing is the actual Location property ;)

teichgraf's picture

Sounds promising. :)

Stevo14's picture

I am coding a little demo and it would be nice to get the change of the window position, to simulate the inertia of the objects in the window, when it moves.
*brain explodes with cool game ideas* :)
I will definitely want to see this demo when it's finished.

Also, it would be interesting if the code was multiple-monitor-aware. e.g. Which monitor is the game window displayed on.

the Fiddler's picture

Yeah, you'll be able to get the DisplayDevice where the GameWindow is located, or set the DisplayDevice you want the window to be created on. This is future material though - for now GameWindow is created on the default/primary DisplayDevice.

teichgraf's picture

I am afraid that my idea won't work. When the window is moved, the thread seems to be supended. So no rendering or update events will be fired.

the Fiddler's picture

Yes, this is a real problem on Windows (but interestingly not on X11).

The only solution I have been able to find so far is to perform event handling on a different thread than rendering (this is a feature I'm planning to add to GameWindow in the future).

Let me know if you happen across any other solution.

teichgraf's picture

Maybe it is possible to do the whole GameWindow.Run() in a separate thread, so the window won't be blocked.
There is a component in .Net 2.0 named System.ComponentModel.BackgroundWorker, which uses a AsyncOperation. ? Or a System.Threading.Timer could do this?
But good thread handling is hard to realize.

the Fiddler's picture

No, GameWindow.Run starts the event loop, so moving it to another thread won't help. The change will have to come from inside GameWindow.Run.

The big difficulty is cross-thread data marshalling. For example, GameWindow call input event handlers from the event thread or from the thread RenderFrame runs on? What about the Resize event (where it's typical to call GL.Viewport?)

Also, should UpdateFrame be able to run on a different thread than RenderFrame? This is much more difficult for the user to handle (no OpenGL code in UpdateFrame!), but will scale better to multicore architectures. (don't worry, it's going to be opt-in)