These are chat archives for bjz/gfx-rs
swap_buffers. Could that be because we initialize it in one thread (
main) but use in another (device thread)?
make examples && bin/ex-triangle
device::Serverhas markers to stop it being moved out
gfx::start, and a game task spawned in the example
swap_buffersgets called on the call to
.update()in the example code
gfx::startspools up a render task, and gives you two things - one which must always live on the main thread, and one you can move off into your own thread
17in the triangle example to
let platform = gfx::platform::Glfw::new(window);?
let platform = gfx::platform::Glfw::new(window.render_context());
swap_buffersdirectly where the sample creates the context, and it still crashes. So I just need to find the difference between this and my triangle
make_currentmethod be part of
Platform? dunno if that is more specific to glfw
get_proc_address) with this level of abstraction
get_proc_address()is not a member of
Contextmethods of Glfw window, so we are unable to load GL entensions with
get_proc_address(). It should be moved in to
Context, or better - encapsulated into a separate trait
GlProvider, which would contain
extension_supported(). I'd submit a PR but I've got to go back to work now.
get_proc_addressis not threadsafe :(
extension_supported()) in a separate trait then?
<C: Context + GlProvider>in the platform
tri_list_xy_f32_rgba_f32_uv_f32in the back-end hurt my eyes...
EntityDataimplementation in the shelve, my idea would be to not remove the handle from
dataif the generations are over. Keep it there - we'll always be able to check if it's actually invalid by looking at the generation count
EntityDatamay guarantee that nothing tries to use that handle