in game switch to fullscreen , how to ?

[gabdab]

How do I switch ,back and forth , to fullscreen in game ?

[Lonesome Ducky]

You'll have to clones all textures and scene nodes, create a new device, then put those scene nodes and textures into the new device. Inconvenient, I know, and I don't think there are plans for changing it in the next version.

[shadowslair]

You can also try to call "Device->setResizable(true);" to allow you to resize and minimize/maximize the screen size. You can see it working in the 09.MeshViewer example. Yeah, not that good, depending on the case. Usually letting the user choose the screensize and device at init time or applying the changes at next game/app restart does the job.

[aanderse]

i have a question about this...

i create an irrlicht rendering context in a window i create with qt
i can then use the qt api to toggle between fullscreen and windowed mode dynamically without having to do any texture reloading etc... it "just works"

my question is: what are the draw backs to this method i am using?

the pros are that it gives me full control of the window (dynamic fullscreen vs windowed, i can programmatically set the size of the window and lock it, or allow the user to change it, etc...)

thank you

[Radikalizm]

@aanderse:

When a D3D or OGL application runs in full-screen the entire GPU is dedicated to this application, allowing for a greater performance than in windowed mode at the same resolution
Since you're using Qt you'll still be running windowed, so you won't be able to use this performance boost

There are probably some other problems with this, but I can't come up with any atm

[gabdab]

i create an irrlicht rendering context in a window i create with qt ...
my question is: what are the draw backs to this method i am using?

You can not use directx acceleration on qt widgets , and also opengl might be troublesome I kind of remember.
Or .. are you embedding by window id , not sure about that ..

When a D3D or OGL application runs in full-screen the entire GPU is dedicated to this application, allowing for a greater performance than in windowed mode at the same resolution

That is why I am asking for fullscreen .
I am using

Code: Select all

Device->setResizable(true);

in my code , but I need to restart the engine for fullscreen rendering .

Usually letting the user choose the screensize and device at init time or applying the changes at next game/app restart does the job.

Maybe one could use threads to achieve a self - quit/restart irrlicht - with new settings (fullscreen) ?
I have no previous experience with that .

[hybrid]

No, you can't. Nt straight away at least. But why do you think that you need threads anyway? Easiest would be to serialize your scene, quit the device, and restart. Creating a second context and sharing the data could be possible under OpenGL, but ressources in Irrlicht won't support this either. Just not a very common thing to do this on the fly.

[Radikalizm]

You can not use directx acceleration on qt widgets , and also opengl might be troublesome I kind of remember.

Who told you you can't use DirectX with Qt widgets? As a matter of fact, I'm working on a material editor at this very moment in Qt using a rendering widget for my engine, and it works just fine in DX11 mode

[aanderse]

Or .. are you embedding by window id , not sure about that ..

yes, i am

When a D3D or OGL application runs in full-screen the entire GPU is dedicated to this application, allowing for a greater performance than in windowed mode at the same resolution
Since you're using Qt you'll still be running windowed, so you won't be able to use this performance boost

good to know
everything renders really fast even in windowed mode because my scenes are pretty simple
the ability to dynamically switch between fullscreen and not is pretty important to me so i will stick with this

There are probably some other problems with this, but I can't come up with any atm

if you think of any, please let me know!

[gabdab]

http://blueskin.posterous.com/creating- ... t-using-qt
This is the only reference material I was able to find googleing for 'qt directx' .
It adheres to the 'window id' system.
I am afraid such system might be prone to risks.. not sure though.

Easiest would be to serialize your scene, quit the device, and restart.

Ok, I'd like to avoid having to manually relaunch the program, but having a thread controlling the 'close irrlicht thread / open new irrlicht thread ' and passing the serialized (in memory) scene to the new thread .

Creating a second context and sharing the data could be possible under OpenGL, but resources in Irrlicht won't support this either. Just not a very common thing to do this on the fly.

You don't need to 'share' the data , you just close and reopen the active irrlicht thread.
threads
thread_1(listener) | thread_2(irrlicht) close | thread_3(irrlicht) open
I didn't test it ,but can't see any problem with that.

[Granyte]

i can't belive it's that damn complex in DX it's only two damn lines is it open gl that screw up the thing?

[gabdab]

i can't belive it's that damn complex in DX it's only two damn lines is it open gl that screw up the thing?

Maybe not too complex to achieve after all.
It might be a drivers related problem with different video cards.
Not sure where to start looking in source files , apart device related ones.

[hybrid]

There's no need to use threads, you can serialize and deserialize in the main thread without problems. Also opening and closing Irrlicht devices is no problem with just one thread.
Context sharing would be necessary if you want to save textures or vertex buffers across the video driver closing. Otherwise, all these ressources would belong to just the first video driver instance. But it's still quite unlikely that it would be any easier than just reloading the whole scene.

[gabdab]

Also opening and closing Irrlicht devices is no problem with just one thread

How do you do that ?
[EDIT] updated code later , this goes

Code: Select all

[hybrid]

try to call device->closeDevice() and device->run() also right before the device->drop(). This will remove the dangling window under Windows (Linux should work without, but won't harm). Then it should work - just that your code does not have a loop or something to call this code for the second time.
Though, creating many devices is no problem with or without this stuff. The test suite creates about 500 devices IIRC, the only problem without the above call cycle was that hundreds of windows (and often also quite some amount of memory) was kept occupied on the screen. But it still ran.