What version of C2 are you running? I'm still on r190, maybe it's an issue with a beta version?

Animmaniac

Know how that goes. I've been hoping to find some time to dive into GLSL myself, but just haven't got around to it yet.

Here hoping you find the drive again sometime.

Never seen that particular error as far as I know. Are you getting it consistently?

I've found that if you hit the run/debug button multiple times when it's starting up, it can corrupt the preview runtime.

I've also noticed that clicking on the preview/debug button doesn't always start the preview; sometimes you need to click, hold for maybe half a second, then let up. Odd, I know, but I've seen it a dozen times if I've seen it once.

My understanding is that WebGL effects can be tricky on mobile because some mobile GPU's have odd architectures whose shortcomings can cause effects to fail entirely.

For example, on my android phone, the noise effect fails due to the way my Adreno GPU handles the sin() operation used to generate the noise effect, as per this article:

http://byteblacksmith.com/improvements- ... gl-es-2-0/

I know I've also heard of seemingly cheap effects grinding games to a halt on mobile because the particular GPU has trouble handling certain mathematical operations or data types in an efficient way.

Then again, you might be hitting a simple fillrate issue. Try a lower resolution and see if that clears things up.

In my case, while the noise function fails, most other effects work fine. I have an Adreno 305, and I continue to be amazed that I can pile on multiple webGL effects without tanking the FPS. Yet, I'm CPU limited: a couple dozen physics objects brings me sub-30fps framerates.

That's mobile: you have to figure out what the bottlenecks are, because they simply aren't consistent. It's best to try and build tests into your own game, enabling/disabling effects depending on what the FPS is doing.

I've been thinking lately that it should be possible to test effect compatibility on mobile by having startup tests where effects were applied to test sprites, sprites captured to a paster object or via the CanvasSnapshot function, then processed as an array to check if the effect is actually working.

So, see if a white sprite with the noise effect has mostly uniform pixel values (effect is failing), or if all the pixels seem different from each other (effect is working). For HSL, transform a small sprite, and check that the captured color is the same or close to what it should be. Etc...

A directional blur with 4 attributes:

Samples: Angle: Length: Z-Order: on top/underneath

With this effect we could accomplish a reasonably cheap motion blur effect by setting blur params with object angle of motion (angle) and speed (length/samples).

Could also be combined with the expensive but awesome looking multi-sample approach here (which would look way better with a proper directional blur effect):

The best thing to do is just look at other plugins, and ask on the forum, where, unlike some forums, you'll almost certainly get an answer.

The SDK documentation has never been that extensive, and somehow quite a few people (including myself) have managed to put a plugin together. Most plugins are freestanding from the engine code, but solid is one exception.

Unlike Unity, there really isn't an engine SDK, which is unlikely to change for C2, but seems to be on the radar for C3.

A lot of people have expressed their frustrations with the limitations of the solid behavior. I'm going to hazard a guess that Ashley is aware of this.

I've heard rumblings of SIMD coming to JS for awhile now, but I just now got around to watching this talk by Moh Haghighat from Intel. As I only had a basic understanding of SIMD (and vectorization in general), I found this a really enlightening peek into the tech.

Youtube:

In short, SIMD.js will not necessarily require custom code on the part of javascript programmers, as future JIT engines will automatically optimize incoming code to take advantage of SIMD where applicable. Of course, explicit use of SIMD functionality is coming first, as JIT integration will take more time.

Also, many mobile platforms already support SIMD via NEON, something I had no idea about.

Glad to see some slow recovery from the disaster that was chromium v38/nw 0.11.X

10.5 still works better, but 0.12.x is certainly a viable option, unlike 0.11. Here's hoping it zooms ahead by stable.

XP support...well, it had a damn good run, but honestly, I see this as a positive step, much for the reasons you mentioned (users on XP are liable to be a support issue anyway). Win 7 is the best OS Microsoft has made so far, and hopefully 10 will be another step forward after the mis-handling of Win8.

BTW, Ashley, great idea to 'alpha test' a new version of node this way prior to update. Hope to see this become the standard approach moving forward.

First off, I'm still seeing the HSL glitches mentioned previous by other users. Only seeing it on certain colors. It persists after export as well. My graphics are intel HD4000, so that might be part of the problem. Anyway, here's an example of what I am seeing:

[attachment=0:z32q4vn8][/attachment:z32q4vn8]

While I'm here, I'd just like to say this about Stuffgen:

As a designer first/artist last, this is insanely helpful for me when prototyping, as I tend to get hung up on art and lose my flow sometimes. I can always get something passable, but since I'm just not very efficient in that area, I lose precious time worrying about dev art details that are often meaningless in the context of a brainstorming session.

Stuffgen is brilliant for this, as I can work up a bunch of temp sprites in no time, and get back into events and programming, which is generally where my real ideas are anyway. With the way things are progressing, I could even see using some of these sprites in a real game.

So...thanks — For preserving my brain. In a totally cool, non-mad-scientist sort of way.

Thanks for contributing this Phobos002. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

I modified your last capx to add a velocity dependent blurring effect that makes this look even better in action, and is useable down to 4 samples for slower movement (lower settings blur more, which sacrifices accuracy, but still looks smooth in motion). Here it is:

CAPX: https://www.dropbox.com/s/9j0q36mne5x56 ... .capx?dl=0

Be aware, this is a much hungrier effect GPU-wise (blurring is being applied to each moblur sample individually as a webgl effect).

Still, at 12 samples it's smooth on my HD4000, and it could probably be used in a real game w/ a dedicated GPU. As an incidental effect, it could be used just about anywhere.

Could make the effect cheaper/better looking with a proper directional blur effect, but I'm not aware of one for C2. Also, could probably batch moblur sprites on their own layer(s) for considerably cheaper blurring at high samples, but that would require a separate layer for each set of sprites (not un-doable, but a PITA to be sure).

This sounds like a good solution, though I haven't had a chance to try it yet. Thanks, Joannesalfa.

As far as I can tell, I'm no longer seeing the flipped image with the last example you posted.

Glad to help with the testing; thanks again for this great plugin.