Sorry I haven't had a chance to read all the posts in this thread yet.
I experimented a while back with the .dll wrapping a "for i=1, 10" around the whole thing. I wanted to see how much time was lost calling the .dll with its long list of arguments. I figured if it kept control for 10 iterations before passing it back to VB, that there would be a significant increase in speed at the cost of making the program seem jumpy. But there wasn't. I think it only sped things up by about 1%, so I abandoned that idea. I should test it again. I like the idea of not passing all those arguments once per iteration.
On my computer, Gravity Simulator never uses more than about 50% of the cpu cycles, so other applications run smoothly in the background. I wish I knew a way to make it run closer to 100%, so if I didn't care about running other applications that I could make the sim run faster. But I don't know how. I've been told on coding forums that it can't be done.
The vb that calls it looks something like this:
where "other stuff" does things like
xxx = RunLoop(objects, ObjMass(0), objx(0), objy(0), objz(0), objvx(0), objvy(0), objvz(0), objsize(0), CollisionObjectA(0), CollisionObjectB(0))
Loop until Pause
*update the distance boxes
*update the orbital element boxes
*check to see if it is time to execute an autopilot command
*check to see if it it time to output data to a file
*check to see if the user has paused the simulation
*apply thrust to an object if the user has chosen to do so
In the "Don't Plot" mode, it ignores a lot of these things.
Another area where I can gain about a 1% increase in speed is to not multiply tM*mass inside the loop. Rather than store objects' masses in the objMass array, I would store their mu's. (mu=GM).
Thanks for all the suggestions and work so far. Speed is the most critical thing in these types of programs (next to accuracy). I've put a new beta version on my web forum that uses your latest .dll.