Wait, why do you call root.after(1000, step(window, root))? You need to pass the step as a proc/lambda, or it will be evaluated immediately.
(Why does after even accept two arguments? Mysteries of Ruby/Tk... :))

This works for me:

window = GameWindow.new
root = TkRoot.new { title "ex1" }
TkLabel.new(root) { text "hello world"; pack { padx 15; pady 15; side "left"; }; }
step = proc { window.tick; root.after(16, &step) }
step.call # start Gosu::Window#tick timer loop
root.mainloop

I think I'll leave Window#tick in the final Gosu 0.10.2, but mark it is experimental in the docs. Thanks for testing, and for nudging me to refactor Gosu a little more.

I ran into the same issue, and chatted about it with flgr. The trick is that again only works with the listen 1.x gem, not 2.x or 3.x. So you can either uninstall all versions of listen, and then gem install listen -v 1.3.1, or you can specify the version through your Gemfile:

gem 'again', require: false
gem 'listen', '= 1.3.1', require: false

I think it works now. If it doesn't pick up changes to your files, *I think* you can also force it to reload a file like so:

Again.instance.send(:reload, Again.instance.send(:resolve_library, "#{File.dirname __FILE__}/src/model/piece.rb"))

I guess that's a bit of a vague response, but last time I had to stop coding after the first "proof of concept" reload worked :/ (Ruby 2.0, OS X)

Ha, very creative use of Gosu :) (I've fixed the YouTube link in your post, it was probably garbled by the board software.)

You're welcome :) There's another Mac-only issue I have to fix, and then I'll probably release 0.10.2.

Can you please give Gosu 0.10.2.pre1 a try: gem install gosu --pre

It has fixed the issue for me.

I don't think there's an easy way around the perspective correction issue, either. Gosu does not use Z coordinates in its OpenGL code – the Z ordering happens in software. It's probably easier to use OpenGL and this flag:

GL.Hint(GL::GL_PERSPECTIVE_CORRECTION_HINT, GL::GL_NICEST)

Of course, that is just a harmless toy in comparison to this tool: https://github.com/flgr/again

Now to check if it still works with Ruby 2.0...

I'm really enjoying this bit of code right now, and thought I'd share it. It uses terrible Ruby monkey-patching to reload all images when the user presses R. (I'm require-ing this file after my class Window < Gosu::Window has been defined, adjust the class name accordingly...)

https://github.com/jlnr/monstris/blob/master/src/debug/image_reloading.rb

It doesn't override Image.load_tiles and is generally shaky, but isn't it fun what you can do in a few lines of evil Ruby :)

Good question! It is this issue here, right? https://github.com/gosu/gosu/issues/293

I'll try to compile a new version of Gosu using the SDL 2.0.4 RC2 on the weekend and see if it helps:

https://www.libsdl.org/tmp/download-2.0.php

If you want, you can try to replace Gosu's embedded SDL2.dll with one from the page above, and re-run your game - with some luck, that will already improve the situation.

Ah, too bad. I'll take a look myself, but I'll put it on my lower-priority list if I can't figure it out quick enough.

It seems that using Tk's #update should be good enough for internal tools like level editors, though? That's actually good to know!

Oh, Tk has an .update method? I thought it only had the full .mainloop. Do we even need Window#tick then? I've just created a TkRoot in a Window constructor and called .update on it from Window#update, and then just called window.show. The result seems to be the same as in your gist - a tiny Tk window alongside a working Gosu::Window.

Cool. I've pushed a --pre version of Gosu that has Window#tick as described above. Seems to work fine from a quick test, but I haven't integrated it with any libraries, only called tick in a while loop. It is still possible that Gosu's tick eats OS events that Tk is waiting for, or the other way around.

w = Gosu::Window.new(...)
loop { break if not w.tick }

Note that everything related to Gosu has to be called from the main thread.

Looking forward to your results :)

