is FLC rock solid in Linux?(SOLVED)

[EnterTheStory (aka tolworthy)]

Hopefully this will be my last newbie question for a while... I've checked the manuals and the forums, and it appears that FLC files should run in Linux, whereas AVI raise more problems. But I am nervous to see how FLC and AVI are sometimes used in the same sentence. How reliable is FLC in Linux? Is it rock solid? Can I rely on it for complicated and essential scenes? Or is there the smallest chance that the FLC parts won't always work in some flavors of Linux? Any issues here?

[Gilbert]

FLC should always work, as it's handled internally by the engine, whereas AVI requires external applications (and codecs, maybe) to work (for example the Windows engine need to call DirectPlay for this).

However, FLC is quite limited in terms of colour depth (only 8-bit) and compression rate (also, without sound, you need to play other sound alongside with the movie if you need sound in playback). So, it's up to you to decide which to use (or don't use any FMV at all).

[EnterTheStory (aka tolworthy)]

That was a quick response. Thanks!

However, FLC is quite limited in terms of colour depth

[edit to remove robust but irrelevant defense of FLC format]

After testing, it seems that AGS stretches FLCs to full screen, and adds a screen flash before and after. So FLCs are unsuitable for normal use. A pity. I've tried other ways to add animation, with no success:

Attempt 2:

Sprites are out because they only allow 15000 frames. I have several animations that exceed 1000 frames, so would soon exceed that.

Attempt 3:

using rawDraw is out, because it seems to only use sprites.

Attempt 4:

'CreateFromFile' seems to need BMP files that are not part of the compiled exe. I could bundle twenty thousand tiny BMP files in the same folder as the game, but somehow I don't think it would work.

Is there no other way to load images in AGS? Or no way to use large animations without flashing? Or any chance that the 15,000 frame limit will be greatly increased?

[Candall]

I told you that the limit was 15,000 based on the manual supplied with the ags 2.72 release.  Evidently, this is not true as of 2.72.  My statistics menu shows a maximum of 30,000.

[Ashen]

What are you using this for? Is it background animations (crowd movements, etc)?
Flics don't HAVE to be streched to fit the screen (read the manual, which you already should've done) but even so wouldn't be particularly good for that. The flc would be played centered on the screen, but without transparent areas so it hides everything around it (if you use the 'don't clear screen' option, or with a black border if you don't). Additionally, they're blocking animations, so you wouldn't be able to DO anything while they're running.

If you can tell us why you need animatons with so many frames, we might be able to suggest workarounds - but the most obvious answer is likely to be "use less frames"...

[EnterTheStory (aka tolworthy)]

30,000 frames eh? That is very good news!

Flics don't HAVE to be streched to fit the screen (read the manual, which you already should've done)

I did. But I apologise that I wrote that part in haste. Yes, technically you can play unstretched, but as you point out, the animation takes over the screen. That is what I should have said, but I was thinking of the interactions button which does not give the size option (that has to be added in a script).

If you can tell us why you need animatons with so many frames, we might be able to suggest workarounds

Here's a typical example: in part of my game a character rescues some children from a  burning house. He walks on as normal, there is an explosion, then fire, he reacts, assesses the situation, runs across the screen, turns, runs toward a window further back in the scene, climbs the building, breaks the window and enters, soon after emerges with one child, and so on and so on. I could create this as twenty or so separate costumes and movements and carefully link them together, but that would take a long long time. These actions will only be seen once, and the character is fairly small on screen, so it made sense to make one single animation. At 30 fps it comes to about 1000 frames, with some gaos for dialog. It really needs even more frames, but that would become tedious. It's a high action event that's crucial to the story so it's hard to avoid. The user can of course skip the sequence if they want.

I have other animations like this - over a thousand frames, with tiny characetrs who do unusual things on the screen. One is a rescue high on a ships' rigging. Another is a policeman chasing and capturing a villain. Another, the opening sequence, is just a very long video, but it has to merge seamlessly with the room that follows. Another issue is that characters exist at three different scales, in eight directions, 12 frames per loop... the sprite numbers rise very quickly.

Having said all that, the 30,000 limit would make a huge difference. I've given this a lot of thought, and realistically I think the first version of the game could probably be squeezed into not much more than 15,000 frames. My concern was for later versions, because each one uses the same game world and interacts with previous stories. But on reflection I will then have the problem that the game will take longer and longer to compile. And of course users may not appreciate being asked to dowload more than they need to. RickJ said that the RunAGSGame feature allows games to be linked together in a way that's invisible to the user, so it makes sense to split the game where possible. A 30,000 limit would be enough to put two or three similar installments together, then join games at places where there is a natural separation. For example, the first two installments take place around the Napoleonic wars, so they need to closely interact. But the next two installments take place underground, so while they also need to interact together, they don't have much connection with the first two. It's a natural break. I would only need one connection between those two groups (say, a cave in Prussia) so it would be sensible to launch one game from the other at that point and the user would not notice the joins.

So the 30,000 change may be enough, being realistic. That is very good news.

[RickJ]

Sorry to hijack this thread but perhaps my question will brink some more ideas to light for tolworthy.  I have a somewhat similar situation and have not done much experimenting in this area.  Perhaps some who has been through this before may be able  to suggest some things try and/or some things to avoid.   Here is my situation ....

I have been given a really cool 3D fly by type animation sequence, with neat camera work and everything.   I would like tp use this in the introduction.  Obviously could just make an AVI  movie with whatever text and sound I wanted overlayed with the animation  but I was wondering how seemless is the switch between game-video-game?   Will there screen transitions or disturbances, timedelays, or other practical considerations?   

I was thinking of experimenting with the method tolworthy is considering, only I don't have nearly as many frames to contend with.   Letting AGS do the animations gives much better control of the animation and more flexible options for adding text and sound.  It also provide the ability to use looping  to create extended animations without requiring more text. 

Anyway I wouldn't mind hearing from anyone who has used either the PlayFlc() or PlayVideo() functions and what their practical experience has been.

Also, tolworthy, from what you describe, I would be tempted to create animated sprites for the characters and the flame/fire and other objects. and then script the sequence.  I would think that it wouldn't be any harder to create animations for individual characters and objects than for the entire video.

[EnterTheStory (aka tolworthy)]

Also, tolworthy, from what you describe, I would be tempted to create animated sprites for the characters and the flame/fire and other objects. and then script the sequence. 

Yes, certainly the ideal solution for me is to create a sprite for each segment and script them together. That way I can reuse them next time I need that character to look surprised, or turn, or run, or whatever. It's just a matter of not wanting to spend the time. I had that sequence ready to use in the Sludge format, and I have it ready to use in FLC format. It would be nice to just plug it in and move on. But I guess I should set aside the time and do it properly. The fire sequence is the most complex, the others will be easier to convert.

[RickJ]

If you're not already familiar with it you may find the free version of Graphics Gale useful for this purpose.  If you were to export frames of your animation clip to separate files then you could import them into Gale where each frame would appear on a film strip.  You can select individual frames for edit or you can do operations, such as cropping or adjusting color depth, etc on all frames at once.  You can save the results as a single file for future edits or export frames to individual files for use as AGS sprites.

[EnterTheStory (aka tolworthy)]

Thanks for the suggestion. I'll try that.

[Ashen]

If it's for 'cutscene' style animations, where you don't need player interaction, why not just use full screen flcs? I think the 'Don't clear screen' option will get rid of the 'flash' you mentioned (which I've heard of, but never seen myself, so I can't be sure).

One suggestion for working around the sprite limit, though. Since you say they're mostly small sprites, what if you import them as several frames on one sprite, and use the DynamicSprite functions to crop them down on the fly? I'm not sure what the processing time would be, particularly when you're talking about 1,000s of frames, but it might be worth a try. Even if you only do 2 to a sprite, that halves the number you'll need. (Howevr, this is entirely untested, so don't hold your breath. It might just cause more problems.)

Or, of course, you could use less frames

[EnterTheStory (aka tolworthy)]

If it's for 'cutscene' style animations, where you don't need player interaction, why not just use full screen flcs?

Mainly the black flash at the start and end as the FLC is loaded or unloaded. But also, while full screen is possible, it means knowing exactly what the screen will look like before hand, and creating a 256 color version of it. In the fire rescue animation for example, ego is standing watching the events unfold. I'd need to force ego to stand in the spot where she appears on the animation, then restrict the user during the pauses of the cut scene. It's doable but very time consuming.

what if you import them as several frames on one sprite, and use the DynamicSprite functions to crop them down on the fly?

That sounds like a useful suggestion. I don't think I need to use it now (given the expanded 30,000 limit and my plans to split my game in the long term) but as the only way to increase sprite numbers it's definitely worth knowing. Thanks.

[ciborium]

One thing that may help your sprite/frame count is reducing the frame rate.  I know American TV uses 30fps, but film uses 24fps.  In a computer game you can usually get away with 15fps unless you have very long quick movements in very high resolution.  So by using 15fps instead of 30, you can cut your total number of frames in half. 

[EnterTheStory (aka tolworthy)]

One thing that may help your sprite/frame count is reducing the frame rate.  I know American TV uses 30fps, but film uses 24fps.  In a computer game you can usually get away with 15fps unless you have very long quick movements in very high resolution.  So by using 15fps instead of 30, you can cut your total number of frames in half. 

I already reduced the overall game frame rate to 30, and most of my sprites work at 15 fps (except the ones that move quickly across the screen, where 15 fps looks very jerky).

The fundamental problems were:
(1) using pre-rendered animations (to simplify scripting),
(2) the 15,000 limit (which is roughly the same as my expected total - it makes me nervous to have no flexibility), and
(3) the plan to add more stories to the same game in future.

All of those problems are now solved: as I become more familiar with AGS I will use more scripting and less pre-rendering, the 15,000 limit is apparently now 30,000 (hurrah!), and I now plan to divide the game into maneagable chunks that will hopefully link together seamlessly. So all is well! On the wise advice of Ashen  I have now marked this thread "solved." A big thankyou to all who helped out.

If anyone else wants to comment of course feel free, I'm grateful to learn new things all the time, especially about my favorite file format, FLC. But this topic is no longer on my "things to panic about" list.