New feature: Hidden RenderWindows
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New feature: Hidden RenderWindows
Hm, ok, I've never used autoAspectRatio, always set it manually. So it seems setAutoAspectRatio should immediately update the aspect ratio?
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
I guess so but I don't understand something about the current implementation. It seems like it should be possible for a single camera to update multiple viewports, even though each viewport has different dimensions and aspect ratio. Also there is no way to get the list of viewports a camera is attached to. The only mechanism that makes sense to me is that as the viewports are updated, they grab info from the camera and form their own matrixes. However I don't see it working like this.
This seems a bit weird because creating multiple cameras and putting them into your scene is not much of a problem, so it could be easily constrained to a single viewport per camera.
This seems a bit weird because creating multiple cameras and putting them into your scene is not much of a problem, so it could be easily constrained to a single viewport per camera.
- Praetor
- OGRE Retired Team Member
- Posts: 3335
- Joined: Tue Jun 21, 2005 8:26 pm
- Location: Rochester, New York, US
- x 3
- Contact:
Re: New feature: Hidden RenderWindows
I believe the Camera <> Viewport connection is a frustratingly soft constraint already. Cameras reference a viewport and viewports reference a camera. Neither can reference more than one. However, a camera can be added to more than one viewport and it will work (as in, the rendering will be correct), but the reference stored in the Camera will be of the last Viewport added.
This has happened many times to me before. I've gotten lazy and re-used cameras and then had problems later on down the road. Now I'm careful and always create unique cameras for my viewports.
This has happened many times to me before. I've gotten lazy and re-used cameras and then had problems later on down the road. Now I'm careful and always create unique cameras for my viewports.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
http://www.darkwindmedia.com
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
Yeah looks like the design is as fragile as I thought when looking at the code then.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
I am confused by this business of recreating windows to change vsync. I thought the only RenderSystem where this mattered was D3D9, but surely you can just change the present parameters on an existing window there? (this may involve recreating the device, but not the window).
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
After googling a bit, i found this on mogre page:
How does 'need a different buffer format' follow to 'recreate the whole window, keyboard/mouse system, viewports, reattach cameras, etc'. I am beginning to think OGRE is just wrong about this.FSAA and VSync cannot be changed without recreating the window, both fundamentally change the buffer structure on some render systems (either the count or format of them). You don't need to reinitialise the whoe render system, just recreate the window. Since the first window is 'special' in that it holds all the GPU driver resources, if you want to do this at runtime you should create a 1x1 background window first, then create a second window afterwards which can be destroyed and recreated to your hearts content.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New feature: Hidden RenderWindows
If I'm not mistaken, all commercial games recreate the window (or require you to restart the game) if you change the antialiasing settings. Vsync, however, usually works without restart, so yeah, Ogre might be missing an opportunity there. I'm not an expert, though
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
Most commercial games require a restart for lots of things out of pure laziness I think. E.g. texture sizes in IV. Windowed vs fullscreen, resolutions in other games. I don't think I've seen a game recreate a window before, I think they probably keep the same window and recreate the device at worst.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
I tried using setHidden in D3D9 and it doesn't seem to hide the primary window. It just stays there with black background. If I close it, the main app window goes haywire.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New feature: Hidden RenderWindows
Works for me. What version of Windows and Visual Studio are you using?
That closing the primary window would cause havoc on your actual renderwindows is expected. After all, the primary renderwindow holds all the resource handles and what not, which is the reason you need a primary renderwindow in the first place.
That closing the primary window would cause havoc on your actual renderwindows is expected. After all, the primary renderwindow holds all the resource handles and what not, which is the reason you need a primary renderwindow in the first place.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
Yeah I guessed. It is XP and Visual C++ Express 2008.
I noticed on Linux I can keep the window alive if I defocus it early enough.
I noticed on Linux I can keep the window alive if I defocus it early enough.
- Pyritie
- Gnome
- Posts: 363
- Joined: Wed Feb 25, 2009 6:15 pm
- Location: UK
- x 8
- Contact:
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
Cabal: If you have a test that is known to work, I'll try that. Otherwise I'll try and do a counter example. I bet this is some wanky windows thing like all the fullscreen/windowed window size drama we've been through.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New feature: Hidden RenderWindows
In what was perhaps a foolish motion I've switched all of my computers to Win7 x64, so if it's indeed a WinXP thing, I can't test it. But if you can provide a counter example, I'll happily test it and see if it works here. Aside from that, I'll try to see if I can find something on the topic.
One thing I should note: It may very well be necessary that you call the messagePump after setting a window to hidden before it's actually hidden. This is definitely true for Linux/Xorg, I'm not entirely sure about Windows, though. Just mentioning this in case you might have omitted the messagePump for a very basic test case.
One thing I should note: It may very well be necessary that you call the messagePump after setting a window to hidden before it's actually hidden. This is definitely true for Linux/Xorg, I'm not entirely sure about Windows, though. Just mentioning this in case you might have omitted the messagePump for a very basic test case.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
What is the difference between setVisible and setHidden by the way (neither worked)
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New feature: Hidden RenderWindows
setVisible is, I think, defunct. The original purpose of that function isn't entirely clear, however, the DirectX rendersystems use isVisible() to report if the window is minimised or not. That's why I didn't touch it and chose to add a new set of functions, instead.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
I tried this on the sample browser and it didn't work, the window was still visible. (same system: xp with VC++ express 2008).
Code: Select all
diff -r ba53873fc894 Samples/Browser/include/SampleBrowser.h
--- a/Samples/Browser/include/SampleBrowser.h Thu Aug 05 20:07:29 2010 -0400
+++ b/Samples/Browser/include/SampleBrowser.h Thu Aug 12 00:23:53 2010 -0400
@@ -1031,7 +1031,9 @@
#elif OGRE_PLATFORM == OGRE_PLATFORM_ANDROID
// TODO: what to do here...
#else
mWindow = mRoot->initialise(true, "OGRE Sample Browser");
+ mWindow->setHidden(true);
+ Ogre::WindowEventUtilities::messagePump();
#endif
#if OGRE_PLATFORM == OGRE_PLATFORM_IPHONE
-
- Greenskin
- Posts: 110
- Joined: Sun Dec 04, 2005 5:17 pm
- Location: Russia
- x 5
- Contact:
-
- Halfling
- Posts: 94
- Joined: Sun Sep 25, 2005 10:25 pm
- Location: Menlo Park, CA
Re: New feature: Hidden RenderWindows
FWIW, I was about to submit the same patch kornerr did before noticing it was already in the queue. The problem seems to be the fact that unmap is called immediately after map... I found another instance where someone had a similar problem: http://www.mail-archive.com/fvwm@hpc.uh ... 08195.htmlCABAListic wrote:Ah, you are right, setFullScreen is called in setHidden. Not very readable, though. Still, I don't see why it wouldn't work for you now, but only with those changes.
-
- Greenskin
- Posts: 110
- Joined: Sun Dec 04, 2005 5:17 pm
- Location: Russia
- x 5
- Contact:
Re: New feature: Hidden RenderWindows
With OGRE it just looks ugly when you want window hidden - it first appears and only then disappears. This just fixes it. But the same problem is present in Windows, so I guess I will have to fix that too, as it looks ugly too.
EDIT: i recalled that on X it also doesn't disappear this way.
EDIT: i recalled that on X it also doesn't disappear this way.
- sparkprime
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
- Contact:
Re: New feature: Hidden RenderWindows
I think it best to find out how to change vsync without recreating a window. I don't think windows have anything to do with it.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New feature: Hidden RenderWindows
@kornerr: The reason I haven't applied your patch was because I first wanted to understand why the current code doesn't work for you. I want to know what I'm doing But if Unmap after Map causes problems, I guess that explains that. I agree that the window popping up before being hidden is ugly, and I will fix it. It's just a matter of a few more ifs. Or, perhaps, a little refactoring, but I'm reluctant touching too much of the RenderWindow implementations because they are a little ugly and magic at times.
@sparkprime: I looked up the implementation of vsync: For OpenGL it's just a matter of calling glXSwapInterval / wglSwapInterval to set vsync for the current context, so this would indeed appear to be straight-forward to switch at runtime without recreating the window. For D3D9 vsync settings appear to be set in a D3DPRESENT_PARAMETERS struct, which are then passed to D3D9->CreateDevice. I haven't yet found out how one would change those for an existing device; there is a Device->Reset call which takes that, but I'm not sure if it's applicable. Requires further investigation (or someone who is familiar enough with D3D to know ).
@sparkprime: I looked up the implementation of vsync: For OpenGL it's just a matter of calling glXSwapInterval / wglSwapInterval to set vsync for the current context, so this would indeed appear to be straight-forward to switch at runtime without recreating the window. For D3D9 vsync settings appear to be set in a D3DPRESENT_PARAMETERS struct, which are then passed to D3D9->CreateDevice. I haven't yet found out how one would change those for an existing device; there is a Device->Reset call which takes that, but I'm not sure if it's applicable. Requires further investigation (or someone who is familiar enough with D3D to know ).
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: New feature: Hidden RenderWindows
Alright, I think I fixed the outstanding issues with hidden windows.
I've also added new options setVSyncEnabled and setVSyncInterval with corresponding getters. Implemented in GL (Win32/GLX) and D3D9. I quickly tested it in the SampleBrowser, and the framerate changes indicate that setVSyncEnabled is working fine.
(On another note, I really think the RenderWindows need to be refactored. Particulary the Windows versions share so much code which only deals with creating and maintaining a window via WinAPI, not related to the rendering API.)
I've also added new options setVSyncEnabled and setVSyncInterval with corresponding getters. Implemented in GL (Win32/GLX) and D3D9. I quickly tested it in the SampleBrowser, and the framerate changes indicate that setVSyncEnabled is working fine.
(On another note, I really think the RenderWindows need to be refactored. Particulary the Windows versions share so much code which only deals with creating and maintaining a window via WinAPI, not related to the rendering API.)
-
- Greenskin
- Posts: 110
- Joined: Sun Dec 04, 2005 5:17 pm
- Location: Russia
- x 5
- Contact:
Re: New feature: Hidden RenderWindows
can setVSyncInterval be used as FPS limiter?
-
- Halfling
- Posts: 98
- Joined: Wed Jun 16, 2010 11:44 pm
- Location: Freiburg, Germany
- Contact:
Re: New feature: Hidden RenderWindows
vSync is often used as a FPS limiter