Yep, but it was still a bug in Gosu because LOTS of code still uses the old interface, and I'll probably have to support it forever :) Anyway, great to know that it works now.

Another release with only a single bugfix:

• Ruby: Fix compatibility with Gosu 0.8 interface (Gosu::Image#initialize; GitHub issue #360)

Oh man, in retrospect that was a really silly oversight on my part. Anyway, should be fixed in Gosu 0.10.4.

Fixed in Gosu 0.10.4.

Oops, I can actually reproduce it now.

See https://github.com/gosu/gosu/issues/306

Same issue as in this thread: https://www.libgosu.org/cgi-bin/mwf/topic_show.pl?tid=1208

I haven't been able to reproduce it... :(

Creating subimages is probably cheap enough that you can do it in every tick. Images are not much more than a refcount to the texture, plus u/v values.
Doubled is not possible right now, though :(

Hey everyone,

I didn't really plan on releasing another version of Gosu so quickly, but this issue came up several times on this forum:

• Fix black/white empty window before Gosu::Window#show is called (issue #280)

Let me know if the fix works, and whether it has broken anything else.

I guess it's time to add features again, instead of squishing bugs! Nice :)

I've created a new GitHub issue here: https://github.com/gosu/gosu/issues/300

But here's a workaround you can try in the meantime:

If you load the image using Image.new, then use image.subimage(x,y,w,h) to create a Gosu::Image representing a portion of the image, and then call gl_tex_info on the new (sub-)image, you should get the correct u/v values (0.0 to 1.0) in .left/.right/.top/.bottom.
You only need to take care not to create an image >1022x1022px with Image.new, because when an image is split up across several textures, subimage and gl_tex_info won't work.

Gosu's button constants are integers (Fixnums):

https://github.com/gosu/gosu/blob/master/Gosu/Buttons.hpp#L127-L141

It would probably be best to pick two random unused Fixnums for new constants, to avoid collisions.

I'd suggest lazily generating these images during development, and then at some point you write them all out to PNG files. That way your players don't need to have ImageMagick installed on their machines.

Which OS and which version of Gosu do you use? And which keyboard (US, French, ...)?

I've opened a new issue for text input bugs on OS X, maybe I can fix some more bugs at the same time: https://github.com/gosu/gosu/issues/299

Oh, I didn't know that about TexPlay. =/

Hi and welcome :)

1. Instead of rewriting methods on Gosu::Window with class_eval, you can just add a setter to your own Window subclass:

class MyWindow < Gosu::Window
  ...
  attr_accessor :cursor
 
  def initialize(...)
    ...
    # Neither default cursor, nor a custom cursor image - I think this makes for nicer code than ""
    @cursor = false
  end

  def needs_cursor?
    @cursor.nil?
  end

  def draw
    ...
    if @cursor then
      # This is a bit of a hack - it's probably better to cache cursors indefinitely in a Hash
      @cursor_image ||= Gosu::Image.new(@cursor)
      @cursor_image.draw mouse_x, mouse_y, 1000000
    end
  end
end

2. No, Magick::Image is a bitmap in memory, Gosu::Image is an OpenGL texture, or something similar. But you can convert RMagick images to Gosu using Gosu::Image.new(rmagick_image).

(And I feel I have to point out that releasing games that depend on RMagick is going to be complicated =/ Deploying Texplay is a lot easier.)

3. Gosu::screen_width and Gosu::screen_height are your friend.

Thanks for the feedback! I'll try to look at the asynchronous image loading soon-ish, as well.

Nice, another Ludum Dare entry! :) Was surprised to spot quite a few Gosu entries this time around.

Pixel Monster by shawn42: http://ludumdare.com/compo/2015/08/23/pixel-monster-done/

They Came in the Night by Kakuremino: http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=8853

I've also spotted Aglæca by philomory: http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=1112

And here is my entry, Monstris: http://ludumdare.com/compo/ludum-dare-33/?action=preview&uid=114

(Sorry for hijacking this thread a little...! :) )

Nice work, the sun looks great!

Ah, too bad. I think I know how to fix it, though.

For those of you who experienced white flickering on startup with Gosu 0.9.x+ (Windows) - has the SDL update fixed this?

Another boring maintenance release :)

• All: Fix many common text rendering artefacts
• Mac: Fix compilation error on OS X 10.11 El Capitan
• Windows: Update to SDL 2.0.4 RC 2
• All: Add experimental Window#tick method to potential integration with GUI toolkits (see Tk thread in Gosu Exchange)

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 :)