I don't resize the map though, and pixel rounding and linear only makes my character move veery fidgety while never really achieving anything in terms of the blurriness. I'll tel l the artist to change it to PNG-32 and see if anything changes.

What Drew and Paradox are saying is that sampling should be set to point, not linear. Pixel rounding isn't necessary if you have sampling set to point and is the likely the cause of movement looking fidgety.

If point sampling doesn't fix it, it could be an issue with your graphics drivers.

Have you checked to see that the value of the variable is actually "menu"? You may have a trailing space on there, such as "menu ", which would cause your condition to evaluate to false.

Something like: round(x / 32) * 32, x being the number you want to round.

The System object already has built in expressions for converting between strings and numbers: int(x), float(x), and str(x). You can check the manual for more info.

Are you sure the carriage returns are at fault? I haven't been able to replicate the issue, even using files with Windows style line endings. It might help if you post your capx and txt files.

When you call a function, previously picked objects are forgotten, which is probably what's going on here. A way around this would be to pass the enemy's UID as an argument to the function, then from that pick the enemy inside the function.

If I'm not mistaken, I think Coin-coin wants to be able to queue up -- or run simultaneously -- multiple camera shakes, rather than shake individual layers. MagiCam can't handle that itself, but one could always setup a queue that initiates camera shakes in sequence.

It would help if you said what the problem is, but I'm assuming you're talking about the bullets moving in the wrong direction. To fix that, change the Set angle property on the 8DIrection behavior for obj_Player to "no".

Zebbi setting a higher lag value would help to smooth that out, but there's otherwise no specific way to compensate for small object movements. That said, it's an interesting thought -- I could see the use in dynamically setting lag on a curve based on how far an object has moved.

So that's something I'll consider for the next version(when or if that happens), but until then you could probably achieve a similar effect with events. I'll see if I can rig something up.

Zebbi MagiCam is certainly doing more work than scrollto, but it's nothing overly complex, and is almost certainly faster than implementing the same features in events, so I wouldn't expect any performance issues.

Have you actually measured performance? It seems like you're trying to prematurely optimize under the ill conceived notion that a single event is going to make a discernible difference, which only happens in extreme cases. I wouldn't worry about it.

Why not just remove the "Every 0.05 seconds" and let the event run every tick? Unless you have an unreal number of these spaceship objects, there shouldn't be any performance impact.

EDIT: Also, the way you're limiting the speed is... odd, and not really accurate. A more accurate way would be to set the velocity to something along these lines:

VelocityX = cos(angle(0, 0, self.Physics.VelocityX, self.Physics.VelocityY)) * maxSpeed
VelocityY = sin(angle(0, 0, self.Physics.VelocityX, self.Physics.VelocityY)) * maxSpeed[/code:3fkmkwlh]