[XP] Non-blocking way of loading bitmaps?

[Terv]

Hi,

Loading bitmaps via the built-in Bitmap class is halting program execution until the file is fully loaded. This is also true when done in a seperate Thread. Not sure about fork or spawn as those are not supported by Windows Ruby 1.8.1. Is it possible to asynchronously load bitmaps from files (mostly pngs) without lag, maybe using some third-party library or dll? I took a look at chunky_png and RMagick, however I suppose those don't work in RM-Ruby.

TIA, cheers!

[Blizzard]

Ruby doesn't support fork() and spawn(). And yes, this also happens in a new thread, because Ruby 1.8.1 doesn't have real threading.
Even if you loaded files with an external library, all you would get is a bunch of color data that you had to blt() on the manually created Bitmap anyway so you wouldn't really gain any performance.

[Terv]

Well it's not about the improved performance of multiple green threads (if there's any) but avoiding the small lag that occurs when loading a new tileset/lightmap while the player is wandering a map. If I could I'd just load these files in a seperate thread in advance and swap them when it's time.
I've put my autosave system into a seperate thread as well and it eliminated the hickup so I was wondering whether this is possible with caching bitmaps too.
I wouldn't mind if it took three times as long, however it shouldn't affect the main thread as the built-in Bitmap does.

[Blizzard]

But that's exactly the problem, it can't be queued into another thread, because Ruby 1.8.x doesn't have real threading. All threads are executed sequentially without switching between them.

[Terv]

  So why can you, for example, calculate pi in a seperate (Ruby 1.8 ) thread while not experiencing any significant lag in the main game thread itself?

[Blizzard]

Because file input/output is implemented in C, not Ruby. Ruby just calls C functions internally and because it's not really threading, Ruby has to wait for the C function to finish. It's the same reason why calling Win32API calls in Ruby causes the game to freeze until they are done.

[Terv]

Ah now that makes sense, thanks for enlightening me so I guess no lag-free image loading on XP with 1.8.1 :/

[Blizzard]

Nope. :/

[KK20]

Just curious, what are you trying to do? I mean, if it lags to load bitmaps, why not just load them during times where lag is prominent/less inconvenient (such as during teleporting or starting up the game)?

[ForeverZer0]

You could run a small snippet to pre-cache bitmaps using RPG::Cache when the program is first launched. It would add a few seconds to the initial startup time of the game, but would allow for a little smoother loading of maps, etc. Depending on the size of the game and number of bitmaps, this may not be a viable option due to RAM usage, but for most RM games, that really wouldn't be an issue. At the very least you could just load some of the larger files, such as tilesets.

Like I said, it may not be a dramatic change, but would help.

[Blizzard]

I preload icons in CP and create desaturated versions on the fly during startup. It saves me time when accessing the ingame menu's item screen and other screens. I have around 1.5k icons so it really makes sense to do that. Keep in mind that loading times are a normal occurrence in games.

[Terv]

Just curious, what are you trying to do?

For every outdoor map, for each time of day there's a dedicated light-/shadowmap, along with a region-specific tileset, which are changed on-the-fly on the map and tend to be rather large.

why not just load them during times where lag is prominent/less inconvenient (such as during teleporting or starting up the game)?

You could run a small snippet to pre-cache bitmaps using RPG::Cache when the program is first launched.

This is what I currently do, pre-buffering graphics at the start and in inns or in lieu of wait commands in events, etc. So far RAM usage never exceeds 400 MB.
Yet I thought it was kind of a waste and was wondering whether there were more elegant alternatives. Furthermore you'll be able to stream the game, so I'd really like to keep the required minimum preload (files accessed in the first ~3 minutes) as small as possible (<50 megs), while avoiding stutters on maps later on in the first chapter.