Not logged inGosu Forums
Forum back to Help Search Register Login
Up Forum
1 2 3 4 5 Previous Next  
Topic ODROID-GO By RunnerPack Date 2018-09-22 02:14
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:
Topic ODROID-GO By RunnerPack Date 2018-07-01 00:00
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:
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:

I've also looked around for a development environment. This looks like a good one:

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:

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!)
Topic bg_utils - a small extending library around Gosu By RunnerPack Date 2018-06-16 15:35
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.
Topic Discord for Gosu users ! By RunnerPack Date 2018-04-10 23:47
It didn't work for me. I got an "invalid invite" message.
Topic bullets are not created right in the middle of the ship By RunnerPack Date 2018-01-05 22:27
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.)
Topic undefined method 'draw_rect' By RunnerPack Date 2017-11-24 02:55
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:
Topic Gosu::Grid, passing draw an array By RunnerPack Date 2017-08-25 00:51
(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?

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?
Topic Two gamepad buttons at once? By RunnerPack Date 2017-05-25 03:13
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)).
Topic The "Vulkan" Thread By RunnerPack Date 2017-02-02 01:53
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).
Topic Gosu 0.11.1 released By RunnerPack Date 2017-02-02 01:45
+1 for fixing/integrating Ashton (or fragment shaders in some form).
Topic Gosu 0.11.1 released By RunnerPack Date 2017-02-01 03:03
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...
Topic Gosu 0.11.1 released By RunnerPack Date 2017-01-29 16:20
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:
  RUBY_VERSION =~ /(\d+.\d+)/
  require "opengl/#{$1}/opengl"
rescue LoadError
  require 'opengl/opengl'

At first, I thought it was failing because I'm running 2.3.3 (from, 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/" 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?
Topic What's the best way to patch in new "draw_foo" methods? By RunnerPack Date 2017-01-16 22:33
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!
Topic What's the best way to patch in new "draw_foo" methods? By RunnerPack Date 2017-01-16 03:20
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.


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?
Topic What's the best way to patch in new "draw_foo" methods? By RunnerPack Date 2017-01-16 01:30
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!
Topic Nvidia 3D Vision By RunnerPack Date 2016-09-20 00:12
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.
Topic Simple card memory game demo By RunnerPack Date 2016-08-01 01:04
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).
Topic Simple card memory game demo By RunnerPack Date 2016-07-31 16:02
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.
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-04-11 22:30
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?
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-04-04 00:56
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?
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-03-27 19:35
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
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-03-27 15:48
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...
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-03-25 00:03
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.
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-03-24 02:55
The only thing I found about the pthread error is this:

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
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-03-20 01:17
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:

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 (mingw-w64-i686-toolchain) [installed]
mingw32/mingw-w64-i686-winpthreads-git (mingw-w64-i686-toolchain) [installed]
mingw64/mingw-w64-x86_64-libwinpthread-git (mingw-w64-x86_64-toolchain)
mingw64/mingw-w64-x86_64-winpthreads-git (mingw-w64-x86_64-toolchain)
msys/mingw-w64-cross-winpthreads-git (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.
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-03-19 20:39
That got us much closer! I knew it would be something n00bish like that -_-''

Here's the output after adding that:

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 :/
Topic Getting (& Keeping) libgosu & C++ Games Compiling in MSYS2 By RunnerPack Date 2016-03-19 01:51
I've been trying to compile a (C++) Gosu program under MSYS2. I'm following the (out-of-date) "Compiling on Mingw" tutorial (

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:
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:
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!
Topic How get the id of clicked sprite By RunnerPack Date 2016-02-14 17:56
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):
It's kind of a WIP, and I have no idea what the performance is like.
Topic How get the id of clicked sprite By RunnerPack Date 2016-02-10 02:42
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.
Topic By RunnerPack Date 2016-02-03 02:26
Hi, Forum!

I just made a category for Gosu on

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...
Topic Gosu #draw_line bug? By RunnerPack Date 2016-01-26 00:57
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.
Topic Gosu #draw_line bug? By RunnerPack Date 2016-01-25 00:38
@jlnr: Have you ever seen this?
Or an earlier, basic version:

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...
Topic drawing tiles with Gosu... HELP By RunnerPack Date 2015-12-15 21:54
def Level should be class Level
Topic a Callback method when the user exits ? By RunnerPack Date 2015-12-11 02:12
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".


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.).
Topic More than 1 key simultaneously down? By RunnerPack Date 2015-12-05 02:52
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.
Topic Problem with Delta-Time Physics in a windowed Gosu (Ruby) By RunnerPack Date 2015-10-15 00:31
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: (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?
Topic Some Gosu requests By RunnerPack Date 2015-09-24 03:26
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.
Topic Some Gosu requests By RunnerPack Date 2015-09-20 15:13
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 ;)
Topic Some Gosu requests By RunnerPack Date 2015-09-20 00:30
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 ;)
Attachment: GosuRubyDoubleClick.7z - Sample code to detect double-clicks in Ruby (7k)
Topic Giving tiled maps perspective? By RunnerPack Date 2015-09-05 19:41
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.
Topic Chinguroids -- Asteroids Remake with Epic Ending By RunnerPack Date 2015-08-15 01:14
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!
Topic a Callback method when the user exits ? By RunnerPack Date 2015-08-01 00:40
Topic Ubuntu 14.04 quick start By RunnerPack Date 2015-07-15 01:15
In case you haven't noticed yet, it's actually " libsdl2" not " libsd12" (i.e. it's a lowercase "L", not a "one").
Topic Gosu Examples 1.0.3 released By RunnerPack Date 2015-05-17 02:15
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.
Topic Ashton - shaders and framebuffers in Ruby By RunnerPack Date 2015-03-19 04:23
Regarding the shadow-casting:

Have you seen this page?


"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
Topic Ashton causes window to go blank By RunnerPack Date 2015-03-11 20:13
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...
Topic Ashton causes window to go blank By RunnerPack Date 2015-03-11 05:26
This might be related to the invisible image problem I mentioned above. Do I just put{} at the top of my Window#draw?
Topic Ashton causes window to go blank By RunnerPack Date 2015-03-11 05:24
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.
Topic Ashton causes window to go blank By RunnerPack Date 2015-03-09 23:24
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.
Topic Ashton causes window to go blank By RunnerPack Date 2015-03-09 19:54
Wow, that's pretty cool! Actually, I've been looking for a way to make stereo "sprites" that can be rotated (which you obviously can't do with just a stereo pair), and this might be a good idea to try. Thanks for bringing it to my attention.

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill