|
|
ToDo
Gosu's mixup between a roadmap and a short-term to-do list.
ASAP
- Document Gosu::interpolate, improve it too?
0.7.9.x
Features that COULD be pulled into the 0.7.x series without breaking compatibility to keep the step to 0.8.0 as small as possible; I'll try to implement those for which I see actual demand :)
- Ruby 1.9.0 support
- Testing around with multiple monitors on Windows
- get rid of OpenGL tearing on Windows (Intel GMA 950)
- get rid of context selection error with driver set to always do FSAA
- don't round updateInterval on Windows
- don't round updateInterval on Linux
- implement frameskip
- be able to have more FPS than Hz despite working vsync
- Unify documentation!
- also, Font should respect monospaced fonts and fonts with very weird kerning (Zapfino...)
- make the Ruby wrapper's menu bar more complete on OS X
- Experimentation: Should support for multiple Window instances be kept? Should the window argument to most constructors leave? -> Only stronger error messages could be pulled into the 0.7.9.x series.
0.8.0 (after a cleanup/documentation delay)
- Experimentation: In Ruby, can the window be a singleton and still provide the ability to inherit from it? (Singleton standard class)
- Experimentation: Don't switch resolution EVER but stretch in software? Would probably look better on TFT's and be less error prone.
- Experimentation: Should the C++ version keep using wstring, or switch to UTF-8 strings?
- clean up Ruby's interface; draw_quad and friends should require the Z parameter (BREAKS CODE)
- rewrite Gosu::Input with support for multiple gamepads and analog joysticks, serializable button IDs, …
- maybe rewrite Gosu::Image with support for clipping and other things
- provide C++ application templates where possible, maybe even installers for the templates
Major design goals for 0.8.x (graphics, polish)
- much improved text output system, at the VERY least/as a first step, Font shouldn't be forced to be bold
- more alpha modes, yay!
- find a way to factor rot flips out of Gosu => Image/draw redesign
- implement clipping and a target() modifier for the new Image
- speed up LargeImageData!
- Apple remote support would rule.
- clean up after playing around with possible optimizations
- assure Gosu::File also creates directories as necessary
- more C++ examples
Major design goals for 0.9.x (IO)
- the window argument in Ruby is annoying, because only one window can be used anyway. Maybe it should be Window.run, and all open Windows should work.
- simplify Gosu's IO philosophy (C++)
- document Gosu's Sockets
Major design goals for 1.x (perfection)
- Windows: Input will regularly query devices which are not currently attached, thereby causing the game to halt every few seconds - think about this
- FSAA/mipmap experiments
- force feedback would be cool
Sign in to add a comment
maybe it's just something too specifical, but i think there should be a way to manipulate pixels, like reading and writing them. it is essential for low-level gfx, hardmaps and so on. excellent work so far! uh.. also you cannot think about making games like worms or lemmings without a way to handle pixels..
one more thing: as you've found a good method to get keyboard input, why limit it to certain chars? it is a problem to have a decent per-character keyboard input (you have to struggle with (n)curses or highline and the like). i think extending the class to have a general button_down event that checks if any key has been hit and return which key it is, wouldn't be too hard to implement and would turn out to be soooo useful!
In C++, it is possible to change pixels by keeping around Bitmap objects and re-creating new Images from them. In Ruby, benchmarking needs to happen. Creating large craters with set_pixel would be slow (pi*r*r calls!). Using Rmagick would be slow. What's the better option? But it's interesting that this comes up so often.
I agree on your second point, and I find it embarrassing that 'popular' libraries such as the SDL do not provide real keyboard input (tried using dead keys with it?) - so this is the 'text input system' mentioned for the 0.7.x era. I want text input that's just as smooth as entering text into your favorite OS'es text boxes. It's not trivial though.
Thanks for the feedback! :)
(The post above was from before RMagick was integrated. See examples/RMagickIntegration.rb for an example of how to do/simulate image manipulation in Gosu.)
Hi, I'm a big fan of Gosu !!!
Under the heading "ASAP" there is the item "testing on Vista". Gosu seems to work perfectly on my Vista machine. Anything in particular you want us to test ?
dagedy: Thanks, that's great news! :) I guess fullscreen is the most critical thing usually. I also hope to have Alt+Tab out of, and into Gosu games working in 0.7.9 (it doesn't even work under XP right now), so if that's in, feedback on whether that works would be very appreciated.
Julian: Fullscreen seems to work fine on Vista ... with the exception of when you alt-tab to switch to another program. In this case Gosu is still fullscreen, with the windows task bar in front of it. If you then use the taskbar to switch to a program Gosu still remains in front (only Gosu and the windows taskbar is visible).
If Gosu is run in non-fullscreen mode everything seems to work perfectly.
I've got no idea how hard this would be to implement, but it would be nice to have support for multiple windows, which could allow some interesting features - multiple monitor support, and integration with GUI toolkits such as Cocoa and GTK being a couple.
Multiple Gosu::Window instances and integration with GUI toolkits don't have much to do with each other :) However, with multiple windows one could get around using another toolkit for things like a level editor. In C++ this is already possible, in Ruby I don't even really know a GUI toolkit. Maybe when I do I'll can take an educated guess at how useful this would be :)