ODE on slow machines

Blitz3D Forums/Blitz3D Userlibs/ODE on slow machines

Shifty Geezer(Posted 2006) [#1]
I've just tried my program on a 233 MHz K6. As expceted it runs very slowly, about half speed I'd guess. In every way it does run correctly though, EXCEPT in some rotating forces. In one example I have a roundabout with two ragdolls on, a motor force applied to the roundabout, but on this K6 PC it doesn't turn at all. In another example I have a couple of invisble sphere's rotating about a point to push a plank left and right, and the plank doesn't move.

I'm using triple QuickStep calls of size 0.1. I can't see why the forces aren't being applied. They shuld just be being applied in slow motion, the same as the rest of the ODE.


VIP3R(Posted 2006) [#2]
I've tried to replicate the problem by slowing the main loop to a crawl, but don't see any evidence of missing forces here. How are you applying the force?

I get exactly what you would expect, everything running in slow motion.

There must be some other factor involved, how much memory is on the K6 PC? What OS is it running?


Shifty Geezer(Posted 2006) [#3]
If I slow down the program on my main machine, it still works correctly just as you experience.

The K6 is Win98. Not sure about the RAM. It could be quite low. I'll have to check.

Obviously my concern here is finding the minimum spec to run my software. I was expecting that almost any machine could run it, but in slow motion. I'm facing the scarey prospect that some machines won't run it correctly at all.


VIP3R(Posted 2006) [#4]
Weird problem, I'm sure we'll get to the root of it though :)

Can you post the full spec of the machine, DX version everything...

At the moment I'm stumped, I can't think of any reason for this in either ODE or JV-ODE? The only differences that would matter to ODE between the dev machine and the K6 machine is the timing and memory right? How can that be affecting forces?

Have you tried getting some debug info from the K6 machine when it's running the simulation to see what value the forces are at?


Wayne(Posted 2006) [#5]
I would suspect some of the crafty Shifty framerate control code. hehe

Perhaps Geezer could show us his render loop.


Shifty Geezer(Posted 2006) [#6]
Here's the main loop


Here's the ODE update...



I've just tried on a PIII 600 MHz and things were much, much better. My target machine of an 800 MHz PIII should be reached. I don't know what the K6 is all about, and I was surprised the P3 is so much faster (both have 256 Mb RAM, Win98). Of course, now I'm getting random MAVs to worry about, so I'll have to stick Blitz on there and investigate. Hopefully this problem can be laid to rest without us ever having to solve it!


Shifty Geezer(Posted 2006) [#7]
Well, it's not working. I've found that the method I use to create joints that works on modern computers doesn't work on old computer. How on earth am I supposed to understand that?

This pic shows one level. A series of boxes decends a chute. This white plank moves left and right to sort them. To move the plank I have a sphere either side (semitransparent) that pushes it, jointed with a hinge joint around the red pivot points. The rotation of these spheres is selected by the user.



On my computer and other modern computers, this work perfectly. On the older Win98 machines, it doesn't. On the P3 they just drop out of the sky, as though the joint wasn't created, which would explain the MAVs I was getting when I tried to change the joint parameters. Although I don't always get a MAV.

The pics are upside down BTW. The bottom pic is the starting positon.


Shifty Geezer(Posted 2006) [#8]
This appears to be solved. In creating joints you have to specify the body/ies to connect it to, which are memory addresses. If you want to save the state of joints you can't use memory addresses so I used a simple Id of joint obj = 1 for this object, 2 for the previous object.

In my code I was replacing the joint values 1 and 2 with the memory locations for objects, but referencing the create joint function after that when object memory locations had changed. Hence MAVs and some joints not working.

In the more modern PCs, objects were being kept in the same memory locations when destroyed and recreated. Whether that's Win2000+ or more memory or what, I don't know.

Now my camera is starting to wander aimlessly, but hopefully I can pin that to the same problem.


Wayne(Posted 2006) [#9]
Outstanding Shifty, I'm glad you were able to identify the issues, I guess MAV really works! 8)

Always nice to see what interesting things other people are doing. Thanks for posting.


Shifty Geezer(Posted 2006) [#10]
It's not easy. I can't solve bugs on the development PC because it manages to cope with them. Whereas the P3 has about a 5 second lag on mouse input when debugging! Hopefully people will read this and avoid the pitfalls I've found. Basically referencing objects by pointer and delting+creating objects is a recipe for trouble that you might not encounter a until long after you thought you were finished and finding these sorts of critical bugs can cause maximum stress! Planning is absolutely key. No what your addressing and when. Unfortunately I'm not a natural coder and I find it very hard to keep track of how the thing works. Developing piecemeal code and gaffer-taping it all together is far from ideal.