Posted Wednesday, 12 March, 2008 - 09:19 by the Fiddler
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!)
Posted Wednesday, 12 March, 2008 - 09:53 by teichgraf
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.
Posted Wednesday, 12 March, 2008 - 09:59 by the Fiddler
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 ;)
Posted Wednesday, 12 March, 2008 - 13:55 by Stevo14
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.
Posted Wednesday, 12 March, 2008 - 20:01 by the Fiddler
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.
Posted Thursday, 13 March, 2008 - 09:40 by the Fiddler
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.
Posted Thursday, 13 March, 2008 - 10:30 by teichgraf
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.
Posted Thursday, 13 March, 2008 - 10:54 by the Fiddler
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)
Comments
Re: How to get GameWindow.Location ?
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!)
Re: How to get GameWindow.Location ?
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.
Re: How to get GameWindow.Location ?
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 ;)
Re: How to get GameWindow.Location ?
Sounds promising. :)
Re: How to get GameWindow.Location ?
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.
Re: How to get GameWindow.Location ?
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.
Re: How to get GameWindow.Location ?
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.
Re: How to get GameWindow.Location ?
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.
Re: How to get GameWindow.Location ?
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 aAsyncOperation. ? Or aSystem.Threading.Timercould do this?But good thread handling is hard to realize.
Re: How to get GameWindow.Location ?
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)