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/

Awesome visual style! I love the "SNES mode 7" look.

Sorry to hear about the mouse trouble. SDL 2.0.4 RC 2 has been released a couple of weeks ago, I hope the stable version will be released ASAP to fix these issues.

And congrats on saving 14 hours a day, you can re-invest this time into more programming ;P

After glancing at the code, well, I don't know. But it looks pretty effective so far :)

I would suggest that you find a computer graphics book and implement a "classic" rendering pipeline built on 3D vectors and 4x4 matrices. Writing the vector and matrix types should be fun to do in Ruby, anyway. I don't have any book/blog pointers though, this was a university class for me.
If nothing else, doing 3D the "standard way" makes it easier to debug your solution by comparing it to other 3D code.

早安 :) Can you please try if it works with Gosu v0.7.50?

In Gosu 0.8+, I use SDL 2.x to handle all gamepad input. I remember SDL 1.x had a bug with handling some directional pads, maybe it still exists in 2.x? -> In that case we can simply file a bug at the libsdl bug tracker.

Since Gosu 0.8.x+ uses the SDL GameController API to access gamepads, it possible to fix this issue by writing a SDL game controller mapping string for your gamepad:

https://wiki.libsdl.org/SDL_GameControllerAddMapping

Maybe this tool is useful to find out the gamepad's GUID etc.; I haven't tried it:

https://github.com/Ryochan7/antimicro
https://github.com/Ryochan7/antimicro-profiles

Once you have a mapping string for your gamepad, you can set this environment variable before requiring Gosu:

https://github.com/spurious/SDL-mirror/blob/master/include/SDL_hints.h#L306

It probably looks like this:

ENV['SDL_GAMECONTROLLERCONFIG'] = '..........,Sun-Yes USB Gamepad,...........'
require 'gosu'

Hope that helps. I'll make a note to test this myself and write a guide for the Gosu wiki. (....But I usually need a few years to follow up on my notes ;) ).

Cool, thanks!

I've diffed the sources for Gosu 0.8.0 (which I know worked on Raspbian) and 0.8.7.2 and couldn't find anything that should cause this issue. =/ I wonder if anything in SDL 2 or Raspbian has changed since then. The only advice I can give is to compile an OpenGL ES 1.x demo that uses SDL 2 and see if it works on your machine. Sorry! I've already given away my Pi.

1) Ruby/Gosu uses SDL 2 to create the window for rendering OpenGL. There is a SDL_CreateWindowFrom() function that can create an SDL window from HWND and NSWindow, but I don't know how it would work with an NSView, especially when OpenGL is thrown into the mix.

