Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Forum
1 2 Previous Next  
Search
Topic Tron 3000 By philomory Date 2009-05-01 15:02
Incidentally, for what it's worth, using Ruby 1.9 approximately doubles my frame rate.
Topic Tron 3000 By philomory Date 2009-05-01 14:22
This looks really awesome. Extendable AI? Very, very cool.
Topic Gosu 0.7.13 released! By philomory Date 2009-04-17 23:30
Hooray! I'll be playing with this this weekend (though I won't be participating in Ludum Dare this time around). Thanks for the update, and look forward to, at the very least, SDL- and 1.9-SDL- based builds of 0.7.13 for Mac. Maybe I'll get a chance to do a Windows build this time around, too.

Thanks for you continued work!
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-04-03 20:44
Sorry, are you using Tiger or Leopard? The version of libiconv that Apple ships with Tiger has a slightly different API than the one shipped with Leopard (as I understand it). Julian has Leopard, I have Tiger. Your two options are to either a) change four lines of source in Gosu, or b) install an updated version of libiconv. You can find some info in this thread:

http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?pid=27;hl=libiconv

EDIT: Whoops, didn't occur to me that the person I was replying to was, in fact, Julian. Which I guess makes me confused. Perhaps MacPorts has installed for you it's own copy of the older version of libiconv? This is part of why I don't use MacPorts or Fink anymore. I used to swear by it, but one day I realized that I had six different installations of Python on my machine, despite never having been a Python programmer.

EDIT AGAIN: And no, I didn't drop static linking because of linker problems, or at least, not because of overt linker problems, and in particular not in relation to libiconv. Whenever I try to statically link Gosu with libruby-static.a (for any version) rather than libruby.dylib, it builds and links without errors, but trying to require Gosu crashes the ruby interpreter.
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-04-01 16:29
Actually, I just a few days ago got a working universal build of Gosu against both 1.9 and SDL. I was going to wait to post about it until I could put up a windows version too, but I guess I've been called out :-p

If you just want to build gosu against ruby-1.9 for your own platform, it should be pretty simple. First, make sure you can build gosu normally. You may have to adjust some paths for libraries and header files if you've got things installed in different places than Julian does.

Now, we need to make sure we have a version of 1.9 that is built correctly. The most important part is that it was built with the --enable-shared option passed to './configure'. If it wasn't, you won't get a dylib, only a .a, and I've never gotten static linking to work here. You'll also need to know where your 1.9 libruby is located and what it is called. For instance, my copy of was installed with the default prefix (/usr/local/), and a program-suffix of -1.9, so my libruby file for 1.9 is located at /usr/local/lib/libruby-1.9.1.9.1.dylib, and has a symlink at /usr/local/lib/libruby-1.9.dylib . This will be important later.

At this point, you're ready to build Gosu against Ruby 1.9. Open your Gosu project in XCode, and set your Active Target to RubyGosu Core. For simplicity of instructions, I'm assuming you have the current build configuration set to 'debug'. Go to Project > Edit Active Target 'RubyGosu Core', select the 'build' tab, and set the configuration to 'Active Configuration (Debug)'.

