I do not know if you know this, but I tried the scroll and C2:s own fade together and it produced strange results. But maybe you posted this just because of my findings. or from your own findings with the border shader problem. Looks like the transparency is culprit for many of the shader troubles?

I did see your post and had observed this previously as well. Hopefully in the end we can have proper shader behaviour for all.

I recommend posting a minimal repro capx as example if you find glitches like these, otherwise is hard for someone to know if it's really a bug. There's too much variables involved, and sometimes depending how it is setup it doesn't show up (like this time). I tested your shader and it worked as expected initially. But it needs a different stack order to manifest.

As said above it will get a little tricky given the custom Shaders, but I guess Ashley will just have to install them. Will look into it.

I have dozens of shaders that I did to myself but I never published (except for Alpha Threshold and old CC effects). Most of them still needs proper descriptions for parameters, some code clean up to remove commented junk, and proper usage examples. Like I said in another topic, I intend to publish them sometime but I never find the time to do it. Someday perhaps...

You really should, people seem to like those things

I see now, I get the same glitched results. It's strange that the problem only occurs at a specific stack order.

Well, I think it's not that much specific as "every following shader gets screwed" sort of thing.

But it's definitely a bug.

Amen to that! Finally someone gets it!

Now I understand why one of my drop shadow shaders behaves weirdly when I change the opacity of an object or layer it's applied to. It's probably related to the problem you depicted in the other topic.

Huh, you also have a drop shadow Shader? Or it hasn't been published?

My guess is that it happens in C2's compositor. Maybe it can be an overlook caused by some kind of render optimization (?).

I have a very recent Nvidia card with up to date drivers, so there's only a very small chance of being a driver's bug.

And I have tested on a very old and semi-old Nvidia cards. Now we just have to hope this does get considered a problem and not "standard behaviour" and gets fixed. Most of my pixel-friendly Shaders depend on it.

Edit: I would submit a bug report for both of these, but then the best way to show it is using my own Shaders so that might complicate things... Oh well, might just go ahead and do it (but probably tomorrow).

Only with Shaders and then you get a possible performance hit (or it may just not work - on mobile, for example).

I did some tests but I can't reproduce this inconsistent behavior that you are describing.

You can try for yourself here.

*I did some modifications to the shader based on what I think you are trying to achieve, but it works the same regardless of the modifications.

I'll need to compare what those modifications do. The way it has an outline, but respects the alpha of the insides is great. Thanks!

Are you getting the same results?

I wasn't, because the test wasn't the same as mine - the moment we change the shader stack (shader BEFORE the effect) everything goes plenty bad here. I have changed your demo to show this:

[attachment=0:7we6oz6l][/attachment:7we6oz6l]

[attachment=1:7we6oz6l][/attachment:7we6oz6l]

In my case it needs to be at least beyond one other Shader (one that trims things) so, unfortunately, I cannot change the stack order.

In general I think it's related to this - the way Shader-using thing sequencing works (or doesn't):

Well, you have to have a variable that you change over time and then assign it to the effect - the effect itself is "dumb" and does not remember any values, just what you pass to it.

Say:

NoiseStrength = 100

Every tick: NoiseStrenght - dt*100, set effect Noise param 0 to NoiseStrength

Would make the noise disappear within a second.

I could be wrong, but I think, in C2 terms, the items that get placed on a layout are "instances" of an object type. So if you copy an instance of an object, you get another instance of that same object type.

Absolutely, it makes perfect sense from C2's standpoint, it's just that in most other apps copies are usually separate objects and you have to pick a different option (clone, for example) to make instances. Hence my comment.

I'm quite impressed with your post-to-post adherence to neat formatting, btw

In a way C2 may be muddying the waters by it's definition that a "copy" is the same object, while a "clone" is a new object with the same base parameters. But I guess they went with it so people who "just want to copy and paste" don't make a million new objects in the process.

Rather neat indeed. I think it would work even better with less double roads.

Glad to help out - meanwhile codah's approach is probably a better bet if you had to use it in several places or had quite the amount of lines.

Well, Android doesn't have the Agency font, does it? Besides for better compatibility and performance you might want to use spritefonts.

Depends a little on your random facts, you might as well just do a really simple thing, like: Set Text = choose("My first sentence","My second sentence","My third sentence","Well, this is getting LONG","But it does seem to take even more")

No variables, no unnecessary setting of anything, easy to edit. As long as you don't have a million facts it seems quite suitable.