fluffl is a media layer that provides an extremely simple, but cross-platform, interface between desktop and wasm targets. Its built on top of the glow OpenGL bindings.
If you need a simple layer/interface that provides audio,graphics, and maybe networking then this is the crate for you.
Interface-wise its like SDL(you can use literally use* SDL if you select it) but it doesn't depend on the wasm32-unknown-emscripten
target. The emscripten target is considered to be deprecated and is intended on being phased out last I checked. Instead, this crate uses the preferred wasm32-unkown-unknown
target when building for the browser.
Check the examples
folder for runnable demos.
Wasm version of the examples are here: https://k-c-dacosta.github.io/wasm_bins/examples/audio_ex_1/
https://k-c-dacosta.github.io/wasm_bins/examples/brick_demo/
I wrote this GUI lib in pure rust so It will obviously work exactly the same when compiled for webassembly.
gui.mp4
The utility maintains a 2D scene graph (using a "flat" tree datastructure) of components.
The user is responsible for:
- building the tree and defining the parent child relationships between components.
- The user must then manually "pipe" events recieved from fluffl into the GUI Arena for everything to work.
- The user of this utility must also define event listeners on the components he makes with this library.
- Upon rendering of the GUI the user is currently responsible for restoring OpenGL state.
- Currently the GUI renderer traverses the scene graph in preorder traversal and draws each gui-component one at a time (not ideal)
- The draw routine makes heavy use of the stancil buffer, if for some reason that buffer isn't created this module wont work properly
The library has 3 built-in "widgets"/"components" so far:
- A button
- A slider
- A textbox for user input
This GUI system was obviously not implemented with OOP principals, rather, I just used composition. I wrote this utility because I didn't want to hardcode my GUIs for any future applications that I might write with this.
- For the web it uses
WEBGL
andWEBAUDIO
- For desktop:
- if
SDL2
is selected for windowing- Audio options are:
SDL2
but with AUDIO_SUBSYTEM enabled
- Audio options are:
- if
GLUTIN
is slected for windowing- Audio options are:
ALSA
- on linuxWASAPI
- on windows
- Audio options are:
- if
For desktop targets GLUTIN
(for windowing) and native audio APIS are chosen by default since it doesn't require the program to link to SDL2
dynamic libraries since SDL2
may not be installed on a lot of machines we can avoid a link error on compile. GLUTIN
also appears to use either use native libraries or directly interacts with operating-system specific windowing protocols (major protocols are X windowing protocol and Wayland on linux)
If you STILL want to use SDL2 make sure its actually Installed
Just use apt to install:
sudo apt install libsdl2-dev
Its slightly more complicated. IIRC, you have to either drag the sdl2.dll (you either download it off the offical website or compile it yourself) file to a special directory where the compiler sits or place it in the directory where the binary is. My directions are currently vague because my main OS is linux and I'd have to reconfig my KVM instance of windows to figure out exactly what to do again. Luckily you can just cross-compile.
Using MinGW you can actually build for windows on linux.
On ubuntu first install mingw :
sudo apt install mingw-w64
Then use rustup to install the mingw toolchain
rustup target add x86_64-pc-windows-gnu
Finally to compile you program do:
cargo build --target=x86_64-pc-windows-gnu
The beauty of cross compilation is you can immediatly test the windows binary on your linux machine by running binary in WINE
and it just werks (TM) .
Wine chads... I kneel
- look in
./fluffl/examples
- pick a file you want to run (lets say we want to run brick_demo)
- In the terminal do:
cargo run --exmaple=brick_demo
I have scripts that basically does what the git-workflow does except locally, however it requires a tool called cargo-make
.
to use the script make sure cargo-make
is installed by doing a:
cargo install cargo-make
then to run do
cargo make build
- I'm considering removing:
- websocket module (tungstenite)
- the Vorbis decoder (lewton)
- the mp3 decoder (puremp3)
This crate has over 20k lines. I have a hand-coded GUI ,AudioMixer, linear-algebra and fixed-pont libs built into the library that I'm considering splitting off into other crates.