So, for my Configure screen, some of you know that I am trying to re-init IrrLicht with new parameters-- I've had limited success. Well, I've had small success with DevCpp, and none at all with MSVC. I dont really know why that is.. but anyway.
I was looking thru CIrrDeviceWin32 in the engine source, and I note that Niko never calls UnregisterClass(). Also, he doesnt return from fullscreen in closeDevice(), but in the ~CIrrDeviceWin32. Meaning you'd have to delete the object to completely restore the system.
I dont know that I'd need to do that if I'm just re-initing the system, since if I were in fullscreen, and the new setting was not fullscreen, it would explicitly ChangeDisplaySettings out of fullscreen anyway.
But the real attention of this thread is:
1) 'does he need to call UnregisterClass()' for a successful destruction of the window before recreation?
2) And secondly, can we actually get away with just calling ChangeDisplaySetting()s + adjust window size + destroy/recreate createDriver() and createGUIAndScene()?
If 2) is correct, then we can simply make re-initialization an extra function, without moving any of the current code around. One just has to be aware that their Driver/GUI/SceneMgr pointers will all be invalidated when calling this "ReInit()" function. Actually, technically most of this shouldnt be invalidated unless changing devices (from OGL to DX, for example), since I assume the only difference is their stored textures/vertex buffer objects/display lists and what have you-- the resolution shouldnt matter to Scene/GUI/Textures anyway.
Furthermore:
3) What is the likely hood of being able to automatically unload and reload resources (such as textures and display lists) in the event of a Device change? Would the Driver/GUI/SceneMgr pointers still be invalidated? Technically the GUI and SceneMgr objects should be able to stay in place in this case, though the Driver object is another matter. I could get by with not keeping static pointers to Driver (as long as I've got a Device pointer, technically I dont need any others).
re-init IrrLicht at runtime
re-init IrrLicht at runtime
a screen cap is worth 0x100000 DWORDS
well, you cant simply keep the Scene/GUI mgrs-- because they rely on graphical resources, which have to be reloaded after a device change (though not for simple things like resolution/fullscreen).
Sure, the actual Mgr objects themselves can still be the same, but since all of their managed objects will become invalid anyway, I think its cleaner just to shut the whole Mgr down (unless we can get them to automatically re-load their resources into the new device).
Sure, the actual Mgr objects themselves can still be the same, but since all of their managed objects will become invalid anyway, I think its cleaner just to shut the whole Mgr down (unless we can get them to automatically re-load their resources into the new device).
a screen cap is worth 0x100000 DWORDS
Well I was saying that if this ability was built in to the engine, Niko could keep the scene manager (with the node heirarchy etc) and just reset all managed objects as necessary. To me the biggest issue for users currently when restarting the device in a different mode (aside from the fact that we can't get it working right now ) is that they have to remake the node tree, and likely reset all the node's flags and such.
the way I see it, there are two options:
1) invalidating re-init (so only call it from a state where you are ready to re-start your program basically)
or
2) maintained re-init -- which requires transparent reloading of resources from one device to the other
obviously #2 is a lot more work, and what is the benefit? the user can decide to use openGL in the middle of playing his game-- meh. I dont think #2 is worth it.
Meanwhile, all #1 means is that you should only re-init from a main options menu or something. Sort of like how you have to dis-connect from your game in Half-Life to change video properties, or how you have to re-load the level in Quake3. This seems to be the way the Pros are doing it, so it should be enough, I think.
1) invalidating re-init (so only call it from a state where you are ready to re-start your program basically)
or
2) maintained re-init -- which requires transparent reloading of resources from one device to the other
obviously #2 is a lot more work, and what is the benefit? the user can decide to use openGL in the middle of playing his game-- meh. I dont think #2 is worth it.
Meanwhile, all #1 means is that you should only re-init from a main options menu or something. Sort of like how you have to dis-connect from your game in Half-Life to change video properties, or how you have to re-load the level in Quake3. This seems to be the way the Pros are doing it, so it should be enough, I think.
a screen cap is worth 0x100000 DWORDS
okay, so I've made a little more progress.
re-init (as per method #1 in my last post) is working in DevCpp, changing such options as Device driver, Resolution, and Color Depth.
(Of course, choosing DirectX8 will crash, because I am using the vanilla DevCpp library without DX8)
I do have a problem though, my code should only save the settings if the device change is successful. Right now my Init() function returns TRUE if irr::createDevice() returns a valid object, and FALSE if it returns a NULL. This is consistant with the documentation that says irr::createDevice() will return null if it could not create a device.
the problem is-- its not returning null at all.
in code:
I think instead, Niko should do something like:
re-init (as per method #1 in my last post) is working in DevCpp, changing such options as Device driver, Resolution, and Color Depth.
(Of course, choosing DirectX8 will crash, because I am using the vanilla DevCpp library without DX8)
I do have a problem though, my code should only save the settings if the device change is successful. Right now my Init() function returns TRUE if irr::createDevice() returns a valid object, and FALSE if it returns a NULL. This is consistant with the documentation that says irr::createDevice() will return null if it could not create a device.
the problem is-- its not returning null at all.
in code:
Code: Select all
return new CIrrDeviceWin32(driverType, windowSize, bits,
fullscreen, stenticbuffer, res, version);
Code: Select all
CIrrDeviceWin32* device = new CIrrDeviceWin32(driverType, windowSize, bits, fullscreen, stenticbuffer, res, version);
if( device->isValid() ) return device;
delete device;
return NULL;
a screen cap is worth 0x100000 DWORDS