Forums Archived

The forums are being archived. See this topic for more information.


Post about games, applications, etc. made with Rubygame. Feel free to promote your own projects here!


Postby Groogy » Thu May 20, 2010 5:06 am


I've made a LoadingManager module that will spawn a new thread when LoadingManager.load is invoked. I'm kinda new to the Thread idea and have only played around with it in irb mostly. So I'd like you all to comment on it(either here or on my webpage) and possibly say what I can do better and stuff like that.

Code: Select all
require 'rubygame'
require 'loading_manager.rb'

LoadingManager.load Rubygame::Surface, "image1.png"
LoadingManager.load Rubygame::Surface, "image2.png"
LoadingManager.load Rubygame::Surface, "image3.png"

# Will print something between 0.0 to 1.0 depending on how far the thread has gone
p LoadingManager.progress
# Wait for the loading to finish before exiting the application.

I've made it quite independent so you don't need Rubygame for it to work but you'll have to change the module specified in LoadingManager::LOADER_MODULE(defaults to Rubygame::NamedResource).

For the source and more information see: ... g-manager/

The code got a lot of documentation for each method so should be pretty easy to comprehend what everything does.
Posts: 11
Joined: Tue May 18, 2010 10:57 am

Re: LoadingManager

Postby shawn42 » Thu May 20, 2010 3:00 pm

I'm not sure this really buys you anything with the exception of maybe in JRuby. All other Ruby implementations have a global interpreter lock (GIL) that they share. So even though it is threaded, each FFI call out to SDL will lock the GIL. Jacius could change the SDL bindings to not lock the GIL (:block => true or something in FFI-land).

I'd like to see a breakdown of any performance gains you've observed vs just loading all the assets sequentially (mutex locking is not a fast operation). This is just my knee-jerk reaction, maybe you're on to something awesome and I'm just missing it. Performance numbers would help a lot.
User avatar
Posts: 109
Joined: Tue Feb 10, 2009 8:22 pm

Re: LoadingManager

Postby Groogy » Fri May 21, 2010 6:58 am

I know about the GIL, read some about Ruby 1.9 threading. But it would only go faster on a computer(if it weren't for GIL) with a multicore processor. I sat like 1 week going back and fourth if it was worth the effort of doing this module for my project but then when I decided to do it, it took less than 3 hours. Funny how things turns out.

The purpose of the module is not to make it go faster but only to make it go smoother for the developer to load in the files needed.

For example:
Code: Select all
model1 ="model_data1.yaml")
model2 ="model_data2.yaml")
# Will look into the model_data yaml file and see what files are required
# for this model and queue them into the loading manager. But it will return
# with an instant since the Loading thread will handle it from there
# Several lines later we display the loading screen with progressbar for the loading.
# Then a bit later we finally come to the game and:
game_object1 = model1.new_instance #=> Game::Object
game_object2 = model2.new_instance #=> Game::Actor
# etc. etc.

So I'm not looking for speed. Just make so that loading stuff won't give huge delay times that's noticeable on the screen by the user. The application should still be running at a decent framerate(might be lower) but if used in-game it shouldn't make the user notice that the game is actually loading in something new and give it a more smooth appearance.

Don't know if that's awesome but that's the intention of the manager. It's my first Threaded application but I did my research at least ;)
But what's most efficient? Using Thread.critical or mutexes?

Though I'm not familiar about FFI so can't comment on that :P

Actually, on my application my framerate skyrocketed after clicking "new game" and the loading screen(With the loadingmanager running) appears, but that's probably because the loading screen is only white background with text displaying progress and what is currently being loaded. While the title screen got buttons and moving text.
Posts: 11
Joined: Tue May 18, 2010 10:57 am

Re: LoadingManager

Postby jacius » Fri May 21, 2010 4:36 pm

shawn42 is correct about the GIL. On most Ruby interpreters, all Ruby threads will pause while the SDL function is running, even on multicore processors. So, you won't see any speed gain from doing this, compared to loading them sequentially.

But, that said... there is some merit in using a separate Ruby thread to load assets: it would allow you to "spread out" the pauses from loading the assets, so that the user wouldn't notice one very long pause. This would be especially true if you have many small assets to load. The interpreter could load an image, run some code in the other thread, load another image, run some more code in the other thread, and so on. This could be a good strategy for loading assets for level 2 while the player is still finishing level 1, for example.

P.S. to shawn42: I hadn't heard there was a way to make the bindings non-blocking with FFI. Do you have a link to more info about doing that?
User avatar
Site Admin
Posts: 131
Joined: Fri Feb 06, 2009 11:13 pm

Return to Creations

Who is online

Users browsing this forum: No registered users and 0 guests