I still cannot fix CTRL-ALT-DEL bug on Vista (TGB 1.1.3).
by Nicolas Olhaberry · in Torque Game Builder · 05/16/2007 (1:52 pm) · 9 replies
Guys, as you might be aware already, TGB 1.1.3 crashes on Vista after you pressed CTRL-ALT-DEL while running your game. Amaranthia's posted about this issue here:
garagegames.com/mg/forums/result.thread.php?qt=61846
This is a very serious issue for me since every casual game needs to run properly under vista so it can be accepted by any major portal.
The thing is Amaranthia posted a solution but it doesn't seem to be working for me. I don't own Vista yet, so I have to send the game for testing before even knowing if the fix worked. But I cannot get the game to run properly on XP after I've applied the fix. When I switch the game from window mode to fullscreen or viceversa, I use the torquescript function toggleFullScreen() BTW, is like it stops rendering, it just displays a black screen. I should point out that the game works fine if I build TGB on debug mode, I only get this issue on release mode. But of course, I cannot send the game build on debug mode.
Has anybody tried to build a release version of TGB with Amaranthia's code? Did it worked fine? Does anybody know why I get a black screen after I call toggleFullScreen()? Have any ideas that might help to figure out where the problem is? Of course I'll try to figure this out myself, but I've never dwelved into the sourcecode before and I'm not that familiar with win32 programming either. Frankly I don't know how long its going to take me to tackle a major bug like this one, so any help will be greatly appreciated.
I would really like to hear from the garagegames staff about this issue too. It is a very serious problem so garagegames should be giving us developers some kind of support. With all due respect, the "you have the source, fix it yourself" attitude isn't the right way to go on this one, I think.
Thanks,
Nicolas.
garagegames.com/mg/forums/result.thread.php?qt=61846
This is a very serious issue for me since every casual game needs to run properly under vista so it can be accepted by any major portal.
The thing is Amaranthia posted a solution but it doesn't seem to be working for me. I don't own Vista yet, so I have to send the game for testing before even knowing if the fix worked. But I cannot get the game to run properly on XP after I've applied the fix. When I switch the game from window mode to fullscreen or viceversa, I use the torquescript function toggleFullScreen() BTW, is like it stops rendering, it just displays a black screen. I should point out that the game works fine if I build TGB on debug mode, I only get this issue on release mode. But of course, I cannot send the game build on debug mode.
Has anybody tried to build a release version of TGB with Amaranthia's code? Did it worked fine? Does anybody know why I get a black screen after I call toggleFullScreen()? Have any ideas that might help to figure out where the problem is? Of course I'll try to figure this out myself, but I've never dwelved into the sourcecode before and I'm not that familiar with win32 programming either. Frankly I don't know how long its going to take me to tackle a major bug like this one, so any help will be greatly appreciated.
I would really like to hear from the garagegames staff about this issue too. It is a very serious problem so garagegames should be giving us developers some kind of support. With all due respect, the "you have the source, fix it yourself" attitude isn't the right way to go on this one, I think.
Thanks,
Nicolas.
#2
I'm curious: how much different is TGB 1.5 from 1.1.2? We haven't thought of using 1.5 as we thought it require a completely new set of QA tests.
Cheers,
Juan Gril
Producer
Joju
05/17/2007 (9:10 am)
Hi Kenneth. Thanks for answering. I'm curious: how much different is TGB 1.5 from 1.1.2? We haven't thought of using 1.5 as we thought it require a completely new set of QA tests.
Cheers,
Juan Gril
Producer
Joju
#3
I'm sure a lot of development studios are in the same situation. We started the development of our game in October 1st of last year, and we shipped it to the market last month (it's available on several web sites already, but MSN won't put it up until this issue with Vista is fixed). Back then the latest version of TGB was 1.1.2.
I'm hoping GarageGames can address this problem soon.
Cheers,
Juan
05/17/2007 (1:57 pm)
Hi Kenneth. We just tried running our game with TGB 1.5 Beta, and it just doesn't run. Obviously TGB 1.5 has made some changes and our code it's just not compatible.I'm sure a lot of development studios are in the same situation. We started the development of our game in October 1st of last year, and we shipped it to the market last month (it's available on several web sites already, but MSN won't put it up until this issue with Vista is fixed). Back then the latest version of TGB was 1.1.2.
I'm hoping GarageGames can address this problem soon.
Cheers,
Juan
#4
I haven't tested this, just something that popped into my head as a possible issue..
05/17/2007 (2:18 pm)
Just a quick something to try... Looking at the code in the other thread, make sure that in the active section of the code, you call GameDeactivate(false)... My guess is, you're turning off rendering, but then never turning it back on. So the code from the other thread should look like this:if ((bool) wParam)
{
// Do your activation code...
GameDeactivate(false);
}
else
{
// Whatever else you need or care to do on deactivation here...
GameDeactivate(true);
}I haven't tested this, just something that popped into my head as a possible issue..
#5
The code didn't worked but you were absolutely right, the rendering was never turned back on. I messed around with the code a bit and found a way to enable the rendering again. The code would look something like this:
And the declarations should be:
If anybody sees anything wrong with this code, please let me know. I tested it and it seems to work, hope it doesn't break anything somewhere else.
So thanks again Eric, I'm not familiar with TGB source code, without your post I don't know how long it would have taken me to figure this out. Thanks Amaranthia too for posting the code in the first place :D
05/17/2007 (7:51 pm)
Eric, thanks a lot for your post!The code didn't worked but you were absolutely right, the rendering was never turned back on. I messed around with the code a bit and found a way to enable the rendering again. The code would look something like this:
case WM_ACTIVATEAPP:
if ((bool) wParam)
{
// Do your activation code...
gDGLRender = true;
}
else
{
// Whatever else you need or care to do on deactivation here...
GameDeactivate(true);
}And the declarations should be:
extern void GameDeactivate ( bool noRender ); extern bool gDGLRender;
If anybody sees anything wrong with this code, please let me know. I tested it and it seems to work, hope it doesn't break anything somewhere else.
So thanks again Eric, I'm not familiar with TGB source code, without your post I don't know how long it would have taken me to figure this out. Thanks Amaranthia too for posting the code in the first place :D
#6
05/17/2007 (8:58 pm)
I just found there is a function called GameReactivate. Do you guys think is better to call this function instead of just doing gDGLRender = true? 
#7
I've posted a fix in the thread linked below.
garagegames.com/mg/forums/result.thread.php?qt=61846
Cheers,
-Justin
05/21/2007 (2:54 pm)
Hey guys,I've posted a fix in the thread linked below.
garagegames.com/mg/forums/result.thread.php?qt=61846
Cheers,
-Justin
#8
Your fix works well on the Intel 950 chipsets by the way, and that covers a lot of computers out there.
Thanks,
Juan
05/25/2007 (4:39 pm)
Hey Justin. Yes, it did fix the problem. But unfortunately not on all machines. We still see the game crashing on the Nvidia Geforce 7300. You guys may want to try it on the rest of the Nvidia series, as it may still creating a problem.Your fix works well on the Intel 950 chipsets by the way, and that covers a lot of computers out there.
Thanks,
Juan
#9
Bryce made some changes to the main pump that we think might fix the window and full-screen version of this bug. The code he added prevents the game message pump from executing drawing instructions to surfaces in which it does not have access. We've only tested this solution on Windows, so you might need to test it on other operating systsems.
(The code below has been simplified to expose only the actual game loop. We've removed lots of things that we didn't need over here to run our game.)
In main.cc, update this snippet:
An additional strategy might be to query the foreground window process ID, and only draw when the foreground window is that of the game. Both strategies have been proven to work, but the supplied one is the simple solution that will continue painting and updating timer instructions when the game is not at the top of the Z-order. Refactoring this loop to exploit usage specific threads may also be a worthy exercise.
06/04/2007 (2:28 pm)
Juan & Justin, we *may* have a fix... Bryce made some changes to the main pump that we think might fix the window and full-screen version of this bug. The code he added prevents the game message pump from executing drawing instructions to surfaces in which it does not have access. We've only tested this solution on Windows, so you might need to test it on other operating systsems.
(The code below has been simplified to expose only the actual game loop. We've removed lots of things that we didn't need over here to run our game.)
In main.cc, update this snippet:
while(Game->isRunning())
{
Game->journalProcess();
Net::process(); // read in all events
Platform::process(); // keys, etc.
if (IsWindow(GetForegroundWindow()))
{
TimeManager::process(); // guaranteed to produce an event
Game->processEvents(); // process all non-sim posted events.
}
} An additional strategy might be to query the foreground window process ID, and only draw when the foreground window is that of the game. Both strategies have been proven to work, but the supplied one is the simple solution that will continue painting and updating timer instructions when the game is not at the top of the Z-order. Refactoring this loop to exploit usage specific threads may also be a worthy exercise.
Torque 3D Owner Kenneth Holst
Default Studio Name