Skip to content

Instantly share code, notes, and snippets.

@emoon
Last active January 28, 2016 10:34
Show Gist options
  • Save emoon/cdc8ed3548a014f9bf9c to your computer and use it in GitHub Desktop.
Save emoon/cdc8ed3548a014f9bf9c to your computer and use it in GitHub Desktop.

The more stuff I add to minifb the more I actually want to use it in some other projects (like ProDBG) as I'm almost doing double work/cut'n'pasta now. So I have considered extending minifb somewhat that might break the current API.

Window::new(title, width, heigh...) <- this is all good but i'm thinking off perhaps adding something like

Window::new(title, width, height, Option<Scale>, Option<WindowStyle>) (style is for resize and such)

window::update_with_buffer(&buffer) <- rename of the current update function.

@kondrak
Copy link

kondrak commented Jan 27, 2016

Alright, that makes sense then! So if you're talking OpenGL now, I assume shader support will be there as well? ;)

@yupferris
Copy link

gonna be hard to beat glium in that case :)

@emoon
Copy link
Author

emoon commented Jan 28, 2016

No, I'm not going to add OpenGL support at all. The thing is for ProDBG I use bgfx and it pretty much only need a window handle so all that setup can be outside of minifb which is the point.

The idea is here to support widows which isn't "forced" to update with a buffer but can still do so if wanted as it's something I want to do on a regular basis.

Yeah it really doesn't make sense to take on glutin/glium really. All I want is basic window setup which you have a bit more control over :)

@kondrak
Copy link

kondrak commented Jan 28, 2016

Sounds good then! Being able to use a separate OpenGL context will be definitely beneficial for some users.

@yupferris
Copy link

👍

@emoon
Copy link
Author

emoon commented Jan 28, 2016

Thanks! I will go ahead doing this stuff :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment