I think either the time limit is too short, or it isn''t measured accurately enough. Both SampleBot and my test bot (which does very little each frame and so should not go past the limit) have gone over the limit. Given that SampleBot doesn''t do *anything* the fact that it occasionally goes over the time limit suggests that there''s something wrong somewhere.
System specs are:
1.7GHz Pentium 4
256 MB RAM
128 MB Radeon 9600 Pro
WinXP
John B
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Defect Reports
I didn''t see "swap" mentioned here, so I''d like to point out that if Windows decides to swap out some memory (maybe one of the bots is being a total memory hog, maybe whatever), the arena will decide that one of the bots took too long.
How will we know that if, during the real thing, the arena decides that we took too long, it was our fault?
(Both of the bots in the arena just spun around.)
How will we know that if, during the real thing, the arena decides that we took too long, it was our fault?
(Both of the bots in the arena just spun around.)
quote: Original post by TSwitch
I didn''t see "swap" mentioned here, so I''d like to point out that if Windows decides to swap out some memory (maybe one of the bots is being a total memory hog, maybe whatever), the arena will decide that one of the bots took too long.
How will we know that if, during the real thing, the arena decides that we took too long, it was our fault?
(Both of the bots in the arena just spun around.)
Good question. I''ll let you know when I have an answer.
systems level programming is NOT my forte, but it seems to me that it would be virtually impossible to keep windows from doing it''s "thang", so maybe something needs to be worked out where, for example, each bot gets 2 or so free "overtimes" per match. i dunno...something like that?
A headache, ancillary; an hourglass auxiliary.
"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)
A headache, ancillary; an hourglass auxiliary.
"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)
To solve the problem with interruptions, the priority of the process could be raised to the maximum level. The problem with raising the priority is that you will end up with a real mess if the program goes into an infinite loop.
khawk can you correct the GDArena Timing???
i mean instead of doing:
timer.reset (time is 0)
bot1
timer.getdeltatime (=>0,002, time is 0,002)
if(timeout) kick...
timer.reset
bot2
timer.getdeltatime (=> 0,005, time is 0,007)
if(timeout) kick...
timer.reset
arena_does_stuff_drawing_moving_etc
timer.getdeltatime (=>0,05, time is 0,057)
arena calculates movement based on the last delta time => 0,05 not the correct passed time of 0,57 causing slowdown (if both bots use their 100% calculation time its already slowing extremly down!)
can u invest one extra variable to get correct simulation time or give us info how much time was spend by the arena for updating the world??? i mean its useless to give us move/rotate-speeds when the arena isnt able to simulate them correctly
... when you think a bit you can kill every enemy bots calculations/predictions/movements by changing your bots time consuming, because the enemy bot will get wrong times...
T2k
i mean instead of doing:
timer.reset (time is 0)
bot1
timer.getdeltatime (=>0,002, time is 0,002)
if(timeout) kick...
timer.reset
bot2
timer.getdeltatime (=> 0,005, time is 0,007)
if(timeout) kick...
timer.reset
arena_does_stuff_drawing_moving_etc
timer.getdeltatime (=>0,05, time is 0,057)
arena calculates movement based on the last delta time => 0,05 not the correct passed time of 0,57 causing slowdown (if both bots use their 100% calculation time its already slowing extremly down!)
can u invest one extra variable to get correct simulation time or give us info how much time was spend by the arena for updating the world??? i mean its useless to give us move/rotate-speeds when the arena isnt able to simulate them correctly
... when you think a bit you can kill every enemy bots calculations/predictions/movements by changing your bots time consuming, because the enemy bot will get wrong times...
T2k
Ideally, I think it'd be good to separate the framerate from the update rate, so that the movement calculations are always correct. This could be done either with multithreading (might be difficult - but isn't necessarily so), or with something like the method described in this Gamasutra article incidentally, having a fixed update rate like this (and therefore using constant speeds instead of scaling by time since last frame) would allow relatively easy replay functionality, which could be useful for debugging.
John B
[edited by - JohnBSmall on August 7, 2003 2:50:40 PM]
John B
[edited by - JohnBSmall on August 7, 2003 2:50:40 PM]
quote: Original post by T2k
khawk can you correct the GDArena Timing???
i mean instead of doing:
timer.reset (time is 0)
bot1
timer.getdeltatime (=>0,002, time is 0,002)
if(timeout) kick...
timer.reset
bot2
timer.getdeltatime (=> 0,005, time is 0,007)
if(timeout) kick...
timer.reset
arena_does_stuff_drawing_moving_etc
timer.getdeltatime (=>0,05, time is 0,057)
arena calculates movement based on the last delta time => 0,05 not the correct passed time of 0,57 causing slowdown (if both bots use their 100% calculation time its already slowing extremly down!)
can u invest one extra variable to get correct simulation time or give us info how much time was spend by the arena for updating the world??? i mean its useless to give us move/rotate-speeds when the arena isnt able to simulate them correctly
... when you think a bit you can kill every enemy bots calculations/predictions/movements by changing your bots time consuming, because the enemy bot will get wrong times...
T2k
I've already fixed the timing issues... just haven't uploaded it. And BTW, that sequence you have is certainly not how it's done..it would cause some sticky problems.
How come my bot can only see walls when they are NOT in my field of view???
[edited by - Sailorstick on August 7, 2003 10:22:33 PM]
numObjs = Core->GetNumObjectsInSight();for(int i=0; i<numObjs; i++){ Core->GetObjectsInSight(i, objID, direction, distance, objDirection); if(objID==OBJ_WALL && direction<epsilon){ Core->Taunt("Wall detected"); return true; }}[edited by - Sailorstick on August 7, 2003 10:22:33 PM]
quote: Original post by Sailorstick
How come my bot can only see walls when they are NOT in my field of view???
The taunt only appears when the bot is looking towards the center of the arena and the walls just escape the edge of my FOV.numObjs = Core->GetNumObjectsInSight();for(int i=0; i<numObjs; i++){ Core->GetObjectsInSight(i, objID, direction, distance, objDirection); if(objID==OBJ_WALL && direction<epsilon){ Core->Taunt("Wall detected"); return true; }}
[edited by - Sailorstick on August 7, 2003 10:22:33 PM]
Because it doesn''t work?
I never said it was..This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
