WideVM for particles

[FRex]

Based on general idea in this paper ( http://www.bitsquid.se/presentations/scripting-particles.pdf ) I've coded a VM that decodes a single instruction and then does it on a lot of data. No sse, avx or anything fancy and parallel though, just plain C++. It's few times slower (2-4x) than native C++ with O2 doing same operations (much slower with no O, since debug mode and simple optimizations give native a huge head start) which I'd say is pretty good for a VM that lazily coded in a day with no optimization in mind at all.

Here is the git repo, there is simple pixel particles example code in there too, just compile and link all .cpp provided:
https://github.com/FRex/WideVM

Opcodes function and their mnemonics can be read from opcodes header and source and op* functions in VM source.
If anyone is interested in actually using that for real or is interested about something in it or wants to constructively criticize it then please drop a post here.

[PsichiX]

it's better to "script" particles in shader - it's hundreds times faster than c++, it's parallel and needs a lot of gpu knowledge, but it's definitely worth it

[FRex]

Yes, I know, but the idea from the presentation is to have one very easy scripting language that can compile and optimize for many backends depending on the needs.

[PsichiX]

but that's what shader does right now - SFML uses GLSL on every supported platform, it uses the same syntax and functionality everywhere. even it optimize code for given GPU. it's doing the same what you did there and it's doing it better & faster

[Ruckamongus]

but that's what shader does right now - SFML uses GLSL on every supported platform, it uses the same syntax and functionality everywhere. even it optimize code for given GPU. it's doing the same what you did there and it's doing it better & faster

I don't think FRex is disagreeing with you; this is just a proof of concept. I think particles are just an example (because that's what the paper used), but the same idea of the VM can be applied to things other than shaders.

[FRex]

Particles don't have to always be only on GPU, performance critical, extremely numerous and parallel well.
Besides, the idea of such a script is to be small restricted language, easy for humans to write (ie. for designers, without help of programmers), easy to generate by a visual tool and easy for compiler to parse, optimize and translate into something else - C, cg, glsl, hlsl, bitcode, bytecode for a VM written in specific ASM etc.
This all is so they don't have to hand write and optimize several scripts for single effect and can use one tool for every effect in the game, both graphical and physical/gameplay logic related by simply changing where the script executes and not worry about backend specific optimizations and coding practices because compiler (and carefully handcrafted VM with few execution paths that use different ASM extensions depending on what CPU offers) takes care of that or warns about that during translation.

SFML uses GLSL on every supported platform, it uses the same syntax and functionality everywhere

It does use same syntax but some built in functions might vary (be missing or deprecated) with glsl versions.
And the pdf this is based on is from a developer that runs their engine on two or three graphic APIs, not just OpenGL.