Forum
Gosu 0.12.1 works with Ruby 2.4. \o/
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.
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.
(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?
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?
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
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.
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).
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.
Oops. I've had to push 0.11.3.1 to hotfix an issue with legacy button constants on Ruby.
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
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.
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
.
Thanks :) I've just release version 0.11.2 to fix the issue.
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)
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
Ouch! They might have disappeared when I renamed the C++ equivalents. I'll investigate in the next weeks, life is busy right now :)
I think
better support for OpenGL ES is the lower-hanging fruit; a few
#ifdef
s 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.
Hah. Glad you enjoyed it :) I had a lot of fun collecting these videos - I hadn't even heard of most presentations before.
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.
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.)
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.
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.
=( 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.
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-L303Do 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.
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.htmlIn 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.
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 :)
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.
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
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.
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/317If 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?
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/89953f1199080ccaa5bd8fe6d66ea188It 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 :)
#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?
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
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
:)
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
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
You are right, it seems that
needs_redraw?
is currently broken. Oops! I've opened a ticket here:
https://github.com/gosu/gosu/issues/376What 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.
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?
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=
This is the canonical macOS wrapper for Ruby/Gosu code:
https://github.com/gosu/ruby-appMoving 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.rbAs 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.
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 :)
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.
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.)
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 :)
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=557I 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.
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/rubysteinIt 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
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