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. ;)

You could use a texture packer and then load all images using Image#subimage, see https://github.com/spajus/gosu-texture-packer

This would be the ultimate in performance, as Gosu does not have to do any atlas-building during runtime. :) subimage is perfectly portable. Just make sure that the tile atlases are 1024x1024 and loaded with tileable: true, so they end up on their own OpenGL texture.

There have been several discussions about light & shadow in this forum, you should be able to find them using the forum search. I don't think I have ever seen finished code, though. :(

I think it'd work just fine, especially if you are going to add more "juice" as time progresses - things bouncing around, tweening etc.

Working with text can be a little tricky though - you should understand the difference between Gosu::Font and Image#from_text. Also, Gosu has half-assed support for &custom_entities; in text for which you can define an image as well as pseudo-HTML like <b>bold</b> and <i>italic</i>, however these can be pretty slow if used with Gosu::Font.

Good luck even if it's with the wrong engine! ;) Feel free to post the Kickstarter link when you get to that stage.

Right, usually this ends up in bug reports where everything works fine on Windows but suddenly the Mac port crashes, etc. :)

If it works on one platform and that's good enough, there's no reason not to rely on it, as far as I'm concerned.

I don't think that's "officially" possible right now. However I am in the process of moving most Gosu::Window implementations on top of SDL2, and I think that'll make it easier to add support for resolution changing soon. For now the only thing that's guaranteed to work is to have two executables/apps (depending on your OS) and closing the first while launching the second.

It probably works on some platforms but it's not officially supported (yet). :(

Nice interface! Does this have any connection to Chingu, though? Looks like you might as well use it with Gosu, Gamebox or even in a Rails webgame %)

Edit: I also wonder if it would be worth it to change the find_path method to return a linear array of coordinates ([x1, y1, x2, y2, ...]) to take a big load off the garbage collector. But I think working with such an array would be quite painful. :/

Unless your last name is Miyamoto :)

1. Learning how to program, and how to structure games, which are very different from websites and GUI programs. (I wish I had more time to support projects like RubyKids.)

2. Prototyping. Ludum Dare competitions are great for this (when ocra works), and that's basically how Ruby/Gosu was born. If I felt that any of my Ruby/Gosu projects had the potential to become the next Angry Birds, all the hurdles you mention would be easy enough to overcome: By fixing ocra (and it often actually works), or by porting Ruby/Gosu to iOS via RubyMotion (should take around one day), by rewriting the game in C++ or even C#+XNA, ...
(Successful games are regularly ported across systems, anyway. I don't think much of the original Spelunky code is still in the version that's on XBLA/Mac App Store, or in the HTML5 version of Cut the Rope etc. The trick is to build a classic game in the first place :))

3. This is obscure, but I did have a little contracting gig where I built an animated kiosk/touch-screen system in Ruby/Gosu on Linux. I think it worked pretty well. If I had the time, I would advertise this as a service.

(Also, thanks for enjoying Gosu :) )

Oh wow! I haven't played around with C++/Gosu on Windows in a while, but what were the issues you encountered?

No, because parts of Ashton are written in C. Spooner should know more about this :) Please email me at julian@raschke.de and I'll try to send you a .dylib back that you can put into the .app wrapper within the next days, but I can't promise anything.

The burden for providing app wrapper-compatible gems is on me :( Ashton will be included in the next app wrapper release, but I have no schedule for this right now.

From what I remember, that is exactly the bug that I have mentioned in the top posting :)

See this old thread about how to do this without TexPlay or Ashton, but it will be very CPU intensive.

http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=134

If the Banana Pi team is planning to build a gaming machine, then let's hope they work closely with the SDL people! :) I'm just afraid Gosu will not put the second CPU core to good use right now...

There's a guide on getting it all set up now:

Getting Started on Raspbian (Raspberry Pi)

Is it a laptop WITHOUT any label in the black bezel around the screen?

http://images.apple.com/macbook-pro/design-retina/images/fluidgallery/gallery3_2256.jpg

Then it's a MacBook Pro with Retina display. :)

It might be this issue here or it might not. I'll try to reproduce it with an external Retina display...

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

...I guess the bad news about this is that 0.8.0 will not be the release in which I clean up Gosu's interface, but cleaning up the internals is equally satisfying. :)

If you still receive notifications from this forum - please check out http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?tid=1095 :)

My little experiment to implement Gosu on top of SDL 2.x looks promising so far:

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