The following settings need to be changed:
Header Search Paths: Make sure it includes the include path for your ruby 1.9 headers. For me, this is /usr/local/include/ruby-1.9-1.9.1 . I included this as /usr/local/include/ruby-1.9-1.9.1/** to make it go down into subdirectories, IIRC.
Library Search Paths: Make sure it includes the path to libruby.dylib. For me, this was /usr/local/lib
Other Linker Flags: change -lruby to have a suffix appropriate to your copy of 1.9's libruby. I.e., since I configured libruby with --program-suffix=-1.9, my linker flag was -lruby-1.9.

Those should be the only changes necessary to get an intel-only 1.9 Gosu with otherwise default configuration. Close the Target Settings window and click 'build', you should get a built copy of gosu.bundle linked to ruby 1.9. You can double check the linkage using otool -L /path/to/gosu.bundle from Terminal.

Note that this stuff is somewhat off the top of my head. I'm pretty sure it's accurate, though.

Edit: the flag is --program-suffix, not --suffix
Topic Movie maker for Gosu and Rubygame By philomory Date 2009-04-01 01:37
I love the idea behind this; however, a attempting to use this suggests, and looking at the source confirms, that this library requires not Gosu *or* Rubygame, but Gosu *and* Rubygame. So... anyone thinking of making use of this, be aware of that.
Topic A neat little word-wrap trick. By philomory Date 2009-03-23 22:48
Of course, by now I've discovered that this feature is already available as part of the 7 argument form of Gosu::Image.from_text() . Unfortunately, Gosu::Image.from_text doesn't work. I've filed an issue: issue 60
Topic A neat little word-wrap trick. By philomory Date 2009-03-20 02:09
I spent some time thinking about how to do word-wrap for non-fixed-width fonts, and came up with this. It's pretty simple, but works well and seems fast enough for me. I thought someone else my like it, too!

Here's the wordwrap method:
  def wordwrap(message,width,font)
    word_array = message.split(' ')
    lines = [word_array.shift]
    word_array.each do |word|
      if font.text_width("#{lines[-1]} #{word}") < width
        lines[-1] << ' ' << word
      else
        lines.push(word)
      end
    end
    return lines
  end

and here's a demonstration of use:
#!/usr/local/bin/ruby
require 'gosu'

class MyWindow < Gosu::Window
  def initialize
    super(640,480,false)
    @font = Gosu::Font.new(self,Gosu::default_font_name,20)
    @message = "Hello and welcome to my very long text string which is also pretty boring and stupid, but oh well I guess there is a time and a place for lorum ipsum, and this was probably it, but I didn't have any handy so we get this crap instead, which is too bad really, because Lorem Ipsum is kinda nice, but oh well, what can you do, other than end this damn string already?"
    @margin = 20
    body_width = self.width - 2*@margin
    @lines = wordwrap(@message,body_width,@font)
  end
  def wordwrap(message,width,font)
    word_array = message.split(' ')
    lines = [word_array.shift]
    word_array.each do |word|
      if font.text_width("#{lines[-1]} #{word}") < width
        lines[-1] << ' ' << word
      else
        lines.push(word)
      end
    end
    return lines
  end
  def draw
    @lines.each_with_index do |line,index|
      height = @margin + (index * @font.height)
      @font.draw(line,@margin,height,0)
    end
  end
end
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-02-24 03:05
Here's gosu.bundle for Gosu 0.7.12 + SDL for OSX!

Use it exactly as you would use the regular gosu.bundle. Make sure you have SDL.framework [1] and SDL_mixer.framework [2] somewhere useful, like /Library/Frameworks/. When using the deployment package, copy the two aforementioned frameworks to RubyGosu Deployment Template.app/Contents/Frameworks/, and put gosu.bundle in the Resources folder of your bundle, as normal.

---

[1] http://www.libsdl.org/release/SDL-1.2.13.dmg

[2] http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.8.dmg
Attachment: gosu.bundle.zip (0B)
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-02-24 02:57
Ok, so I've been trying a lot of things with Gosu 0.7.12. I have no less than seven separate source trees for it (on OS X), all of which are almost completely identical, but with different libraries being loaded.

Here's my record so far:

gosu_orig: Original gosu, altered only to point header and library lookup to the correct paths on my machine, and fix a 10.4.x iconv issue. Builds universal and works.

gosu_1.9: gosu_orig, altered to build against ruby-1.9. Builds ppc-only and works. I don't have a universal copy of 1.9, so I can't build universal extensions.

gosu_SDL: gosu_orig, altered to use the Unix-style SDL libraries (i.e. libSDL.dylib, libSDL_mixer.dylib). Builds universal and works, has some odd sound quality issues on my machine.

gosu_SDL-framework: gosu_orig, linking against the precompiled SDL.framework[1] and SDL_mixer.framework[2] available from libsdl.org. There were some tricks to getting it to compile, but now it builds universal and works. Sounds better than gosu_SDL on my mac, which means either I did something wrong when I built libSDL and libSDL_mixer, or the precompiled frameworks have been optimized. As a bonus, the frameworks are precompiled downloads, so other people wanting to use gosu with SDL don't need to compile SDL themselves this way.

gosu_1.9_SDL-framework: The alterations from gosu_SDL-framework and gosu_1.9, combined. Builds and works, but ppc only, for the same reason that gosu_1.9 was.

gosu_static: gosu_orig, but linking against libruby-static.a rather than libruby.dylib. Builds without errors, but crashes on load.

gosu_1.9-static: just like gosu_static, but with ruby 1.9. Same results as gosu_static, builds without errors, but crashes on load.

In summary, using Gosu with SDL on the mac is easier now that I've figured out frameworks. Distribution is *way* easier, because the precompiled frameworks available from libsdl.org are already configured for being embedded in a bundle. Just drop them in a RubyGosu Deployment Template.app/Contents/Frameworks and you're off.

Gosu with SDL and ruby 1.9 is theoretically possible, but I can only get 1.9 to build to PowerPC, and the performance benefits of using 1.9 would be totally overshadowed by the performance penalty of running under Rosetta. Until someone sends me a universal binary copy of at *LEAST* libruby.1.9.1.dylib [3], I can't make a useful, deployable version of this for 1.9

So... this is kinda long, and short on the info people really want, which is, where's the updated gosu/sdl bundle, and when is the windows version coming? Answers: Attatched to the next post, and hopefully attached to my next post after that.

----

[1] http://www.libsdl.org/release/SDL-1.2.13.dmg

[2] http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.8.dmg

[3] Or an i386-only version which was built in roughly the same way I built my version, so I can lipo them together without issue. My arguments to ./configure were  '--program-suffix=-1.9' '--with-readline-dir=/usr/local' '--enable-shared', and I was building on 10.4. If you built yours on 10.5, it'd have to have been using the 10.4u SDK, or it probably won't be backwards compatible with Tiger, as I think came up in the RMagick thread. The only option I included that's really critical is --enable-shared. If you don't include --enable-shared, you won't get a dylib at all.
Topic Deploying RMagick on OS X By philomory Date 2009-02-23 16:26
This is really neat, if you manage to get it working on Tiger too that'd be awesome. I'd try it myself, but I'm still working on that SDL build :-p
Topic Gosu with Ruby 1.9 By philomory Date 2009-02-12 17:36
There *is* a one, true installer for Ruby 1.9 on Windows: ftp://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.9.1-p0-i386-mswin32.zip

Note that I haven't actually tried this yet, but even if it doesn't work, it's still the one true installer linked from ruby-lang.org and marked 'recommended'.

Various linux distros may or may not have ruby 1.9 available through their package managers.

The situation for OS X is a little less clear-cut. Ruby-lang.org discusses installing via macports or fink, and then discusses installing from source, which is what I always do.

In the long-term, official Apple support for ruby 1.9 may very well come in the form of MacRuby being pre-installed with the OS... though unless they can work out binary compatibility with extensions built for YARV, they may well include a 'standard' 1.9 as well.
Topic Gosu 0.7.12 released! By philomory Date 2009-02-09 07:57
Dastardly Julian! Just when I finish working on the Gosu build process and get back to working on my game, you improve Gosu!

I'll let you know how the new version builds for me in a couple of days.

None of this should be in any way taken as saying I don't appreciate the updates, as I most certainly do! Thanks for your hard work!

(Also, nice look for the forums)
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-02-07 02:23

>>  the reason I compiled my own copy of ruby to begin with is that when I tried to build gosu linked against the one-click installer, I got a 'fatal error MSC version mismatch'
>
> That error is the first line I comment out when I install One-Click Ruby *cough* ;) I'd expect that if anything, the resulting DLL shouldn't be loaded or crash, and so far it seems to work.


Indeed, figuring that part out thanks to various web searches was crucial to my getting this to work. Without further ado, here is the Windows version!

Again, obviously you have to have SDL.dll and SDL_mixer.dll installed either in your path or in the folder with the gosu.dll. Luckily, you can download them prebuilt for windows rather than having to compile them yourselves. SDL: http://www.libsdl.org/release/SDL-1.2.13-win32.zip SDL_mixer: http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.8-win32.zip

As for packaging up the game, I've got no template because normal Gosu doesn't either. Rubyscript2exe is, I've decided, a pain in the neck to work with, though it *is* the only solution I know of that gives you a truly single-file distributable game. Personally, I've so far had good success with exerb, so I recommend that if you don't mind having your non-ruby files sit outside the executable (gosu.dll gets embedded into the exe, but SDL.dll and SDL_mixer.dll remain outside, which is fine since it makes licensing easier). Crate also looks very promising,  but I didn't really have time to get into it; it's not quite as simple to use (from a dev standpoint) as exerb.
Attachment: gosu.so (0B)
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-02-05 07:26
OK, I had a revelation today that makes deploying Gosu/OSX/SDL much, *much* simpler. All the nonsense playing with install_name_tool was *completely* unnecessary (though it was educational). As such, it is my pleasure to introduce the simpler Gosu/Ruby1.8/OSX/SDL build, with instructions on how to use it easily and simply:

(Note that this does require compiling something, so you'll need XCode installed, but the actual effort demanded of you is not high).

For development:
   1. Put my modified gosu.bundle anywhere that is appropriate, like you would with normal gosu.
   2. Download the SDL source archive (http://www.libsdl.org/release/SDL-1.2.13.tar.gz)* , extract it and compile it as follows:
       (open a terminal window and cd to the directory you extracted SDL's source into)
       $ ./configure
       $ make
       $ sudo make install
   3. Do the same thing for SDL_mixer (http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.8.tar.gz)*
   4. SDL and SDL_mixer are now installed in /usr/local/lib/, exactly where gosu expects to find them!.
   5. in your ruby app, require 'gosu' and proceed merrily along as normal.

For deployment:
  1. You can use Julian's RubyGosu Deployment Template, almost completely unmodified! You don't have to recompile it or anything.
  2. In the RubyGosu deployment template, put gosu.dylib in the Resources folder like you normally would.
  3. Put libSDL and libSDL_mixer and libruby in the same folder as gosu.bundle. The only tricky part here is making sure you get the actual dylib, since most of the files in /usr/local/lib will be symlinks pointing to the real dylib. On my machine, the real dylib was called libSDL_1.2.0.11.2.dylib. Rename the dylibs to libSDL-1.2.0.dylib and libSDL_mixer-1.2.0.dylib, or make symlinks with those names pointing to the 'real thing'.
  4. Now the step that makes it all work: Open up Info.plist in Property List Editor and add a key called LSEnvironment, of type Dictionary. As a child of that, add a key called DYLD_LIBRARY_PATH, of type String, whose value is a single '.' (dot). Save the plist. If you are averse to Property List Editor, the XML is
        <key>LSEnvironment</key>
        <dict>
                <key>DYLD_LIBRARY_PATH</key>
                <string>.</string>
        </dict>
  5. Double-click your app and watch it run! Take it to another machine with no SDL, SDL_mixer or ruby and watch it still run. Rejoice!

Ok, in retrospect, this doesn't *sound* very simple, but it really is. Compared to what I was doing before, this is much better. Primary benefit? You can use the same gosu.bundle for development and distribution. Before, I had one specially set up for the deployment bundle, and if you changed anything you were pretty much doomed.

Also, to get a truly self-contained app, I suppose you could include libruby in your bundle as well, but since all macs ship with libruby I think you should be ok unless your users have actually deleted it off of their machine.

Windows version to come shortly!

* Note that the exact verison number for SDL and SDL_mixer probably don't matter, as long as it's 1.2.x. Also, you could probably use MacPorts or Fink instead of compiling it yourself, but I've never tried it, and I don't know if it would work well or not.
Attachment: gosu.bundle.zip (0B)
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-02-03 09:04
Ok, so it seems there is a problem. My Gosu/Windows/1.8/SDL build works on a copy of 1.8 I compiled myself, but not on the version installed by the one-click installer. I believe this has to do with the different version of the Microsoft Visual C Runtime (MSVCRT) that the two rubies are linked against? The version I compiled provides msvcr80-ruby18.lib, on account of being built with Visual Studio 2005, i.e. 8.0. The one-click installer provides msvcrt-ruby18.lib, on account of being built with whatever it was built with, I suppose. I'm a little out of my league here, but the reason I compiled my own copy of ruby to begin with is that when I tried to build gosu linked against the one-click installer, I got a 'fatal error MSC version mismatch', which google said meant I needed to compile ruby with the same compiler I was using for my extension.

The actually process of getting Visual Studio to build *normal* gosu was quite difficult for me, due in part to the fact that I have little C++ experience and less Windows development experience, in part to the fact that I wasn't willing to shell out money to get the paid version of Visual Studio, and in part to the fact that the only Windows machine I have available for reckless experiments like this is still running Windows 2000. That being said, the number of *additional* steps needed to go from compiling gosu with fmod to compiling gosu with sdl was very small, just three or four steps. I'll outline them here tomorrow, for the time being I'm going to sleep.

For the record, my last accomplishment before going to bed was getting rubyscript2exe to product a working executable version of my game, which unfortunately revealed a number of 'path assumptions' I had made which I need to fix... luckily, that problem lies entirely within the realm of Ruby and is something I expect to have little difficulty with.

A more serious problem looms in that what I've read leads me to believe that rubyscript2exe is completely incompatible with ruby 1.9 (indeed everything after a certain patchlevel in ruby 1.8... patchlevel 111 works, patchlevel 287 does not). That being the case, I think I'm going to stick with 1.8 on windows and leave 1.9 to someone else... without the ability to build an exe afterwards, the cost/benefit ratio is far to poor at my skill-level.

...

Goodnight.
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-02-03 03:22
I am very happy to say that I've managed to compile RubyGosu+SDL... for Windows! There's been very little testing, but it does work with my game on the machine I compiled it on. It's built for Ruby 1.8.6, I haven't had time to play with 1.9 yet. Frankly, the hardest part by far was figuring out how the hell to use Visual Studio 2005 Express C++, given that I a) have never done windows development of any sort before, and b) I have little knowledge of C++.

Anyway, it certainly seems to work, so I'll be uploading it soon.

(Note of course that instead of including fmod.dll in your source directory, you'd include SDL.dll and SDL_mixer.dll)

(edit: grammar)
Topic Framerate Limits? By philomory Date 2009-02-03 03:17
Personally, I have this code in my Player class... obviously you would need to tailor it to your own game somewhat.

def initialize(...)
  ...
  @movement_delay = 0.2
  ...
end

def pressedMovementKey(direction)
  return if Time.now - @last_moved < @movement_delay
  if @facing == direction then
    destination = self.send(direction)
    if destination.empty? || destination.collectible? || destination.pushed(direction) then #Short-circuit evaluation is relied on here
      @y -= 1 if direction == :north
      @y += 1 if direction == :south
      @x += 1 if direction == :east
      @x -= 1 if direction == :west
      destination.playerEnteredTile(self)
    else
     puts "Bump!"
    end
  else
    @facing = direction
  end
  @last_moved = Time.now
end
Topic Gosu sound... By philomory Date 2009-02-02 23:29
Just to throw a quick note out there, there are a few flaws in the SDL_mixer/OSX release I posted a while back. I was hoping to actually get around to addressing them tonight, actually.

A request, also - I want to do a 1.9/SDL/OSX/Universal build, but I can't do that without a universal build of ruby 1.9. I've got a PowerPC machine with 1.9 on it, but I've been unable to cross-compile it for intel. If someone could build ruby-1.9 from source on an Intel Mac with the flag --enable-shared and then send me the resulting libruby.dylib file, I'd very much appreciate it. Then I could just lipo the PPC and Intel versions together. Or if someone just sends me an already build universal dylib, that would work too.

If someone thinks they could do that, let me know and I'll put contact info here. In the mean time I'll work on fixing the 1.8/SDL/OSX/Universal build so that it's actually self-contained.
Topic GGLib: A Gosu GUI Library By philomory Date 2009-01-30 08:27
Ok, I haven't had a chance to download this and play with it yet, but from readings your description I'm quite excited. I've been wishing for something like this for a while now.
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2009-01-02 18:10
The template provided in the above post will be completely useless to you on Windows, it's an OS X application package. I plan to try to build a copy of gosu/ruby/windows with SDL when I have a chance, but I have absolutely zero experience with windows software development so I may run into roadblocks very quickly.
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2008-12-18 19:17
That last post was by me. Now I'll attempt to upload the file.
EDIT: Nope, hit's the file size limit. Email it is.
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2008-12-13 05:53
Ok, so I've got a confirmed working universal binary RubyGosu Deployment Template for OS X, linked against SDL instead of FMOD. libSDL and libSDL_mixer are linked dynamically, but included in the bundle, so you get the 'it just works' of static linking, and the 'drop-in-replace-ability' of dynamic linking. Using 100% open source code, to boot.

Julian, now I have an inkling of why you aim to statically link everything whenever possible. Dealing with the dynamic linker is a pain in the neck.

Anyway, I'm attaching my built deployment template (including built gosu.bundle, libSDL, and libSDL_mixer) here. I'd post my source changes, except I didn't make any: this was all build-environment trickery.

EDIT: I guess I'm not attaching it here, as it runs up against the 1MB limit and I can't seem to compress it below 1.2MB. Does anyone want this?

Usage of the template is a tiny bit different from the original RubyGosu Deployment Template: put your scripts in Contents/Resources, but leave gosu.bundle where it is. Also, don't rename your game's main script to Main.rb, instead open up the Main.rb already present, and edit the second line to require your own main file (or, get rid of my Main.rb, make your own starting file Main.rb, and add $LOAD_PATH.unshift('../lib/ruby') to the very beginning).

Hope this proves useful to someone. Now if someone could do something similar for Windows so I didn't have to, I'd be very appreciative :p
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2008-12-12 17:27
I guess there's a first time for everything. I got was finally (after hours of beating my head on it) able to cross-compile SDL & SDL_mixer for Intel macs, and I grabbed a universal build of ruby-1.8.6 from the OneClickInstaller package (I just grabbed libruby, I didn't actually install the package), since ruby wouldn't cross compile (errors about setpgrp). And I built RubyGosu Core, and it worked! In fact, once I had lipoed the dependencies together, I was able to build RubyGosu Core itself as a fat binary right from XCode, rather than building twice and lipoing. And when I got to an Intel mac to test it on, it worked on the first try, so I'm very pleased.

One thing I did notice though: I don't think the problem I was having with 1.9 has anything to do with 1.9 per se... my 1.9 build of gosu statically linked libruby, which works fine by itself, but when I try to build Gosu with SDL against a statically linked 1.9 *or* 1.8, it blows up. Dynamically linked 1.8 works fine, so I'm going to try building dynamically linked 1.9 when I get home.

Just thought I'd post this follow-up, in case anyone else finds the info useful. If you like, I can post my builds, too.
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2008-12-12 04:29
Actually, I'm building it for PPC *now*. Building it for Intel means... uh... getting another computer? I've never managed to successfully cross-compile anything, that I can think of. I usually don't bother trying.

Static linking is out, because I'm pretty sure I'd then have to make my source GPL or LGPL. I plan to go open source, but not one of those licenses. Isn't licensing fun?

So, I started over with a fresh copy of the 0.7.11 source, and it worked like a charm actually. Then I tried altering the build settings to make it build in 1.9, and it compiled and linked fine but threw a bus error on use.

Soo... at the moment it seems that Gosu + OS X + SDL is fine, and Gosu + OS X + Ruby 1.9 is also fine, but Gosu + OS X + SDL + Ruby 1.9 is not as fine.

I tried running it in XCode's debugger, and it seemed to be crashing with EXEC_BAD_ACCESS in this call stack:
#0  0x0110eb6c in st_lookup
#1  0x010c37e4 in rb_intern3
#2  0x010a5b1c in rb_define_module
#3  0x0100c120 in Init_gosu
#4  0x002065ec in dln_load at dln.c:1284
#5  0x0030198c in rb_vm_call_cfunc at vm.c:1323
#6  0x002352e8 in rb_require_safe at load.c:553
#7  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#8  0x00304f4c in vm_exec_core at insns.def:999
#9  0x00308e8c in vm_exec at vm.c:1041
#10  0x00309da8 in eval_string_with_cref at vm_eval.c:737
#11  0x0030a214 in rb_f_eval at vm_eval.c:820
#12  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#13  0x00304f4c in vm_exec_core at insns.def:999
#14  0x00308e8c in vm_exec at vm.c:1041
#15  0x0030d1b0 in loop_i at vm.c:487
#16  0x0023151c in rb_rescue2 at eval.c:614
#17  0x002fe950 in rb_f_loop at vm_eval.c:560
#18  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#19  0x00304f4c in vm_exec_core at insns.def:999
#20  0x00308e8c in vm_exec at vm.c:1041
#21  0x0030b3a0 in rb_f_catch at vm.c:487
#22  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#23  0x00304f4c in vm_exec_core at insns.def:999
#24  0x00308e8c in vm_exec at vm.c:1041
#25  0x0030b3a0 in rb_f_catch at vm.c:487
#26  0x003026e0 in vm_call_method at vm_insnhelper.c:376
#27  0x00304f4c in vm_exec_core at insns.def:999
#28  0x00308e8c in vm_exec at vm.c:1041
#29  0x00309550 in rb_iseq_eval at vm.c:1246
#30  0x00231160 in ruby_exec_node at eval.c:205
#31  0x00233a88 in ruby_run_node at eval.c:233
#32  0x00002cf8 in main at main.c:35

...but frankly I don't have a clue how to even use GDB, so I very likely did it wrong.

Frankly, I'm just glad I got anything to work, I was getting rather frustrated. I was quite surprised when it not only didn't crash, but actually played the music correctly to boot.
Of course, lord knows how I'd do this for the windows version, having absolutely no experience working with Windows build tools whatsoever.

<semi-off-topic>Actually, it continues to amaze me how much of 'programming' takes place outside of the code, trying to get the build-environment right, etc. Not just C, Ruby too, since if you ever want to distribute anything to an end user you have to make sure that they'll meet all the requires and have them in the right places, etc</semi-off-topic>

Anyway, thanks for your patience. I'll be sure to note here when the game is ready for other people to see.
Topic Building gosu with SDL instead of FMOD on OS X and Windows By philomory Date 2008-12-11 03:27
(Note, this is for the ruby portion of gosu)
So, I've been a little annoyed at FMOD (primarily their weird freeware license that forbids you from accepting donations), and I thought I'd try to compile gosu with SDL instead on OS X. I actually got it to compile, which was pleasing, but then it threw [BUG] Bus Error when I tried to require it, so clearly I'm doing it wrong.

(Incidentally, the way I did it was this: I removed AudioFMOD.cpp from the xcodeproj, added AudioSDL.cpp in it's place, and then added the SDL frameworks to the project. I got frustrated trying to get the SDL frameworks to behave, so I took them back out, and linked against my UNIX-style SDL installation instead, and added -lSDL and -lSDL_mixer, and added the SDL path to my lib search, etc. At this point, everything built and linked without errors, but it blew up on the require statement.)

Any tips on this? Is it worth my time? Or should I just suck it up and stick with FMOD? It's not that I actually expect anyone to give me money for my game, it just seems a little ridiculous to me that, for licensing reasons, if someone likes my game and wants to send $5 my way, I have to refuse.
Topic [Resolved] - [BUG] Bus Error By philomory Date 2008-12-08 10:01
Out of curiosity, what is self in this context? An object you created entirely yourself, or something derived from Gosu?

Perhaps more importantly, what is the text of the radius method? Or is it just an attr_* method (in which case, do you get the same result with puts @radius)?
Topic Gosu::Song, s3ms, quality and looping By philomory Date 2008-12-08 08:15
Well, I *did* compile a custom version of it, for use with 1.9. But I don't see any reason not to use Ogg files anyway, so I'll re-convert them.

But, what about my other question? Is there any way to get a callback when a song ends, or do I need to poll for it?
Topic Gosu::Song, s3ms, quality and looping By philomory Date 2008-12-08 00:00
Ok, whatever issues FMOD may or may not have with s3m playback, everything is working just fine with mp3s, so that's good. Now I have another question, though: is there anyway to register a callback for when a song has finished playing, or do I just need to keep polling with Gosu::Song#playing? during the update loop?
Topic Text capabilities? By philomory Date 2008-12-07 06:43
Julian could give you a more definitive answer, but I think Gosu might not be what you are looking for for this particular project. It does not support multiple windows, and more importantly does not include a text buffer of *any* sort, let alone ncurses-like functionality. All text is rendered as open-gl textures. Which is not to say you could not implement your own scrolling text buffer... but I can't think off-hand how you'd do it. Gosu is much more intended for graphical, mostly 2D games with input usually being supplied single-key-a-time by keyboard/gamepad, or input via mouse.

As for a good alternative, that depends on what language you are looking at. Were you intending to write in Ruby, or C++? I assume it's one of the two if you were looking at Gosu.

Again, though, my word isn't final on this; Julian may pop up at any moment and point out some undocumented feature that makes Gosu just *perfect* for writing a MUD UI. Though, I doubt it, because his documentation is pretty good, honestly, so I doubt he'd leave something like that out.
Topic Gosu::Song, s3ms, quality and looping By philomory Date 2008-12-06 23:02
Ok, I've got a handful of files in PC Screamtracker format (.s3m), and I've finally gotten to the point of adding them to my project. My problem is, they seem to sound a lot worse when playing through Gosu::Song/FMOD than they do played in, for example, Richard Bannister's Audio Overload. They play at a noticeably slower tempo, some of the samples get stuck, and others don't play at all. EDIT: It turns out, Audio Overload was actually playing them too fast. Gosu/FMOD is playing them at the right speed. But, the part about the broken samples is still true.

Does anyone else have experience using FMOD/Gosu with Screamtracker files? Was the quality OK? I'm wondering if I should keep these as .s3ms or convert them to something else such as mp3s. They've already been converted once, TO Screamtracker files, as they were originally in the ancient Apple IIgs Soundsmith format.

On a related note, it seems that Gosu::Song loops at the end of the track, though it's also possible my s3m files have a loop instruction at the end. Is looping the standard behavior for Gosu::Song, and if it is, is there any way to turn it off? I'd like to move to another song when one finishes.

Thanks for your help,
- Adam Gardner
Topic Gosu Bullet Hell Shmup By philomory Date 2008-12-03 02:57
God, from the gameplay videos it looks like a Kenta Cho game! Impressive.

I don't suppose you have a fast-paced electronica soundtrack to go with it, do you?
Topic Gosu not working with ruby 1.9? By philomory Date 2008-12-03 02:50
It's possible to get Gosu to work with 1.9, but you have to recompile Gosu specifically targetting 1.9 instead of 1.8. There's some information on doing so under OS X in the thread, "Compiling Gosu on OS X - Build errors in Utility.cpp" (I guess I really should have put '1.9' somewhere in the title). I'm not sure how much of the stuff in that thread is relevant to the windows build process, though.
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-12-03 02:41
Hi, sorry for taking so long to get back to you! I've been away from my Gosu project for a while doing other things (such as RubyQuiz 184, which was a lot of fun). But I'm back now.

I'm hardly an XCode expert either, but I'm glad to help if I can. Note that my instructions assume XCode 2.4.1 on Tiger. Things may be different with XCode 3 on Leopard, but they shouldn't be *that* different. What I did with FMod was the following:

Download the FMod API and extract it. I got a folder called fmodapi375mac. I put that folder in the root of the gosu source tree (that is, a sibling folder to Gosu, GosuImpl, mac, linux, lib, etc). Then, I opened the XCode project for Gosu (that is, gosu/mac/Gosu.xcodeproj), and selected Project > Edit Project Settings... from the menu bar.

In the Project "Gosu" Info palette, select the 'Build' tab. Select the setting 'Header Search Paths' (should be near the top), click the 'edit' button, and then in the sheet that drops down, press the plus button for a new entry. The path for the new entry is '../fmodapi375/api/inc' (without the quotes). Then, click OK.

Now, back on the Project "Gosu" Info palette, select "Library Search Paths", which should be two lines below "Header Search Paths". Click Edit for this line, and in the sheet click plus. Add '../fmodapi375mac/api/lib' (again without quotes), and click OK.

I'm pretty sure that's all I did as far as FMod is concerned. I know it probably would have made more sense to just dump the fmod stuff into /usr/local/inc and /usr/local/lib instead, but I didn't feel like it.

Anyway, good luck!
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-11-11 01:44
Ah, there's the piece I was missing: not that it was in the Target settings (I checked those) but that it was set individually for each configuration. The 'all configurations' setting was coming up blank, but when I put something into it, it was clobbering your settings, which just baffled me.

As for packaging, I don't know a lot about using static libs, I'll play with that one some more too. In the mean time, however, I believe a similar effect (at least with regards to packaging up a distributable application) can be achieved by putting a copy of the dylib you've linked to (in this case, libruby-1.9.1.9.1.dylib, on my machine) into the bundle, say in a Contents/lib/, then calling install_name_tool -change /usr/local/lib/libruby-1.9.1.9.1.dylib @executable_path/../lib/libruby-1.9.1.9.1.dylib "/path/to/RubyGosu Deployment Template". I'd probably take this opportunity to rename the libruby and fix the ridiculous 1.9.1.9.1 part I ended up with (since I built ruby 1.9 with ./configure --program-suffix=-1.9).

Anyway, this is basically speculation based on how RubyCocoa does things... I'll play with it when I get the chance, and let you know if I find anything interesting.
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-11-10 16:04
You are in fact correct... this is something I finally figured out last night, but was too tired to post about it. In fact, I now have it compiling and linking and working and (nearly) everything is good. The end result? The game is now using somewhere around half the CPU cycles under 1.9 as it does under 1.8! So, all in all I'm very pleased, even if it took a while to get here.

There are still a few problems. The primary one is this: Where did *you* specify the Linker Flags in the XCode project? I made it link against my 1.9 libruby by adding the dylib to the project and adding the path to the library search path, but now it's linked against both 1.9 *and* 1.8. Since you never added the other linked libraries (fmod, boost, png) the way you added the linked Frameworks (like Foundation, IOKit, etc), and they aren't listed under 'Other Linker Flags' in the Target Settings, I don't know where else to look. The only thing I can say is that the call to linker has both -lruby-1.9 and -lruby now. Before it had only -lruby.

In the mean time, I'm pleased as punch despite the minor issues (the other issue of note is that I've only gotten this to work for powerpc - universal binary is something to worry about later).

Thanks a lot for your continued assistance!
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-11-10 06:22
Ok, one thing I've figured out (using otool -Iv) is that the 1.8.x version of libruby does *not* export the symbols _rb_intern2 or _rb_str_new_cstr, while the 1.9 version of libruby *does* export those symbols.

Which makes it a complete mystery to me why, when I try to link against 1.8, it works fine, but when I link against 1.9, it fails complaining it can't find them.

Or is it that it has found them and doesn't know what to do with them?
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-11-10 01:01
Hrm. I see that you brought the stuff from the wiki over, but I created this thread before I noticed. Oh, well.

In any case, when I talk about SWIG, I really have very little idea what I'm talking about, since I've not worked with it before. I was guessing that either the swg file or the build settings would be the place to look. It turned out to be the build settings (as you indicated it should be in the other thread). The path to 1.9 in the header search path for the target settings was incorrect for my machine. Since 1.8 was *also* in the list of header search directories, just lower priority, it chose 1.8 when it couldn't find 1.9's ruby.h

My build is now to the point where all the files compile, but I get a single error when linking. XCode says:

Building target "RubyGosu Core" of project "Gosu" with configuration "Release" --
  Linking ../lib/gosu.bundle (1 error)
    Undefined symbols:
      _rb_intern2
      _rb_str_new_cstr
      /Users/adam/code/gosu/mac/build/Gosu.build/Release/RubyGosu Core.build/Objects-normal/gosu.bundle-ppc-master.o reference to undefined _rb_intern2
      /Users/adam/code/gosu/mac/build/Gosu.build/Release/RubyGosu Core.build/Objects-normal/gosu.bundle-ppc-master.o reference to undefined _rb_str_new_cstr
      collect2: ld returned 1 exit status
   Build failed (1 error)

Unfortunately, I have even less of an idea what to do here than I did before... again, suggestions would be appreciated.
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-11-09 20:18
Hrm. Even though SWIG was compiled pointing to Ruby 1.9, the gosu.bundle I produced is linked against libruby 1.8. I'm guessing this has something to do with either XCode's build settings, or the RubyGosu.swg file. I'll keep poking around.
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-11-09 20:14
On a hunch, I removed the 'const' from the beginning of line 39, and it seems to have worked. It's compiled without errors, anyway, I'll report later on how things turn out.

Thanks for the help.
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-11-09 20:12
Sadly, this does not improve things (or maybe it does, since it does reach argument 4 rather than 2 before getting the error). After adding the semicolon to the end of the first line, I get eight *nearly* (but not quite) identical errors:

error: invalid conversion from 'const char**' to 'char**'
error:  initializing argument 4 of 'size_t libiconv(void, const char**, size_t*, char**, size_t*)'

...from the same lines. Any further suggestions?
Topic Compiling Gosu on OS X - Build errors in Utility.cpp By philomory Date 2008-11-09 19:30
I've been trying on and off to compile Gosu from the XCode project, in order to use Ruby 1.9 instead of 1.8. I first built Ruby 1.9 myself, and that works without issues. I then Built SWIG, making sure to have it link against Ruby 1.9 rather than 1.8. I then built Boost and installed that in the appropriate location, and finally I downloaded FMod, which turned out to be a pre-built library, so I dropped it into Gosu's parent directory where it was looking for dependencies. So far, I've managed to get XCode to go from aborting after 100 errors (as it was doing when I was missing dependencies) down to 8 errors, but these seem to be more specific code errors, and since I don't really know C++, I don't know what I should do about them.

Specifically, I am getting the following pair of errors four times from different places in Utility.cpp:

error: invalid conversion from 'char**' to 'const char**'
error: initializing argument 2 of 'size_t libiconv(void*, const char**, size_t*, char**, size_t*)'

The errors themselves seem to occur on line 44, and they are 'instantiated from here' at lines 70, 74, 80 and 84, for a total of 8 errors, causing the build to fail.

I tried looking this up, but there I found several different proposed solutions, and I have no idea which is the appropriate one in this case. Frankly, I suspect that there is nothing wrong with the code in Utility.cpp at all, but that rather there is something inconsistent between /usr/include/iconv.h on your system vs. on my system. After all, this presumably compiles without issue for you. Is your system running Tiger or Leopard?
Topic Redrawing static content [from wiki] By philomory Date 2008-11-09 17:52
Awesome, that sounds exactly like what I'm looking for.

As for Gosu working with 1.9 on OS X, I actually have some questions about that, too, but I guess now that we have a forum, I should make a new thread for it.
Topic Redrawing static content [from wiki] By philomory Date 2008-11-09 06:39
First of all, thanks for these forums!

Now, the macro you refer to... how would it work? It seems like it's either essentially a proc, and is storing the sequence of drawing steps, or it's a way to generate a Gosu::Image object (or something very much like one) which is composed of many others. I'm hoping it's the latter, since the former wouldn't be very useful. If it does save the result, rather than the list of steps which generated the result, it'd be exactly what I'm looking for.

Say I wrote something akin to this:

---
level_background = record_macro do
  (0...width).each do |x|
    (0...height).each do |y|
      @places[x][y].draw_background(x,y)
     end
   end
end
---

If I call level_background.draw, would any calls to my tiles' draw_background method be made?
        
As for the performance issue, it's not that the game doesn't run well. It's perfectly smooth at all times. It's just that it also has my CPU pegged at around 80% or higher at all times (G5 iMac, 1.9 GHz). If you say Gosu shouldn't be doing that, then you are very likely correct, and there is probably something unnecessarily inefficient in my code, which I suppose I will go look for now.

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill