Thanks! I have added this package to the "Getting Started on Linux" wiki page.

For anyone who wants to ship a game that works on the latest macOS (hopefully) and also includes an up-to-date version of Gosu, there's a new build of Ruby.app:

https://github.com/gosu/ruby-app/releases/tag/v0.14.5

This feature has been added as Gosu.render{}. (I'm replying to see if new posts are being reported on Discord now :P)

I'm still not quite sure what the issue is, but I would suggest a structure that I've used and seen in many Gosu games: Instead of having all the methods and variables in the Window, you can create new classes such as StartScene, GameScene etc. And then inside your window, you point @scene at an instance of the scene that is currently selected, and call @scene.draw in draw etc. That makes it a lot easier to follow the flow of control throughout the game.

To make it possible for scenes to replace themselves with a new scene, you can pass the window to each scene's constructor, and then you can set @window.scene = EndScene.new(...) to advance to the next part of the game. Or you could simply make the current scene a global variable $scene and update that as appropriate.

Anyway. Once you have scene objects, you would typically construct the scene for a specific level like this: GameScene.new(@window, level_number), and the GameScene would store the level number in an instance variable @level_number. And if you have a screen that comes up inbetween levels, you would also pass the next level number to its constructor, and so on.

I hope that is the kind of progress saving you are talking about? Either way, it's a useful design pattern :)

Please post more source code, it's not clear from the snippet where the problem might be.

You can find the angle from point 1 to point 2 using Gosu::angle(x1, y1, x2, y2), which internally does the tan^-1 that nifriz mentioned.

Hey! I've only played the first level but it's a really fantastic piece of work. So many different mechanics :)

My first bit of feedback would be that this game is super hard. I just played it casually and didn't get past the first stage... It wasn't clear to me that I could jump on enemies because I thought the game was about bombs, and it took me a while to discover that walking longer also makes you jump higher. And beyond that, it was just hard in general :)

I believe it would feel a little easier if the game was more forgiving about jumping, e.g. if you press "jump" one frame too early (before the player touches the ground) it would be nice if the player would jump as soon as they hit the ground. Or if it was still possible to jump for one or two more frames before falling off a cliff. I might be biased here because I've added these precise two mechanics to my last game, but I think it made a difference.

I've linked to the game in the Discord server (linked from libgosu.org) because that's the most active part of the Gosu community now. If you're still looking for feedback or help, I definitely recommend checking it out!

Thanks for testing. Hm! If Super Tux Kart can manage 25 FPS, then Gosu should run way faster than 18 FPS?! If I can find the time I'll look at their OpenGL code. Maybe there's some flag that I set that makes the Intel drivers unhappy.

Hey, where did my reply go? :C

Thanks for digging into this! These OpenGL issues on Windows come up from time to time and it would be really good to know if there's anything I can do in Gosu to fix them. Your "opengl" renderer with 275 FPS and SDL_RENDERER_ACCELERATED doesn't sound like it's just software?!

Can you please try a "pure OpenGL" game like Super Tux Kart to see if it runs acceptably on your PC? Gosu is something between 15 and 20 years old, so your GPU really shouldn't be the problem. I've just recently added the first non-OpenGL 1.0 call, and it's an optional feature (render-to-texture) :)

Thanks for trying this and posting the code. It seems that SDL_Renderer does not necessarily use OpenGL on Windows, so maybe SDL 2 works better because it uses Direct3D.

Can you please try calling SDL_CreateWindow and SDL_CreateRenderer separately as in this example:

https://wiki.libsdl.org/SDL_CreateRenderer

I guess you could try different indices for the renderer (0, 1, 2 instead of -1) and then print the name of the renderer using this function:

https://wiki.libsdl.org/SDL_GetRenderDriverInfo

