Do you have a code snippet to show? Hard to offer suggestions without it. Except that you need to restrict clipping to the current light sprite obviously.

Actually I meant hundreds of man-hours on my part :P If I go all out developing something in C2 in the hopes of getting this feature down the road only to discover a year later that upscaled low-res renders (or something equally effective) will never happen for whatever reason then I'll be very unhappy. But hey, if it's too much work for Scirra to implement then sure, I understand. They have limited resources. I'd just like to know what's what so I can plan better.

Ashley

I hate to be pushy, but it would be a big help if we could get some kind of answer. Are there any plans to tackle this? Is it possible with html5 and node-webkit? Construct 2 has a great workflow and set of features, and it's faster to develop with than any other gamedev software I know of. But much as I love using it, I'd rather not sink hundreds of potentially wasted man-hours into it based on a thin hope that maybe this crippling problem gets solved sometime in the future.

Hmm, that's weird. The inconsistency could be due to sprite-placement on the screen at different times (whether interpolation kicks in or not). If it happens just to some sprites I thought it could be an almost invisible stray pixel somewhere that gets amplified from being drawn multiple times, like if several layers of blurred images get drawn on top of each other. But since you tried cutting away different portions that isn't the case probably.

But sprites are packed onto sprite atlases, so if other sprites don't have an empty 1-2 pixel border around them they could still mess with the drawing of those that do.

Does it happen to all sprites or just some? What kind of effect is it?

640x480 is pretty high for a pixel art game. If you plan to go that high wouldn't it be better to just use regular 2D painting techniques?

Here's an interesting article on pixel art if you haven't read it:

gamasutra.com/blogs/AdamSaltsman/20090724/2571/Pixel_Art_Freelance_Best_Practices__Guidelines.php

And an exerpt:

nfortunately, a facet of this problem extends even to well-planned, well-intentioned projects. It's a quadratic problem; that is, doubling the resolution of your project actually quadruples the size of the art assets. After all, you can fit four 64x64 images into a 128x128 image. In many 2D mediums that just means using a bigger brush, no big deal, but in pixel art the ramifications are pretty serious. When you are painting your lines and details and anti-aliasing pixel by precious pixel you have 4 times as many elements to manipulate with tender, obsessive care.

+ a million. C2 really needs something like this.

Looks like texture bleeding. Try adding an empty one pixel border around your sprites and see what happens.

If you decide to use LoadState/SaveState instead it all becomes real easy. Just add this Action in a running event sheet:

(System) - Save game to slot "autosave"

If there's no autosave slot yet, C2 will create one, otherwise it'll overwrite the old "autosave" with the new. Then use (System) - Load game from slot "autosave" to load it. The autosave Action could be placed inside an On Start of Layout condition for instance.

And to avoid your savegames getting bloated with unnecessary information, add a "NoSave" behaviour to objects that don't need saving (i.e. stuff that gets reloaded/reset on level changes).

Has anyone else noticed a big slowdown in LoadState lately? Pre-v145 loading a state was almost instant for me but now the same state(saved at same point so should be equally big) takes about two seconds.

It surprises me how extremely underestimated the workload for a 3D engine is in this thread.

...

C2 is a 2D game creator for a good reason...

This right here. Adding new features is the easy part. The hard part is making sure it will work safely and predictably across different rigs, take care it doesn't break anything else, and make sure it can't potentially break later on or paint you into a corner in terms of adding new features. Put simple, the more features you add, the harder it gets to maintain it all. And 3D support is such a massive added layer of complexity that it could very possibly see C2 degenerate into a buggy mess that gets updated twice a year. I'm amazed that one guy is able to maintain and push out new updates every week for C2 as it is.

So um, not to nag but have you made any decision on whether or not to look into this? It's kind of crucial performance-wise I think.