search

rpjohnst / dejavu

Game Maker reimplementation
https://dejavu.abubalay.com
Apache License 2.0
70 stars 7 forks source link

(Question) There's Linux support? #59

Open hardBSDk opened 5 months ago

rpjohnst commented 5 months ago

There is currently only support for Win32 and WebAssembly.

If you (or anyone) is interested in adding Linux support, the entry point to the platform implementations is here: https://github.com/rpjohnst/dejavu/blob/a012bf5/runner/src/lib.rs#L22-L36

The easier one to use as an example is probably Win32- you'll want to add a new linux.rs in platform that creates a window, then kicks off and runs the game like this: https://github.com/rpjohnst/dejavu/blob/a012bf5/runner/src/platform/win32.rs#L83-L124. You'll also need a graphics backend (probably OpenGL) implementing crate::graphics::load, frame, and batch like this: https://github.com/rpjohnst/dejavu/blob/a012bf5/runner/src/graphics/d3d11.rs. The engine will call those APIs at the appropriate points in the game loop.

hardBSDk commented 5 months ago

@rpjohnst You can also use cross-platform crates for minimum code porting.

For advanced GUI there's the egui toolkit, if you want a simple GUI (no UI controls), you can use the winit crate directly.

rpjohnst commented 5 months ago

I'd like for the project to have small, purpose-built, per-platform backends. The interface between engine and platform is a single data structure containing GM-specific things like input events and sprite batches, and each platform can use its own control flow and only deal with what it needs to implement that exact functionality.

Crates like winit have to be a lot more generalized than that, so they invariably become both too high-level and too low-level: high-level in the ways they paper over platform differences, yet too low-level to really make smart choices about those differences. This becomes particularly important for emulating some corners of GM's behavior on Windows.

I would not be opposed to an additional backend based on crate(s) like winit, which might be a useful fallback for platforms we don't support directly, but platforms we do support should default to the platform-specific backend.