Filtered scale

[monele]

I fondly remember the zoom function but less fondly the fact it was very taxing on the processor. As an in-between solution, I just wondered if there could be a way to apply a filtered (bilinear?) scale to pictures just as you can tint them or composite them before displaying them. Since this would be even slower, they could be used in more distinct steps, along with a dissolve.

Let's say I have a character in a dark room. I want a first step where it's smaller (in the back of the room) and tinted with black (silhouette). Then with a dissolve, the characters gets closer (bigger and less tinted). And the final step is the regular character sprite : full size and no tint.

Would it be better to make all three versions on disc or to have on-the-fly processing ?

[PyTom]

You can try using im.Rotozoom, which IIRC does a filtered scale, at least up to a point. (I'm not sure how well it works beyond halving or doubling the original image size.)

Beyond that, I would precompute the images and store them on disk.

[monele]

Darn... I even looked at the list of functions not so long ago and remember seeing this now o_o;;...

Let's add another question then : how well will it work in terms of performance ? Does it use the preloading to avoid slow downs or something like this ?

And just to confirm : is it possible to generate a set of pictures and group them into an animation ? (for example a set of 8 pictures that would span a 360° rotation). When would the processing be ? At the initialization ? A bit before the animation is called on screen (preloading) ? Or just as it's called ? :/

[PyTom]

All the im.whatever functions do their work when the image is loaded into memory, which would be preload time. Preload time, in turn, is some ill-defined time before the images are actually shown to the user, when we have a bit of spare time.

There's also the image cache issue. The image cache only holds (IIRC) 8 screens worth of images, by area. You should probably design your game so you don't show more than 8 screens worth of images to the user at once.

(This 8 screen limit includes every frame in an animation that is shown to the user, for example.)

[monele]

So... assuming I created an animation with 12 frames and it was the only thing displayed in a scene, I suppose the cache would contain the last 8 of them and would then slow down to reload the 4 first frames (and then the next ones since they've just been pushed out of the cache ?...). Is this how it works or am I misinterpreting ? ^^;

[PyTom]

No... the cache is actually burstable. Although it tries for 8 screen's worth of data, it will grow if it must to accomodate everything that's on the screen right now. (If an image is a frame of an animation, it's considered to be on the screen right now by cache standards.)

So what will happen is 8 or so of the 12 will be loaded in the preload phase, and then the remaining 4 will be loaded right before the screen is displayed. Actually, somewhat less that 8 will be loaded, since the cache has to keep the contents of the previous screens in memory.

Realize that the cache stores uncompressed images, so each screen in the cache takes:

800 * 600 * 4 = 1,920,000

bytes (at least on systems with a 32-bit depth).

The cache is keyed in on image size rather than number of images, so small images like character graphics and the text window will take less then one screen. (An 800 x 150 text window will take under 20% of a single screen, for example. We could store 5 of them and not take up a single screen's worth of cache.)

You could always up the image cache size (by setting config.image_cache_size to something larger than if necessary. The default size was set fairly arbitrarily to balance out memory usage and image prediction, in the mostly static games I'm accustomed to.

I'm curious what you think you need 12 frames of animation for, as the most I can recall in a professional game was around 4-5, and the most in a _good_ professional game was 2-3, plus a screens worth of transients in both cases. Anything longer then that was a movie of some length.

[Alessio]

Thanks for the explanation, it might be monele was calculating the same way I was to get to a total of 12 animation frames: 3 characters with 4 phases of blinking eyes each (open - halfway closed - closed - halfway closed) would already be 3 x 4 = 12. But luckily it seems that's not how Ren'Py is counting. :)

[PyTom]

I should point out that if using LiveComposite, then this may not be a problem. That's because each of the frames of eyes is much smaller than a full screen's worth of data. (Probably, a character + all eyes is about half a screen or so.)

It's usually only when animating full-screen backgrounds that things get a little hairy.

(I should also point out that things will always work, it's just if they have loading pauses or not that concerns us.)

[monele]

Thinking back on this during this afternoon, I was really afraid Ren'Py would... "stream" from the HD once it had reached its limit. Now you're saying it *will* load anything and that the cache is really limited in image size (either many little pictures or a few big ones).. (am I right so far? ^^)

Now don't worry, except for the extreme examples found in the demo with fully moving backgrounds (and loaded twice to loop e_e;;;...), I'm only asking about cache and animations for ... well... smaller things *turns around and chuckles*

I'm curious what you think you need 12 frames of animation for, as the most I can recall in a professional game was around 4-5, and the most in a _good_ professional game was 2-3, plus a screens worth of transients in both cases. Anything longer then that was a movie of some length.

Well let's just say that if things work as I hope them to work, it will be *really* fun and won't be called "static" anymore ^.^. Might require a good machine though. Must test how well Ren'Py handles all this.
I'll keep you updated in more details once the tests are done if you want.

[monele]

Tried Rotozoom. It has a strange behaviour when it comes to filtering the result : rotating a 100% image results in a bilinear filtered image. Scaling up an image results in a bilinear filtered image. Scaling down an image, though, wether rotating it or not, results in a nearest neighbour filtering :/... Makes things all sharp.

I've had a few ideas using rotozoom that would all use a single hires picture to create other pics at various zooms (close, normal, far). I'm thinking "economy in file sizes" but also "ease of manipulation" (just changing a number in the script is better than having to crop-resize the image from the editor)

EDIT : Oh and since I'm at it >.>.. (not worth another topic)... im.Map doesn't seem to allow any desaturation of a picture, right ?

[PyTom]

Unfortunately, no desaturation (or any other multichannel operation) is possible.

[monele]

Hm, sad :/... Any way we could access to image content to filter them ourselves ?

What about rotozoom ? ^^;

[PyTom]

Hm, sad :/... Any way we could access to image content to filter them ourselves ?

Not really. Python is a bit too slow to do image manipulations of this sort. That means that the image manipulations would need to be done in C. And it's really hard to get C code running on the 3 platforms I support, let alone other platforms.

At the end of the day, Ren'Py isn't photoshop.

What about rotozoom ? ^^;

Ditto. Rotozoom exists because it's provided for me as part of pygame. So whatever pygame's rotozoom does, that's what Ren'Py's rotozoom does.

[monele]

Eh :/... big sadness!... *can't wait for RenPyGL :3*

[shaja]

It is possible to use PIL with RenPy, with the full range of processing that allows - separating channels, nicely filtered scale and rotation, and even convolution-kernel filters for blur and such.

But it's not nearly as easy as using the regular RenPy functionality, and I think the only advantage it might have over pre-processing in Photoshop is just the space you'd save in not having the premade files - and even that might be outweighed by the size of the PIL library files you'd have to include with your game.