I'll release this as version 0.8 as soon as it works on Windows; it does work on the Raspberry Pi though!

• Install Raspbian and all dependencies that don't have anything to do with X (should be: build-essential,libfreeimage-dev, libopenal-dev, libpango1.0-dev, libsdl2-ttf-dev, libsndfile-dev)
• Install SDL 2 (I've built 2.0.3 from source, took me about an hour)
• gem install gosu --pre

The only caveat I've noticed is that you should really run in fullscreen mode, because windowed mode is really fullscreen mode without scaling :)

This gem also works on Linux and OS X (with sdl2 installed via homebrew).

If you happen to have sdl2 installed via homebrew, you can try if this solves the issue: gem install gosu --pre

No, Gosu is primarily developed on a Mac (several of them, actually ;) ). Are you on a Retina Mac?

So with the original values of 32/32 it does not work?

Can you please attach a screenshot of what this looks like? Which version of Gosu is this?

Gosu used to expect this order of coordinates: top left, top right, bottom left, bottom right. I think it was in the middle of the 0.7.x series when I started accepting clockwise order as well. Just to make sure, can you see if it works if you replace the 3rd and 4th coordinates?

Ha! :) That's a good optimisation indeed.

You can always increase the motion blur level to 1000 to find out; self.caption = Gosu::fps.to_s is your friend ;)

It's getting better though! Immediate Floats in Ruby 2.0 on 64-bit are a big step forward. Now it's mostly Gosu::Color that is dangerous, and you can often use 0xaarrggbb constants (only a little bit horrid).

I like the amount of polish :)

And this was a fun Ruby/Gosu optimisation exercise too: The game jitters a lot as soon as the player bursts into particles. It's not the CPU, because then it would be consistently slow (and Ruby is not that bad) - it's this loop which is creating lots of work for the garbage collector:

      @particles.each do |particle|
        (1..MOTION_BLUR).each do |i|
          xoffset = i*MOTION_BLUR_OFFSET*0.4
          yoffset = i*particle[:vy]*MOTION_DT
          alpha = ((1.0 - i.to_f/MOTION_BLUR)*MOTION_BLUR_ALPHA).to_i
          @particle.draw particle[:x]-@particle.width-xoffset, particle[:y]-@particle.height-yoffset, 0, 1, 1, Gosu::Color.new(alpha,255,255,255)
        end
        @particle.draw particle[:x]-@particle.width, particle[:y]-@particle.height, 0
      end

I don't know if all the temporary Floats are still an issue (they should be immediate objects on 64-bit Ruby 2.0, right?), but the Gosu::Color is definitely causing trouble. Quick loop refactoring:

      (1..MOTION_BLUR).each do |i|
        xoffset = i*MOTION_BLUR_OFFSET*0.4
        alpha = ((1.0 - i.to_f/MOTION_BLUR)*MOTION_BLUR_ALPHA).to_i
        color = Gosu::Color.new(alpha,255,255,255)
        @particles.each do |particle|
          yoffset = i*particle[:vy]*MOTION_DT
          @particle.draw particle[:x]-@particle.width-xoffset, particle[:y]-@particle.height-yoffset, 0, 1, 1, color
        end
      end
      @particles.each do |particle|
        @particle.draw particle[:x]-@particle.width, particle[:y]-@particle.height, 0
      end

Et voila, the jitter is gone (at least to my eyes) :)

Sounds good! For a project as big as this, I would recommend that you find honest play-testers who usually like the genre you're aiming for. It's what I should have done more often when I was writing an adventure-y game. Turns out there are always some aspects of the battle system that people don't care about deeply, and others where they expected more.

I think Window#needs_cursor? is your friend :) Just override this method and return false to get rid of the system mouse cursor.

Looks as if the binary core of Gosu was missing (gosu.bundle). I'm honestly clueless what the Ruby/RVM/Gem people are doing lately. I'm not changing anything and stuff breaks in exciting new ways every day. :)

Can please you try uninstalling and reinstalling the Gosu gem to see if there is anything suspicious in the console output?

I only have time to answer 1 - MsWheelUp and MsWheelDown are sent to button_down(id) when the wheel is moved.

I'm still convinced that I should kick the resolution-changing fullscreen code out of Gosu. :) The SDL2 offers "fake fullscreen" now, a desktop-sized window where I can just scale everything in OpenGL. Even if I can't use the SDL2 as the base for Gosu on all platforms, I'm still planning to use that bit of code. (The Linux port of Gosu already works like this.)