Not yet. Gosu 0.8 has made it a lot easier to add this later, as all Window implementations are now based on the SDL 2 library, which has support for this (AFAIK). Feel free to file a github issue for this, that's where I usually go when I have spare time :)

I am calling SDL_GetMouseState once per tick to update the mouse position. The upcoming SDL 2.0.4 will have updated mouse functionality which Gosu will probably make use of, plus lots of bug fixes. So one quick fix you might try is to use the latest version of SDL 2 from Mercurial (which should be pretty close to the final 2.0.4 version by now).

wat :) I think I don't even want to understand this bug! Must...not...look...into...

This release only fixes a couple of compilation errors that have affected OS X, and possibly Linux.

Can't you just run gem install bundler to install bundler? That seems like the obvious solution :)

o__O That sounds like one of the crazier bugs I've heard about!

Gosu has actually used "i386-mingw32" in past versions: http://rubygems.org/gems/gosu/versions

I don't even remember why I've changed it, I guess it must have stopped working? I also remember vaguely that in some cases, Rubygems would change the string I pass to GemSpec#platform= into another one. (It's probably normalising it.)

If you find out if any platform string is "more right", please let me know :)

Thanks for the write-up :) I have also linked it right from the wiki page: https://github.com/jlnr/gosu/wiki/Getting-Started-on-Linux

You will probably have to concatenate (multiply) two matrices - one to rotate the image by 90° to make it 'fall on the ground', and another to implement a perspective transform based on Z coordinates. I am sure you can find information about both types of matrices in any book on 3D programming - there are only a handful of common matrix types, anyway. :)

Hmm, what does "gem which gosu" or "gem which gosu.bundle" say in the ruby_racer directory? Does it find anything at all after you uninstall the other gem versions?

In recent Ruby setups, there is an extensions/ folder next to gems/. Maybe something got stuck there?

If nothing else helps, there is always rvm implode ;)

Thanks! It's not too bad actually. Probably one "support request" per game that is posted to the Showcase. :)

Today the focus was on all things resolution! I'm not sure what could be more exciting :)

• Gosu::available_width & Gosu::available_height can now be used to calculate the available space for a non-fullscreen window. (The return value is only accurate on OS X and Windows for now.)
• Gosu::Window::show now respects needsRedraw/needs_redraw? again.
• Fix scaling errors on Retina displays, caused by a regression in Gosu 0.8.3.

Hmm. Did you maybe run bundle --deployment (which will install the gem in a local .bundle subfolder), or do you use several versions of Ruby with rvm/rbenv? Uninstalling gems is the pretty much the only thing that gem developers are not responsible for :) Should have been a bug somewhere else...

0.8.4 is out now, as well. One thing that I've noticed is that brew install sdl2 --HEAD works a lot better here than the current stable version.

I would suggest running gem uninstall gosu until all versions are gone, then installing Gosu 0.8.2, which should hopefully fix this issue.

There is a tiny bug in Gosu 0.8.3 that can cause this issue on a Retina MacBook Pro. In related news, I've just spent all of this morning trying to get some advanced features of Gosu to work on a Retina Mac: https://github.com/jlnr/gosu/issues/244 :) But your issue should already be fixed, and I'll try to push 0.8.4 ASAP.

Two more tiny fixes. Overall, the SDL 2 transition was pretty smooth. Hurray!

• All: Mouse wheel constants is not swapped anymore, thanks to d3vkit for reporting this on GitHub.
• Linux: Gosu now works with outdated versions of SDL. In particular, it can now be installed on OpenSuSE again.

Next stops: Updated .app wrapper & 64-bit gems for Windows.

Oh wow. I guess making sure fonts render (mostly) the same on all platforms is a good challenge for Gosu 1.0 :) Not something that I can fix right now. In this case, I guess you would have to render all text at a higher resolution and then scale it down to make it look better on OS X.

I know, I wish Gosu supported MIDI files, but MIDI playback is weird on all platforms, especially Linux. From the SDL2_mixer documentation:

> Timidity:
>   Mixer supports playing MIDI format files using software wavetable via an old version of timidity. This requires you to have a GUS compatible set of sound patches on your system. By default, the library looks for these patches on Win32 in C:\timidity, and on UNIX in /usr/local/lib/timidity/.

I think it would be easier to convert MIDI files to XM or a similar format, and integrate MikMod into Gosu on all platforms.

:D I guess the concept would work if the levels were complicated enough that you'd bump into the mana limit really quick. Like having a maze of fires & barrels, and only one way through it that you can afford. I still really like the perspective (and want to write a game in that perspective myself now :P)

