Actually never mind, I have gone ahead and added the link to your page. Thanks!

Hey, sorry for the super slow response. Glad that you are having fun with Gosu :) You should be able to edit the Gosu wiki without a PR, just by virtue of having a GitHub account. You could either host the tutorial somewhere and add a link from this Gosu wiki home page, or you can add it directly to the Gosu Wiki as a page. https://github.com/gosu/gosu/wiki

...wat :D

Oops, looks like I had unsubscribed from this board by accident. Welp, I can only assume that the image does not contain the rect that you've tried to load from it.

A lot of Gosu game development these days happens on itch.io, in the form of short Gosu Game Jams such as this one: https://itch.io/jam/gosu-game-jam-4

They are being organized on Discord: https://discord.gg/gTaHxdm

Shout out to all organizers and participants for their hard work 💪

Gosu development is going very, very slow currently. There is also not a lot of low-hanging fruit left after almost 20 years of development.

As far as Gosu games are concerned, there was another Gosu Game Jam last April with 7 entrants: https://itch.io/jam/gosu-game-jam-4 - but all the talk around these jams happens on Discord, and none of the jams have been mentioned here.

I guess most people these days are used to Discord, instead of tiny forums like this one with their own account system and so on.

Edit: Added a sticky topic to point this out.

Hi Yamisloth, great to see another Gosu Showcase post after all this time. It seems that this forum is going out of fashion, if you have any questions or are looking for feedback, I would suggest joining the Discord "server": https://discord.gg/gTaHxdm

• When using SDL 2.0.12 or later, the LED indicators on gamepads will now be set to match the gamepad index that Gosu has allocated for them. (#639)
• Added some missing #include statements, thanks to @LittleLightLittleFire for the PRs. (#641, #642)
• Update all bundled dependencies. (#643)

• Finish the fix for the Windows main loop from #634, a key part was missing. (#636)
• Update all bundled dependencies, thanks to @cyberarm for the automation. (#635)

• Add clipboard support in the form of Gosu.clipboard/Gosu.clipboard=. (Thanks @cyberarm! #630)
• Fix a regression in the Window.show main loop on Windows that was introduced in 1.4.3. (#634)
• Fix a potential build/linker error on ARM macOS. (Thanks @jimtng! #627)

Hey, I am not sure why I didn't receive an email for this new post. This issue has been discussed a bit on the Discord, and sound is actually one of the areas that have changed the most recently. Gosu now uses SDL_sound for loading audio files (as opposed to a merry mix of different libraries), and mojoAL for playback instead of a different OpenAL implementation per operating system.

Can you please share the WAV file? I am curious what kind of WAV format/encoding broke.

• Update bundled dependencies: stb_image, stb_image_write, stb_truetype, stb_vorbis, utf8proc, mojoAL, SDL_sound.
• These updates fix MP3 playback and Gosu::Sample pitch changes. (#592, #623).
• Introduce optional retro: true option in Font#initialize, thanks to @cyberarm. (#479, #624)

This has already been discussed in the Discord. In general, it is probably easier to use raw OpenGL to manage textures because then you can ask for advice in general gamedev communities, not just the tiny niche that is Ruby/Gosu. If you want to use Gosu to load images into RGBA format, you can use Gosu::Image.new(...).to_blob to retrieve a binary RGBA string.

• Fix an audio bug when repeatedly playing a Gosu::Song. (#618 / #619)
• Fixed Window::tick never waiting for update_interval. (#620 / #621)

Both fixes once again contributed by @cyberarm.

• Windows: Support for Ruby 3.1. (#611/#612)
• Windows: Update SDL to 2.0.20 (#610), also update SDL_sound on all platforms (#606).
• Replace OpenAL (usually oal-soft) with mojoAL. (#608)

All three improvements contributed by @cyberarm.

• Add Window#gain_focus callback to mirror Window#lose_focus, which was previously undocumented and only implemented on iOS. (#600) Thanks @cyberarm!
• Fix Gosu::Window#tick not raising errors from callbacks. (#594) Thanks again, @cyberarm!
• C++: Refactor the Gosu::Color interface to be less verbose.

The Windows file was marked as a virus, had to remove it.

Hey, for some reason I didn't see a notification about this thread. Thanks for the suggestions. I have actually reduced the number of channels in the past because I found it hard to remember which channel had which discussion. Honestly I just think Discord is pretty bad for anything but real-time chat, Slack is a bit better with its threads, and I've heard good things about Zulip, but nobody uses it.

Re: Backups, I think I'll probably back it up by just crawling the site and saving every HTML page, so in case everything breaks, it'll just be frozen in time forever.

:D

I've thought about updating Chingu before because I'm trying to keep the games on the Showcase board playable, and many of them use chingu. But there's also texplay and chipmunk...

I don't know. Maybe I'll give it a try during Hacktoberfest. I've already forked Chingu into the Gosu organization, if anyone wants to sell pull requests, you're welcome: https://github.com/gosu/chingu

Oh hey! Thanks for editing and updating this :)

Billiardv1.0.zip was marked as a virus by my web hoster. I assume it's a false positive, but I won't re-upload it either. I think the best way is to only share source code on here going forward.

Hey Kody, glad to hear you're enjoying Gosu.

The OpenAL implementation on Linux seems to be pretty verbose in genereal. Maybe there's a way Gosu could finalize everything at the right time to avoid this message, but when I tried doing so with at_exit callbacks, it didn't quite work. I haven't invested more time afterwards because any game that is packaged for final release will run without a terminal attached, so only developers will see this.

Annoying as it is, I recommend ignoring it for now.

• Gosu.language() is deprecated, please use Gosu.user_languages() instead.
• macOS: Fixed loading of bold/italic system TTF fonts.

* Improved accuracy of Gosu.available_width / Gosu.available_height. Thanks @cyberarm!
* Fixed a bug where macros (images returned by Gosu.record) were deformed when rendered with specific coordinates. Thanks @jsb!
* macOS: Improved support for ARM-based Macs.

• Gosu::Window can now be created with borderless: true (WF_BORDERLESS in C++) to hide all window chrome. Thanks to @cyberarm for this contribution.
• Gosu::Window#resizable= and Gosu::Window#borderless= allow changing these properties later.
• Windows: Pin the main thread to the first processor core during Window::show to avoid timing glitches.

• Breaking change: Image.from_text, Font.draw_text and Font.text_width have stopped parsing pseudo-HTML markup. Replace "text" with "markup" in each method name to get this functionality back.
• Breaking change: The alternative gosu/zen interface has been removed.
• Breaking change: Gosu::Window::needs_cursor? now returns true by default, not false.
• Support for Ruby 3.0. Gosu now requires Ruby 2.5 or later, and can only be used on Windows when the RubyInstaller DevKit has been installed.
• Support for analog gamepad sticks. Previously, all sticks and D-pads of gamepad 1 were merged into the same constants such as GP_0_LEFT. Now there is a GP_0_DPAD_LEFT button ID for the D-pad, and GP_LEFT_STICK_X_AXIS / GP_RIGHT_STICK_X_AXIS axis IDs that which can be used with Gosu.axis() to query a value between -1 and 1. Thanks to @cyberarm for this contribution. (#524, #540, #542, #543. #546)
• Replace all audio libraries by a statically bundled copy of SDL_sound. (#539)
• Added button IDs: KB_PRINT_SCREEN, KB_SCROLL_LOCK, KB_PAUSE, KB_CAPS_LOCK. Thanks to @edwinacunav for this contribution. (#545)
• Some method arguments have been made optional again, for compatibility with very early Ruby/Gosu projects.
• C++: Rewrite CMake files for Linux and macOS (#535), clean up MSVC 2019 project.
• Adds a C API to use Gosu from other languages (using FFI or other mechanisms); this is a work in progress, but there are proof of concept bindings for Crystal and MRuby. Join the Discord server to learn more. Thanks to @cyberarm for this contribution.
• Update all stb libraries.
• Windows: Update the bundled versions of SDL 2 (2.0.14) and OpenAL soft (1.21.0).

Hmm, sorry, not sure what place in the code you mean specifically. All the high-level scaling happens in Window::resize, which also keeps the scaling of graphics and mouse input in sync.

Hey, I had this thread open in a tab but didn't really understand the CRuby parts. If you want every image to be twice the size, then the most pragmatic approach would be to subclass or monkey-patch Gosu::Image to apply a factor to the scale_x/scale_y arguments. If you want to scale all coordinates, not just image sizes, then you can put a Gosu.scale(2) do ... end block around your Window#draw implementation.

If you want to do the same by modifying the Gosu source code, then multiplying scale_x/scale_y in Image::draw would be one simple way (plus draw_rot probably).

Also, the explosion animation looks really good. But as someone who hasn't played the original game, I found it hard to tell when I could shoot again :<

For collaboration and feedback, the Gosu Discord server might be the best place right now: https://discord.gg/gTaHxdm

Out of curiosity, I saw you've used Gosu::Button::KbLeft etc. for the button constants. They have been renamed to Gosu::KbLeft a long time ago, and to Gosu::KB_LEFT recently. Where did you still find the old names?

This releases only fixes compilation errors with gcc 10 (typically on Linux).

As discussed on Discord, the official RDoc page hasn't updated yet, no idea why. It's documented if you go to the page for the current HEAD commit: https://www.rubydoc.info/github/gosu/gosu/0740c5/Gosu/Image

Oh, it's been a year. Time to roll out some bug fixes with Gosu 0.15.0:

• Introduce the resizable: true argument in Window#initialize to create resizable windows (thanks @cyberarm) (#437)
• Introduce Image.from_blob(w, h, rgba), which makes it much easier to create images from binary data than having to emulate the RMagick::Image interface
• Fix a crash in debug mode when passing certain strings to Image.from_text (#509)
• Fix bugs in Image#insert (#515)
• Introduce Color#argb/Color#to_i (#476)
• Deprecate Color#bgr/Color#abgr

I've also released a follow-up version, 0.15.1, to catch up with dependency changes:

• Support for Ruby 2.7 (#520)
• Update utf8proc and all used stb libraries (#520)
• Windows: Update bundled SDL version to 2.0.10 (#520)

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.