2009-04-07, 11:06 PM
I can tell you the collision detection is probably a function of the frame rate. It sounds like collision is handled by time based simulation rather than trajectory tracing/intersection routines. So if the frame rate is low, then the simulation will be very likely to pass thru things undetected. Usually these things are done outside the framerate because they actually need to be finer grained. But either way, I doubt there is any other factor here other than cpu time. So increasing the priority of your SoM game might also help alleviate this.
For the animations, the situation is also similar. If if it's slowing down and speeding up, it is probably not a realtime animation (in sync with the system rtc) ...though if your system has a messed up rtc that might also explain it (say perhaps if SoM is using some legacy timing routines) ...but most likely what is happening, is the animation is just not synchronized, so when things are speeding up and slowing down, it might reflect the load other processes are having on your system. Again giving SoM (the runtime game exe) a higher priority would help aleve this.
It's possible SoM runs these simulations in separate processes which could also help explain why they seem to fluctuate independent of the game proper. In which case you might have to adjust the priority of those processes independently.
Lastly the cpu load might not be properly pipelined in accordance with the graphics hardware api calls, in which case your graphics could be causing a bottleneck which would cause these things to chug. If they do run in a separate process, you probably don't have to worry about that (outside of general performance concerns) but if they don't, it's possible the software could not foresee all possible iterations of DX, which could now be throwing a wrench into the works. Not to mention who knows the how DXs backwards compatible runtimes work, or the quality of their implementation (because really Microsoft probably cares little to see that old games continue to work... unlike OpenGL, each new version of DX is a completely new beast)
So pretty much you can chalk all of this up most likely to simplistic design thinking on SoM's part, shady backwards compatibility philosophy on behalf of DX, and perhaps most importantly, how much of a priority SoM (and any subprocesses) is getting on your system.
Anyway, I haven't tried some of the other scenarios (windmill animations and other tricks & hacks) on my machine, but everything seems to run well for me. Projectiles all work as you'd expect, which suggests the collision routines are very generalized. Striking type attacks do go thru walls, and the enemies on the other side seem to be attacking at me... but that is more of an AI thing... but if I fire a spell at an enemies spell, the two actually cancel out... so my collision processing seems to be fairly fine grained to say the least. I doubt having a too powerful machine is a problem. But I don't want to speculate too far.
For the animations, the situation is also similar. If if it's slowing down and speeding up, it is probably not a realtime animation (in sync with the system rtc) ...though if your system has a messed up rtc that might also explain it (say perhaps if SoM is using some legacy timing routines) ...but most likely what is happening, is the animation is just not synchronized, so when things are speeding up and slowing down, it might reflect the load other processes are having on your system. Again giving SoM (the runtime game exe) a higher priority would help aleve this.
It's possible SoM runs these simulations in separate processes which could also help explain why they seem to fluctuate independent of the game proper. In which case you might have to adjust the priority of those processes independently.
Lastly the cpu load might not be properly pipelined in accordance with the graphics hardware api calls, in which case your graphics could be causing a bottleneck which would cause these things to chug. If they do run in a separate process, you probably don't have to worry about that (outside of general performance concerns) but if they don't, it's possible the software could not foresee all possible iterations of DX, which could now be throwing a wrench into the works. Not to mention who knows the how DXs backwards compatible runtimes work, or the quality of their implementation (because really Microsoft probably cares little to see that old games continue to work... unlike OpenGL, each new version of DX is a completely new beast)
So pretty much you can chalk all of this up most likely to simplistic design thinking on SoM's part, shady backwards compatibility philosophy on behalf of DX, and perhaps most importantly, how much of a priority SoM (and any subprocesses) is getting on your system.
Anyway, I haven't tried some of the other scenarios (windmill animations and other tricks & hacks) on my machine, but everything seems to run well for me. Projectiles all work as you'd expect, which suggests the collision routines are very generalized. Striking type attacks do go thru walls, and the enemies on the other side seem to be attacking at me... but that is more of an AI thing... but if I fire a spell at an enemies spell, the two actually cancel out... so my collision processing seems to be fairly fine grained to say the least. I doubt having a too powerful machine is a problem. But I don't want to speculate too far.