If either the OpenGL or OpenGL ES driver works better than what Gosu does, then I could fix it. But adding a Direct3D backend to Gosu itself would be too much :(

Do you use OpenGL in the equivalent SDL 2 code as well? I think they have this "renderer" library that uses OpenGL under the hood, but is easier than using raw OpenGL. If it works from C but not via Ruby -> Gosu -> SDL 2, then that's really curious.

This is what Gosu does: https://github.com/gosu/gosu/blob/master/src/Window.cpp#L37-L47

Usually these kinds of issues are solved by reinstalling drivers or windows or whatever, but that's obviously not a great solution. :/ OpenGL 2.1 (what your chip supposedly supports) should be good enough as well.

You don't need OpenGL for that. I've hacked together a quick example here: https://gist.github.com/jlnr/413b03c4289dab70932540e6fc0b01a6

If you want to draw a textured progress bar, you can also draw two images on top of each other, but use Gosu.clip_rect to only draw a portion of the inner bar.

Great to hear. So alert2.mp3 works both as a Sample and Song now?

There is definitely still a difference in the file type detection between Song and Sample. I have just tried to reproduce this with an MP3 file on my desktop, and it only worked in Sample(!). Turns out this file is actually an M4A file with the wrong extension... Not sure why Song can't stream the file. It might be a macOS-specific error too, because I use Apple's AudioToolbox for file loading on macOS and iOS.

I have opened an issue here: https://github.com/gosu/gosu/issues/484

I am not sure if you can use Gosu::Song on a background thread; Gosu is designed to be used on the main thread (for now). However, there is a Gosu::Song.update method that should be pretty much what you are looking for, if you have a way of regularly calling it from the main thread.

The MP3 loading bug should have been fixed in Gosu 0.14.3. If you are still experiencing this issue, can you please attach the MP3 file to your post?

Let's start 2019 with a small maintenance release:

• Windows: Compatibility with Ruby 2.6.
• Windows: Update bundled SDL version to 2.0.9.
• All: Add KB_NUMPAD_DELETE constant, thanks PeterCamilleri on GitHub!

Also, thanks to D3nx for letting me know about the Ruby 2.6 release on the Gosu Discord server.

Just a tiny bugfix release:

• Added diagnostic logging when the GOSU_DEBUG environment variable is set.
• Linux: Improve font fallback logic, which used to be severely broken on Fedora-based distributions.

This is a minor bugfix release after the big changes of 0.14.0. The minor version has jumped straight to .3 due to two packaging errors on my side.

• F11 can now also be used by default to toggle fullscreen mode (many browsers and video players support this shortcut)
• Gosu.render now supports the retro: true argument in an option hash
• Linux: Improve both the default and fallback font logic; this should fix bold/italic text with the default font, and exceptions on some distributions
• Update all "stb" library dependencies
• Windows, Linux: MP3 files now work both in Songs and Samples

Your image is not available anymore, but this is the error I'm seeing:

Traceback (most recent call last):
  14: from game.rb:75:in <main>'
  13: from /usr/local/lib/ruby/gems/2.5.0/gems/gosu-0.14.1/lib/gosu/patches.rb:72:in tick'
  12: from /usr/local/lib/ruby/gems/2.5.0/gems/gosu-0.14.1/lib/gosu/patches.rb:72:in tick'
  11: from game.rb:17:in update'
  10: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Screens/main.rb:43:in update'
   9: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Screens/main.rb:392:in automatic_state'
   8: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Screens/main.rb:623:in remove_matches'
   7: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Screens/main.rb:631:in initial_match_removal'
   6: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Helpers/game_helper.rb:56:in get_starting_point'
   5: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Helpers/game_helper.rb:56:in each'
   4: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Helpers/game_helper.rb:58:in block in get_starting_point'
   3: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Helpers/game_helper.rb:58:in each'
   2: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Helpers/game_helper.rb:60:in block (2 levels) in get_starting_point'
   1: from /Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Metrics/graph.rb:55:in find_start_when_finish_known'
/Users/jlnr/Projects/Gosu/Gosu/matchThreeRuby-master/Metrics/graph.rb:92:in shortest_upward_path': undefined method []=' for #<PriorityQueue:0x00007fa510a25438 @queues={}> (NoMethodError)
Did you mean?  []

The link seems to go to the Ruby file only. By the way, you can also attach zipped games (I think the limit is 10 MB on this board), and you can toggle "embed" to make your screenshots appear inline with your post.

No problem. I think the current PRs on GitHub would make for a good ladder to Gosu 1.0, with 0.15.0 inbetween (one version for audio, one for all the Image/keyword args stuff). Thanks for getting these branches started! And sorry for butchering the CI a bit because I wanted to get 0.14.0 out. Cross-platform tests still aren't as easy as I'd hoped =/

This is a pretty big release, with commits going back all the way to 2017.

All text rendering has been rewritten to use stb_truetype instead of platform-specific APIs. This means text will look subtly different than in Gosu 0.13, but it will now be much more consistent across platforms.

I have also made markup parsing (<b>This is bold</b>, <c=ff0000>this is red</c>) more explicit by introducing new methods: Font#draw_markup, Font#draw_markup_rel, Font#markup_width, Image.from_markup. The existing methods will stop parsing markup in Gosu 1.0. If you want to keep using the markup feature, you should use the markup methods from now on.

One new feature that I'm sure many users will appreciate is Gosu.render(width, height) {}, which can render arbitrary Gosu code to a new texture and return it as a Gosu::Image.

And then there are a few bug fixes for macOS that were long overdue.

Other changes:

• Ruby: Gosu::Font#initialize now accepts style parameters, e.g. Gosu::Font.new(20, bold: true, italic: false). Unlike in earlier versions of Gosu, Font is not bold by default.
• macOS: Compatibility with macOS 10.14 Mojave
• Ruby: Image.from_markup/Image.from_text now supports alignment: :center, alignment: :right, and the spacing: parameter even when there is no width: parameter.
• C++: The interface for rendering text has changed completely, please look at Gosu/Text.hpp to see the new set of available functions.
• iOS: Support for Gosu::TextInput on iOS.
• Ruby: Remove support for Ruby 1.8-2.2 on Windows. Ruby 1.9 through 2.2 are still supported on macOS and Linux while I'm working to update (fix) the CI.

Looking forward to see more activity around mruby :) I keep reading about it in the context of game development, I really hope it takes off as an alternative to C Ruby.

The C++ version of Gosu is mostly an elaborate wrapper around the SDL 2 library, and is suitable for commercial games on macOS, iOS, Windows, and Linux. I used to have a commercial Gosu game on the iOS App Store and never had any issues.

The RubyMotion version of Gosu for iOS and macOS seems to work well enough, but nobody has tested it on the App Store as far as I know.

The 'normal' Ruby/Gosu library on Windows, macOS, and Linux suffers from the fact that Ruby can't really be compiled. This should be fixable with mruby, but nobody has put in the work yet.
The typical ways of distributing Ruby/Gosu games, i.e. using Ocra on Windows and the Ruby.app wrapper on macOS, do not hide or obfuscate your source code at all. That doesn't technically stop you from selling these games, but neither way looks super professional.

In terms of bugs, there are rare reports where games don't work on some Windows machines, but it's extremely hard to determine if those are issues with the graphics drivers (specifically OpenGL) or with Gosu/SDL 2.

All of that being said, I'm always willing to prioritize issues if it helps anyone ship games, especially commercial ones.

This is the main documentation website: https://github.com/gosu/gosu/wiki

This is the relevant GitHub issue to subscribe to for updates: https://github.com/gosu/gosu/issues/406

It's unlikely that I'll just implement this on a weekend though. I am not a web developer, and I also wonder if it really makes sense to port Gosu to the browser. Is the interface even a good fit in terms of performance? I don't know.

My personal hope is that someone else figures out how to deploy Ruby everywhere (even Windows and macOS are a pain to be honest), and then I'll piggyback on that with Gosu :)

Thanks. I've mailed the link to my Windows machine. I only boot it twice a week because I'm not a true gamer :S If the Gosu discord catches on, I might install it on some other device too.

I try to reply to bug reports ASAP but I really need an example that demonstrates the issue. Now that you have updated the game before I had the free time to download it, I still don't understand what the issue with subimage was :/

Putting your game on GitHub makes it easier to refer to previous revisions. You can also always download a ZIP of the current master version (or link to that ZIP from other sites), instead of having several RAR files in MediaFire. I really recommend it (plus: knowing Git/GitHub is a valuable skill :)).

I guess this belongs here: https://github.com/chipmunk-rb/chipmunk/issues

I'm not sure how gem compilation works on Windows, it could also be an issue with your Ruby 2.4.3 installation. You could check with Ruby 2.5 (which Gosu supports now). If nothing else works, 2.3.3 is a fine version ;)

The two Window.show calls at the end of the file are a little odd but shouldn't be the issue, because the second window will only be created and shown after the first window's show method returns (because it was closed).

Code looks good, but I don't know what Title and ResChoice do. I would suggest isolating the issue by commenting out parts of the source code to see at which point the problem goes away.

Gosu also swallows some exceptions and re-raises them later. If there's a bug in this part of Gosu, it can happen that exceptions just disappear altogether (this has happened before) :/

Gosu uses the well-maintained SDL library for creating the window and setting up OpenGL. If vsync doesn't work on your Ubuntu system, then it's not a problem with Ruby/Gosu, but with all SDL-based games.

There was someone on IRC just this week who also experienced tearing (lack of vsync) on Linux with Gosu. I'm afraid vsync issues on Linux will be with us until everyone uses Wayland (which Nvidia's drivers don't support, yay). https://unix.stackexchange.com/a/182841

The only Gosu-specific advice I can give you is to keep the update_interval at its default value, in which case the vsync on Windows should not slow your game down.

Thanks for creating the issue.

It's actually on my never-ending To Do list to play around with Godot as well. I mean, I started Gosu because I didn't like any existing gamedev library around ~2001(!). It was only a matter of time before someone would build a much better library/framework :) I just hoped it'd be based on Ruby or a similar language like Crystal, so that I could provide a compatibility layer and stop maintaining Gosu.

The truly sad part is that there are many great games on the Showcase board (yours especially!) and there's still no solid way to publish them. I would love to help with getting Gosu games onto Steam, but would you really want to base it on Ocra's self-extraction to %TEMP%? It just feels so shaky to me. :/ The lack of a good native compilation path for Ruby games is frustrating me to no end. I think I'll give mruby a second chance some time, mostly because I want to stop maintaining the macOS Ruby.app wrapper, but if that doesn't work, then what? Porting Gosu to web assembly feels overwhelming to me, I'm just not a browser person.

In the unlikely case that mruby's native compilation works and kicks ass, I might contact you to see if you still have some games left which you haven't rewritten in Godot :) In the meantime, please do bump your threads in the Showcase board if a Godot port makes its way onto Steam. It would be cool to see the progression. Good luck!

Spooner has transferred Ashton to the Gosu organization on GitHub, so I can fix this and maybe even release a fixed gem. Can you please open another issue with details here? https://github.com/gosu/ashton/issues

There is something framebuffer-ish in the current Gosu master (soon to be 0.14.0). Shaders might still take a few versions though :(

FYI, this game was marked as having a virus/trojan embedded by my web hoster, and thus the ZIP file is gone. It could be a false positive.

One more reason to post GitHub source links :)

With input update delay, do you mean the update_interval parameter in the Gosu::Window constructor?

One possibility here is that your Linux system does not vsync Gosu with your screen, and so if you use an update_interval of 6 ms, you could be simulating three frames but only one is rendered. If your Windows system supports vsync, then each 6 ms frame could be waiting for your 60 Hz monitor refresh, effectively stretching each frame to 16.666 ms. If you are using a 4K screen that only supports 30 Hz, it would even take 33.333 ms for each frame to finish. This is definitely something where Gosu needs to improve given that so many people have screens with refresh rates ≠ 60 Hz nowadays.

Oh wow, thanks for pointing that out! The 64-bit version of the 0.13.3 was missing, not sure how that happened. I've just pushed it again. I only tested the 32-bit version after uploading it.

This release only updates some dependencies, mainly for Windows users:

• Windows: Support for Ruby 2.5 (#427)
• Windows: Update bundles SDL to 2.0.8
• All: Updated stb dependencies (#428)

Your coworker?! Nice coincidence - say thanks to him for maintaining it :)

I wasn't aware of the ruby-opengl project. I think an older gem was called ruby-opengl before? I'll keep an eye on the new version and maybe update the wiki and example. They have a Gosu-focused example, based on tjbladez' example series, which is nice:

https://github.com/vaiorabbit/ruby-opengl/blob/master/sample/Gosu/lesson01.rb

It's reassuring that it uses libffi. Maybe FFI really is the way to go, after all? The C extension situation on Windows just doesn't seem to get any better with time.

Oh wow, this issue again :) Does the workaround from the linked thread still work (calling glGetError before any other gl method)? Although it would probably be cleaner to find the OpenGL maintainer and figure out the source of this error instead of working around it. I'm not even sure that OpenGL errors are severe enough that they should throw an exception in Ruby.

Great analysis! I think the performance behavior of Gosu::Font can be a bit unintuitive because other toolkits cache fonts internally. What Gosu's font does is basically call Gosu::Image.from_text('a'...) once for each letter that is used, and these letters are then cached per Font instance. So yeah, don't re-create fonts if you can at all avoid it, otherwise every letter will have to be rendered again.

I always feel I should document these things better, but I'm not sure where. RDoc? GitHub wiki? :/

The reddit is newer, but I don't think it really succeeded in replacing this forum. Some people seem to prefer message boards (me included), some people prefer subreddits, but neither is active enough that I feel like shutting down the other. There's actually a third place :D - StackOverflow, sometimes I see some Gosu questions over there.

Anyway, I'm closing this thread per kyonides' request. If you change your mind and want to post your full game or a minimal version that exhibits the problem, PM me and I'll unlock it.

A minor bugfix release:

• 2018-01-16: All: Fix Gosu::KB_SLASH constant (#426), thanks to @mblumtritt for reporting this issue.
• 2018-01-14: macOS: Fix compilation on macOS High Sierra with Apple's built-in Ruby 2.3.0, thanks to @jiazhh0325 for reporting this issue.

Correct, moving this thread.

Even if you were working with multiple windows, the OpenGL context is shared. Passing a window into game objects is only necessary right now if they need access to its title or mouse position.

The compat.rb file overrides a few methods in Gosu, so the stack trace will usually include this file even if the error happens in a completely different file. Interpreting these errors is tough, but gets easier with time.

This little debug statement doesn't try to fix the issue, but it should print true or false in the terminal when you run the game, depending on whether the file can be found.

Sorry for not replying earlier, but glad you found it :)

Hmmm. What is your plan with Gosu running inside a Vagrant VM? Is the VM headless? That would explain why Gosu can't open a window. And why are you using a 3+ year old version of Ubuntu?

You mean ruby game.rb, right? No idea. What does this print if you run this as the first line in your Ruby script:

p File.exist? "assets/starfighter.png"

Do you have a folder assets next to the Ruby source code files, and does it contain an image named starfighter.png? How do you run your game?