I've looked into several Ruby GUI toolkits (Tk, wx, Fox...), and they all seemed to be pretty obscure or half-broken on most platforms, so I haven't spent time integrating any of them with Gosu. The state of GUI programming in Ruby is terrible :|

Anyway, the biggest problem is that both Gosu and Tk (or any of the other UI/eventing libraries) have their own mainloop. Gosu's is here:

https://github.com/gosu/gosu/blob/master/src/Window.cpp#L179-L219

In theory I could unroll the while (true) loop and introduce a new method tick that handles a single step in the while loop, so that show becomes a simple while tick; end.
Then in Tk, you could just never call show, but keep the Gosu::Window running by calling tick regularly from Tk (a timer?). Do you feel like doing a little research work? I can push a beta gem.

I was thinking about it, but I don't think I am ready to give on multiple window support just yet :/ I'll keep it in mind - it's a bit annoying in my own code as well.

Yes and no. A client once ran into the same issue, and for a while there was an experimental Image.async_new method that returned a 'placeholder' object. You could ask this object whether it was ready? and then call get to extract the Image on the main thread. (I'm not sure if it is a Future or a Promise in computer science terms…I always get them wrong.)

The problem with the async_new interface was that I'd also have to add Image.async_from_text, Image.async_load_tiles, Sample.async_new etc. to be consistent. My client ended up not using it anyway, so I've silently removed async_new.

It would be pretty easy to just make most of Gosu's resource management thread-safe. Alas that wouldn't help, because Ruby is still not executing code from C extensions on separate threads (unless I've missed something in the changelog).

Anyway, that sounds like a cool project, and I'll see if I can bring Image.async_new back as an experimental feature. I miss it as well. I've opened an issue on GitHub that you can subscribe to: https://github.com/gosu/gosu/issues/294

It's also strange that Gosu cannot find the other libraries:

checking for TTF_RenderUTF8_Blended() in -lSDL2_ttf... no

Maybe I'll download an ISO image real quick and see if I can reproduce it. I've never seen Linux Mint in action, anyway!

Edit: I can't install the dependencies in the live CD because of package conflicts; libsndfile depends on libflac-dev, but libflac-dev depends on "libflac8 (= 1.3.0-2) but 1.3.0-2ubuntu0.14.04.1 is to be installed" etc etc... No idea, sorry.

I'll definitely add a link to the book as soon as it is finalised, I really like the fact that there's a puzzle game in there (they are underrepresented on this board :)).

Works as expected on OS X. I wonder if it doesn't work on Windows because I'm still using SDL 2.0.3 there. (Man, SDL 2.0.4 can't come fast enough :( Maybe I should compile an intermediate DLL myself?) Thanks for reporting this, and sorry for the lack of progress.

I've opened a GitHub issue here: https://github.com/gosu/gosu/issues/293

Version 0.10.1.1 is out as well and only fixes an installation issue on Linux.

Does installing mesa-common-dev help? Can you see the GL/gl.h header somewhere in /usr/include?

A tiny bugfix release:

• Windows/Linux: Fix audio playback of stereo, non-Ogg-Vorbis files (https://github.com/gosu/gosu/issues/237)
• Ruby: Fix :retro parameter in Image.load_tiles and Image.from_text

Have you tried installing the packages from the wiki page that is linked in the error message? Since Linux Mint is based on Ubuntu (Wikipedia says so...), the package list for Ubuntu should do the trick.

If it does, feel free to edit the wiki page to clear things up for the next Linux Mint user :)

I've dug into it and Chingu by itself seems to work - no problem with any of Chingu's examples (at least, the five I've tried) and Gosu 0.10.0.

However, Ashton monkey-patches a lot of stuff in Gosu, and that might be the problem at hand. I know that everything in Ashton should actually be part of Gosu...but right now I don't have the resources to either implement it in Gosu or to fix the Ashton gem. Sorry :|

Loading tiles will copy the image data to a new texture, so you'd have to pass :retro when creating the individual tiles - that should work!

If you use retro_image.subimage(x,y,w,h), it should preserve the parent texture's retro-ness. The image data is shared in that case, which also makes subimage extremely cheap.

Then again, I'm not sure if subimage was really a good idea, or if Image.load_tiles should just take an array of rectangles to support texture atlas loading.

Confirmed, looking into it now.

Edit: Fixed, will be released as 0.10.1 ASAP. I've also fixed the :retro parameter in Image.from_text, for the sake of consistency.

Two more things:

First, I'm sorry for not looking into the Chingu bug yet! It's on my list.

Second, 33th Ludum Dare gamedev competition starts tomorrow! If you have no plans for the weekend, stock up on healthy snacks and write a game :)

http://ludumdare.com/compo/

Gosu 0.10.0 is out. It contains two things that I thought I had already released:

• Add new ifRetro/:retro parameter to image constructors
• Ruby: Fix mouse position getter/setter interaction

Sorry for the delay, I meant to release 0.9.3 months ago. The tl;dr is that you should start using Image.new("filename.png", :retro => true) instead of using Gosu::enable_undocumented_retrofication.

I've also replaced a few third-party libraries with easier-to-maintain public domain code.
(The version was bumped to 0.10.0 because some exotic image files might not work anymore — but at least they will consistently be broken across platforms now! No more surprises during porting.)

• Use stb_image(_write) for image I/O instead of GDI+, FreeImage, UIImage/NSImage etc.
• Use stb_vorbis for OGG decoding instead of libogg/libvorbis/libvorbisfile

This is also great news because libogg/libvorbis require written attribution in every game that uses the libraries (BSD license) - and readers of our games' README files honestly don't care about audio codecs. Less clutter for everyone.

The biggest changes in 0.10.0 are in the non-Ruby build scripts, though:

• Windows: Upgrade to Visual C++ 2015 (the free Express Desktop edition works). Microsoft has pulled all downloads for good old Visual C++ 2010, time to move on.
• Unix: Fix the CMake build files.
• Xcode: The Gosu.podspec for OS X and iOS is now versioned, instead of being stuck at v0.0.1.

Precompiled libraries for Windows, and a source code tarball for UNIX systems can be found here: https://libgosu.org/downloads/

To keep the Gosu codebase somewhat manageable, I have also ripped out the Socket classes for C++ and moved them to https://github.com/jlnr/Sockets.

Delicious! Good to hear.

Please try again, I've pushed fixes for the CMake files today :)

The strange thing is that Chingu does not alias any methods in Gosu::Image (monkey-patching). It seems to only use the public interface.

Since Gosu 0.9 is supposed to be backwards-compatible, it might be a bug in Gosu. (But testing with 0.8.7 is still worth a shot!)

I love my gamepads, and I agree that everything you mention should be possible -  PLUS force feedback :) However, I'm afraid that redesigning/extending the gamepad interface will take a while. So my current roadmap is:

Gosu 0.9.10 - more cleanup
Gosu 1.0 - once SDL 2.0.4 is released, plus some interface fixes (Gosu::TextInput and <b>pseudo HTML tags</b> are an embarrassingly bad mix right now!)
Gosu 1.1 - input redesign

I'm a big fan of the SDL 2 Game Controller API, so I'll probably model the new input API after it, and I'll try to expose as much of it as possible (+ backward compatibility layer for the current Gosu API).

One more thing that I'd like to keep an eye on is serialisation/deserialisation of button IDs. (They're only semi-portable now.)

