Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Forum
1 2 3 4 5 6 7 8 9 10 Previous Next  
Search
Topic Gosu and Ruby 2.4 on Windows - cannot load gosu.so By jlnr Date 2017-06-20 10:22
Gosu 0.12.1 works with Ruby 2.4. \o/
Topic Gosu 0.12.1 released By jlnr Date 2017-06-19 21:34
A minor maintenance release for Windows users:

• Windows: Add support for Ruby 2.4 (#407)
• Windows: Fix MP3 playback on 32-bit systems (#405)

C++ and Mac/Linux users have no need to upgrade.
Topic Gosu and Ruby 2.4 on Windows - cannot load gosu.so By jlnr Date 2017-05-31 19:09
This one's easy: Gosu does not support Ruby 2.4 on Windows yet, mostly because I didn't realise it has been released already. So thanks for pointing that out :)

I'll try to add Ruby 2.4 support ASAP, in the meantime, please downgrade to Ruby 2.3.
Topic Raspberry Pi music touchscreen By jlnr Date 2017-05-26 10:42
(Took me forever to get back to this post in my reading queue...)

That was really great timing with the MP3 patents expiring just in time for this project ;)

I didn't think it was possible to overheat the Pi though. Is it really the temperature? I've noticed flakiness on my Pi when I use a USB port that doesn't provide enough power. Has it worked OK in the long term?
Topic Create a Gosu::Image from clipboard By jlnr Date 2017-04-30 08:02
There is a Image.from_blob: You can pass an RMagick image instead of a filename to all Window constructors (also load_tiles etc.)

It doesn't really have to be an RMagick image, but it needs to respond to columns (width), rows (height) and to_blob (return RGBA data as a String). The problem is that you would still need to extract the width and height from the binary DIB image, and convert the RGB DIB data to RGBA.

If this is just for use during development, then I think saving the bitmap information to a temporary file and loading it back isn't such a bad option. It should be too fast to notice?
Topic Create a Gosu::Image from clipboard By jlnr Date 2017-04-27 19:21
Hah, interesting suggestion. There's no GitHub ticket for it yet, but I feel that clipboard support is definitely missing from Gosu's text editing.

My plan so far was this:
Gosu.clipboard returns the copied text or filename, or nil if the user hasn't copied anything useful. Games can just listen for ctrl+V/cmd+V and implement pasting of image files using the filenames. (Gosu::TextInput should have built-in copy & paste, though.) Writing to Gosu.clipboard= would allow for copying of arbitrary text.

I didn't even think of copying/pasting image data, though. Makes me wonder if a future Gosu.clipboard should be able to read/write Gosu::Image instances as well. Or maybe you could call it like this, image = Gosu.clipboard { |imgdata| Image.new(imgdata, tileable: true) } if you are interested in image data, and without a block if you are interested in text.

What is the use case for pasting image data in a Gosu game? To quickly iterate on your game's assets? Maybe this hack will do the trick - pressing R in the window will cause all images to be reloaded from disk: https://github.com/jlnr/Trikus/blob/master/src/debug/image_reloading.rb
Topic Gosu 0.12.0 released By jlnr Date 2017-04-27 17:58
The limit is actually 1024x1024 with tileable: true, and 1022x1022 with tileable: false (because one row of empty pixels will be added at each side). I am just too lazy to type all of that every time :)

I was a bit worried that Drag & Drop might be unusual for a game framework, so it's great to hear that you enjoy the feature :) I'm looking forward to use it as well.
Topic Gosu 0.12.0 released By jlnr Date 2017-04-23 20:51
This version is mostly aimed at making Gosu less surprising - for example, MP3 files already worked on macOS and iOS, but not on Windows or Linux.

I've increased the minor version number because Gosu has a new dependency on Linux (libmpg123-dev).