2) nope :(

Considering that wrapping up Ruby/Gosu apps as .app/.exe files is a bit of a hack anyway...I think this is out of the scope of what Gosu can do. Sorry!

I wonder if I have broken something in Gosu 0.9.x - I didn't have a chance to test this version on a Raspberry Pi. Can you please try using Gosu 0.8.x? If that helps, I'll need to grab a Raspi again and debug Gosu 0.9.x. Thanks.

I see. I've been meaning to finally replace enable_undocumented_retrofication with a new flag during image creation, e.g. Image.new("tile.png", :retro => true), same for load_tiles etc.; would this help?

(It's gotten a lot easier to actually implement this based on the new interface :) )

I've tried to reproduce this issue but it all looks good here. Does this gist work for you?

https://gist.github.com/jlnr/a42235af10f75159f2d9

It is creating a 12x2 sized image (pure white) and drawing it all over the screen. Or is it because your borders are separate images?

Ooohh, SDL 2.0.4 is coming closer! Can't wait: http://forums.libsdl.org/viewtopic.php?t=11294

Ouch! It's on my list. Hopefully updating to SDL 2.0.4 "soon" will fix the issue :)

I've been playing around with Gosu and RubyMotion lately, and I thought I'd share what the experience was like. RubyMotion is a commercial implementation of Ruby running on Apple's Objective C runtime (OS X, iOS), and on Android. I've only tried it on OS X so far.

To run Ruby/Gosu code in RubyMotion, I had to wrap Gosu in two thin layers of code. First, a set of Objective C classes that call C++ code - this part is called GosuKit, and in theory you could use it to write Gosu games in Objective C and Swift (but why...). It looks like this:

https://github.com/gosu/motion-gosu/blob/master/GosuKitTests/GosuKitTests.m

It is possible to call GosuKit from RubyMotion, but the method names are very un-Ruby-like: GSKImage.new.drawAtX(x, y: 5, z: 45...) and so on. So there is a second layer of paint called "motion-gosu" that wraps the GosuKit Objective-C classes in the familiar Gosu 0.9 interface:

https://github.com/gosu/motion-gosu/blob/master/motion/image.rb

It's not 100% complete - TextInput, custom OpenGL and loading images from "blobs" are all missing. Also, motion-gosu is not backward compatible at all - every step away from the new Gosu 0.9 results in an exception.

With these two things in place, I was able to get my old game Peter Morphose to run (half the levels, anyway). It's a very chaotic codebase, mostly translated to Ruby from Delphi source files written in 2001 - but it only took a few changes to get it to work in RubyMotion! That's pretty sweet :)

https://github.com/jlnr/petermorphose/tree/motion

Thoughts:
• RubyMotion does not use garbage collection. If you want to have circular references between objects, you have to use WeakRef - otherwise you'll leak memory. Auditing an existing Ruby codebase for circular references sounds frustrating.
• Everything about RubyMotion is extremely unforgiving. In one case I've passed :additive instead of the newer :add to Image#draw and had to use lldb (the low-level Objective C debugger) to figure out what was going on. So I'd always develop my game using "standard" Ruby/Gosu and then only wrap it up for release with RubyMotion.
• I'm not sure if you can keep your existing directory Ruby/Gosu structure and just add a RubyMotion Gemfile, Rakefile etc? I moved everything around to match the RubyMotion default structure.

iOS is next, obviously. My long-term goal is to run the same (unreleased) Ruby game on iOS and Android devices.

Cool thanks, will take a look. Maybe it's an SDL issue anyway :)

Thanks! Does it happen only in 0.9.x, or also 0.8.x? Do you have an example script for me to try?

Gosu 0.9.2 and 0.8.7.2 have the same rendering backend. Even Gosu 0.7.x, which didn't use libSDL to open the window, used effectively the same OpenGL code internally. But still, go ahead and benchmark all the combinations you are interested in, maybe there are a few surprises :)

FWIW I saw this question on StackOverflow a (long) while ago: http://stackoverflow.com/questions/1784138/why-rubygame-and-gosu-are-slower-than-pure-opengl

1. You don't need to pass a window reference around anymore in Gosu 0.9 :)
2. In Gosu 0.9, you can also omit the third argument, "false", to the Window's super constructor.
3. I think you should be fine if you replace this line:
        @tile.draw(x, y, 0)
with:
        @tile.draw(x * TILE_WIDTH, y * TILE_HEIGHT, 0)
x and y are indices into the arrays here, and by multiplying them with your constants you can convert them to pixels.

Long overdue, but here it is:

https://github.com/gosu/ruby-app/releases

Now bundles Ruby 2.2.1 instead of 2.1.2, and Gosu 0.9.2 instead of 0.7.50.

Please let me know if there are any issues with this version of the app wrapper.

The changes in Gosu 0.9 are really mostly superficial. I'm not sure why Ashton broke - but chances are that raw OpenGL will still work.

Yes! Thanks for reminding me to update the reference to ruby-opengl on the libgosu.org homepage.

I guess it would be possible to render to a texture and then scale it up, but I still haven't looked into render-to-texture at all.

My expectation was that it should actually look better if you render it at a higher resolution directly, but I'm not sure if that's true.

What kind of artefacts, by the way? Are you using the :tileable parameter to ensure crisp tile boundaries?

Awesome, good to know that Gosu by itself works.

I'd love to fork and fix both Ashton and Releasy, but before I get to Gosu 1.0 or so, I don't see it happening :(

Note: SDL_GetGlobalMouseState is only available in SDL 2.0.4, which is still not out by now (pending tickets: https://bitly.com/sdl204-todo). So it probably only fixes mouse_x and mouse_y if you use brew install sdl2 --HEAD on OS X.

Next up: Updated Ruby.app for OS X, if I don't receive any bug reports for 0.9.2 in the next days. Then CMake build files, and I'm playing around with RubyMotion as well.

Another tiny release to keep everything going – support for the current version of Ruby on Windows, and two fixes for things that actually used to work in Gosu 0.7.

• Windows: Support for Ruby 2.2.x
• Allow macro recording outside of Window::draw
• All: Use new SDL_GetGlobalMouseState function if available (this function tracks the mouse position even when it leaves the window)

You can either lazily record it inside the Window#draw call tree, or wait for me to fix this issue here: https://github.com/jlnr/gosu/issues/277

I wasn't sure if anyone already used record outside of draw, so I didn't make it a priority for 0.9.0 - oops. I'll try to address this later today.

Three bug fixes:

• Ruby: Fixes freeze-at-exit bug on Windows (thanks to RunnerPack for reporting this)
• Ruby: Fixes one uninitialised variable that could affect text alignment
• Ruby: Fixes backwards compatibility in Font#initialize

Fixed - will push Gosu 0.9.1 in a bit. Thanks for reporting this!

I write these errors myself using puts - if you don't have the rmagick gem installed, you won't see the RMagick related examples in the list. Same for OpenGL or Chipmunk.

Edit: I can reproduce this. Oops.

(Versions 1.0.0, 1.0.1 and 1.0.2 was me being an idiot with the $LOAD_PATH, and have been yanked. 1.0.3 is the first public version.)

I've moved all the Ruby example games into a separate Ruby gem: https://github.com/gosu/gosu-examples

Now you can simply run gem install gosu-examples and then gosu-examples to open a list of examples. The 'S' hotkey opens each example in a new text editor window.

Please let me know what you think—hopefully this will be easier to find (and maintain!) than the examples/ folder in previous Gosu gems.

Ouch, Gosu::Font#initialize does not seem to be backwards compatible. I'll see what other bugs I find until tomorrow and release v0.9.1 then.

This version finally implements the new, cleaner interface I had originally planned for Gosu 0.8.0. (This release does not introduce any other major features, nor does it fix any bugs.)

Basically, instead of this:

Gosu::Image.new(some_window, "filename", true)

...you can now write:

Gosu::Image.new("filename", tileable: true)

This does not rely on any global variables or other hacks - Gosu::Image is really independent from Gosu::Window now. All the constructors and factory methods have been completely refactored. All the rendering primitives, from draw_line to rotate(4) { ... }, now live directly inside the Gosu module, e.g. Gosu::draw_line(...).

The new interface has been documented in rdoc already: https://www.libgosu.org/rdoc/

Please let me know if anything that works in Gosu 0.8.x does not work in Gosu 0.9.x. In theory, this version should be 100% backwards compatible.