Enemies Only Move in Integer Units

[C-Dawg]

New discovery. Well, new to me.

Enemies only move in whole number units of X and Y. If you try to move an enemy 0.5 using a script, the enemy ignores you and doesn't move at all.

[Gleeok]

Ouch. That sucks.... What does that mean, lots of integers being moved with enemies stuck on those? ...Is the movement cumulative for enemy x and y, or does the system round those numbers off to a whole each frame?

EDIT:

If you try to move an enemy 0.5 using a script, the enemy ignores you and doesn't move at all.

Oops, you actually answered my second question >_>

[C-Dawg]

Yep. You can get around this by only moving an enemy every so many frames. Say you want movement of 0.5. Set a counter that makes the enemy move 1 frame only every other frame. So on.

I wonder if everything is stuck to integer movement, but for FFCs the devs have put code in that does this little frame delay trick for us..?

But if you check out the Zodiac file i just uploaded, you'll see I went another direction and just set X and Y directly relative to a reference point. That seems to give smoother results.

[Joe123]

Well I don't see any other ways of doing it, I mean, if ffcs could actually move by half a pixel then the resolution for the whole system would have to be different just for them.

[C-Dawg]

It would just be handy if the engine resolved decimal movement for enemies, items, and Link the same way it does for FFCs, thats all. Like if we had Vx and Vy variables for each of these other entities.

But, absent that, nothing we can't work around.

[Joe123]

This is true.

And is why I made this:
http://www.armageddongames.net/forums/showthread.php?t=100161

[Praethus]

Another solution would be to have a value that stores the actual value of the enemy's x,y and use that value for calculations then set the enemy's x and y to that value only when you need it. I think the problem is that you add .5 to the enemy's x, and then it truncates, so you are adding .5 to the same value every time. If you have a separate value store the actual x,y value you get the real result.

Example:

If it starts at 7 and you want to add .3 every frame.
It would go to 7.3 then 7.6 then 7.9 then to 8.2. For the first 3 the enemy would consider it 7, then after the actual value got to 8.2, the enemy would move to 8.

If you tried this with the actual enemy x value you would got to 7.3 get truncated to 7 then go back to 7.3 and repeat forever.

I ran into this with Link's x,y as well, and that was my solution.