That all being said, if you have an idea of what the API could look like, feel free to post it here or open an issue on GitHub for discussion :)

No idea about Releasy - especially since it seems to be more of a libxml installation issue than issue with Releasy itself.

Ocra: I suspect that Ocra does actually include the images. However when the game runs, they are not necessarily accessible from the current directory, so you will not be able to load them using a relative path like "resources/bg_01.png". One thing you can try is to add the --chdir-first option to the ocra call. (I'm not sure if that will set the current directory to the folder containing the EXE file, or to the temporary folder into which images are extracted, but it's worth a short.)
For further debugging you can log Dir.getwd or Dir['*'] to a file on the desktop to inspect what's going on, or pass --debug-extract to ocra and inspect which files are being included - see the README on GitHub: https://github.com/larsch/ocra

Hope that helps.

Can you please post the rest of the output? Most of it is indeed unimportant but there's usually one line in there that isn't :)

The two most common pitfalls are: 1. since Gosu 0.8 you'll need to brew install sdl2 libogg libvorbis, and 2. you might be using RVM, which often breaks Gosu's compilation.

Great to hear that it works and thanks for the write-up! I've added a link to your posting to the Getting Started on Linux guide.

And another idea: Does gem install opengl work?

Phew - not sure why it can't find this library?

Gosu is using a tool called pkg-config to find OpenGL, what is the output of pkg-config --libs gl on your machine?

