Thanks!

Just the scroll position (center of screen).

Hey Ashley

Just to remind you again, can you please add this to one of the next betas?

I did some custom shaders for Airscape, and they are really needing this to eliminate the frame delay glitch and squeeze every performance improvement possible.

I guess it shouldn't be too difficult to implement.

Sometime ago I read some articles about smoothing dt to handle performance spikes.

I made this test with two jumping objects and discovered that the one using smooth dt had a much more precise jump height than the one using normal dt.

Here's the results:

Normal Scenario

Extreme Scenario

• The orange object uses normal dt and the blue smooth dt.
• The orange and blue lines at the top are the maximum height of the last jump.
• The semi-transparent boxes around the lines indicate how much the jump height has drifted in the last jumps.

Notice that the jump height of the object with smooth dt barely drift compared with the one using normal dt.

What happens is that it creates some micro slow-downs or speed-ups on the object the more dt oscillates, that results in a more constant position increment.

Maybe it can help solve your problem.

I used a pretty naive smoothing, but there's better methods that take more frames into consideration and may give better results. The way I implemented doesn't work with behaviors, but I think it's possible to set the global timescale to (smoothDt/dt) and it will work with everything. Maybe you should give it a try.

Here's the capx:

[attachment=0:ym3jqwvc][/attachment:ym3jqwvc]

*It uses the Canvas plugin.

**For some reason it's not rendering the dt graph correctly in Firefox, but it works in Chrome.

I guess you could turn it into a nice clock. Or turn it into a cool lamp.

Maybe create an app that display a clock while the background has an adjustable flat color that doubles as an RGB lamp. If you have access to some kind of I/O ports you could remove the mouse and keyboard and add some control knobs for the hue and lightness. Or maybe hack the mouse and mount it's components into the case to work as the input: X for hue and Y for lightness. This way you get a nice form factor.

Another idea is to use it as one of those fancy lcd picture frames.

Or make it display the weather or news if you can make it communicate with the web.

While this makes sense for a single layer scaled, I don't think it's an expected behavior for changing the layout scale.

The MouseX and MouseY should return layout coordinates scaled according to the layout, as the manual states:

[quote:2hlb0m9u]X

Y

Return the position of the mouse cursor in game co-ordinates. This is (0, 0) at the top left of the layout. It changes to reflect scrolling and scaling. However, if an individual layer has been scrolled, scaled or rotated, these expressions do not take that in to account - for that case, use the layer versions below.

As the manual describes, the specified layer positions MouseX(0) should be only used when a single layer has a different scaling than the others, otherwise MouseX should cover it.

So it doesn't seems to be a problem with tilemap's PositionToTile, but the MouseX and MouseY not accounting for layout scaling.

Ashley Shouldn't it account for?