Movement Problem

Clouds

I've got a problem . . . . .
. . . and was hoping the mighty collective brain of the forum might have some useful input.

..............................................

I have an actor which I want to move left by 32 pixels and up by 19 pixels every 1 second.

..............................................

Here's the code for the actor:



..............................................


Here is his starting position (zoomed in so you can see the pixels)
The red diamond is perfectly aligned with the diamond grid - the actor is sitting on whole number co-ordinates, the grid is sitting on whole number co-ordinates.



Now here is what happens when he starts to move, he drifts a pixel to the left and a pixel down, so he ends up off centre:



..............................................


It's important for what I am trying to do that I can get this actor to move by -32 pixels and +19 pixels, I have been fighting this issue all day, I stripped my project down to just these two elements (the grid and the diamond) and I am still stuck with this problem ! (

The only insight I can offer is that when you try the same move with an actor generated in GS (ie: a box with no image) using the very same rules (in fact using the same project file) it sticks to the grid perfectly.

Here's the project file I am struggling with:

http://www.mediafire.com/?6z4i1d97pbplz6t

Here is the very same project code except using only a GS actor (with no image) as a guide/marker to see if it drifts out of sync (it doesn't):

http://www.mediafire.com/?cg5glwfivg2l42z


..............................................


Any help or ideas how to get around this greatly appreciated, I know it's only a couple of pixels, but it defeats what I am trying to do !!



Cheers



Tynan.

calvin9403

perhaps your image center is not the same as the red thing center?

Clouds

I dont understand what the issue is. in the project it is moving.

Cheers for the reply tshirtbooth . .

The red diamond instead of sticking to the grid - by moving 32 pixels left and 19 pixels up - ends up out of sync with the grid by a couple of pixels after a while.

Clouds

perhaps your image center is not the same as the red thing center?

They are identical, I got forensic on it's ass, it really is perfectly aligned, perfectly mathematically aligned, that's not the issue - in fact when you use the same code on a plain old GS actor (a box with no image) is stays perfectly in sync, so alignment is not the issue . . .

It's got me stumped !!?? 8-X 8-X 8-X 8-X

Clouds

@tshirtbooth

oh i see it now......

Got any insights, I am stumped, I am tried everything I can think of (which isn't much !) but no luck. It seems like such a basic bit of coding but I just can't get it to work.

?

JohnPapiomitis

have you tried changing the image so its not perfect to compensate for it? Gamesalad throws image positions off sometimes. Just like sometimes when you put your background in perfect position, it shows a black line on the edge of the screen. But then you adjust it so its not perfect to adjust for the line, it shows as perfect.

Clouds

have you tried changing the image so its not perfect to compensate for it?

My (perhaps flawed) logic is that any offset I do to the actor's starting position will be reflected in all it's positions . . . . when it starts it is in perfect alignment with the grid, after it's moved it shifts off centre, if I were to adjust it's starting position so subsequent positions are corrected then wouldn't the starting position be wrong (ie: be off centre).

? Have I understood your suggestion right ?

Cheers for the input.

LiquidGameworks

@Tynan When I ran the project, I checked the display x to just watch it. It moved perfectly for roughly 20 turns, then got off kilter. I'm only mentioning this because it seems slightly different than how you described it. I'm going to keep looking and see if I can find what changes at the point when it goes off course.

Clouds

@Tynan When I ran the project, I checked the display x to just watch it. It moved perfectly for roughly 20 turns, then got off kilter.

For the moment I'd ignore the 'Display X position' behaviour as it's misleading, even though the numbers on the first 20 or so turns display the correct offset (evidenced by even numbers) if you look at the actual red diamond (you may have to zoom in) it loses it's sync after just 2 or 3 turns (even when the display read out appears to say all is well).


Cheers for any help, it's genuinely appreciated.

Clouds

One further observation which may or may not be of use . . .

If you zoom in on your Mac using ctrl+scroll wheel up (make sure you have 'smooth images switched off in the universal access systems preferences so you can see GS's actual pixels) . . . . and you follow the actor up and across the screen, you can actually see it move to the correct position and then (in a fraction of a second) jump down a pixel ! It's as if once it arrives at the correct locations (-32 across and 19 up) something tells it to jump down a pixel ?

Clouds

Solved !

Well, kind of solved, I always think solved should mean you have worked out why it's not working and you have fixed it . . . but I've got it to work as it should but have no clue why it wouldn't work before nor why or how the solution works !!!?!

Taking a lead from JohnPapiomitis' suggestion I added +0.1 to the X and Y value . . . . as the actor was drifting down and left by 1 whole pixel I added a +0.1 pixel value in the opposite direction, not enough to move the starting point out of alignment but seemingly enough to stop the actor drifting the other way.

Just another little GameSalad idiosyncrasy I guess !


Cheers to everyone, much appreciated, sometimes a day's frustration and testing can be solved by even a few hints and nudges from other people.

LiquidGameworks

@ Tynan It certainly sounds like a GS issue. Have you tried using tables for movement, just to see if it makes a difference?

Clouds

@ Tynan It certainly sounds like a GS issue. Have you tried using tables for movement, just to see if it makes a difference?

I would do, but to be honest I haven't got a clue how they work (I'm a little embarrassed to admit) - I am still learning all the other stuff you are probably already very familiar with !


Would tables be a better way to move stuff around a grid ? I'll stick a screen shot up so you can see what I am trying to do . . .

Clouds

Here's a screen shot, everything moves in a pseudo-isolmetric grid . . . at the moment I am using angles and offsets (like the -32 / +19) that sync with the grid . . . but would tables help me out in any way here ?

JohnPapiomitis

glad you got it working and i could help, and it looks great!

Clouds

glad you got it working and i could help, and it looks great!

Yep, cheers John, working fine, you'd be amazed at the hours wasted trying everything to solve this, almost the whole afternoon, but still if this kind of problem comes up again I'll know what to try first !!

LiquidGameworks

@Tynan I'll see if I can set up a demo tomorrow using tables (not promising anything, never used them for diagonal movement). If anything, it'll help you utilize them later on. I have no doubt they won't be a challenge for you, given your attention to detail. That screenshot is gorgeous....

Clouds

@LiquidGameworks

@Tynan I'll see if I can set up a demo tomorrow using tables (not promising anything, never used them for diagonal movement). If anything, it'll help you utilize them later on. I have no doubt they won't be a challenge for you, given your attention to detail. That screenshot is gorgeous....

Cheers ! That would be brilliant !

I will PM you a rough project so you can see what angles / numbers I am using . . . . !

The_Gamesalad_Guru

@tynan I had a problem with my movements too but I took a laxative and it helped.

Rob2

If you use an integer attribute to calculate your position rather than adding directly to the actors X and Y you will avoid incorporating GSs erratic sub pixel behaviour.

Clouds

If you use an integer attribute to calculate your position rather than adding directly to the actors X and Y you will avoid incorporating GSs erratic sub pixel behaviour.

This is one of the first things I tried, moving the actor's position with two attributes called PosX and PosY, both set to interger, but, suprisingly, it made no difference, the same issue occurred. In theory the existing system is already using intergers anyway, everything is on whole number coordinate and is being moved by a whole number amount, nothing has a sub-pixel value.

For me the weirdest thing is that dumping the image (just using a blank actor / flat coloured box) solves the problem ?

Clouds

@tynan I had a problem with my movements too but I took a laxative and it helped.

Yep, I thought the same thing too after typing out the title, this does look like something for the doctor, apparently a good doctor will always recommend Lua drops for this kind of thing.

Rob2

But the problem is still there with non image actors. I tested that - as I initially thought it was probably related to dpi hiccups. Hold on ill have another look.

Clouds

But the problem is still there with non image actors. I tested that - as I initially thought it was probably related to dpi hiccups. Hold on ill have another look.

If you generate a new actor with no image (rather than simply deleting the image from the previous troubled actor) then using the exact same code it will sync perfectly to the grid, no drifting at all . . . check it out, here is an example file (from my first post) the very same project file as the one with the troubled actor but using just plain ol' GS boxes and it exhibits no drift at all !?

http://www.mediafire.com/?cg5glwfivg2l42z

SlickZero

Not that it makes a difference now, but out of curiosity, did you ever try using the interpolate behavior instead of change attribute?

Rob2

Its deffo a funny old business - I think the actor size could be playing a part too !! Have a peek at this. The square on the left has no correction and after about 100 iterations the problem creeps in (maybe not visually but the display text shows it) and by the end is permanent. (watch the left counter) http://bit.ly/wuiGVr

Clouds

Not that it makes a difference now, but out of curiosity, did you ever try using the interpolate behavior instead of change attribute?

I did, in fact I did everything you can imagine, I even danced naked around a burning effigy of Angry Birds and shouted out incantations to the LUA gods.

Interpolation exhibits the same problem, although a little different as it seems to jump back into sync every few iterations, but essentially it's the same deal.

SlickZero

So a blank actor works fine...How about the image, was it perfectly centered in the document when you created it?

Clouds

Its deffo a funny old business - I think the actor size could be playing a part too !!

I tried every reasonable variation on size, from a single 1 x 1 pixel image, a 2 x 2 pixel image . . . . to squares and lines and odd and even dimensions, they all displayed the same issue.

Have a peek at this. The square on the left has no correction and after about 100 iterations the problem creeps in (maybe not visually but the display text shows it) and by the end is permanent. (watch the left counter) http://bit.ly/wuiGVr

I tried something similar - and found that the numbers lie ! My actor would drift out of sync fairly quickly (by a pixel left and a pixel down) but the display readout would continue to show the correct numbers -so even though your display numbers take 100 iterations or so to display an issue the actor can be out of sync after just 3 or 4 iterations.

In my first post in this thread there is the example file (the troubled actor version) - and in the actor is a display text behaviour, if you switch it on it will happily show you nice even integers for 20 or so iterations . . but if you look at the actual actor it is out of sync after 2 or 3 moves.

Clouds

So a blank actor works fine...How about the image, was it perfectly centered in the document when you created it?

Of course ! Perfectly aligned.

Rob2

Try experimenting with different dpi settings or different software to produce the image. Sometimes 72dpi is actually 72.00x and you wont know it. It would seem there is some kind of rounding error going on between numbers and actor position.