https://rubydoc.info/github/gosu/gosu/Gosu/Image#draw_rot-instance_method

There are "center_x" and "center_y" parameters before the scale parameters.

Okay, no real progress to report, but the project isn't totally dead; I'm still doing research and gathering ideas and code.

For example, I found this, which should allow larger game projects: https://github.com/mrubyc/mrubyc

Many of you have likely heard about the ODROID family of single-board computers, at least in passing. You may have even heard of the ODROID-GO. In case you haven't, here's a link:
https://wiki.odroid.com/odroid_go/odroid_go
As you can see, it is a hand-held game console (reminiscent of Nintendo's Game Boy) based on the ESP32 WiFi-enabled microcontroller platform. It's not very expensive for what you get (although the shipping adds 50% to the price - it's $48 shipped to the U.S.)

The first time I saw it I thought “ODROID-GO? More like ODROID-Gosu, amirite?” ;)
But seriously… this looks like tons of fun, and (like most things) it would be even better with Gosu!

So, before I ordered one, I made sure that some form of Ruby would run on it, and I found a port of mruby:
https://github.com/mruby-esp32

I've also looked around for a development environment. This looks like a good one:
https://docs.espressif.com/projects/esp-idf/en/latest/get-started/index.html#setup-toolchain

Now, there's one little hitch when it comes to porting Gosu: I don't think it has any kind of video acceleration hardware. That means all video rendering will have to be done in software. Since, to my knowledge, Gosu doesn't have any software rendering code, I suppose this could turn out to be less of a port and more of an API re-implementation... But, I'm okay with that, since it's the nice, clean API that made me fall in love with Gosu in the first place. Also, there's this:
https://github.com/ssloy/tinyrenderer

On top of getting the basics to work, I plan on making a platform to allow other Gosu users to target the ODROID-GO with their games.

I'm envisioning a front-end that lists and launches Gosu apps, each stored in its own folder (or archive?) on the SD card. Picture the "XMB-style" interface that many projects are using (including the emulator front-end that comes preinstalled on the unit) with a standardized icon/description format.

Anyone who wants to help is welcome, even if it's only to offer testing or constructive criticism.

NOTE: I don't have much free time to devote to this, so don't expect this project to move forward in leaps and bounds. In fact, I don't even have the little guy in my hands, yet (but it should be here Monday!)

This is really cool! Downloading immediately :D
Question: Can you pass a TiledImage to TiledImage#new?

EDIT: Now that I think about it, it probably wouldn't be very useful to do that... You could just increase the number of tiles in the original TiledImage.

It didn't work for me. I got an "invalid invite" message.

Image#draw puts the upper left corner of the image at (x, y). Are you taking this into account for both the player ship and the bullets?

(Also, this isn't the right forum for posting questions. It's really for finished projects you'd like to show off.)

Using and passing a Window object around to all of the drawing methods was deprecated a few versions back. Now all of the drawing methods are Gosu class methods and don't require a Window object.

The latest documentation can be found here: http://www.rubydoc.info/github/gosu/gosu/

(Note: The "Showcase" forum is for showing off completed projects. Please start posting your questions in the "Exchange" forum. Thanks.)

This is a Ruby question, not a Gosu one. You might want to take a look at some Ruby tutorials before continuing with Gosu. The language is both powerful and readable, but it has some quirks and special ways of doing things that will take some getting used to.

The way to do something with each item in an array is to use it's Enumerable methods. One of these is Array#each. It can be used like so:

@grid.each { |g| g.draw }

Look for documentation on Ruby's Array class (or the Enumerable mixin module) for more information.

EDIT: Note that this assumes your Gosu::Grid class behaves as an Array (or also mixes in Enumerable), which there is no evidence of in the above code. Since I can't find any documentation for the Grid class, I don't know if this is the case.

EDIT2: Are you using this? https://github.com/shemerey/gosu_grid

If so, it looks like the Grid class does respond to #draw as you would expect, so you must be using it incorrectly somewhere else. What line actually gives the "cannot pass array into integer" error?

The button IDs aren't bit-masks, so they can't be boolean'd with each other. The Window#button_down callback is called for each button press, and receives a single id. The id will only ever equal one key/button. You have to check if the id is one of the buttons in the combo, then check to see if the other button is also held down (with Gosu#button_down?(id)).

One of the few things I've heard about Vulkan is that it makes "desktop vs. mobile" pretty much obsolete, as well as (likely) a lot of other cross-platform stuff. This alone would be a great benefit to Gosu (IMO).
On the other hand, it might just end up as yet another dividing line between "current" and "obsolete" (as in, "three or more years old" :P ) hardware, with drivers only being released for the last one or two generations of GPUs (and/or only the highest-priced "gamer" cards).
Thoughts?

+1 for fixing/integrating Ashton (or fragment shaders in some form).

At least they still have a 1.9.3 installer (although you have to go into the "archive" to get it). I installed it, the devkit, and the "standard" Gosu-related gems, and the crate demo (with the patch to fix the black screen issue) is working fine.

Ashton is having problems, but that's getting too far off-topic...

I tried to test your code, but there's something wrong with the opengl gem on my (Windows 7 64-bit) PC. When I try to require it, it attempts to load a different library based on the version of Ruby, as follows:
begin
  RUBY_VERSION =~ /(\d+.\d+)/
  require "opengl/#{$1}/opengl"
rescue LoadError
  require 'opengl/opengl'
end


At first, I thought it was failing because I'm running 2.3.3 (from rubyinstaller.org), and there's no 2.3 folder inside the gem. I copied the 2.2 folder and renamed it to 2.3, and it still didn't work. I tested the regex in opengl.rb, and it's working fine. I disabled the rescue clause, and the backtrace says Ruby's looking for: "C:/Ruby/lib/ruby/gems/2.3.0/gems/opengl-0.9.2-x86-mingw32/lib/opengl/2.3/opengl.so" and that's exactly where the file is. This is the only gem that fails like this. Is it a problem with my setup, or a problem with the gem?

Well, now I feel silly... I really was sending an "invalid value" to draw_circle (and, thus, to the draw_rect inside)!

I've made draw_circle a class method of Gosu and made an instance method of Window pointing to it, and all works as it should!

I'll probably post the project (which isn't really a game), along with the circle routine itself, to the showcase.

Thanks for your help, jlnr!

That results in, in the working example: undefined method 'draw_circle' for #<GfxWindow:0x287bc20> and, in the non-working example: undefined method 'draw_circle' for #<Connector:0x2944398>

I'll post some minimal code to show what I'm trying to do.

EDIT:

If I add "Gosu::" to the draw_circle calls, the non-working example gives "invalid value" and the working example works again, but I don't have to add "Gosu::" to draw_quad, etc., so why should I now?

I've got the beginnings of a passable "draw_circle" method that draws an unfilled circle with a given edge thickness (using draw_quad), but I don't know how to integrate it into Gosu so it functions like draw_line, etc.

I tried monkey-patching it into Gosu::Window, and it works fine when called directly from within (a subclass of) Window#draw. However, I want to call it from within the #draw of another class, which is itself called inside Window#draw. When I do, Ruby says the method is undefined. Okay, that kinda makes sense... I just have to call Window#draw_circle, then, right? So, I pass a reference to the Window object into my class' constructor, but calling @win.draw_circle(...) makes the first call to draw_quad inside draw_circle fail with the message "invalid value".

Since draw_quad, etc. are defined directly in the Gosu module, I tried doing that with my draw_circle, too, but then I can't figure out how to call it at all. It doesn't "just work" like calling draw_quad, etc.

I don't know enough about Ruby namespaces or the way Gosu works to figure this out. Help!

Hi, all. I just submitted this feature request/placeholder for adding support for stereoscopic displays in Windows using Nvidia's 3D Vision.
I plan on implementing this myself (very slowly), but if anyone wants to help, I'd welcome any assistance (and boy do I need some...)
If anyone else is interested in having this functionality, feel free to post your thoughts. I'll need to come up with a "Gosu-like" and "Ruby-fied" way to control the extension, among other details. I'm also interested in what kind of hardware people are going to be using it on (so we can do lots of testing with various setups).
My own system consists of a Geforce 560 Ti (1GB GDDR5) connected to an ASUS VG23AH passive (FPR) 3D display (1080p, row-interleaved).
If you're not interested in stereoscopic Gosu, just ignore me and go about your business.

Focusing on learning Ruby (and OOP) first is a good idea. I know I could stand to be more fluent in it. I don't think anyone's going to make fun of your code, though, at least around here. This is one of the most helpful, sharing, and friendly communities you'll find online. Any criticism you get will be constructive, and usually only when you ask for it (as you already have).

As for using arrays instead of classes, that can sometimes be a better way to go to get the speed you need, especially for a game. You should focus on using the best tool for the job and ignore the coding elitists and know-it-all pedants (which, like I said, we don't really have here).

I only took a quick look at it, but the only thing that jumped out at me is the use of "magic numbers", which will make it harder to change aspects of the game later. It's better to make everything a constant, or load stuff from configuration files.

It's pretty fun for as simple as it is. Keep up the good work. Be sure to browse and/or search though the forums; there's a lot of good information here.

Re: the distribution thing, you should check out Releasy. There's a link on the Gosu homepage.

1. Good to know that after all the trouble I went through to install it :P
2. You're right; glu32 isn't needed to compile Tutorial.cpp. It could be useful to someone doing custom GL stuff along with Gosu, but I'll probably leave it out to keep from confusing noobs. I wasn't including it in Gosu itself, BTW.
My post contains two lists. Which one needs libsndfile? It's currently in the Gosu makefile, but not the Tutorial one. Is it supposed to be the other way around? If not, how is it being linked by VC, since it isn't in the VC project? Is "AutoLink.hpp" doing it?
Does the MSYS/MinGW build need libraries at runtime that the MSVC build doesn't?
Yes. It requires libstdc++-6.dll.
Are pthread and stdc++ statically linked?
I think pthread is, but stdc++ isn't (see answer above). I should probably figure out how to ensure they're both static, to cut down on the DLLs required.
What if we made a "Getting Started on Windows" page that linked to separate MSVC and Mingw pages?

Thanks! I have a couple of questions about things I came across while updating the wiki guide:
1. Is the DirectX SDK needed when compiling Gosu? If so, why?
I found the following in the linker section of the VC project file: SDL2.lib, opengl32.lib, openal32.lib, winmm.lib, delayimp.lib (Note: DirectX stuff conspicuously absent...)
Mingw doesn't even include a delayimp (although it does have a delayimp.h), but libgosu.a seems to compile and work fine without it.
2. What libraries are needed when building programs based on Gosu?
I experimented and found that some of the libraries suggested by the current guide don't appear to be necessary, including some seemingly DirectX-related libraries distributed with MinGW (e.g. libdxguid.a and libdinput8.a). The bare minimum seems to be: gosu, stdc++, libpthread (or whatever's linked when you pass the -pthread option), SDL2, OpenAl32, opengl32, glu32, and winmm
It would be great if there was an up-to-date (per platform?) list of every library needed for both Gosu itself and Gosu apps. Something to add to the wiki, maybe?

Thanks again, jlnr! Adding -mwindows to LDFLAGS did the trick!

BTW, I've uninstalled MSYS2. With just the stand-alone Mingw installer, and with its /bin folder on the path (which is easily done by running the batch file it comes with), I am able to use mingw32-make at a normal Cmd prompt to build the Tutorial program :D

I had to modify the paths in the makefile, but other than that it "Just Worked(tm)" ;)

