That makes sense. Thanks for the info. I still wonder why the results are so different. Maybe C2's renderer composites the results separately? Seems like a bug in the way shaders are handled. Or if not a bug an oversight, because this could potentially affect any object that uses more than one shader: tint + additive, blur + noise, etc.

digitalsoapbox

Just included tint inside this shader this do exactly the same fx (opacity+tint) at the same time; tint+opacity combined in one shader;

Can you download and test this one again ?

Btw i have 60fps with chrome in my 3d starsfield example;

http://gigatron3k.free.fr/html5/C2/FX/opacity.rar

Yes, works perfectly. Is there something in the default tint shader messing up the behavior of your opacity shader?

Zebbi

Most game engines I've run across do it.

Zebbi

Yes, that is a fairly basic feature that you'd think would be obviously useful. As would being able to prevent solid objects from checking for collisions with other objects of the same type. An example of this would be solid/jumpthrough platforms - why would they ever need to check if they're colliding with the same object type next to them, when they're used to build platforms? That's just silly and C2 should include a way to disable such checks. While I'm sure there's some optimization in the engine to reduce the impact of collisions occurring in this fashion, automatic will never be as optimized as (optional) manual settings.

> Zebbi did you ever hear back on this other than in this forum?

>

Unfortunately, no, it looks like it's going ignored, I'm afraid! Maybe we can ask Ashley nicely again.

Being able to ignore specific solid/solid types seems like a no-brainer, especially in terms of optimizing collisions. Unity has layer-based collision (https://docs.unity3d.com/Manual/LayerBasedCollision.html), and it's not hard to imagine why similar functionality, or some kind of tag system for collisions (also in most other engines), would be useful in a 2D game as well. Every little bit of optimization can help, across all platforms. Hopefully Ashley and co look into this. Even extending it to other objects types, like bullets, would be great - bullets may not need to track if they're colliding/overlapping with each other at any point, for example, so that check could be ignored - though I suppose any benefits arising from that scenario would depend on how C2 is checking for collision/overlap in those circumstances to begin with. Heck, just being able to manually set collision cell size (this matters a lot when the "camera" zooms in/out) instead of having it set automatically to theoretically avoid misuse by less experienced users would be a big step...I've never understood the "we don't include this feature because some people may be confused by it" mindset that exists around C2 development.

> Gigatron

> I just tried this shader with the Tint shader also applied, and the framerate dropped very low. Is your shader intended to work with other shaders?

>

I have tested tint + opacity... you must have 60 fps without framerate loss...

Have you a .capx file to make test for me ?

Just add the tint shader to the star sprite in your demo .capx - it slows down even more than the version without using your opacity shader. This is on a GTX 980 (newest drivers), Windows 10, in Chrome. It's topping out at 15fps. If the tint shader is put on the same layer as the star sprite, it works fine - but I'm hoping there's a way to get it functioning with the tint shader on a sprite that also uses your opacity shader.

Gigatron

I just tried this shader with the Tint shader also applied, and the framerate dropped very low. Is your shader intended to work with other shaders?

Lots of new updates & features coming to Sombrero next week! New Arena, new Weapon Power-Up and more! Just in time for the holidays .

Read about new content and tweaks here:

http://store.steampowered.com/app/472690/

Wow! This looks amazing! Never expected to see this kind of lighting in C2! I really love how the grenade explosions light the scene!!!

No performance issues here, but my desktop doesn't have that low of a specs...

This part of the forum is a bit obscured, I believe this topic needs more attention!

Keep up the good work!

Glad to hear performance is okay. The test itself is pretty low-res (640x360) so I probably need to try a higher resolution and optimize from there. I'm not sure what other forum to put it in, since it's not really an add-on/plugin, but events/actions that use the built-in objects a lot more efficiently than their default behaviors...but I'm open to suggestions .

rexrainbow

Is there a way to get the image used in on an object if it's from a tileset? Does TMXImporterV2.TilesetName & TMXImporterV2.TilesetFrame work for objects?

You could also create a second image point and use that as the reference when you're scaling.

Or if you didn't want to deal with creating a second image point, and want to scale from the center bottom, you could scale from sprite.x, sprite.y+sprite.height/2.

First post ever to say I'm keeping an eye on this, and holy hell I would love to try testing it out. I've been struggling with multiple lights natively and through plugins like Paster, especially since I want scalability with a larger layout and many more layers. I know it's not ready for production release, but I would be grateful if you could throw me a bone for how you're generally laying it out using Paster.

Regardless, it looks amazing considering the constraints of C2's engine.

The lights aren't composited in to Paster all at once - that would create the same overlapping/incorrectly rendering issues we see without using Paster.

There's a loop that basically does this for all of the static lights:

For each ShadowLight

• Paste ShadowLight into Paster (there's some steps here to run effects on the shadows to soft them, but this is the basic idea)
• Delete ShadowLight

For the dynamic/interactive lights, there are unique Paster objects for each. The ShadowLight isn't deleted, but it's turned off unless there needs to be an update to the Paster object, which is tracked based on the collision polygon of the Sprite that acts as the light stencil (the shape/look of the light). The Paster objects for these lights are sized only as large as needed for the image being used in each Sprite.

So for example, the rotating spotlight:

Here the collision poly is overlapping the Tilemap and player Sprite, so the Paster object needs to be updated with the correct shadows. Note the collision poly isn't actually this big, the lines are just shown for reference.

But here, the Sprite acting as the Light stencil doesn't need to be updated because it's not colliding/overlapping with anything, and so it just rotates the Paster object based on it's anchor point (Image Point, in C2 terms).