Strict Standards: Non-static method phpbb_feed_factory::init() should not be called statically in /home/jacius/rubygame/forums/feed.php on line 66
[phpBB Debug] PHP Notice: in file /feed.php on line 171: Cannot modify header information - headers already sent by (output started at /feed.php:66)
[phpBB Debug] PHP Notice: in file /feed.php on line 172: Cannot modify header information - headers already sent by (output started at /feed.php:66)
Rubygame Forums 2010-05-21T18:20:23+00:00 2010-05-21T18:20:23+00:00 <![CDATA[Re: LoadingManager]]>

Statistics: Posted by shawn42 — Fri May 21, 2010 6:20 pm

2010-05-21T16:36:14+00:00 <![CDATA[Re: LoadingManager]]> 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?

Statistics: Posted by jacius — Fri May 21, 2010 4:36 pm

2010-05-21T06:58:50+00:00 <![CDATA[Re: LoadingManager]]>
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:
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.

Statistics: Posted by Groogy — Fri May 21, 2010 6:58 am

2010-05-20T15:00:06+00:00 <![CDATA[Re: LoadingManager]]>
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.

Statistics: Posted by shawn42 — Thu May 20, 2010 3:00 pm

2010-05-20T05:06:25+00:00 <![CDATA[LoadingManager]]>
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.

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.

Statistics: Posted by Groogy — Thu May 20, 2010 5:06 am