Now I need to modify the other makefile accordingly and see if I can still build Gosu itself. Once that works, I'll be able to update the wiki page :D

A quick question to anyone familiar with using gcc under windows: What argument(s) do you pass to gcc to prevent the "DOS" (console) window from popping up along with the Gosu-generated window? I used to know this, and I even tried searching both the forums and the 'Net at large, to no avail...

I would do that, but I had to do so much more than just editing the makefile that I don't think it would be much of an improvement on what is already there (plus, I might have included superfluous things). Also, like I alluded to in my previous post, I don't think the full MSYS2 distribution is necessary to make this work. I believe all one needs are the Mingw native compiler tools and the requisite libraries, but I still have to prove that.

The only thing I found about the pthread error is this: https://github.com/rust-lang/rust/issues/29649

It turns out, this thread was the key! Specifically, this post, which mentions another MinGW installer, and a specific build of MinGW that uses win32 threads.

I installed it, copied the mingw32 folder it created into my main MSYS2 folder (after renaming the existing one, just in case), ran make, found out CC=cc, copied gcc.exe to cc.exe, ran make again, and got a working Tutorial.exe that has a space-ship you can fly around and stars that make noises! Woot! :D

Next step is to try to use just that second installer and do another pair of makefiles that allows one to run make (or possibly mingw32-make) from a standard Windows Cmd shell and end up with a libgosu.a and a Whatever.exe. Then, I can write that up in the relevant section of the wiki, and wait for someone to "improve" something until it breaks again :P

Ah right, the MinGW Makefile precedes the switch from libogg/libvorbis to stb_vorbis.c. We should probably fix this in master too.

Does that also mean I don't need the three Ogg/Vorbis .DLLs when I distribute my games?

BTW, I couldn't get it to work just including stb_vorbis.c (something about certain things being declared static it didn't like *shrug*), but I renamed it to .cpp, and that seemed to work, so... *shrug*

The only thing I found about the pthread error is this: https://github.com/rust-lang/rust/issues/29649

But I'm not sure how that translates to your setup.

Yeah, I found that, too. I'm as unsure as you are about its usefulness... I think I'm going to have to contact the MSYS2 maintainers.

It looks like I have all the (32-bit) thread-related "packages" installed:
$ pacman -Ss | grep '^\w.*hread'
mingw32/mingw-w64-i686-libwinpthread-git 5.0.0.4573.628fdbf-1 (mingw-w64-i686-toolchain) [installed]
mingw32/mingw-w64-i686-winpthreads-git 5.0.0.4573.628fdbf-1 (mingw-w64-i686-toolchain) [installed]
mingw64/mingw-w64-x86_64-libwinpthread-git 5.0.0.4573.628fdbf-1 (mingw-w64-x86_64-toolchain)
mingw64/mingw-w64-x86_64-winpthreads-git 5.0.0.4573.628fdbf-1 (mingw-w64-x86_64-toolchain)
msys/mingw-w64-cross-winpthreads-git 5.0.0.4574.ce1ad45-1 (mingw-w64-cross-toolchain mingw-w64-cross)


I might try to install the 64-bit ones and recompile everything 64-bit, just to see if they're more complete/compatible.

That got us much closer! I knew it would be something n00bish like that -_-''

Here's the output after adding that: http://pastebin.com/cPqw9ZZR

Looks like problems with pthreads and Vorbis. I think I can go from here, but as usual, any advice is appreciated.

EDIT: adding "-lpthread" didn't help... still looking :)

EDIT2: A problem with the Makefile was keeping stb_vorbis.c from being built and included in libgosu.a. The pthread thing is still eluding me, though :/

I've been trying to compile a (C++) Gosu program under MSYS2. I'm following the (out-of-date) "Compiling on Mingw" tutorial (https://github.com/gosu/gosu/wiki/Compiling-in-Windows-using-MinGW).

Surprisingly (given my lack of experience in these things) I was able to modify the instructions enough to build libgosu.a itself (with only a few compiler warnings). I've been attempting to compile the "Tutorial.cpp" that comes with Gosu, and I'm stuck.

I've made my own Makefile. When I run it, I get a lot of "undefined references" as you can see: http://pastebin.com/PUNVMWJg
The compiler also seems to freeze, because I have to press Ctrl+C to get back to a prompt. (Although, I suppose this could be a bug in MSYS2...)
If I comment out "-std=c++11", I get this: http://pastebin.com/QXB2X7HV
Either way, I don't get a nice Tutorial.exe to run.

My hope is that the collective experience of the smart people here can help me get this working, and then we can use this thread to deal with new issues that crop up as the various bits and bobs Gosu relies on are modified (as they invariably and incessantly are) by their respective maintainers.

I love developing with Gosu in Ruby, but I would really like to (someday) build actual games that others might want to play, and distributing Ruby+Gosu games is too troublesome. The performance boost of C++ is another nice perk...

Thanks for reading!

Yes, I suppose it can be considered overkill, but it's a pretty light and fast library, and it would basically give you infinite room to expand, while never worrying about bogging down the collision engine. It's your project, though. Like I said before, it's just another option.
Here's another one (although it doesn't do arbitrary polygons): https://github.com/runnerpack/intersect
It's kind of a WIP, and I have no idea what the performance is like.

If you're going to define clickable polygons, there's also lol_o2's wrapper around Chipmunk. I don't know how the speed, memory footprint, or ease-of-use compares to your ruby-geometry-based solution, but it's another option I figured I'd mention, just in case.

Hi, Forum!

I just made a category for Gosu on Rosettacode.org

I think I got most of the pertinent facts in there, but feel free to add/correct anything (after all, that's what a wiki is for!)

I also added a Ruby/Gosu example to the "Animate a pendulum" page, in case you want to check that out...

Ah, yes... hadn't thought of that. You could include a non-AA mode option for this use case, right?

I assume not, but is there any (efficient) way to let stuff inside the macro know what size its being drawn at, or somehow record a scale-independent version of the line code?

One work-around would be to record everything but the draw_line()s, and then draw the lines scaled up wherever you draw the recorded "image".

Anyway, thanks for taking a look at it.

@jlnr: Have you ever seen this?
https://github.com/tyt2y3/vaserenderer
Or an earlier, basic version:
http://artgrammer.blogspot.com/2011/05/drawing-nearly-perfect-2d-line-segments.html

I suppose they could be implemented in Ruby as an add-on to Gosu, but they'd be faster in the library itself. I wish I had time to do it...

def Level should be class Level

The callback would only be used to check whether closing should be allowed. It could set appropriate flags - so that the "Really quit?" dialog could be shown - then cancel the close. Other logic could then call "Window#close" when the decision to close has been made. Even if "Window#close" also triggers the callback (and I'm not sure it should), you could just set whatever flag the code in the callback checks so that it allows the window to close as normal. That's my take on it, anyway...
BTW, I think the callback should simply be called "closed".

EDIT:

I've thought about it some more. I think it would be more Ruby-ish to call it Window#close?.
Perhaps Gosu could even pass an argument indicating the reason for closing (e.g. the "X" button was clicked, the computer wants to shut down, Window#close was called, etc.).

Testing to see if those keys are both down is as easy as:
@character.move_diagonally if button_down?(KbW) and button_down?(KbD) (and, no, that's not really how you'd do it in actual code, but that's the gist)
But your keyboard also has to support that on a hardware level. For more information, look up "NKRO" and how matrix keyboard decoding works.

I've done some research on physics engines, and most of them treat fast moving objects as lines, rather than points, for collision purposes. I.e., you take the imaginary line segment from the object's last position to its current position, test for the first collision between that line and the rest of your geometry (the floor, in this case), clip the object to that point, and calculate the appropriate collision response.

BTW, I ported some geometry intersection code to Ruby a while back. If it's useful, feel free to use it: https://github.com/runnerpack/intersect (be sure to click the link to the project from which I ported it!)

Another idea would be to simply detect extremely long dt's, and reject them (maybe save the last dt and reuse it for one cycle).

Finally... what about just using full-screen mode? Do you have to use a draggable window?

Great work! I'm not sure how much more functionality a simple double-click test needs, but there is one thing...

While writing my code, I thought a bit about how one would integrate it into Gosu. At first, I assumed a double-click shouldn't trigger either of the constituent single-clicks. However, to do this, you'd have to defer reporting the first click until after the timeout, so you can throw it (and the second click) away if the user completed the double-click. Thinking some more, I decided it wouldn't be worth the trouble to implement, especially considering that wouldn't always be the desired functionality (e.g. when getting single clicks rapidly is the goal, as it often is in mouse-based games). If I'm reading it right, your code throws away the second click, but still triggers the first one immediately. This is probably a good compromise, but still isn't ideal in all cases, and will almost always still have to be worked around, even when you don't care about rapid-fire clicks.

More comments on your code:
1. Why are "MsDoubleLeft" and "...Right" strings? It seems wasteful of memory and CPU cycles. Why not just use symbols like (I think/assume) Gosu does?
2. As jlnr mentioned before, it's better to simply subclass Gosu::Window, rather than "monkey-patching" functionality into it at runtime. If you want to keep your code clean, you can use separate, "require_relative'd" files to break things up for readability.

You're quite welcome.
I knew you could do it, but to make it really robust, you need that distance check (which Gosu makes very easy, as you can see). It's been in MS Windows since the beginning for a reason ;)

If you think about the problem for a while, I'm sure you could come up with your own solution, but I like to solve little programming challenges like this, so I'll share mine.

Detecting that the mouse is over the item of interest is left as an exercise for the reader ;)

You don't really need to do stuff like that pixel-by-pixel with OpenGL or Gosu. They take care of mapping texture pixels to screen pixels for you.

Gosu has "Image#draw_as_quad". Just figure out where the four corners of your image should be in screen space, and send the coordinates to "draw_as_quad".

EDIT: Actually, I just tried this, and there is no perspective correction, so it looks badwrong :P It might depend on the OpenGL implementation, though. It should still be possible to do it using OpenGL directly, or by drawing the image as a number of quads/triangles (i.e. a "triangle fan").

Loading a TileD map in Gosu - or converting it to a picture Gosu can load - is another topic. A forum search will probably turn up some results.

Great work, guys! It was indeed short, but it still requires some skill to beat, and the ending truly is epic!

Download this game NOW! It's worth the (very little) trouble!

+1

In case you haven't noticed yet, it's actually " libsdl2" not " libsd12" (i.e. it's a lowercase "L", not a "one").

This looks very cool, but it gives me an error related to rmagick (on Windows 7) and won't exit cleanly. It works fine, otherwise, though. I don't feel like jumping through the necessary hoops to install rmagick just to get rid of an error message, so some more error checking would be nice, when you get a chance.

EDIT: Actually, all errors now hang Ruby, so that it will not go back to the prompt, or won't close its windows. Not sure if this is caused by Gosu or Ruby. I'll investigate further.

Regarding the shadow-casting:

Have you seen this page? https://github.com/mattdesl/lwjgl-basics/wiki/2D-Pixel-Perfect-Shadows

Quote:

"My technique is inspired by Catalin Zima's dynamic lighting, although the process discussed in this article is rather different and requires far fewer passes."

It has code examples and descriptions that should give you some ideas. It's written in Java using LibGDX, but it shouldn't be too hard to translate.

I noticed the "issue" you created for splitting the shadow stuff into a separate gem, so I thought you might want to just start from scratch using this more efficient system.

PS: I'm making some progress on that multitexturing thing you helped me with :D

Yeah, when I include that, it makes the lines all flickery, and prevents the post_process from even working.
I've had no progress at all, BTW. If I draw solid colors in my shader, I get perfect interlaced lines, but when I try to draw from the texture, it's all blurry like it's using a low-resolution version of the window that's been scaled up and bilinear filtered :/
Image3D is still not drawing at all, but a standard Image loading the same PNG works fine.
I'm out of ideas...

This might be related to the invisible image problem I mentioned above. Do I just put Texture.new.render{} at the top of my Window#draw?

I think you might be on to something! I disabled your buffer workaround, and tried to draw an image using my Image3D class, along with the test lines. The image didn't show up in either 2D or 3D mode (which is odd), but the lines are there in both modes as if the workaround was in place! It's getting late, but I'll do some more testing, tomorrow.

Well, yeah... everything graphical in Gosu is done with OpenGL. I assume that's what allows shaders to work on Gosu graphics.

Also, if it was just that lines didn't work in the post_process block, they should come back when you release Tab, but they don't. That's what makes me think something weird is going on inside Ashton.