I’m running into an issue integrating twisted with panda. The manual gives the following suggestion:
from twisted.internet.task import LoopingCall
from twisted.internet import reactor
LoopingCall(taskMgr.step).start(1 / Desired_FPS)
Which works like you’d expect UNTIL I added
Once that line was added, twisted’s internal clock seems to go nuts. For example the following runs immediately instead of waiting the specified time:
reactor.callLater(3.5, f, "hello, world")
Pretty much anything relying on a timer fails… including my connection code which gives an immediate timeout error.
Removing the DirectStart line causes everything to work as expected (minus ya know… anything graphical).
Any ideas how to make them happy together?
edit: I’m using a nightly build of panda 1.7 with the latest build of twisted (0.9 I think).
what os are you using, i remember a post that mentioned that panda screwed up (stopped) the python clock on a windows system. this is some time ago and i have no idea if that’s still the case or if it could have to do with your problem.
Are you perhaps running DirectX? When you open a DirectX context, it forces the FPU into single-mode, and that is probably what Hypnos means here.
Okay, so here’s where I’m at now:
The combination of 64 bit windows plus an ATI graphics card/driver causes both the floating point issue documented in the post linked by rdb, and also causes the twisted timer problem I’m having, no idea if the problems are connected or coincidence. What’s odd is Panda’s timers (taskMgr.DoMethodLater) seem to work fine.
Switching the following makes everything behave as normal, though obviously not particularly helpful.
And this is all pandagl, no directx
FYI, apparently some opengl drivers (cough ati) can also force single-precision mode on the FPU, and the twisted mailing list confirms this mode does bad bad things to twisted’s ability to read time (expecting a double).
I have done twisted+panda3d and don’t remember any problems. You have to use a “step reactor”. I think twisted step reactor is an unofficial script you can find with google foo.
The problem isn’t figuring out how to integrate the two blocking calls…
The problem is that with both a directx or opengl window open, with the 64 bit ati display driver on windows, forces the FPU into single-percision mode which has a bunch of side effects, including breaking a decent amount of twisted.
There’s suppose to be a way to get around that in how the window is created… but Panda’s implementation isn’t working and I’m probably not good enough to figure it out myself.
I’m having the same problems with several machines running an ATI card and Windows 7 (64bit). Some intel chips seem to be affected as well
Nvidia cards on the other hand seem to run fine.
Bug still occurs in 1.7.0.
The calculations in my program need the normal precision, so a bugfix would be greatly appreciated.
Edit: using opengl
Has there been a solution to this problem?
I haven’t heard anything further about it. I don’t know of anything different we should be doing when creating a window. DirectX does provide an interface to ask that the FPU be left alone, and we’re using that interface, but it’s being ignored by the driver. OpenGL doesn’t even provide such an interface. I’m open to any other ideas.
I already fixed this way back, I think. It was a bug in Panda, some other code was creating a context the wrong way, and some drivers don’t support multiple contexts being opened with different precision settings.
Please upgrade to 1.7.1. If you can’t use that for some reason, use this as a workaround: