I am using r99. I noticed the issue initially on r96, but never reported it because I wanted to try and get it fixed without begging for help on the forums.

I think the issue is related to lowering the stepping below 0.1 is the cause of "lag" on the collision detector. 128 speed with 0 stepping makes it easy to see.

Thank you for taking an interest and looking into it!

Thank you for the response, I really appreciate you taking the time to look into this!

The original capx can have the issue but it is very difficult to get it to go into a wall. I download it and playtest for a few minutes and can run into the wall after trying for a few minutes (moving along a wall and turning towards it constantly). Not always or easily, but it is possible.

If you turn the speed down the collision detector lags behind the player more noticeably. Setting the speed to 128 and stepping to 0 makes it much easier to run through walls. It's unfortunate because 256+ is too fast for my needs, I want a classic looking slow grid movement :(

I really like the script, so didn't want to use anything different, and I've built other scripts that rely on this script to work. I will keep looking into it, but I am no programmer lol!

http://dl.dropbox.com/u/23551572/C2/gridMovement.capx

With this (otherwise perfect for me) script you are able to move through walls occasionally.

If the speed is lower than 256, the player can move through walls easily, but even at 256 the player can still move through walls. Is it possible to make the collision detector always position itself before the player moves to it?

I hate to bump the topic, but I have a sticking point in my game because I do not want there to be a bug where player can run through walls, and I need grid based smooth movement.

If you turn on the visibility of the green sprite, collision detector, you can plainly see how the character moves faster than the detector sprite allowing you to at times enter the collision object (wall). Is there any work around for this?

It's easier to reproduce if you lower the speed variable, but even at 256 you can still at times move through walls.

You can get away with a few sprites that are animated by a few frames and get a decent looking effect.

Start with a rain falling sprite, just a blue pixel animating from the start position to the end position over the time of a few frames. Have a second animation that is placed on the ground plane for an impact.

'               frame 1

'               frame 2

'               frame 3

'               frame 4

v               Impact

-------------    Ground

I've seen many games effectivly use lighting, sound, and the ground impact sprite effect only to create nice looking rain scenes

bjadams - don't forget WebGL shaders only work in Chrome and Firefox, and only when the graphics drivers are relatively new as well.

What about on mobile platforms, do those support webGL shaders?

Is there ever going to be a chance of normal and specular mapping, and or vertex based lighting when using vector objects?

If you don't want to use a third party plugin, for each ordered is the method to use. The plugin I linked to might be faster, though.

Aside from the ability to not publish to the Scirra arcade, are there any other downfalls to 3rd party plugin use?

I have to use SpriteFont right now, so does that mean I might as well use all plugins I feel are needed since I am already using one?

My workaround for this right now is to have a "debug" layer, on that layer I add all of my debug info, whenever I am ready to release all I need to do is be sure the debug layer is not visible. I have 1 text object with instance variables to link it to different functions, and 1 sprite with animation frames to have different colors to represent different things while debugging. A in-engine debugging feature would be nice, but with a bit of setup checking things using the tools available isn't super hard.

Is this the best sorting option available to us right now?

I am going to try this out before jumping into a plugin, but sorting in my "birds eye view" game is becoming an issue that I do not want to design around any longer, so hopefully this works out for me.

> I dont understand why youd want to move between layers at all. If a layer is over the main play layer then that layer should be considered to be a "not much of anything is higher into the 'sky' than this" the exception being sky/clouds etc.

>

You're right that there is no requirement to change layers. The issue is one of performance. If you are sorting every sprite in the layout, and you have a huge layout with hundreds of items, that is a lot of sorting! If you have the items divided between a three or four layers, then you only have to sort 1/3 or 1/4 of the items.

Anyway, I got it basically working with the player swapping layers based on Y. I have one more thing to iron out, and then I'll post it.

EDIT: Here is the version with the player moving between layers. Looks much more complex because of all of the text objects used to show what is going on (layer number, Y, number of sorted objects out of total scenery objects, and cumulative sorts). There are 138 scenery objects, and without dividing them between layers, they'd all be sorted on each collision. Dividing them between two layers cuts the number of sorts, but still not sure of the benefit of this...

DepthSortingLayerd3.capx

NOTE: When I say number of sorts, I guess I really mean the number of objects moved to the top or bottom of the layer as the result of a sort. The sort is actually sorting all SortedSprite objects, but they are only moved if they are on the player's layer.

Sorry to bump the topic, but I figured it was better then making a new thread. In the latest beta release (r98) the log notes that texture sizes for tiled background objects need to be power of two, and gives the example of a 1:1 ratio image.

Can images be in a power of two with different height width ratios?

In my previous experience other engines allow us to use any height width ratio as long as it stays within a power of two.

For instance a 64x32 texture would be fine, but a 61x31 would cause issues.

Our engine at my last job had issues exporting to wii when the ratio was x<y but x>y in the ratio was fine (64x32 good, 32x64 bad) but this was only on the wii not on any other platforms. Also, images smaller than 16x16 had issues on 360, but taht was not much of a problem because of the power of the system using a smaller then 16x16 texture was unncessary in most cases.

My results are invert.

Chrome has sprite showing as sharp and tiled background as blurry, same with firefox. I.E. is all blurry.

I am on nvidia 560m with latest stable driver. I will test on another pc tomorrow if I can.

I am having an issue with all of my tiled backgrounds showing up blurry.

Here is a screenshot of the problem I'm getting https://dl.dropbox.com/u/30187917/issue.jpg

Everything looks good when I am in construct 2, and image editing software, but when I run the project in chrome, i.e., and firefox, my tiled bgs are very blurry!

I need to be using webgl and point sampling to get the pixelated look I am going for.

I am using r97 on a nvidia gpu with win 7 64bit.

My drivers are good, and I get the same result in all browsers.

Here is the capx showing the problem.

https://dl.dropbox.com/u/30187917/tiled_background_blurry.capx

The project shown above is a sprite next to a tiled bg. When I run the project, the sprite is crisp and point sampled but the tiled bg is blurry. Same texture, different object, different rendering results.

The texture is 48x24 (it was 48x20 when I found this thread, but changing it did not help.)

I tried scaling it to 48x48 just to see if that fixes the blurryness, but no luck.

Helpful, thankyou! I think I am going to try Yann's suggestion first to avoid additional plugins, but if if I am unsucessful this is a great plan-b!

Edit:

Setup Yann's suggestion, and it works like a charm! A tiny extra bit of setup compared to an animated sprite, but the results are ideal and controllbe. Wonderful! <img src="smileys/smiley32.gif" border="0" align="middle" />