[SharpPlusJava]

I wanted to know some suggestions on image movement.

I know a lot of games either use snap coordinates to align objects to certain pixel snap adjustments, or have precise collision checking and free per-pixel movement.

Is there any proof or theory on this that proves one is indefinitely better than the other?

For example, 16-bit Final Fantasy 6 for SNES had character's images move aligned with a certain x and y coordinate adjustment, rather than pixel-by-pixel freely.

I don't know much about the advantages or disadvantages of this, but I can see that snapping things to a grid can be less error-prone than having every thing move with out any proper adjustments.

But I'm guessing either can really do. Any ideas?

[allnodcoms]

Just noticed this post... I did a lot of work on this sort of thing in the late 80's and early 90's. Earlier hardware had certain restrictions as to where it could paste images. Sprites had to be a certain width, and could only be placed on 16pix boundaries. To get the speed up, many game devs used a technique called pre-shifted sprites (basically storing multiple copies of the same image at different x offsets) but I worked with a few of the guys at Bitmap Brothers using 'really' optimised MC68K to scroll at run time - it was one of my earliest softy jobs and really fun while it lasted!

Sorry for the old timer stuff, got a bit cloudy eyed there for a minute. The answer to your question is that these days, you don't need worry about it. The sort of stuff that used pre shifted and interleaved sprites was running on an 8MHz CPU with graphics memory measured in little things called 'kilobytes'. If you wanted to be really, really picky (and I'm talking about clock cycles here) it would be (very) marginally faster to access memory on a boundary that is divisible by a power of two, but if you're talking about sprites then you'd never notice the difference unless you had literally thousands of them on screen at once...

Hope that's cleared things up a bit.

Danny