Oh, that sounds like a different error altogether :) The important part is "cannot find -lGL" (=OpenGL)

Can you please check if there is a libGL.so in /usr/lib/x86_64-linux-gnu, or maybe /usr/lib?

Ruby 2.1 is a fine version :) Every version from 1.8.7 to 2.2.x should work with Gosu.

It sounds as if Ruby wasn't the problem: "The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first."

Have you installed a C++ compiler (usually g++ on the command line)? It should have been part of the build-essential package mentioned in the Getting Started on Linux wiki page.

This has been on my internal To Do list already, I've promoted it to a GitHub issue: https://github.com/gosu/gosu/issues/287

I don't think a boolean callback works here because you might want to show an in-game dialog box, and delay the decision by many frames.

I am a little confused why SDL_GL_CreateContext would return 1 – but anything that's not 0 is good, I guess!

There's been a GitHub issue about the Pi just this week: https://github.com/gosu/gosu/issues/285

...so I guess Gosu does *theoretically* work on Raspbian, but at this point I can only say that the Pi is terrible platform for SDL 2/OpenGL (ES), and that I don't know how to support it properly. :(

Sorry, but that doesn't look like a Gosu-related issue. I have never seen these messages on a fresh installation of Ubuntu 14.10, so something must have gone wrong before you even started installing Gosu's dependencies.

Nope, this was an error on my side - will be fixed in Gosu 0.9.3 (ASAP), no need to wait for an SDL update.

Gosu is not in apt-get (yet ;) ). Please try gem install gosu instead.

Has the error message changed after sudo apt-get install libx11-dev (from StackOverflow)?

Re:

@data = Array.new(width, Array.new(height, default_value))

When you pass a second argument to Array#initialize, it will be evaluated once (like all method arguments) and used as the initial value in the array. If you pass a block, however, that block will be evaluated once to generate the initial value for each cell:

@data = Array.new(width) { Array.new(height, default_value) }

Ooops, thank you for reporting this! I've left a few references to unused libraries in Gosu 0.8+. I've committed a fix right now, and Gosu 0.9.3 will not try to #include <X11/Xlib.h anymore. Sorry for the trouble.

In the meantime, does the top answer here solve the problem for you?

http://stackoverflow.com/questions/5299989/x11-xlib-h-not-found-in-ubuntu

It seems glu was moved out of the opengl gem and now lives inside the glu gem instead:

https://rubygems.org/gems/glu/versions/8.2.1

Pretty amazing how small the actual tiles are, and how big they feel in the 3D world :)

Yay, another user!

If you ever feel the need to finish something, there are enough game dev competitions around to present you with a hard deadline ;)

Right, the examples live in the gosu-examples gem now: https://github.com/gosu/gosu-examples (a recent and not very well documented move)

Can you please try calling SDL_GL_CreateContext(window) after creating the window and see what it returns?

I guess something like this: https://solarianprogrammer.com/2013/05/22/opengl-101-matrices-projection-view-model/