Great to see that full screen mode works! But the perspective is a little distorted on my 21:9 screen. Edit: You can simply pass 336, 192 straight into super and have Gosu do all the scaling for you - it even adds black bars at the top/bottom or left/right sides for you, and of course the mouse coordinates will (should) be translated accordingly. Worked fine for me here in a quick test.

The font is a little hard to read on OS X - makes me wonder if Gosu needs a flag to disable anti-aliasing?

Did you simply run Ocra on it for the Windows build? I'm relieved that it worked! :)

Sweet! Love the perspective :)

Right, so far I have only compiled Gosu for 32-bit. But if my hack works, I should be able to push out a 64-bit gem soon.

• Gosu::screen_width & Gosu::screen_width now return the correct values before a Window has been created
• Windows: Experimental support for Ruby 2.0.0! :)

Note: The current Ruby 2.0 installer won't be able to find the pre-compiled Windows gem, please run gem update --system before installing Gosu. Please let me know if the gem works with complex projects, I have only been able to test it with the Tutorial game so far.

Re: cursor issues, let's wait for SDL 2.0.4 :) Shouldn't be too long, they're already beta-testing.

https://github.com/jlnr/gosu/issues/240

I'll lurk around the Ludum Dare blog this weekend, but I already have too many unfinished projects on my hand :) Good luck finding some free time!

The biggest question will be, what state is Ocra in currently? I wonder if it can build a Ruby/Gosu EXE - haven't tried in a while...

Another option would be to offer an interface to this SDL functionality: https://wiki.libsdl.org/SDL_SetRelativeMouseMode

But for everything else I'd still like to "fix" the mouse behaviour. :)

There is also this function, but it's part of the yet-unreleased SDL 2.0.4: https://wiki.libsdl.org/SDL_GetGlobalMouseState

Oh wow, I didn't notice that! I really liked the old behaviour. Even the fact that you could have a negative mouse_x and all that.

Thanks for pointing it out - I mostly use Tutorial.rb and an iOS game to make sure everything still works, and there are so many parts of Gosu that are under-tested... :)

That's interesting. How did the code work before? I assume you calculate last_mouse_x - mouse_x in every update cycle and then reset the cursor to the centre – why would this not work in the new version?

That doesn't really sound like a big hack, I think that's what other games are doing as well :)

Fixed, but I need to test it on Windows before I release 0.8.2. I'll see if I can somehow sneak support for Ruby 2.x in...

Okay, THAT is a good hack. :D

I have to admit that I totally forgot about screen_width/screen_height yesterday. I have to see if it is an issue with the SDL or not. Will try to push 0.8.2 tonight.

You are right. I use some copy & pasted code to extract the font name out of TTF files that hasn't changed in years. In fact, it is so old that I am getting HTTP error 500 from github while trying to dig into the file's history before 2011. :D

The code has always opened the TTF file for exclusive(!) read access. This must have lead to non-deterministic bugs, because even an Explorer window in the background might sometimes open files to query some meta-data, which would cause CreateFile to fail.

Anyway, fixed in 0.8.1.

This fixes three major bugs in Gosu 0.8.0:

• Revert to old, working OpenAL32.dll
• Mouse wheel events are not broken anymore
• Fix TTF loading code (which has been broken forever)

Hmm, can you please attach the font to a post here? I'd like to play around with this bug :)

Edit: Never mind, your github project is result #1 for the filename. :D

Still testing, but  Gosu::Song works in C++. No surprise, it's a Ruby-only bug. :)

I have just received a second bug report about loading fonts, with the exact error message as yours, but in Gosu 0.7.50 - and passing an absolute path name worked. It has to use forward slashes, though ("C:/dir/file.ttf"). What a bizarre bug.

Hmmm, it is interesting that custom fonts would break - none of the code for that has changed. Can you please try loading the font with an absolute path name? Maybe SDL 2 changes the current directory?

Ah yes, Ashton has a dependency on Gosu "~> 0.7.45", e.g. it won't accept 0.8.x. I don't plan on breaking backwards compatibility before Gosu 2.x, so I have suggested a more relaxed dependency on github: https://github.com/Spooner/ashton/issues/31

If you have a few minutes you should be able to test it locally and send a Pull Request to Spooner :) I'll go after the OpenAL issue first.

Oh wow, I think my OpenAL32.dll was custom-built to avoid a segmentation fault. Updating it to an unmodified 1.16.0 yesterday was probably a really stupid idea. Thanks for reporting this. Can you please try to replace OpenAL32.dll in the gem directory with the 0.7.50 one? Does that fix the Song error?

Is Ashton broken or does it just not work because it has a dependency on Gosu 0.7.x? Error messages always help. These are probably all just one-line fixes that I forgot about :)

