A couple thoughts -- which you might be doing already --

Setting the shape property VISIBLE to .F., changing the co-ordinates, then setting VISIBLE to .T.

Another approach would be to set the form's LockScreen to .T. before making changes, then setting that to .F. to commit the changes to the form. Rather than continuous changes, you'd create something more like a movie picture with frames displaying at a rate.

I wouldn't be surprised if for every change you're making, the form is being completely redrawn. By reducing unneeded form redrawing, you may gain the performance you seek.

Jay


>Hello!!
>
>Being an avid gamer and having written games in previous lives, I of course was naturally curious as to how a game would work written in VFP. After various experimentations I have written the framework for a side scrolling platform game written solely in VFP (On my off hours, of course :)). This framework includes sound routines, joystick routines, smooth scrolling, and object collision and detection routines. I basically used subclassed image object as the different items that can be picked up, moved, walked on etc. I use sys(1270) as my collision detection routine. All of this works great except for ONE thing. You guessed it. TOO SLOW. On a P3 system with say 600mhz or higher processor everything works great. But running on a P2 with say a 300mhz it's just a little too slow.
>
>My question to all you API gurus out there is if you might know a way to use API calls (maybe BITBLT) to move an object instead of just repositioning the left and top properties of it as I am doing now. If I could speed up the moving of the actual main sprite character perhaps using API calls then it could run on a slower system.
>
>Other than that, I am amazed at how professional this game is looking using a language like VFP without doing hardly any low level stuff. It's a totally different way to do object collision and detection than what I've done in the past but very interesting.
>
>Any thoughts or comments would be very much appreciated.
>
>Thanks!