Schedule problem
by Nir Ziso · in Torque Game Builder · 12/07/2006 (4:05 am) · 12 replies
I try to make a clock in my game
My clock is set for 30 min so i set it to 1800 sec in the global variable $GameClock
After 10 min the clock go faster and I don't know why
Please help
My clock is set for 30 min so i set it to 1800 sec in the global variable $GameClock
After 10 min the clock go faster and I don't know why
Please help
function StartGameClock()
{
if ($StartMyClock && $GameClock>0)
{
$GameClock--;
if (mFloor($GameClock / 60) < 10)
min.settext( "0" @ mFloor( $GameClock / 60));
else
min.settext(mFloor($GameClock / 60));
if ($GameClock %60 < 10)
sec.settext( "0" @ $GameClock %60);
else
sec.settext($GameClock %60);
$MyClockTimerID = schedule(1000, 0, "StartGameClock", "");
}
else
cancel( $MyClockTimerID);
}
#2
12/08/2006 (3:39 pm)
An example of ontimer is used on the TDN site for simplecarphysics tutorial in TGB (mini tutorials section I believe) and I think Ben would know something about that page too.
#3
12/08/2006 (11:08 pm)
Yeah, that's where I learned to use the timer ;) Forgot all about that!
#5
Why not just use the time functions and add the time up? They're much more reliable for the purposes of checking time. There's getSceneTime() on the scenegraph, or the console function getSimTime(). They both do essentially the same thing, but might differ between each other, so just make sure you use only one of them.
If you're wondering why they might differ, getSceneTime returns the time since the scenegraph you call it on was created and getSimTime returns the total time the sim has been running. There are cases where you might change your scenegraph which would throw the two way off each other for obvious reasons, but from the get-go they will probably be a few milliseconds apart aswell. If you're not sure which you want, go with getSimTime.
12/10/2006 (5:58 am)
Timers are the same as schedules in that they are only guaranteed to fire *after* their time is up. Why not just use the time functions and add the time up? They're much more reliable for the purposes of checking time. There's getSceneTime() on the scenegraph, or the console function getSimTime(). They both do essentially the same thing, but might differ between each other, so just make sure you use only one of them.
If you're wondering why they might differ, getSceneTime returns the time since the scenegraph you call it on was created and getSimTime returns the total time the sim has been running. There are cases where you might change your scenegraph which would throw the two way off each other for obvious reasons, but from the get-go they will probably be a few milliseconds apart aswell. If you're not sure which you want, go with getSimTime.
#6
12/10/2006 (3:51 pm)
But the timer will always fire within the 32ms window of when its time is up and won't accumulate error over time. Or is timer a schedule in sheeps clothing?
#7
I'm not saying not to use a timer in this case - on the contrary, a timer is probably the best thing to use - but I was suggesting that if you're doing time-based anything, it's best to base it on actual time instead of a rather weak assumption that the timer is running accurately.
In other words, use a timer and get the sim time within the timer callback rather than assuming that the correct amount of time has passed.
12/17/2006 (7:49 pm)
They basically work the same way, but the 32ms mark doesn't apply to TGB since the engine doesn't tick independent of framerate right now. You will always get a timer callback the next scene update after the time has expired, just like with schedules. Whether or not they actually accumulate error I'm not sure, but if you're adding up the amount of time that your setTimerOn call was passed in every onTimer callback, *you* will accumulate error because the callback will always be late. Timers and schedules weren't designed for keeping time with any kind of precision.I'm not saying not to use a timer in this case - on the contrary, a timer is probably the best thing to use - but I was suggesting that if you're doing time-based anything, it's best to base it on actual time instead of a rather weak assumption that the timer is running accurately.
In other words, use a timer and get the sim time within the timer callback rather than assuming that the correct amount of time has passed.
#8
Let me preface it with: here at Skunk Studios we absolutely LOVE the TGB engine, it's incredible... having used Flash/Director extensively we would never consider retreating. Yet we are troubled about how TGB can fail - silently - on some PCs that appear to have beefy enough specs to at least launch the engine. There is a failure case where TGB doesn't launch, yet appears in Task Manager invisibly, which occurs on some PCs.
Details on this: our sound designer owns a P4 with tons of RAM, single processor, which will NOT launch Torque, TGB editor, any Large Animal game... AT ALL. Silent launch and "invisible" exe appears in Task Mgr as described. I spent a few hours on site trying to resolve this... upgraded to latest drivers, ran DxDiag, installed TGB to see if I could get a console log, etc.
The main issue I have with this is the silent failure, it doesn't even drop a console.log file at all. If TGB cannot run on some hardware, it should really do SOMETHING rather than silently die like this, such as throwing up the most basic software-rendered screen allowing user to quit, which perhaps a developer could customize to let them down gently and recommend driver upgrades or something.
I have included the top portion of the DxDiag report below ~ can anyone at GG shed some light on why this might fail and whether the engine could be upgraded to 'fail gracefully' in some way? Or, even a way to get this PC to run the engine... we'd really like this person to be able to run the games during development.
Many thanks and props on a great engine overall.
K. Wik
President & CTO
Skunk Studios, Inc.
------------------
System Information
------------------
Time of this report: 1/9/2007, 13:48:37
Machine name: KARNEY-PC
Operating System: Windows XP Home Edition (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.050301-1519)
Language: English (Regional Setting: English)
System Manufacturer: INTEL_
System Model: D845GBV2
BIOS: BIOS Date: 11/15/02 15:11:16 Ver: 08.00.07
Processor: Intel(R) Pentium(R) 4 CPU 2.40GHz
Memory: 1022MB RAM
Page File: 173MB used, 2290MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 9.0c (4.09.0000.0904)
DX Setup Parameters: Not found
DxDiag Version: 5.03.2600.2180 32bit Unicode
------------
DxDiag Notes
------------
DirectX Files Tab: No problems found.
Display Tab 1: No problems found. DirectDraw test results: All tests were successful. Direct3D 7 test results: All tests were successful. Direct3D 8 test results: All tests were successful. Direct3D 9 test results: All tests were successful.
Sound Tab 1: No problems found.
Sound Tab 2: No problems found.
Sound Tab 3: No problems found.
Sound Tab 4: No problems found.
Music Tab: No problems found.
Input Tab: No problems found.
Network Tab: No problems found.
--------------------
DirectX Debug Levels
--------------------
Direct3D: 0/4 (n/a)
DirectDraw: 0/4 (retail)
DirectInput: 0/5 (n/a)
DirectMusic: 0/5 (n/a)
DirectPlay: 0/9 (retail)
DirectSound: 0/5 (retail)
DirectShow: 0/6 (retail)
---------------
Display Devices
---------------
Card name: Intel(R) 82845G/GL/GE/PE/GV Graphics Controller
Manufacturer: Intel Corporation
Chip type: Intel(R) 82845G Graphics Controller
DAC type: Internal
Device Key: Enum\PCI\VEN_8086&DEV_2562&SUBSYS_52478086&REV_03
Display Memory: 64.0 MB
Current Mode: 1024 x 768 (32 bit) (85Hz)
Monitor: ViewSonic 17PS-2
Monitor Max Res: 1600,1280
Driver Name: ialmrnt5.dll
Driver Version: 6.14.0010.4342 (English)
DDI Version: 9 (or higher)
Driver Attributes: Final Retail
Driver Date/Size: 6/21/2005 17:04:48, 38016 bytes
WHQL Logo'd: n/a
WHQL Date Stamp: n/a
VDD: n/a
Mini VDD: ialmnt5.sys
Mini VDD Date: 6/21/2005 17:12:34, 807998 bytes
Device Identifier: {D7B78E66-6622-11CF-C0F3-4D72A2C2CB35}
Vendor ID: 0x8086
Device ID: 0x2562
SubSys ID: 0x52478086
Revision ID: 0x0003
Revision ID: 0x0003
Video Accel:
Deinterlace Caps: n/a
Registry: OK
DDraw Status: Enabled
D3D Status: Enabled
AGP Status: Not Available
DDraw Test Result: All tests were successful.
D3D7 Test Result: All tests were successful.
D3D8 Test Result: All tests were successful.
D3D9 Test Result: All tests were successful.
01/29/2007 (11:41 am)
Hey all! Great thread, I've been following it closely and have a related problem to enter into the discussion.Let me preface it with: here at Skunk Studios we absolutely LOVE the TGB engine, it's incredible... having used Flash/Director extensively we would never consider retreating. Yet we are troubled about how TGB can fail - silently - on some PCs that appear to have beefy enough specs to at least launch the engine. There is a failure case where TGB doesn't launch, yet appears in Task Manager invisibly, which occurs on some PCs.
Details on this: our sound designer owns a P4 with tons of RAM, single processor, which will NOT launch Torque, TGB editor, any Large Animal game... AT ALL. Silent launch and "invisible" exe appears in Task Mgr as described. I spent a few hours on site trying to resolve this... upgraded to latest drivers, ran DxDiag, installed TGB to see if I could get a console log, etc.
The main issue I have with this is the silent failure, it doesn't even drop a console.log file at all. If TGB cannot run on some hardware, it should really do SOMETHING rather than silently die like this, such as throwing up the most basic software-rendered screen allowing user to quit, which perhaps a developer could customize to let them down gently and recommend driver upgrades or something.
I have included the top portion of the DxDiag report below ~ can anyone at GG shed some light on why this might fail and whether the engine could be upgraded to 'fail gracefully' in some way? Or, even a way to get this PC to run the engine... we'd really like this person to be able to run the games during development.
Many thanks and props on a great engine overall.
K. Wik
President & CTO
Skunk Studios, Inc.
------------------
System Information
------------------
Time of this report: 1/9/2007, 13:48:37
Machine name: KARNEY-PC
Operating System: Windows XP Home Edition (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.050301-1519)
Language: English (Regional Setting: English)
System Manufacturer: INTEL_
System Model: D845GBV2
BIOS: BIOS Date: 11/15/02 15:11:16 Ver: 08.00.07
Processor: Intel(R) Pentium(R) 4 CPU 2.40GHz
Memory: 1022MB RAM
Page File: 173MB used, 2290MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 9.0c (4.09.0000.0904)
DX Setup Parameters: Not found
DxDiag Version: 5.03.2600.2180 32bit Unicode
------------
DxDiag Notes
------------
DirectX Files Tab: No problems found.
Display Tab 1: No problems found. DirectDraw test results: All tests were successful. Direct3D 7 test results: All tests were successful. Direct3D 8 test results: All tests were successful. Direct3D 9 test results: All tests were successful.
Sound Tab 1: No problems found.
Sound Tab 2: No problems found.
Sound Tab 3: No problems found.
Sound Tab 4: No problems found.
Music Tab: No problems found.
Input Tab: No problems found.
Network Tab: No problems found.
--------------------
DirectX Debug Levels
--------------------
Direct3D: 0/4 (n/a)
DirectDraw: 0/4 (retail)
DirectInput: 0/5 (n/a)
DirectMusic: 0/5 (n/a)
DirectPlay: 0/9 (retail)
DirectSound: 0/5 (retail)
DirectShow: 0/6 (retail)
---------------
Display Devices
---------------
Card name: Intel(R) 82845G/GL/GE/PE/GV Graphics Controller
Manufacturer: Intel Corporation
Chip type: Intel(R) 82845G Graphics Controller
DAC type: Internal
Device Key: Enum\PCI\VEN_8086&DEV_2562&SUBSYS_52478086&REV_03
Display Memory: 64.0 MB
Current Mode: 1024 x 768 (32 bit) (85Hz)
Monitor: ViewSonic 17PS-2
Monitor Max Res: 1600,1280
Driver Name: ialmrnt5.dll
Driver Version: 6.14.0010.4342 (English)
DDI Version: 9 (or higher)
Driver Attributes: Final Retail
Driver Date/Size: 6/21/2005 17:04:48, 38016 bytes
WHQL Logo'd: n/a
WHQL Date Stamp: n/a
VDD: n/a
Mini VDD: ialmnt5.sys
Mini VDD Date: 6/21/2005 17:12:34, 807998 bytes
Device Identifier: {D7B78E66-6622-11CF-C0F3-4D72A2C2CB35}
Vendor ID: 0x8086
Device ID: 0x2562
SubSys ID: 0x52478086
Revision ID: 0x0003
Revision ID: 0x0003
Video Accel:
Deinterlace Caps: n/a
Registry: OK
DDraw Status: Enabled
D3D Status: Enabled
AGP Status: Not Available
DDraw Test Result: All tests were successful.
D3D7 Test Result: All tests were successful.
D3D8 Test Result: All tests were successful.
D3D9 Test Result: All tests were successful.
#9
--bios date is 5 years old.
--the video card has 64meg, appears to be an internal/integrated card, and has drivers that are roughly a year and a half old.
I agree, issues like this can be frustrating for developers--and even more so for us, because we flat out cannot duplicate them. I will forward this thread to the TGB team lead as well as our QA, but until we can get a reproduceable case we're pretty stuck as to figuring out why it won't even generate a console.log.
01/29/2007 (12:08 pm)
The two things that stick out right away for me are:--bios date is 5 years old.
--the video card has 64meg, appears to be an internal/integrated card, and has drivers that are roughly a year and a half old.
I agree, issues like this can be frustrating for developers--and even more so for us, because we flat out cannot duplicate them. I will forward this thread to the TGB team lead as well as our QA, but until we can get a reproduceable case we're pretty stuck as to figuring out why it won't even generate a console.log.
#10
Check the file ..\games\common\preferences\defaultPrefs.cs
At the bottom of that file, you will see the following code block:
This checks the PCI vendor string for Intel's tag "VEN_8086" which you can also see in your DXDiag dump.
Torque exposes 'VEN' and 'DEV' to the console via the variables '$PCI_VEN' and '$PCI_DEV'. (Note that this works fine with AGP/PCI-E as well.) I didn't see any entries for DEV_2592 in the 'defaultPrefs.cs' logic, so this means that, by default, it thinks it should use D3D.
If you have other pref files in this directory, they will be executed after the default prefs. I would also check that file to see if it changes the value of any of these settings:
1) Another preference file is overwriting the value of these variables, causing the engine to try to load OpenGL/D3D when it is not available.
2) The logic in 'defaultPrefs.cs' needs to be changed for this video card (or worse, that revision of that video card)
01/29/2007 (12:50 pm)
Quote:I am willing to bet that this is your problem, right here, but the crash w/ no console log is very strange.
Card name: Intel(R) 82845G/GL/GE/PE/GV Graphics Controller
Check the file ..\games\common\preferences\defaultPrefs.cs
At the bottom of that file, you will see the following code block:
switch$( $PCI_VEN )
{
case "VEN_8086": // Intel
$pref::Video::displayDevice = "D3D";
$pref::Video::allowOpenGL = 0;
...This checks the PCI vendor string for Intel's tag "VEN_8086" which you can also see in your DXDiag dump.
Quote:
Device Key: Enum\PCI\VEN_8086&DEV_2562&SUBSYS_52478086&REV_03
Torque exposes 'VEN' and 'DEV' to the console via the variables '$PCI_VEN' and '$PCI_DEV'. (Note that this works fine with AGP/PCI-E as well.) I didn't see any entries for DEV_2592 in the 'defaultPrefs.cs' logic, so this means that, by default, it thinks it should use D3D.
If you have other pref files in this directory, they will be executed after the default prefs. I would also check that file to see if it changes the value of any of these settings:
$pref::Video::displayDevice $pref::Video::allowOpenGL $pref::Video::allowD3DSo, in summary, the most likely cause of failure is one of two things:
1) Another preference file is overwriting the value of these variables, causing the engine to try to load OpenGL/D3D when it is not available.
2) The logic in 'defaultPrefs.cs' needs to be changed for this video card (or worse, that revision of that video card)
#11
1. I did upgrade to the latest drivers from Intel's site, yeah, they're a few years old but they are the latest
2. Upgrading BIOS - ouch - was asking for a floppy disk so I bailed on that. Is it likely that upgrading BIOS would solve the issue?
3. I have seen the "silent crash" on one other machine - a circa 1998 P3 500Mhz oldie. But in that case upgrading the drivers solved my problem and I was actually pleasantly surprised by TGB performance on that old p.o.s.
I'll check into the prefs thing the next time I can get over to the sound designer's studio.
K.
01/29/2007 (1:09 pm)
Thanks, guys - you move fast! More details...1. I did upgrade to the latest drivers from Intel's site, yeah, they're a few years old but they are the latest
2. Upgrading BIOS - ouch - was asking for a floppy disk so I bailed on that. Is it likely that upgrading BIOS would solve the issue?
3. I have seen the "silent crash" on one other machine - a circa 1998 P3 500Mhz oldie. But in that case upgrading the drivers solved my problem and I was actually pleasantly surprised by TGB performance on that old p.o.s.
I'll check into the prefs thing the next time I can get over to the sound designer's studio.
K.
#12
Ken
01/29/2007 (1:43 pm)
Is there any way you can throw an AGP card in to the machine and test with it. I too believe very strongly that you will find that the Intel integrated graphics is the culprit here. Please post your findings if you are able to test this theory.Ken
Torque Owner Ben R Vesco
I agree that the schedule shouldn't speed up without reason, but schedule isn't the right approach for a timer. Try the timer and let us know the results!