Ruby 2.0+ on Windows might only need a single rainy day to fix, but looking at the stack trace one post below, who knows what else is in the queue before that :)

This is a pretty chaotic release and I expect things to break left and right, but here we go.

• Gosu now uses the MIT-licensed SDL 2 for all windowing code, on all three major platforms (OS X, Windows, Linux). This should make it MUCH easier to hack the C++ source, and it removes the burden of backward compatibility from my code (though not from. It has turned Gosu into something that I can finish, without fixing broken windowing code every year. So great.
• Most importantly, this fixes the Mac fullscreen bug :)
• Ruby/Gosu now uses rake-compiler to build the source gem for OS X and Linux. The biggest upside here is that Gosu's directory structure is now more in line with other Ruby C extensions.

Note: If you are on OS X, you will have to brew install sdl2 libogg libvorbis before installing the gem. On Linux, you'll have to install libSDL2-dev or a similarly named package.

Still left for me to do:
• Fix all the bugs that we run into with 0.8.0 in the next days.
• Update the change log.
• Update the "Getting Started" wiki pages.
• Build Ruby.app with Ruby 0.8.0 (preparations for this are in place).

Still way out of reach, sadly:
• 64-bit support on Windows
• Support for Ruby 2.0+ on Windows
• A fresh Android port based on the SDL 2 code

Sweet! :) I hope I can follow up with a Gosu 0.8-based wrapper, which should make things even smoother.

This will be the last 0.7.x app wrapper for OS X. The build process is still a painful mess :(

https://github.com/jlnr/ruby_app/releases/tag/v0.7.50

On the server side: One week in Rails, and then 5 years to make it secure. ;)

I've added a note with your email address to my To Do list as well. I've already tried to send one dylib to mcdowellgames, but it didn't really work - I think I'll have to build a brand-new app wrapper.

Hey. The tutorial was contributed a long time ago, and I don't know if the author of the Chipmunk tutorial is following this forum :) I would suggest that you trust your intuition, and add notes to the wiki page where you disagree. I'm not a Chipmunk expert, but everything you mention sounds very reasonable. If you want you can also change the source code and send a pull request for the .rb file.

If you have a chance please install libsdl2, then gem install gosu --pre. The new version uses SDL 2 as its backend, which should have much better Linux support.

I like the pattern where you define a GameState class that has the same callback methods as Gosu::Window does ( draw, update, ...). The window has "one" state at all times, and forwards all its callbacks to it.

One example is here:

https://github.com/belen-albeza/space-shooter/blob/master/engine/game.rb

Then when you want to show something different, you just replace the GameState instance of the main window. The pattern is very flexible. For example, if a dialog box state wants to show the game in the background, it can just have a reference to the "last state" and in its draw method, it can first draw the old state, then draw its information on top. You can also realise transitions in a similar way.

I use this pattern absolutely everywhere. :)

Thanks! I've updated the wiki.

Oh, I think the demo actually worked, but it was a huge hack. Do you want to target iOS?

(mruby games can be published in the App Store, wow :) https://itunes.apple.com/us/app/mobiruby-game/id548210182?mt=8)

I think the biggest task is to wrap all the Gosu APIs like this:

https://github.com/jlnr/mruby_demo_game/blob/master/mrubytest/MRbImage.cpp

...and then these extra C files, along with mruby, could be wrapped up in a CocoaPod. I've created an item in my personal To Do list for this, but I am really, really, really slow right now :) I need to release Gosu 0.8 before I can touch anything else.

It looks like you are missing the C++ compiler g++. I am not sure how your distribution works, but can you just enter "g++" in a terminal and it will tell you that it is missing, and which package to install?

Not yet, but making Gosu easier to hack is definitely a priority! Thanks for checking out the github labels. The plan is to add a hacking guide & a front page link to both the guide, and the help-wanted tickets soon.

For testing things in Ruby, I usually do something like this:

export GOSU_RELEASE_VERSION=0.8.0.pre7 # or whatever version you want to use for testing
rake gem && sudo gem install pkg/gosu-$GOSU_RELEASE_VERSION.gem && ruby my_test_script.rb

If you are changing Gosu's Ruby interface, you also have to run rake swig in-between, to regenerate the Ruby wrapper from gosu.swg.

And then I just use the up-arrow to repeat the last step. This takes like a minute though, so for faster, C++-based development, I always keep an Xcode project of the Tutorial game around that includes the Gosu source files as well. Xcode is smart enough only to recompile the files that have actually changed, which brings the feedback loop down to a second. But for that I don't know the instructions off the top of my head. =/

Should be, because no file I/O is involved, but I don't think the difference will be dramatic (unlike subimage, which is almost a no-op). Only benchmarks know the truth, though. ;)