TGEA 1.7.0 Bug: dedicated server opens display device
by Jeff Faust · in Torque Game Engine Advanced · 04/08/2008 (12:31 pm) · 8 replies
When started as a dedicated server, the Stronghold demo opens a display device and a dedicated server shouldn't do this. It probably shouldn't be starting the sound driver either.
I believe it has something to do with the CommonPackage in the scripts.
I don't think any of the other demos include a scripting solution for this.
I believe it has something to do with the CommonPackage in the scripts.
I don't think any of the other demos include a scripting solution for this.
About the author
Jeff Faust creates special effects indie middleware and games for Faust Logic. --- Blog: Effectronica.com --- Twitter: @FaustLogic
#2
04/08/2008 (12:59 pm)
It doesn't surprise me that some initialization of GFX is required. I'm mainly interested in something that doesn't open up a graphics console. Whatever was happening in 1.0.3 is fine. The main issue I have with this is that I often do quick tests running a dedicated server and a client from the same codebase in order to test certain issues that only come up when the client and server are separate. This worked fine in 1.0.3, but in 1.7, it starts up a lot of display stuff and the two apps compete for graphics resources and shaders, etc. and this causes crashes. Of course you can get around this by duping the project folder, but it's a lot less convenient.
#3
It sounds as if the -dedicated flag just needs to make sure the NULL device is what is created to me, but that's a guess.
04/08/2008 (1:14 pm)
Are you configuring your dedicated server to use the GFX NULL device? It definitely wasn't a focus of testing, so I'd love to hear more regarding what you're doing, and seeing.It sounds as if the -dedicated flag just needs to make sure the NULL device is what is created to me, but that's a guess.
#4
04/08/2008 (2:12 pm)
Setting a GFX NULL device sounds like a good idea. I'll give it a try.
#5
It would work better if:
A - there was a way to set the GFX Device to a "NullDevice" without creating a canvas.
or
B - creating a canvas didn't open a window if the specified GFX Device was "NullDevice".
A solution I am experimenting with follows:
First, at around line 1367 in guiCanvas.cpp, I add the following code to avoid a crash in guiCanvas that occurs if GFX is the NullDevice:
Also in guiCanvas.cpp, around line 136, I add this code to hide the window when using a NullDevice:
Finally, to request the NullDevice I make this change in common/main.cs:
04/09/2008 (11:57 am)
Setting the desired display device to "NullDevice" seems like a good approach and works to a point. The main problem is that the actual setting of the GFX device is done in GuiCanvas::onAdd() which happens as a result of the createCanvas() script function in main.cs. This means you have to create a canvas window in order to get the GFX device set to a "NullDevice", and the window is one of the things you don't want.It would work better if:
A - there was a way to set the GFX Device to a "NullDevice" without creating a canvas.
or
B - creating a canvas didn't open a window if the specified GFX Device was "NullDevice".
A solution I am experimenting with follows:
First, at around line 1367 in guiCanvas.cpp, I add the following code to avoid a crash in guiCanvas that occurs if GFX is the NullDevice:
// Set our window as the current render target so we can see outputs.
GFX->setActiveRenderTarget(mPlatformWindow->getGFXTarget());
[b]if (!GFX->getActiveRenderTarget())
{
PROFILE_END();
return;
}[/b]Also in guiCanvas.cpp, around line 136, I add this code to hide the window when using a NullDevice:
// Initialize the window...
GFXVideoMode vm = GFXInit::getInitialVideoMode();
mPlatformWindow = WindowManager->createWindow(newDevice, vm);
[b]if (a && a->mType == NullDevice)
mPlatformWindow->hide();[/b]
// Set a minimum on the window size so people can't break us by resizing tiny.
mPlatformWindow->setMinimumWindowSize(Point2I(640,480));Finally, to request the NullDevice I make this change in common/main.cs:
// Here is where we will do the video device stuff, so it overwrites the defaults
// First set the PCI device variables (yes AGP/PCI-E works too)
initDisplayDeviceInfo();
// Just setting this here to avoid a console error from GFXInit::getBestAdapterChoice()
[b]if ($Server::Dedicated)
$pref::Video::displayDevice = "NullDevice";
else[/b]
$pref::Video::displayDevice = "D3D9";
#6
05/22/2008 (10:06 am)
Jeff - I'm having the same issue as well with starting up a dedicated server, before I start making the changes you suggested above did it work?
#7
05/22/2008 (10:17 am)
@ Andy -- I've been running with these changes for a while now and haven't had any problems. It's worth mentioning though, that I mainly run dedicated servers to test that my software is working correctly on a separated client. I don't really run true game scenarios so there could still be some hidden issues I haven't encountered.
#8
05/22/2008 (7:31 pm)
I ended up doing similar, but instead of modifying it in C++, we just disable the canvas init if its Dedicated, along with SFX startup/shutdown, (just to alleviate that extra piece)
Torque Owner Stefan Lundmark
Not sure if this (today) is just a matter of changing the scripts, but back when I tinkered with this you couldn't just disable GFX as that would make some objects (VolLight, for one) throw an invalid memory access error when they try to use the PrimBuilder or in other ways tying into GFX in their functions.
Edit: But for all I know, this might have been solved already, just thought I'd post what I knew.