Should be fixed in the next build.

Great to hear, and thanks for the reply.

Ashley, do you need more info on this or do you have enough?

Problem Description

Shadows on mirrored sprites render incorrectly.

Attach a Capx

https://dl.dropboxusercontent.com/u/14245368/C2/mirrored_sprite_shadow_bug.capx

Example:

https://dl.dropboxusercontent.com/u/142 ... index.html

Description of Capx

CapX illustrates incorrect shadow rendering, even when default settings are used.

Steps to Reproduce Bug

• Add a Shadowcaster to a sprite
• Add a Shadow Light to the scene
• Mirror the sprite

Observed Result

The shape of the shadow is wrong, and C2 seems to be flipping the collision polygon used to calculate the shape of the shadow incorrectly.

This is how the collision polygon is set up:

This is how it renders, showing both mirrored (left) and unmirrored (right) sprites.

Expected Result

The shadow to render correctly, when a player or enemy sprite may be mirrored during normal gameplay.

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)
• Edge: (YES)
• NW.js: (YES)

Operating System and Service Pack

Windows 7 x64 updated, Windows 8.1 updated, Window 10 updated, OSX 10.9.5

Construct 2 Version ID

211-212.2

Yeah, me too a few times but I think only on big projects!

Every so often, I see that the open project in the title is changed from ProjectName to ProjectName.capx.autosave.

Yes, it seems to occur mostly on larger projects. I haven't had it happen on anything small.

I've had the exact same issue occurring at random during autosaves. It seems to be COMPLETELY random, so providing steps to replicate isn't really feasible, sadly.

The issue started occurring with either r210 or r211, if that helps at all.

Gigatron the .fx , .xml and .capx can be downloaded from the first post, this:

https://dl.dropboxusercontent.com/u/659 ... editor.rar

zenox98 digitalsoapbox Create a new document, add a sprite with my effect and run, still works wrong? How appears in the layout before run? also cutted in the half?.

Also guys you tested the editor? this:

https://dl.dropboxusercontent.com/u/659 ... index.html

Also appears only a half part of tha shader?

The same issue occurs in the editor, yes.

I'm still having the same rendering error. I'm running the example file you've provided.

On the off-chance that it helps, here's what I see when running the example .capx

I think is a similar error that on my other shader of flames that was solved by Gigatron :

Seems i can't use the X variable of the shader position, when i do some cards not do the work correctly and this happens. I guess is the same or similar error, i can't confirm.

I will try to solve the problem, sorry for the inconvenience :S .

Note: My card is a NVIDIA Geforce GTX 670 , and works perfect :S

I'll check that solution out, thanks!

I'm running on a GTX 770, Windows 10 x64, if that helps at all.

Very cool, and thanks for sharing!

I'm having an issue under Windows 10 where only half of a shader is rendering if parameters are changed in any way - see attached screenshot. This happens across all browsers and NW.js.

I've updated to the newest nVidia Windows 10 drivers, but still no change.

> If you need real-world examples of why and how this would be useful, just say the word.

>

I always need that. That is mandatory. I have no evidence that the sampling mode impacts performance in any meaningful way. Can you provide data that backs up this assumption/assertion?

It's a combination of:

1) Visual Quality - Rendering in low-res and upscaling when the window is small (640x360) and how it looks with linear v. point sampling. It looks horribly blurry when linear sampling is turned on and the quality is set to low, and like pixel art when it's set to point sampling. Leaving the sampling as point when rendering in high quality results in overly crispy art with heavily aliased edging that's visible even when viewing at 2560x1440.

It'd be a shame to have to either deal with blurry visuals when the game is set to low quality to better support low-end Intel HD graphics chips or deal with crispy visuals in high-res on computers with more capable GPUs. Having two separate .exes for the game isn't an especially attractive option when we're talking about supporting multiple platforms and potential sales channels for a commercial game. To savvy end-users, that would just look sloppy, and they'd be right about that.

2) There's definitely a difference in FPS when using linear v. point sampling on Intel GPUs. It doesn't seem to be an issue elsewhere outside of a few years-old nVidia cards (460, 470) that still receive driver updates so out of date drivers are most likely not the culprit. I can send you my game's project files so you can see it for yourself when running on any Intel HD chip (I've tested on Intel HD, Iris, 4000, 4400, 5000 chip variants), but I can't publish it in the forums because it's a commercial product. Should I send to the support email address?

---

Also, and this is a bit off-topic but still hits upon the kind of configuration options computer gamers expect, a VSync action in the nw.js object would be pretty nice too .

Up!

Not to necro an old thread, but I'd absolutely love this feature as well, and it'd open up the ability to run my game in low-quality settings on Intel GPU chips. Otherwise, I'm basically eliminating a good chunk of the OSX market, where even a late 2014-era Macbook Pro can't run a 2D game because of the screen's high resolution - with C2 providing no way to change the screen resolution in the nw.js app - because of its underpowered Intel GPU.

Ashley, I know you've addressed this before, but is this something that's a potential feature in the near future? Even if the renderer needs to be reinitialized to change the sampling, this seems like a great way to address some of the issues with weak GPUs in even higher-end laptops like the Macbooks or a Surface Pro 3 while not having to reduce the overall quality a game is possible of achieving visually on systems with better GPUs. If you need real-world examples of why and how this would be useful, just say the word.

> YouTube:

>

Subscribe to Construct videos now

>

Wow looks good. It looks like it runs smoothly with all the stuff going on

Yep. Due to the efficiency of C2 it's mostly GPU dependent and the CPU usage never really goes over 10-15% even with a lot going on. The video was recorded at 1080p at 60fps on the dual core i3 mini ATX machine. It's still a bit wonky above 720p on an intel GPU - because intel GPUs are terrible - but on a decent GPU, like an nVidia 750Ti card, there are no issues - even on a machine without a very up-to-date CPU.

Now we just need official XB1 support, maybe better mobile support, and pie-in-the-sky PS4 support.

Oh, and also maybe Ashley will hopefully tweak the new F2B renderer so it doesn't completely lock up my very powerful desktop workstation when pasting a sprite into a Paster object, which looks otherwise like it could help with the kind of fillrate issues that bring an intel GPU to its tiny little memory-shared knees...though I guess potentially R0J0hound also needs to add support for the new F2B renderer to the plugin, even if tests show it's more of an issue with the new renderer itself.