Headless Version

[markusmoenig]

Hi,

I love the vision of this project and I think it could be something really special.

Is there a timeline for the headless version ? I would love to integrate my own SDF based 2D rendering backend. Personally I think a headless version which works on an internal bitmap and triggers external actions (audio) would be great as one could embed it into any kind of framework (Xcode, pixels etc).

Thanks

[maximecb]

Hi @markusmoenig

Yes I think there is a legit use case for a headless version. There is no timeline because there's a lot of work to be done on this project and I only have so much spare time. The best way to make it happen is to help implement it yourself :)

Rust has a concept of features which can be used for conditional compilation to implement something like this: https://doc.rust-lang.org/cargo/reference/features.html

It should be possible to have a headless feature that compiles without the SDL dependency. Though then there's a question as to how the window/audio syscalls would behave.

If you do want to implement this, then let's discuss the implementation strategy. Smaller pull requests have a higher chance of getting merged.

[markusmoenig]

Thanks for the answer.

I can only show how I did it for my retro RPG Creator Eldiron.com

1. The only really OS dependent part is the Window creation and events. For this I created a C API to handle the passing of the window buffer and user events.
2. I use pixels with winit to open a cross platform window and send the buffer and user events to the rust lib. This works cross platform and even on WASM (of course SDL2 could also be used for this).
3. For device support I simply create a native app which calls the API. For example I have an Xcode project which creates a Metal surface / window on iOS / tvOS and calls the C API. This allows me to distribute seamlessly to the AppStore (see here.
4. Everything else, like audio, file requesters etc. can be implemented in Rust via crates which only call OS functions and do not introduce any 3rd party libraries.

Of course this is a big change to your current SDL2 based design. I would be happy to implement the above for your project but I do not want to impose my view of things on you when SDL2 just works fine for you.

[maximecb]

Of course this is a big change to your current SDL2 based design.

I'm not sure what you're suggesting, concretely, in terms of changes.

What seems easily possible is to have a Rust/Cargo feature to disable the UVM audio and window APIs and remove the SDL dependency. In order to plug a different API in there, you could then link uvm as a library and manually register your own "syscalls", see: https://github.com/maximecb/uvm/blob/04160058682ae49eaa3625f145a71ba7f3385f99/vm/src/sys/mod.rs#L167

If you were thinking of something else, can you explain what you had in mind?

[markusmoenig]

No. This is what I meant. I just worried that it would be a nuisance for you to maintain this feature changes going forward.

[markusmoenig]

And you said smaller PRs have a higher chance to get merged …

[maximecb]

There's a CI workflow to run some basic tests so at the very least we could test that the headless version builds correctly.

[markusmoenig]

Ok, will implement the feature flag. However features in Rust should add functionality, not remove them. So there will be an "SDL" feature which is enabled by default and one would compile the vn via --no-default-features to get the headless version.

---

btw; my motivation. I am working on a language for 3D modeling / rendering / polygonization using SDFs at ForgedThoughts.com.

The language is based on Rhai (a Rust based scripting language). It's cool to build up the world objects but once you have procedural materials and textures and you have to jump into Rhai for these, things get very slow.

So I hope to be able to write a fragment shader like language and embed these in the FT scripts which would provide fast CPU based procedural material / texture generation.

[maximecb]

Closing for now. Will revisit later.