This game is called Bakery.
Check out the details on http://github.com/janmejay/bakery/
It works well on Mac, but has horrible fonts and is pretty slow in linux.
May be i can use some learnings if anyone has linux/gosu performance war stories to tell.
If you like the concept(or the game itself), please help me make it better by sending feedback to singh[dot]janmejay[at]gmail[dot]com

As I said, I like it :)

And if anyone has either good or bad performance on Linux, please post the distro and other information, because right now I have no idea where to start debugging Gosu :(

Very nice art there! I like it. It works fine on my version of linux, except when run from a terminal.

Well it does work on linux, but has a noticeable delay between show and hide of windows(for instance when user goes from game welcome screen to new game) and places like warehouse(after storyline strips, user is pushed to warehouse to purchase new inventory). Clicking on "Buy" button causes some delay before item shows-up as purchased(gray).

Comparing it with Mac makes it more evident. On Mac it is very snappy.

Fonts is the second problem and a very major one. On linux, gosu fails to load non system fonts(which spoil the appearance in addition to making it unreadable).

What parameters do i need to post to give more detailed understanding of my gosu/linux installation?

Mine is a Lenny(Debain) laptop running 2.6.26-2-686 (almost all the packages are installed from stable lenny repos). Ruby version is 1.8.7 p 72.
aptitude show libopengl-ruby yields version=0.32f-2 and this is the list of installed dependencies -> freeglut3, libc6 (>= 2.3.5-1), libruby1.8 (>= 1.8.2-9), libx11-6 | xlibs (> 4.1.0), libxext6 | xlibs (> 4.1.0), libxi6 | xlibs (> 4.1.0), xlibmesa-gl | libgl1, xlibmesa-glu | libglu1

RUBY_PLATFORM = "i486-linux"

gosu version -> 0.7.2

I didn't look into your windowing system in detail, but if you are actually opening and closing several windows, then you're asking for trouble, because Gosu is not really designed for this :) The usual approach is to have several delegate "game state" classes and using one of these per screen, but keeping the same window open all the time.

Of course, that still doesn't explain where the delay comes from. But I wouldn't be surprised if any of the X11 windowing code could cause delays.

Hmm, just cloned from GitHub and after trying to execute it got this message:

./bakery:12:in require': /home/lobo/development/gamedev/bakery/src/shop.rb:156: syntax error, unexpected ':', expecting keyword_then or ',' or ';' or '\n' (SyntaxError)
...on_down?(Gosu::Button::MsLeft): publish(Event.new(:left_clic...
...                               ^
/home/lobo/development/gamedev/bakery/src/shop.rb:157: syntax error, unexpected keyword_when, expecting keyword_end
    when button_down?(Gosu::Button::M...
        ^
/home/lobo/development/gamedev/bakery/src/shop.rb:157: syntax error, unexpected ':', expecting keyword_end
...n_down?(Gosu::Button::MsRight): publish(Event.new(:right_cli...
...                               ^
/home/lobo/development/gamedev/bakery/src/shop.rb:158: syntax error, unexpected keyword_when, expecting keyword_end
    when button_down?(Gosu::Button::KbEscape): menu
        ^
/home/lobo/development/gamedev/bakery/src/shop.rb:158: syntax error, unexpected ':', expecting keyword_end
    when button_down?(Gosu::Button::KbEscape): menu
                                              ^
/home/lobo/development/gamedev/bakery/src/shop.rb:363: syntax error, unexpected keyword_end, expecting $end
        from ./bakery:12:in <main>'

What am I missing?

well, i am not opening multiple windows, im actually doing multiple game state objects and making one of them hook up with window. Additionally, the only thing i am doing is hide and show everytime i switch the game state object.
My window manager is metacity(and env is gnome(i know that has nothing to do with this, just trying to give out as much info as i can)).
I somehow think Metacity is the most lightweight window manager, i may be totally wrong. Do you think trying it on other window managers like xcomp-manager will help?f

@lobo_tuerto: not sure why should that happen... may be a relook @ loadpath will help. I guess you have a local gosu install(the shared object) which is being loaded in " require 'gosu' " call. I will push a commit to prepend to load_path and not append, so that frozen gosu is prefered over local one.
Will post another message once im done making that change.

PS: there was another problem i observed on OS X where the RUBY_PLATFORM variable was 'darwin-...' and not 'universal-darvin-...', i am going to push the fix for that too.

Ensured it prefers frozen version over locally installed one(in 58819af6bbd21).
lobo_tuerto: you may want to pull and try running it again.

> Additionally, the only thing i am doing is hide and show everytime i switch the game state object.

You mean close and show? Then this amounts to the same kind-of unsupportedness ;) At least it hasn't been tested or optimized at all.

Ok, will fix the close and show problem(will not do that anymore) and try to find out if it still is a problem. Will post the results soon.

Ok, I updated the code and it worked! for like 10 seconds... :(

After just starting the game, and clicked, the char started moving then the app just closed.

And yeah, it's a bit annoying the "hiding/showing" of the window. I bet it'll improve a lot if you just use screens to manage your code. :)

Did away with the close/show code, and pushed.
The user experience is a little better now(as the window doesn't disappear and reappear), but warehouse(the thing that allows purchase of new inventory) is still dead slow(it takes way too much time to load up)(because of which screen remains frozen for a long time).
I will profile it and post the results soon. In the mean time... any other observations?

lobo_tuerto: what version of ruby are you on? i was on 1.8.6 and it never used to crash, ever since i moved to 1.8.7, it crashes once in a while. If you got a 1.8.6 installation by any chance, may be its worth trying to run it with that.

If you experience crashes on 1.8.7, is that with the latest version of Gosu? I had to push a hotfix out one or two versions ago because the behavior of Ruby's GC had changed. It's a bit unfortunate because it means that Gosu games packaged earlier may not work reliably anymore :(

In that case i will probably upgrade to the latest stable, because the one thats frozen is pretty old. Will post back once the upgrade is done.

This is the error I get, happens when I move a little, just after starting the game:

lobo@lobo-laptop:~/development/gamedev/bakery$ ./bakery
./src/customer.rb:132: [BUG] object allocation during garbage collection phase
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]

Cancelado

The other error was when trying to run it from Ruby 1.9.1

Yep, this is exactly the change in the Ruby GC behavior that caused the problem and which I hotfixed from Gosu's side. It will also happen on recent patchlevels of 1.8.6, like those delivered via the OS X Software Update. So now you can guess why the new Ruby wrapper .app contains a complete, unpatchable-from-outside Ruby installation ;)

Upgraded to gosu 0.7.14, so it should work now on 1.8.7.

jlnr: any plans around fonts problem(on linux)?

Feedback?

It works! :)

Finally I could play it, good job!

> any plans around fonts problem(on linux)?

You can always ask people to install the fonts on their system… ;) The problem is that the underlying library (pango) is too confused in its own abstraction to do a simple file loading. cairo has been suggested as a replacement once or twice. Without contributed code, the To Do item will stay on its current schedule :)

See the ToDo wiki page for the stuff that I want to finish before I want to dedicate a full release of Gosu to typographical issues.

any feedback/findings on why warehouse(screen where you purchase new inventory) takes so much time to load?