* 2017-04-23: All: Image#subimage works for images larger than 1022x1022px (#398/#400).
* 2017-04-23: Windows, Linux: Support for MP3 files (#397).
* 2017-04-22: C++: Use std::function parameters instead of begin/end function pairs (#399).
* 2017-04-04: Raspberry Pi: Use correct OpenGL version on Pi 2 & 3.
* 2017-03-29: All: Add Window#drop(filename) callback for when the user drops a file onto the window (#378/#382). Thanks @Kjarrigan!
* 2017-03-27: All: Fix an inconsistency in Color#from_hsv (#359).
Topic Problem Installing Gosu on Raspberry Pi By jlnr Date 2017-04-05 19:59
It turns out that getting Gosu to work on the Pi 2 and 3 is much easier than on the original Pi. Basically, just enable OpenGL and then install Gosu as you would on a normal Linux distro (but be sure to sudo gem install gosu --pre until 0.11.4 is out).

https://github.com/gosu/gosu/wiki/Getting-Started-on-Raspbian-(Raspberry-Pi)

Probably too late, but maybe it'll be helpful for the next person looking into this.
Topic Gosu 0.11.3 [and 0.11.3.1] released By jlnr Date 2017-03-26 21:49
Oops. I've had to push 0.11.3.1 to hotfix an issue with legacy button constants on Ruby.
Topic Gosu 0.11.3 [and 0.11.3.1] released By jlnr Date 2017-03-26 11:17
Some fixes, but also a new feature: Gosu::Window instances can avoid being closed immediately by overriding close. For example, you might want to ask the user if they want to save their current game before exiting.

• Ruby: Add deprecation warnings for many old methods (thanks @Kjarrigan)
• Windows: Fix an encoding issue when the current user has a non-ASCII username
• Windows: TTF files can be loaded using relative paths
• All: Window#close can be overridden to prevent the user from closing the window immediately; call close! to immediately close the Window in Ruby (thanks @Kjarrigan)
• macOS: Fix TTF font file loading
• All: Image#subimage is now part of Gosu's official API
Topic Gosu::Image.subimage and performance By jlnr Date 2017-03-12 16:33
I've removed the comment about it being experimental 🎉 It's now a proper part of Gosu.

A note on your gist: The image does not have to be a power-of-two for subimage to work. Gosu will copy the image to a 1024x1024px texture and use the remaining space for other textures.

But the image must not be larger than 1024x1024px. Beyond that, Gosu will split it up into several 1024x1024px textures automatically, and then subimage will stop working. (This is actually a limitation that I could work around. Hmm. Maybe in a future version...) You could add a check for that in the constructor to prevent surprises.
Topic Gosu::Image.subimage and performance By jlnr Date 2017-03-02 16:40
Good news: Image#subimage is extremely fast. So fast that you could recreate the subimages every tick, draw them once, and then discard them.

The difference between Image#subimage and loading an image via the constructor is that the latter will add padding around the image when copying it to an OpenGL texture. Those pixels will either be translucent (default) or repeat the outermost colour values (tileable: true). That ensures that the image looks good when scaling, rotating etc.

With subimage, it is your responsibility to make sure the images have some padding. (If you use retro: true, this doesn't matter.)

If you are worried about performance, you can just pre-process the tile sheets with RMagick or another image library, and then either use load_tiles or subimage depending on what suits you better.

By the way: All of the image constructors (including Image.load_tiles) dynamically build a tile atlas on 1024x1024px GL textures. You can observe whether images end up on the same texture internally by comparing image.gl_tex_info.tex_name.
Topic Gosu 0.11.1 released By jlnr Date 2017-02-26 10:55
Thanks :) I've just release version 0.11.2 to fix the issue.
Topic Gosu 0.11.2 released By jlnr Date 2017-02-26 10:50
This is a belated hotfix release for some issues introduced in Gosu 0.11.x:

• Ruby: Arguments are automatically converted to String everywhere
• Ruby: Fix name of mouse position setters
• All: Reset current colour to solid white before running GL blocks
• Ruby: Fix handling of exceptions in Window#needs_redraw? (#376)
Topic StickBall how to correct alpha with current Gosu version? By jlnr Date 2017-02-26 10:47
Sorry for the long delay, I have been travelling. You have probably tried to change a predefined colour:

color = Gosu::Color::RED
color.alpha = 5


Gosu prevents changes to colour constants, but this is not documented and the error message is pretty misleading. The correct way to fix this is:

color = Gosu::Color::RED.dup
color.alpha = 5
Topic Gosu 0.11.1 released By jlnr Date 2017-02-11 13:43
Ouch! They might have disappeared when I renamed the C++ equivalents. I'll investigate in the next weeks, life is busy right now :)
Topic The "Vulkan" Thread By jlnr Date 2017-02-06 14:33
I think better support for OpenGL ES is the lower-hanging fruit; a few #ifdefs here and there, and Gosu would work on every system which either supports OpenGL or OpenGL ES, which seems to cover almost everything. Right now, Gosu already uses OpenGL ES 1.x on iOS and on the Raspberry Pi, and full OpenGL everywhere else.
Topic RubyConf 2016 talk By jlnr Date 2017-02-06 12:57
Hah. Glad you enjoyed it :) I had a lot of fun collecting these videos - I hadn't even heard of most presentations before.
Topic Ruby Chipmunk Integration beginner hacking gosu-example By jlnr Date 2017-02-01 06:44
Thanks for reporting back. I've linked the PhilCK/Chipmunk-Examples repo from the Ruby-Chipmunk-Integration wiki page, so helpfully it will be easier to find for the next developer.
Topic Gosu 0.11.1 released By jlnr Date 2017-02-01 06:25
Ashton now lives in the Gosu organisation on GitHub, so it's something I can and will fix at some point (possibly by moving functionality into Gosu proper).

ocra is another gem that seems to be mostly dormant, and which Gosu relies on...

But it's good news that Ruby 1.9.3 is still around, and I'll take extra care not to break compatibility with Ruby 1.9.x. (It seems safe to kick out Ruby 1.8 support, though.)
Topic Gosu 0.11.1 released By jlnr Date 2017-01-30 12:30
np!

> because I assume that in a clean brand new environment, it is by default set to white


I was thinking about that too after posting my reply. gl blocks are supposed to give you a clean environment, so I think that was a bug (or at least unintuitive). Gosu 0.11.2+ will automatically reset the colour before running a gl block; not sure when that version will be out, though.
Topic Gosu 0.11.1 released By jlnr Date 2017-01-30 02:22
Well, the good news is, the texture is definitely not being purged. You can check by calling @texture.save("test.png"), which will use OpenGL internally to download the texture data before saving it to a file.

And I just managed to find the bug. When you use fullscreen mode, Gosu uses black bars to preserve the window's aspect ratio. Since you do not reset it, all vertices will appear black as well. It works if you add glColor4f(1, 1, 1, 1) in CubeModel#draw.

Yay, no Gosu bug :) - which is great because I won't have time for a release in February.
Topic Gosu 0.11.1 released By jlnr Date 2017-01-30 02:16
=( I wasn't even aware that Ruby on Windows was so broken until I tried to run gosu-examples with Ruby 2.3 last week. I couldn't get OpenGL to install, and Chipmunk was extremely crashy. I wonder if it'll get worse now that Rails developers can use the Ubuntu subsystem on Windows 10 instead of Ruby-Installer.
Topic Gosu 0.11.1 released By jlnr Date 2017-01-28 05:56
As for the shortcut: Your game needs to call super when overriding Window#button_down(id). The base implementation of button_down(id) is where the magic happens: https://github.com/gosu/gosu/blob/master/src/Window.cpp#L279-L303

Do you load your textures with custom OpenGL? Do pure Gosu games also have problems with textures on your machine? For example: Does gem install gosu-examples and then gosu-examples or gosu-examples --fullscreen work?

The way I'm using fullscreen mode with SDL 2 should not affect OpenGL textures, so I still have hope that I can avoid refactoring my OpenGL context management.
Topic Gosu 0.11.1 released By jlnr Date 2017-01-23 10:29
Ouch. It worked fine for me in a VM (also Windows 7, 64-bit). I think what's happening is that the OpenGL context gets destroyed when changing between fullscreen and windowed modes:

http://www.bytehazard.com/articles/sdlres.html

In Gosu 0.11.1, every window is created as windowed first, and then goes into fullscreen mode. (This is a workaround for a window placement bug.) That's why windows that start in fullscreen mode are also broken.

Not sure if I can fix this in the next days, but I'll try to reserve a day on the weekend.
Topic Using Window#needs_redraw? By jlnr Date 2017-01-20 17:43
No worries, I just wanted to report back on this bug while I was fixing it (the error message will be correct in Gosh 0.11.2). Good luck with your custom OpenGL engine, that's how Gosu started too :)
Topic Using Window#needs_redraw? By jlnr Date 2017-01-20 15:20
Some late feedback on the needs_redraw? method: it's not actually broken, the error message is just extremely misleading.

What is happening is that if an exception is raised in needs_redraw? (e.g. typo in a method name), then this exception will be swallowed by a safety mechanism inside Gosu, and SWIG will print the wrong error message.
Topic Gosu 0.11.1 released By jlnr Date 2017-01-18 02:52
A hotfix release for some regressions in Gosu 0.11.0:

• Window: Fix UTF-8 Text rendering (#373)
• All: Fix loading of 4-bit PNG files (#375)
• All: Fix window placement when starting in fullscreen mode and then switching to windowed (#369)
• All: Add default shortcuts to toggle between fullscreen and windowed mode (alt+enter/cmd+F) (#361)
• Linux: Fix compilation of Color.cpp (#371)

Links to GitHub issues and precompiled libraries for MSVC: https://github.com/gosu/gosu/releases/tag/v0.11.1
Topic Using Window#needs_redraw? By jlnr Date 2017-01-17 04:38
Hmm. Then I'm out of ideas, sorry. This structure will likely crash sooner or later because it calls record and Image.new on a background thread, which is not supported by Gosu (yet?). Specifically, Window#draw and record cannot run in parallel right now, they use the same internal data structure.
Topic Using Window#needs_redraw? By jlnr Date 2017-01-16 15:13
Hmm. Why is it laggy? The interlocked threads shouldn't introduce more than 16ms of delay in the worst case.
If I remove the sleep calls, it runs at 30 FPS, and it'd run at 60 FPS with more careful scheduling of the draw/update blocks, but of course that depends on the game's actual code.

I want to support render-to-image in Gosu (without Ashton) at some point, but that's not something that'll happen in the next months, I'm afraid: https://github.com/gosu/gosu/issues/317

If the only problem with record {} is that it doesn't work with clip_to, can you maybe record several macros and remember with which clip rect the macros need to be rendered?
Topic Using Window#needs_redraw? By jlnr Date 2017-01-16 07:20
Or, you can keep Gosu::Window running in parallel to your thread, and only interlock when you need to run something on the main thread (create images, read a value from button_down? etc.), and when you want to redraw the screen.

https://gist.github.com/jlnr/89953f1199080ccaa5bd8fe6d66ea188

It relies on needs_redraw?, which mysteriously works on my computer but I'm using a dev version of Gosu, so maybe it'll be broken for you until 0.11.1 is out. But does that seem like a good workaround?

Feels like a hack, but was fun to write - I don't usually use Ruby's threading API :)
Topic Using Window#needs_redraw? By jlnr Date 2017-01-16 06:52
#render_to_image would only help you if you could use it on a background thread, which I don't think Ashton allows.

Can you somehow run the expensive MiniMagick file conversions when you build your game, so that it will start fast enough to not appear stuck?
Topic What's the best way to patch in new "draw_foo" methods? By jlnr Date 2017-01-16 06:36
Ah, I see. draw_quad originally was (and still is) an instance method of Gosu::Window, which is why you can call it without Gosu:: or Gosu. inside of your window subclass, but only there.

The fact that everything had to be called on a Gosu::Window instance made it necessary to pass around references to the window everywhere (same thing with the old Image constructors etc.), which was so annoying that many games used a global $window variable instead. So in Gosu 0.9, I've moved all the draw_ methods into module Gosu, along with button_down?.

There are technically two draw_quad methods now, one on Gosu::Window and one in Gosu itself. If you want draw_circle to have the same behaviour, you'll need to implement it twice as well. The method in Gosu::Window would just forward all arguments to the module.

It's a bit of a mess. I was about to deprecate the instance methods on Gosu::Window in favour of Gosu.draw_xxx, but I'm afraid that'll make things even more confusing when someone uses include Gosu.

Related comment on the pull request that'll bring deprecations to Gosu 0.11.1 - https://github.com/gosu/gosu/pull/370#issuecomment-272708027
Topic Using Window#needs_redraw? By jlnr Date 2017-01-16 02:50
Usually tick is used like this from within Window#show:

def show # pseudo-implementation
  while tick
    sleep 0.016
  end
  # stops when tick returns false
end


When tick returns false the game should end, because either Window#close was called, or the user clicked the [x] in the window corner.

If you just keep calling tick, the window will re-appear.

What do you mean by "crashes"? Is there an error? It's hard to understand if the structure works for you because I don't know what happens in # ... Do something :)
Topic What's the best way to patch in new "draw_foo" methods? By jlnr Date 2017-01-16 02:44
I think the trick you are missing is to def self.x instead of def x:

module Gosu
  def self.draw_circle
    ... draw_quad(...) ...
  end
end
Topic Using Window#needs_redraw? By jlnr Date 2017-01-15 14:50
I see how that could work with record, but not without it. You cannot draw outside of Window#draw, and you can only create Gosu resources (Image etc.) on the main thread currently.

I think there's a better solution actually, it's a bit experimental but I added it exactly for this use case: Window#tick

Basically, your game would become:

class Game < Gosu::Window
  def draw
    # drawing needs to happen here, but maybe you can call into another function...
  end
end

game = Game.new(...)

while true
  # ... Do something
  game.tick # this will call Window#update and Window#draw
  break if # ...
end
Topic Using Window#needs_redraw? By jlnr Date 2017-01-15 10:08
You are right, it seems that needs_redraw? is currently broken. Oops! I've opened a ticket here: https://github.com/gosu/gosu/issues/376

What is your use case? In general, everything that involves a Thread is usually a bad idea with Ruby/Gosu, unless you use it purely for game logic. The needs_redraw? method doesn't guarantee that draw will not be called (even though it does that in recent versions of Gosu), it's just an optimisation hint.
Topic Gosu and ChunkyPNG/MiniMagick: Blob length mismatch By jlnr Date 2017-01-12 06:41
Hm, not sure what MiniMagick::Image#to_blob is good for, it just seems to read a file (expand the source code): http://www.rubydoc.info/github/minimagick/minimagick/MiniMagick%2FImage%3Ato_blob

MiniMagick has an import_pixels method that can import a "blob" (as defined by Gosu), but I can't find the other direction.

This StackOverflow answer also doesn't lead anywhere: http://stackoverflow.com/questions/7152362/return-array-of-pixel-values-using-ruby-and-mini-magick-or-rmagick

It's probably easier to read the image from disk with Gosu.
Topic Gosu and ChunkyPNG/MiniMagick: Blob length mismatch By jlnr Date 2017-01-12 06:32
Gosu expects raw RGBA pixel data in the string, and Canvas#to_blob returns compressed data. The return value of to_blob has to have a length of either columns * rows * 4 or columns * rows * 16 (the latter is rare, when float RGBA values).

Looking at the ChunkyPNG docs, I think to_rgba_stream returns something that can be used with Gosu. In that case, you should probably create a wrapper for ChunkyPNG::Canvas instead of monkey-patching Canvas and changing the names. Example (untested):

module ChunkyPNG
  class Canvas
    GosuWrapper = Struct.new(:columns, :rows, :to_blob)
    def to_gosu
      GosuWrapper.new(@width, @height, to_rgba_stream)
    end
  end
end
...
Gosu::Image.new(my_canvas.to_gosu)


Does that work?
Topic Gosu 0.11.0 released By jlnr Date 2017-01-06 16:42
Internally, this is a huge release. The C++ codebase has been completely modernised.

In Ruby/Gosu, the only noticeable change is that it is now possible to resize the window at runtime, and to switch between fullscreen and windowed mode.

If this release turns out to be relatively stable, then I'll build a new Ruby.app for macOS, and Gosu 1.0.0 will be the next step. Everything that is missing is a little refactoring of the text rendering: https://github.com/gosu/gosu/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0

• Windows: This releases bundles SDL 2.0.5, users on other operating systems should update this library through their package manager
• All: Rename GOSU_COPYRIGHT_NOTICE to Gosu::LICENSES, its content is now platform-specific (thanks @Kjarrigan)
• C++: Use UTF-8 encoded std::string instead of std::wstring throughout Gosu (breaking change)
• C++: Use snake_case for function and method names, just like in Ruby (breaking change)
• All: Window::resize (C++), new setters: Window#width=/#height=/fullscreen= (Ruby); thanks to @Dahrkael for the initial resize implementation
• All: New setter Window#update_interval=
Topic Need Help Actually Releasing a Game By jlnr Date 2016-12-12 14:44
This is the canonical macOS wrapper for Ruby/Gosu code: https://github.com/gosu/ruby-app

Moving code into Ruby.app should work just fine on Linux, as long as you are careful not to lose the executable bit on Ruby.app/Contents/MacOS/Ruby (which can happen if you create a ZIP archive). Just move your code in there, edit Info.plist, create a tarball and mail it to your Mac friends. They'll probably have to right-click and then 'Open' it because the .app isn't code-signed.

Ocra is the most common solution for Windows, but Releasy has another solution that is supposed to work from Linux:

https://github.com/Spooner/releasy/blob/master/lib/releasy/windows_wrapper_maker.rb

As far as I can tell, it bundles your game with the contents of a RubyInstaller package, and then creates a tiny EXE stub that runs rubyw.exe <your_game.rb>? You could give it a try - even though Releasy's README is outdated, that part of the code might still work with the current version of everything.
Topic New experimental subreddit By jlnr Date 2016-12-11 20:42
Fixed Emoji. ??
Topic New experimental subreddit By jlnr Date 2016-12-10 00:02
Hey everyone. There's an experimental subreddit for Gosu now:

https://www.reddit.com/r/gosu/

I've also linked it from the libgosu.org sidebar and put a big, red badge next to it.

If you like the current board (I do…), don't worry. Its contents aren't going anywhere, and I'll keep fixing little things (Emoji should work after I update to a better MySQL Unicode encoding).

But given that the mwForum software is not being actively developed anymore, I wanted to find out whether there are any redditors among us, and maybe a subreddit will turn out to be more accessible than this oldschool Perl/CGI board.

Let me know your thoughts, here or there :)
Topic We're on Homebrew! By jlnr Date 2016-11-29 20:10
Awesome! Thanks.

Funny coincidence, SDL 2.0.5 was my first contribution to Homebrew just recently. Have you done any research into how to keep the formula up-to-date automatically? Not that I'm releasing a lot recently...

Feel free to edit the Getting Started page before I get to it :) It should probably come before CocoaPods, since all Gosu users on macOS are bound to use Homebrew already for sdl2.

I've been working on the Gosu front page itself for the last couple of evenings. I want to have one separate page for the introduction, Ruby, C++ and iOS each. Mixing Ruby and C++ content on the same page is always so confusing... I'll add a note there too.
Topic We're on Homebrew! By jlnr Date 2016-11-29 20:00
Yeah, I've also found out about that the hard way (truncated post). I guess it is an issue with Unicode support in my MySQL table. A friend has helped me snatch the Gosu subreddit so that's something I might try to replace this forum with in the very, very long term. (The mwForum software has been discontinued.)
Topic How does the Map Class in Captain Ruby work? By jlnr Date 2016-11-16 23:21
Using .times is shorter than the for ... in loop, but I have to agree it's hard to read. Glad that you asked about it, I'll make a note to change it :)
Topic Little Raycaster I Made :) By jlnr Date 2016-11-07 09:07
subimage only uses one or two object allocations, and yes, it only references the texture data.

Looking at the C++ source again, I think that you also render walls line by line, right (vertically)? Then Rubystein probably uses the same logic as your raycaster, except they didn't even bother colouring the floor and ceiling - that's why it's fast enough in Ruby.

The old Gosu Showcase board has a screenshot: https://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=557

I don't think that the interop between Ruby and C++ is the issue, after all many core Ruby methods (Array#each etc.) are written in C. It's probably the loop itself that's excruciatingly slow in Ruby.
Topic Little Raycaster I Made :) By jlnr Date 2016-11-06 10:57
Cool stuff! I like your fearless use of calling .subimage() just to create temporary image slices! I've never thought about that before, but performance-wise that's perfectly fine.

Are you aware of this ancient Ruby/Gosu raycaster? https://github.com/zenkalia/rubystein
It was originally written by the Phusion team as a parody of the Rails dev world (lots of in-jokes). To avoid setPixel they used the Wolf3D approach to draw vertical lines. So not W*H setPixel() calls, but W Image#draw calls.

I guess the next step would be a voxel engine :P
Topic Sector Five from Learning Game Programming w/Ruby By jlnr Date 2016-10-30 22:08
def draw needs to be inside the body of class SectorFive to override the empty method "draw" in the Gosu::Window base class:

class SectorFive < Gosu::Window

  ..
  def draw
    ..
  end
end


You have defined a global method called draw, which is never called by anybody.

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill