I believe this was being discussed in another thread, but I can't seem to find that and it was a bit off topic where it was so...
On the topic of multiple windows with Gosu, I personally feel like the core of Gosu should manage the state of the game, and as many windows as one wants can be created to display output. Thus, #update, #button_up, #button_down, etc would move to something like a Gosu::Game class, with Gosu::Window basically just having #draw. You could still have #draw in Gosu::Game I suppose, but it would basically just call #draw for every window. Thus, the programmer would only ever want to override Gosu::Window#draw, as is the current style.
I wanted to bring this up because thought that the core of the engine being a class called Window was a little odd. This approach might seem more complex to some people, but to me it just makes more sense. Would this be possible down the road or would this simply be out of the intended scope of Gosu?
Out of the scope of Gosu for a long while.
If you had several windows, what would be a meaningful way to place them? Does every window have a close button? Does every window have the full window chrome or are there palette windows? And suddenly you have 20% of a GUI toolkit. Which leads to the question, what do you want to do with multiple windows? Is GUI toolkit integration maybe a better approach?
My current plans are to move some stuff out of Gosu::Window, like draw_quad etc. This does not break multi-window support in a distant future, because it can only be called in the context of *one* Window#draw callback thanks to single–threading.
However, there are places where this would make stuff more complicated. For example, if there was a global Gosu::mouse_x function, then it could only be relative to *one* window (just like Window#mouse_x right now). Not sure what to do about these corner cases.
Ah, I hadn't thought of any of those problems at all... Though I was just kinda asking this out of curiosity, as it's not really something I'm interested in implementing. Although I was a bit surprised before that I've never seen a game with a multi-window setup like GIMP before. Perhaps this is why...
Well, thanks for putting an end to my curiosity at least ^_^
Though as for that corner case, you could have Gosu::mouse_x return the position of the mouse relative to the currently active Gosu::Window. If the currently active window is none of those windows then you could return nil. Of course, I can think of a couple other ways to implement that myself, so I'm sure you've though of that one as well as many others. Might as well just stop myself right there then.
Multi-window support doesn't seem that useful to me. Gimp is a pretty annoying implementation for me (regarding multi-windows); I'd much rather have a single system window with tabbed pseudo-windows inside that, which you then have much more control over.
Changing the window makes more sense, but jlnr suggested that allowing a single window to be resized would be better than ensuring that you can close one window and open another to replace it.
I've heard that the multi-window implementation of GIMP is useful if you have a multi-monitor setup. Also, I personally think it's less of a hassle if you use OSX or Linux and have multiple virtual desktops. I normally have one virtual desktop on Ubuntu dedicated to GIMP if and when I have it open.
Still, personally I don't really see how I would use this in a game, although I am generally bad at thinking up ideas for interfaces anyway.
Allowing one window to be resized would be quite nice. I never noticed how cool that feature is until I played minecraft, which is the first game I had played which allowed setting the resolution in that manner. Much more flexible than using a list of pre-determined values for window width and height.
> I played minecraft
I'm surprised you've still got time for other things. :D
However, I don't play much anymore. Got pretty into mulitplayer, but my friends haven't played in a while so... yeah.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill