I’m working on a WORK IN PROGRESS port of morphic.js to Python, as a fun side project. Of course I only have the basic data classes (Animation, Point, Color, Rectangle, and Node) and no Morphs (which is the main part), but it still exists here!
My end goal is to, someday, port all of Snap! (albeit, this will be a very complicated project) to Python to make a true desktop version of Snap!.
Why? Morphic is a deliberately poor decision—speed of the graphics are horribly behind TurboWarp and even slower than Scratch.
SVGs are showing up with weird glitches. The bitmaps are blurry even at the native 100%!
You will be more useful if you adapt the engine from TurboWarp as the new graphics engine for Snap!
3/3 of your recent posts have been criticizing snap’s speed (turbowarp kinda counts).
The truth is, while I would LOVE a faster snap, snap is a COMPUTER SCIENCE tool, NOT a game engine.
not sure how compatible those are.
Well, that’s how I wrote that Snap is best suited for complex tasks. At the same time, without losing the clarity and clarity of Scratch. I didn’t understand why it couldn’t also have fast or at least non-glitchy graphics.
They want to, and I’m pretty sure they’re just doing this for fun, not intending this to be something serious like turbowarp.
These are issues with snap in the browser, not python. Yes, I believe svgs will be even more broken in python (cause rendering svgs outside the browser seems to be severely lacking), but they would have more control over the scaling method used for bitmaps than snap in the browser does.
I feel like you really have no idea what you’re talking about. Turbowarp is using webgl, which is a rendering engine built for the browser. Snap uses canvas2d, which is another rendering engine for the browser. Python does not have access to that, but it can actually use a better rendering engine than the browser, since it’s not limited to what the browser gives.
The graphics are not what make snap slow, it’s actually the runtime. Fun fact, snap actually runs at 60 fps while scratch runs at 30 fps (though turbowarp can run at faster frame rates). Turbowarp is much more optimized than snap, so that’s why it runs faster.
Morphic is not a specific rendering engine, it’s more of a way of programming graphics. The original morphic was actually used in scratch 1.4, which was running natively on your computer instead of going through many layers in your browser. Jens liked morphic, so he ported it to the browser. He first tried to create it in python, but decided to switch to the browser (to get more reach), which is why @codingisfun2831t decided to do this project in the first place.
Neither is scratch. A game engine basically takes care of the boilerplate game code for you, even adding features that make creating games easier. Scratch and snap are just block based programming languages, giving you everything you need to create your own programs, while also giving you an easy to use graphics itterface. While snap is focused on computer science, it’s probably an even better language to make games in, since it makes it even easier to do many common things that you would have to program yourself in scratch (for example, snap has a way to lock sprites to other sprites). In fact, I’d rather encourage people to make games in snap, because games always show what you can do in a programming language.
Porting Snap! to Python is one thing I want to do, but also its cool to just have another UI library for Python.
That simply isn’t the priority. Unless someone wants to contribute it themselves (which jens usually doesn’t like).
Turbowarp is so much faster because it compiles the code. What does that mean? That means that Turbowarp converts your code to JavaScript when you start the program and runs it that way. There are two reasons why this doesn’t work as well for Snap:
Also, one of the reasons why Snap is slower than Scratch is, to my knowledge, that Scratch can take more optimization shortcuts. I can’t think of a particular example, but if I do I’ll edit this post.
PS: Pretty much nobody ever makes deliberately poor decisions, and I’m pretty sure that Snap’s speed is not particularly the fault of Morphic (although Morphic was designed with things like live programming in mind).
Snap using XML definitely doesn’t help.
I don’t think that has to do with map’s compiling function, but correct me if im wrong.
I’m not talking about compiled Snap.
Was there a reason you replied to @mark4sisb 's post then?
To my knowledge, that was a post about Snap being slow. Either that, or I’m dumb.
Oh, I understand.
Snap saving projects in xml doesn’t really have anything to do with its slowness, because it only does stuff with xml when saving and loading, never when you’re editing and running scripts.
