Forum
Which error? The method _release_all_openal_resources was introduced to fix the existing error and I thought it worked… :(
I think that is exactly what Rubystein is doing (or was doing - it seems only there are only forks left on github).
I think using Spooner's Ashton library and applying a full-screen effect is the way to go. :)
The media loader is not bad because it preloads everything, unlike most helpers which load images and sounds on demand, introducing lag during gameplay. But I think Chingu's Image['name'] syntax is still a little neater. :)
The Ruby style could be a little more idiomatic, e.g. inverse_bool seems to be just the !/not operator in disguise?
Yep, same on OS X. Gosu would work just fine with Ruby 2.0 if I had a way to compile it for Windows. C extensions on Windows are a mess, sadly, with the relatively recent transition to MinGW & the new DevKit.
...and you need Ruby 1.9 & the xml-simple gem :)
There are always many fun ways to implement visual effects... :) You can also create the white image once using TexPlay or even pure Gosu:
http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=6425And then overlay the white image over the original with a changing alpha value (or the other way around). However the Ashton solution should handle semi-transparent pixels a lot more nicely.
There was an attempt at porting Gosu in the very, very early days of the Pi:
http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=5638From what I remember this continued on IRC and the biggest obstacle was in fact Gosu's dependency on X11 (or alternatively Win32/Apple APIs).
There was a snippet of code on github that demonstrated how to open an OpenGL ES context using a proprietary, binary driver, but the snippet itself had no license attached so I kept my hands off it.
Do you know how other libraries handle it? If there is a way to open an OpenGL ES context, then most of Gosu should immediately work. Font rendering, audio, input are the next step then.
I am also not sure if I can help much without owning one myself :) I only have a little zoo of mobile devices for general OpenGL ES development.
I would not offer the method pos, as it is tempting to write @gracz.pos.x = 5 which will not work (it only replaces the first element in a temporary array).
Not that my Ruby style is anywhere close to what's hip now - I still love then :)
There is no definitive list of concepts :) If you want to write a jigsaw puzzle game, the code will look completely different from a Super Mario clone. Gosu makes almost no assumptions about what you want to do.
I would suggest that you download a few smaller games from the Showcase and mod them a little, and get a feeling for which code style you prefer.
There was (is?) a bug in Gosu where an exception thrown in draw or other callbacks would be silently swallowed. Please try adding a begin … rescue … end block around your method implementations, and let me know if this problem still exists.
Would rotated sprites with FSAA look any different than they do now? I would expect that only a higher image resolution helps with that :)
I have a personal To Do item for FSAA support in Gosu. If you are interested in seeing it advance, I recommend filing a github ticket with more information :) Most Gosu games would not benefit too much because they only use images.
As a workaround, you can use images to replace draw_line, which I recommend anyway. Driver support can be an issue, and on the new Retina Macs they will look anaemic because of the doubled resolution. :)
I doubt it. I gave up on -d for similar reasons - third-party is often written without -d in mind and there's no way to disable all the warnings that result from it.
Are you using ruby -d? Do you get the same error for other gems too? Maybe an exception is being raised and caught internally when Rubygems loads something.
Ouch. I don't know much about Ashton's internals, but dragonheart's problems and the 5 FPS thing sound like OpenGL issues to me - I used to have a Linux test box where rendering to textures would sometimes freeze for a long time.
I think the way to fix this in the long term would be not to use OpenGL for collisions, but I don't know a good replacement in Ruby either.
The current Mac .app wrapper has a bug that's easy to work around:
Its main binary is three-way universal (Intel 64-bit, 32-bit, PowerPC). But the standard library (or parts of it) are missing the 64-bit component, leading to a crash if you require 'yaml'.
To discard the 64-bit core and make it a 32-bit app, you can use the following command on the terminal:
lipo -remove x86_64 PATH_TO_YOUR_APP_HERE/Contents/MacOS/RubyGosu\ App -output PATH_TO_YOUR_APP_HERE/Contents/MacOS/RubyGosu\ App
This will be fixed in the next Gosu release.
How do you use Ashton for collisions? Does it use OpenGL textures for that / is there a chance that it is driver related after all?
Re 5 FPS: Do other OpenGL games work fine? This sounds like a Gosu or Ashton bug! Feel free to open a new topic / thread for this.
I know what you mean though, now that every Ludum Dare has ~1000 entries, it feels like there are more players than games. I wish Gosu would work on the Mac App Store or Ouya or something like that :/ And sadly enough, OpenGL & OpenAL still cause driver issues in 2013.
It's how collaborative development on github works — user A uploads their code, user B forks their code (=creates their own copy), user B makes changes, user B sends a request to user A to incorporate these changes.
Well, it does really look like a code bug :) I can't imagine how the Windows version would affect a bounding box calculation in such a specific way. The only thing that I guess can be slightly different across Windows versions is image loading, because GDI+ was relatively new in XP I think. But the solid areas are probably not loaded from an image?
I'm building iOS apps all day nowadays, and they're all chock-full of analytics to report errors, checkpoints etc., I guess Gosu games should do the same :) Or at least they might have a "bug" button that emails everything to the dev as a YAML file... Anyway, your best bet is probably to add debugging helpers and send it to this Mr dragonheart91.
Gosu has stopped supporting Windows 9x a long time ago. You would have to compile your own version and link against the Unicows support layer to get it to run.
All these frameworks are in /System/Library/Frameworks unless you have massively broken your installation of OS X :)
I don't know why a compiler wouldn't find them by default. Are you using Xcode or another compiler package?
In any case, it reminds me of why I used to have a pre-compiled binary gem... :)
I am not even sure if c="AAB10F" works, or if it has to be c=AAB10F. The parser is pretty dumb and the XML-style styling is amazingly inefficient. But if it catches on, I'll be happy to make it more awesome. Right now I almost regret adding it. :)
Ouch. That's bad news!
The SWIG file is not entirely language-neutral: The RubyGosu.swg file contains some Ruby C API code that throws around VALUEs. After that, I patch the resulting cxx file to work around a really old bug in SWIG. And THEN I still patch lots of stuff in pure Ruby :)
If SWIG's Java output is of the same quality, then that would be theoretically possible, but it might not be much more fun than hand-writing a wrapper around Gosu...
I have just pushed the changes to the docs, should be synced up to
http://libgosu.org/rdoc within the next 24 hours. (I forgot for when the job is scheduled :) )
Ouch - thanks for pointing that out! I forgot to update the fake "gosu.rb that the reference is compiled from. It should really be generated automatically. :/
Can you please retry now, with 0.7.47.1?
It works for me on Ubuntu 12.10. Thanks for reporting this issue! :)
You are right. Somehow I must have pushed very old code. Not sure how this happened - fixing now...
That was a bug in Gosu 0.7.46 that has been fixed in 0.7.47 - can you please try to install again? You were probably a few minutes too early :)
Gosu 0.7.47 has just been released with this feature.
This is a follow-up release to yesterday's v0.7.46. I've tried to close as many input-related tickets on github as possible:
• All: Add msOther0 - msOther7 constants for extra mouse buttons
• All: Add constants: kbBacktick, kbMinus, kbEqual, kbBracketLeft, kbBracketRight, kbBackslash, kbSemicolon, kbApostrophe, kbComma, kbPeriod, kbSlash
• Windows: Add support for up to four gamepads
• Linux: Fix button_down/button_up/TextInput (thanks @oli-obk)
• Linux: Enable optimizations in CMake build files (thanks @oli-obk)
• Mac: Work around crashes in C++ exception handling
• Mac: Fix some gamepad bugs (e.g. unplugging when Gosu is running)
• Mac: Fix a bug where Gosu processes would not terminate while a song is running
Most of these suggestions were taken from the Gosu Exchange board, so thanks everyone :)
High-level Mac changes: This release drops support for OS X 10.4, and the Mac Ruby gem is not precompiled anymore. This reduces the number of gems to two (source for Mac and Linux, binary for Windows). I still have to upload the Ruby .app wrapper.
High-level Linux and MinGW changes: oli-obk has kindly contributed CMake files. Check them out if you use C++! :)
Full change log:
• Mac: Add support for up to 4 gamepads
• Mac: Disable fullscreen mode for now, as it is broken on 10.7/10.8 (will fix after May)
• Mac: Fix Image::save
• Mac: Fix a crash in font rendering
• Mac: Allow window to use more desktop real estate
• Mac: Fix bizarre crash on OS X with Ruby 1.9
• C++: Add Socket example game (huge thanks to @oli-obk!)
• Linux: Use scancodes as button IDs on Linux, just like on Windows (thanks @oli-obk!)
• Ruby: Fix gl(z) {} memory leak (thanks Spooner)
• Windows/C++: Show error and shut down when draw() throws an exception (thanks @quit)
• Windows: Fix bug where Gosu would not run in a directory with spaces in its filename
• All: Fix integer truncation of clipping rectangles (thanks @jamer)
Wow. While editing the change log, I realised how long this release was in the making - over half a year. The reason was mostly update paralysis: Xcode 4, OS X 10.7/10.8, Ruby 1.9.3 (2.0 by now), Rubygems 2.0, MSVC 2012, iOS policy changes...where to start?
I still haven't properly updated Gosu for any of those. Getting back into the habit of monthly releases will definitely help, though!
I like this kind of game. Have you peeked at the RMagick example? I would be curious to see if you can translate some of the visual effects to Texplay. (I have no Texplay experience - but I understand that it would make the game a lot easier to redistribute than RMagick :) )
Awesome. I've made a note to add it to the front page! Minor nitpick: On a browser without Flash (Safari to be exact), I just see empty areas where the videos are supposed to be :)
...not much worse than what I have to do in TR1.hpp already :)
It would be good if everything still worked on MSVC2010, and if everything that is necessary for the Ruby port would work on gcc4.0+ (that was the OS X 10.4 compiler - I'd like to target OS X 10.5+ but I'm not sure if that was gcc4.0 or 4.2 or whatever - I'll receive my 10.5 oldtimer machine in May :))
You also need to copy the framework into your app bundle. To do so, select your target, go to Build Phases and add a Copy File build phase. It needs to copy Gosu.framework into the "Frameworks" folder inside your app.
The multi-gamepad code has been merged in for OS X already, but I haven't documented it because it is still missing for Windows.
At that point you could probably just use C99 struct literals :) draw((DrawArgs){ .angle = 5 })
But why not the other way around? image.draw(5_angle) (omg the namespace pollution...)
> such an interface would require every image instance to have it's own member values for rotation and scale
image.rotate(5) would not modify the image (immutability ftw) - it would create something like an
ImageDrawParameters that might consist of a 2x2 matrix or four points, four colour values and an
ImageData pointer. Each method call on
ImageDrawParameters would create a new temporary object, and ideally this could also be optimised away, until it is only
image.drawWithImageDrawParameters(...).
This only works in C++ because it relies on cheap/free stack objects, whereas Ruby only allocates objects on the heap _and_ has a terrible garbage collector :)
ScaleAbsolute would be great though. For some reason I've never thought about writing a wrapper for that operation.
Your variadic template solution has the advantage that it could be made extensible. The extensible variant of my code would be
draw(rotate(scale(image, ...), ...)), yuck! :(
Powered by mwForum 2.29.1 © 1999-2013 Markus Wichitill