Window independence

[alteous]

I'd like to propose that three moves away from the 'create a window and update it every frame' strategy. The primary motivation is to allow the user to use three with OpenGL contexts that have already been created, for example from limn or from emscripten. The secondary motivation is ergonomics; it would be nice to have Factory, Renderer, Scene, and Input as independent structures.

[kvark]

it would be nice to have Factory, Renderer, Scene, and Input as independent structures.

They've always been sort of independent structures. Window is just a convenient wrapper around them, it still exposes them in public interface. There is nothing in Window that the user can't do on their side.

So I don't think anything needs to be done here. If you have any issues with hooking up limn, let's investigate. Otherwise, in general, I don't think there is an issue here.

[alteous]

I think we are misunderstanding each other.

There is nothing in Window that the user can't do on their side.

One can't create a Renderer nor a Factory without building a window. These structures manipulate the OpenGL context of the window and no other. The swap_buffers call is in Window::update which takes &mut self.renderer and &mut self.input, implying strong coupling.

[kvark]

One can't create a Renderer nor a Factory without building a window.

So you are talking about glutin::GlWindow as opposed to our three::Window? Ok.
I think it comes down to proper feature support. "opengl" is already a feature, but the project will not compile without it, and that needs to be addressed. "glutin" may very well be a feature too.

[vitvakatu]

Writing a small game with Three I realized that all four core structures (Window, Factory, Input and Renderer) at the same time are very close and very separate.
At the one hand, you usually need more than one from this list in game loop functions (e.g. updating game object's state often requires both Factory and Input, and sometimes Window).
On the other hand, current implementation makes it difficult to actually split responsibility when you need to.

[kvark]

@vitvakatu Could you provide more details? Also, any ideas on how to make it nicer?

…

On Jan 7, 2018, at 10:12, Ilya Bogdanov ***@***.***> wrote: Writing a small game with Three I realized that all four core structures (Window, Factory, Input and Renderer) at the same time are very close and very separate. At the one hand, you usually need more than one from this list in game loop functions (e.g. updating game object's state often requires both Factory and Input, and sometimes Window). On the other hand, current implementation makes it difficult to actually split responsibility when you need to. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[vitvakatu]

Let's observe current implementation.

• Our Window struct in fact does not provide any useful methods. All that Window does - being the wrapper around Renderer, Scene, Input and Factory.
• There is no way to create these four structs manually.
• Aside from Timer creation and usage, it's fairly easy to split responsibility for structures. You need to pass Factory to the constructors, Input to the update methods and keep Scene and Renderer somewhere near main loop. I can't say that it's bad design.
• But there are situations in which logical organization is impossible. Sometimes you need to instantiate new objects during update of some object - so you need Factory. Sometimes you need to get current aspect ratio to calculate coordinates - and you need Renderer. The obvious idea is to pass Window instead those three structs, but it doesn't look nice in my opinion.
• With last changes, you need Scene not only for instantiation, but also for removing objects from scene. It makes situation with complex update methods even worse.
• Summing it up - you need to pass Window almost everywhere. IMO we should call it Context, not Window, cause it serves the role of wrapper around other data types.

I remember that @alteous had an idea of using callbacks for main loop. I think we can consider this idea and look how (if) it can improve the situation.

[alteous]

Good summary.

The main loop callback idea was only to facilitate running three in the browser with emscripten (emscripten_set_main_loop). It doesn't sound very ergonomic otherwise.

I like the idea of a trait Context. I once had a toy game engine (written in C) that had a context interface. Below were the functions necessary to make the engine work. These would be compiled and linked separately from the rest of the engine.

// Either the user would link their own implementation or use the stock engine one (GLFW).
struct ats_context;

int ats_context_init(struct ats_context **ctx, const struct ats_context_config *cfg);
void ats_context_deinit(struct ats_context *ctx);
void ats_context_get_size(struct ats_context *ctx, int32_t *width, int32_t *height);
bool ats_context_is_active(struct ats_context *ctx);
void ats_context_poll_events(struct ats_context *ctx);
bool ats_context_is_key_down(struct ats_context *ctx, int32_t key);
void ats_context_show(struct ats_context *ctx);
void ats_context_swap_buffers(struct ats_context *ctx);

[kvark]

@vitvakatu

Our Window struct in fact does not provide any useful methods.

The update method is quite juicy and useful in all of the examples.

All that Window does - being the wrapper around Renderer, Scene, Input and Factory.

Also, contains glutin's GlWindow and EventsLoop. Having the users to manage all of those separately would be anything but simple.

There is no way to create these four structs manually.

There used to be a way, but now I see pub(crate) on Renderer::new... Change it to just pub and you are done. Conceptually, Window is just an ergonomics helper, and I'd like it to stay such (i.e. not mandatory, scalable, etc).

it's fairly easy to split responsibility for structures .. I can't say that it's bad design.

You answer it yourself:

But there are situations in which logical organization is impossible.

With last changes, you need Scene not only for instantiation, but also for removing objects from scene. It makes situation with complex update methods even worse.

You can remove objects from their parent, which can be a group. In general, if you create objects using X you should be prepared to have X when you need to destroy them. That applies to gfx-hal and specs, maybe not so much to froggy though ;)

Summing it up - you need to pass Window almost everywhere. IMO we should call it Context, not Window, cause it serves the role of wrapper around other data types.

I don't understand. Can't you pass mutable references to the particular things you need from Window?
If something only needs Factory, you make it get &mut Factory and pass it as &mut window.factory. Your sub-systems don't need to know about Window, only your main() function does. What's wrong with this?

@alteous

The main loop callback idea was only to facilitate running three in the browser with emscripten

winit::EventsLoop already covers that, no need to introduce yet another event loop in the architecture. Emscripten support has landed in gfx-0.17 (see #83 (comment)), and the steps to get this going are:

• improve our shader preprocessor to inject GLSL version
• build for wasm32-unknown-emscripten target
• profit test, test, test, submit bugs upstream (to gfx-rs, glutin, winit, etc)

I like the idea of a trait Context

I'm sorry, I don't understand what problem it would solve. I think we can live with the current design until HAL comes.

[alteous]

I'm sorry, I don't understand what problem it would solve. I think we can live with the current design until HAL comes.

Fair enough. I agree with what you just said.