Trimming graphics and GPU questions (best practices)

Hi!
For the last 7 days, I've been bleeding over my keyboard trying to get a grasp of Visionaire studio! Unfortunately information is quite scarce, so I feel I need to bother you at the forum -

here's a question (more coming soon, since I've hit bottom):
Is there some significant overhead when using untrimmed png images for scene objects/animations?

For instance: if I make a scene with a 1920x1080pixels "bedroom" artwork and need to add a 20x20px alternate-state for the light-switch, would it be okay (performance/memory-wise) if I exported the flipped light-switch retaining its original offset inside a huge 1920x1080 png file, but full of transparent pixels apart from the 20x20px area?
Or should I trim it down to 20x20px before exporting it? and move the flipped-switch to its correct position when inside visionaire studio? File-size won't be much different since it's empty pixels, but what about the space occupied in the graphics card memory when loaded? Would it expand to 8MBs for a single sprite (uncompressed), or would it be internally trimmed occupying only the 20x20px area?

What about in-engine animations? If I have a background and wish to animate a)the leafs on a tree, b)the river flowing and c)some ants crawling, How would visionaire studio/player treat the following three scenarios:
1) ...if each animation frame is the whole background re-exported: 1920x1080 with no transparent pixels (lets assume we don't care about the disk-space for now).
2) ...if each animation frame is 1920x1080 but only the animated areas contain non-transparent pixels.
3) ...if three separate animation sequences are generated for the leafs, the river and the ant-infested region respectively.
How would the performance be in the 3 scenarios? what about the GPU memory consumption?

Sorry for the lengthy email, but I'm trying to understand a bit how visionaire studio treats graphics and what are the best ways to work!

Thank you,
Fotis

There is some information on image formats for Visionaire in the Wiki:

http://wiki.visionaire-tracker.net/wiki/Image_Encoding

This thread may also answer some questions:

http://www.visionaire-studio.net/forum/thread/trimming-the-g...

Also, this page... http://wiki.visionaire-tracker.net/wiki/Game_Optimization

It's not necessarily what you asked, but I have summarized various methods for optimization of your game. The smaller the file sizes, the less animation frames you use, the less surface area you use, the better. All in all it will add up to a game that can run faster & smoother on older machines as well as newer ones.

My experience is: avoid this huge animations, transparent or not! Use the 20x20px one.

I have the same problem: my scene is 2500 x 2550 px (png) and I use some animations at the same size as a whole-sized png-overlay. The first run is VERY(!) SLOWLY, because I think the engine has to load the unzipped animation completely in one moment. After some runs the speed is ok, more or less, I think it's in the cache now. I better need to use something like a preload cover screen and start EVERY animation once behind it. But: only if the character doesn't move a lot. After some movements to the other side of the scene the same animation is slow as before! May be the scene is "splitted" into squares to run faster (could make sense). Or the cache isn't big enough to store all animations at the same time... My opinion: This "animation preload" doesn't work properly in the 4th Vis version: EVERY new start of the same animation (also every outfit animations) will be slowly, preloaded or not.

Take a look into some old-fashioned pixel games like "Myst". There are full-screen backgrounds and only the animated things are put in as little squares to load at the exact place. Because of using pixel graphics Visionaire takes a lot of memory and becomes very slowly with too much transparent graphics. I'm not a developer to explain why, but more than three or five transparent overlay animations at the same time makes the player freeze.

Machtnix

Thank you @AFRLme and @redspark for the mention of the image encoding/game optimization Wiki entries; I was aware of these, but of course a second read, does more good than bad.

“

This thread may also answer some questions:
http://www.visionaire-studio.net/forum/thread/trimming-the-g...

„

@redspark, the thread was spot on! You put my searching skills to shame, - I thought that I had searched the forum thoroughly before creating a new thread! My bad :/

@Machtnix: Thank you for the lead! After reading your answer and the quoted thread (above), I'm still a bit confused though...
In the thread @Marvel says that upon export, the images are automatically trimmed. This should had been enough to assume that we can (and for practical reasons, should) export scene objects and their animations (even if they are 20x20px small), untrimmed: At the full scene-size, with lots of transparent pixels (graphics fat) surrounding the objects. In other words, PS/Gimp "layers to files".
However you advise against doing that - am I right? Or are you referring particularly to scenarios such as the example of the "river+leaves+ants" background-animations, where the content might be scattered around the scene and thus can't be trimmed sufficiently when the game is being exported?

Thank you all for the help!
-Fotis

“

In the thread @Marvel says that upon export, the images are automatically trimmed

„

I still use the demo version to test what Vis can or cannot. I think in the demo player version isn't such a trimming.

My example animation needs this "all over size", so I exported it from PS with a huge transparent "layer to file" as a png. The problem isn't that the animation becomes slow ever - the second or third run is ok! - , but the first run of EVERY animation (such as first used looped outfits too) is slowly.
I mean: ONLY the first run.

That's a cache thing or how the engine works inside. The engine works fine with large animations if they are in memory / cache, but the engine can't preload them (may be in an additional preloading screen) to make them faster at the first time using...

You can use this "leaves and rivers" animations if you want. But at the FIRST run the player will be frozen...

There are "preloading" actions in the editor, but I haven't understood how they work properly. Sometimes the animations or persons are hidden...

Machtnix

By default animations load frame by frame. This was done to speed up the loading process as opposed to trying to load an entire animation in one go.

The preloading action part works by loading the entire animation into the cache, but it does this in real time, as soon as you execute the action, so if it's a large animation & you call this action during game-play then it is likely that the game will temporarily freeze or lag until the animation has done loading.

A few things to note about preloading animations & the cache in general...

1. you must remember to manually unload preloaded animations when you no longer need them as they don't manually unload themselves from the cache when you leave the current scene, thus over time your game could start running slow (lagging).

2. I have no idea what happens when you fill the cache & the player tries to add new things to the temp cache. Does it automatically clear old stuff from the cache whenever it loads something new? Does it clear the temp cache when you change scenes? Or does it just fail to store things in the cache? I guess one of the devs would have to answer this, as it's an internal thing & I have no idea.

3. In the game tab you can actually specify the cache size in mb. I don't think the value really needs to be that high though.

Thx, Lee. I've read this preload thing at the Vis Data Structure (f.e. GamePreloadedPicBufferSize), but I really don't understand it.

When I remarked the 2nd and 3rd run of the same animation works fine (I triggered it to run three times), I tried to make an overlay scene cover object at the game's start (like a screen "please waiting"), started the huge animation as a covered one beneath and than I made the cover object to invisible. But it doesn't work, it's unlogical to me. The first visible run is slowly as before. The animation must be in the cache (it runs once!). It's possible that the animation must be visible to get it into memory??

In the cache list (player command tool) all frame pictures of the animation are listed. I've increase the picture cache up to 200 MB... If I use the "unload" action, the animation wouldn't start sometimes.

I can't stand it... Very strange.... :-)

Machtnix

Preloading should work even if an animation isn't running. Unless it just keeps it in the cache permanently after being run once until manually unloaded.

I don't know about using massive animations. Thus far we've used animations that have been cropped down to what we want them to be, & since I converted all the images to webp format we rarely get any lagging (well on my laptop at least).

“

Preloading should work even if an animation isn't running. Unless it just keeps it in the cache permanently after being run once until manually unloaded.

„

Hm, I'm not quite sure about this. F.e.: At the start of the scene I set an action "preload animation xy", and after them I start it. Worked fine in 3.7 and 4 beta.
So it wasn't running while using "preload". That seams logical to me, but the animation doesn't start (or isn't seen any more) now. So I kicked this "preload" out. I think there are some changings in the final 4.2 version.

Machnix