New Extension: Particle Engine#1724
Conversation
|
Peak!! |
|
Two questions I have:
|
|
yes |
|
WOW! a new particle engine with no clones! that's great for performance and now overflow your projects with clones! (even if i use clones, a lot) |
Additionally, blocks in the editor are all SVGs, which means you can't color them with any html property. You have do what I do and make SVG gradients or patterns. |
well, i just function add2Body() {
var svg = document.createElement("div");
svg.innerHTML = \`<svg><defs>
<linearGradient x1="100" y1="0" x2="100" y2="200" id="SPpartEngine-GRAD1" gradientUnits="userSpaceOnUse"><stop offset="0" stop-color="#0090ff"></stop><stop offset="50%" stop-color="#0000ff"></stop></linearGradient>
</defs></svg>`;
document.body.appendChild(svg);
}
if (Scratch.gui) Scratch.gui.getBlockly().then((SB) => {
add2Body();
if (!SB?.SPgradients?.patched) { // Gradient Patch by 0znzw & SharkPool
SB.SPgradients = {gradientUrls: {}, patched: false};
const BSP = SB.BlockSvg.prototype, BSPR = BSP.render;
BSP.render = function(...args) {
const res = BSPR.apply(this, args);
let category;
if (this?.svgPath_ && this?.category_ && (category = this.type.slice(0, this.type.indexOf("_"))) && SB.SPgradients.gradientUrls[category]) {
const urls = SB.SPgradients.gradientUrls[category];
if (urls) this.svgPath_.setAttribute("fill", urls[0]);
}
return res;
}
SB.SPgradients.patched = true;
}
SB.SPgradients.gradientUrls["SPpartEngine"] = ["url(#SPpartEngine-GRAD1)"];
}); |
I've already looked at the code, but I don't intend to use it for my extensions. Thank you anyway though. |
Interesting. I was just curious as to if we could change the scratch-gui repo to add some sort of functionality for gradients and CSS colors in the block color APIs, but I guess not - It didn't occur to me that the SVGs can't use CSS gradients. Maybe we could use this patch though, and manually inject the colors into the patch? IDK, it's just an idea. Probably won't be done though. What might be more possible is expanding the customizable block colors addon to allow for gradients. |
|
Theres now an interpolation option! :) |
|
!format |
|
!format |
okay I just removed the option to toggle interpolation, I just made it automatically turn on |
Fantastic! If you're going to do it that way make sure you explain in the docs :D |
|
I'll take a look later when I have time and probably approve |
Already changed the docs |
There was a problem hiding this comment.
Turning on interpolation and then creating an engine/emitter causes the emitter to be created without interpolation enabled.
Executing the "delete and wait" block still appears to disable interpolation on the emitter
Spamming the following block stack in the editor results in the There are too many active WebGL contexts on this page, the oldest context will be lost error.

It seems to be mostly working and these are very nitpicky "polishing" issues but in general I approve of this PR
|
@Brackets-Coder I fixed all those issues, the |
There was a problem hiding this comment.
-
Interpolation before creating an emitter has been fixed
-
Delete and wait lacking interpolation has been fixed
-
The WebGL error still appears, I got it by spam-clicking the above stack in the running editor. The issue seems to be the following:
const disposeEngine = (target) => {
const engine = target[engineTag];
if (!engine)
return;
vm.off("STAGE_SIZE_CHANGED", engine.drawable.stageSZChange);
render.destroyDrawable(engine.drawableId, "sprite");
render.destroySkin(engine.skinId);
runtime.requestRedraw();
engine.gl.deleteProgram(engine.programInfo.program);
const glExtension = engine.gl.getExtension("WEBGL_lose_context");
// >>>> here
if (glExtension)
glExtension.loseContext();
engine.canvas.remove();
target[engineTag] = undefined;
allEngines.delete(target.getName());
};I'm getting the "Too many contexts, last context will be lost" error before I get a
"WebGL: INVALID_OPERATION: loseContext: context already lost"
It implies that loseContext isn't working because the browser automatically disposes of the context, which reveals a potential flaw with remove all. Maybe, if the argument is all, try simply deleting every existing WebGL context every time, so that when the block is spammed you'll never create too many?
I don't know. This seems like a non-trivial issue and something that could be looked further into. I don't know what's going on and since you can't replicate it on your machine, I don't know how to help you.
I'm literally this 🤏 close to approval. You can probably show a video demonstrating how this issue is not reproducible, fix it really quick (which I doubt this is an easy-fix), or do something... But if you don't know what's going on and I don't know what's going on, I can either approve this right away or we can get another moderator to review and help us out
|
Is that safari? |
Ah... That might be what's causing the issue. I'll test in Firefox and probably chrome too if I feel like it |
|
@SharkPool-SP Are you sure that this shouldn't be a draft? It looks like you all still need a fair bit of work before merging. |
Brackets-Coder
left a comment
There was a problem hiding this comment.
That's the issue.
Working properly in Firefox, only returned WebGL context was lost. 93 times and no error.
I'm going to approve since the issue on Safari really only shows up in the console and doesn't seem to affect performance
Based on what I've tested the most recent version is working as expected aside from the negligible issue above which only affects a small fraction of the population if they're looking in the console. Any other issues I might've missed may be weeded out with a second review |
GarboMuffin
left a comment
There was a problem hiding this comment.
Writing something. Hold on
|
|
Here's a concrete example of a simple project using this extension Untitled-48.zip (sb3 inside the zip) What blocks will make the particles look good at any resolution? Stopping project maybe should delete all the emitters. Currently if you use dynamic emitter names at all, if you want to stop seeing a screen full of particles your easiest way out is to manually run the delete engine block on whatever sprite. Which seems silly. This throws an uncaught error
|
|
See what I mean? |
Might be the cause, safari is garbage |
I mean not really anymore, at the time I pull requested it, it was ready. Now it's just minor changes |
- framebuffers - bug fixes - better canvas quality
|
!format |
|
Okay I fixed all the issues and more |





Create Powerful Particle Engines with NO Clones
Screen.Recording.2024-10-15.at.12.31.42.AM.mov
wow.particles.mp4