Messages

On the advice of the mods I just marked this thread "solved." Thanks to al those who helped! The topics evolved a little, so if any other newbies are reading, here is what I learned:
(1) A character's can be forced lower than normal by using character.z, though we have to be careful with scaling, since he will appear closer to the camera yet no larger, and with walking behind objects)
(2) a screen can be made lower than the visible part, remembering to use 'setViewport' to keep the room from scrolling down, and remembering that the uer cannot of course click below the level of the visible room
(3) trapping a mouse click or mouseover for the purposes of special (click-on code) is not as difficult as it sounds

Sorted! 

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.

Thanks for the suggestions. I'll probably be back when I have some real code in week or three. The important thing is I know now that everything I want is possible, and roughly the form it will take. Thanks again.

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.

Thanks for the advice.

If you post the code you're currently using, and why you think it mightn't be as reliable as you'd like, we could maybe suggest ways to improve it if needed.

I haven't written it yet - it's just pseudo-code. But I need to plan ahead because this kind of decision affects the basic design of the game. The reason I am cautious is (a) I'm new at AGS, and (b) this means going further away from the "normal" way of doing things. Long experience tells me that somewhere down the road this will lead to some minor but hard to trace bug. Bug tracing takes longer than anything and is my least favorite job!

Thanks for the suggestion. I'll try that.

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.

Would that work for hotspots? For example, a lot of my background objects contain trees. I want a generic "tree" object so that I don't have to add the same code ten times per room. I can see that an invisible tree character could be placed in the room, but I don't know how it would be called when the user clicks on one of the tree shapes.

If that could be made to work it would be simpler than my idea, which was to add code to the global script so whenever you click on anything its name is compared with a list of global objects. I have a suspicion that my plan may not be as simple or reliable as I hope - your way sounds better, if it could be made to work.

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.

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?

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?

For what you're after here, though, maybe it'd be easier to include a little extra on the bottom of the background graphic, and use SetViewport to stop it scrolling past a certain Y value?

The perfect solution! Thanks!

As a new user I've got to say I'm highly impressed by AGS. Some parts had me worried at first - like there appears to be no way to define an object globally (e.g. "a tree" or "a window" with all its possible interactions) and then drop it into a dozen rooms. But after thinking about it for a couple of hours I think I know how it could work.

Thanks again.

You can set baselines manually in scripts, e.g. oTree.Baseline=165;

Thanks. Presumably oTree refers to an object called tree? Can the same be done for color regions? My rooms have background images, floors, and walkbehind areas defined by an imported 16 color bitmap. So for example if I wanted to reset the blue coloreed area to y ==200 then I'd note that blue is palet number 1, and would the code be something like walkBehind[1] = 200 ??

Thanks. And presumably Character.Moving could be used instead of addWaypoint, to wait until one walk has finished before starting the next?

Edited to add:

Will walking below the screen raise problems with the "walk behind" areas? or is it possible to set a baseline BELOW the level of the bottom of the screen? Can baselines be edited manually?

You could write a routine that constantly checks Character.Moving and assigns them new coordinates, sending 'em on their way with .Walk.

Would that risk re-starting the walk animation every time, so the character stutters or slides?

Thanks. As long as  it's possible, that's all I care about.

Character.AddWaypoint() which ignores walkable areas

I didn't know addWaypoint ignored floors. Is there any alternative? I planned to use it extensively for background crowds, and I don't want them to walk though wals and trees.

Can I make it so that if I click in the middle of the screen, ego walks there as normal, but if I click at the very bottom of the screen, ego walks further toward me so I only see him from the knees up?  Is that possible?

edit: I assume this would need character.z  I don't need the exact code (I can work that out later), I just need to know if it's possible in principle. Right now, before I learn the details of AGS coding, I'm adding 140 rooms from my old Sludge game. Many of those rooms rely on ego being able to move very close to the camera.

a small fast moving object isn't pretty at TV/film framerates.

Off topic, but I never understood that about movies. They should be renamed "jerkies." It looks OK on a small TV screen, but at the size of a cinema screen any full screen fast movement is terrible. Next time you go to a big screen movie, look at rapid movement, especially at the edge of the screen.
Maybe it's because I live in Britain and they convert two different frame rates? But I wouldn't think that applied to movie houses.

Maybe that's why video games are so popular - smooth moving pictures are a technological novelty.

Just thinking aloud. Maybe it's just me.

If you're very worried about unforeseen complications make a test room with a worst case number of characters and scaled objects. It shouldn't take long.

Good advice. I tried that, and as far as I can tell things will be fine. Though to be certain I'll need to create a very complicated mock up involving large static fixed size objects, numerous small moving smoothed objects, loops, code to make sprites walk towards the visible part of the scene, different views to be loaded for each character, etc... but I'm increasingly confident it will work. AGS is looking very impressive indeed.

Chances are nothing will be unless you're doing something very unusual.

"Very-Unusual" is my middle name. (It's hyphenated. Caused all kinds of confusion in kindergarten...)

The scrolling speed is related to Roger's walking speed; the screen is moved so that Roger is always centered, if possible.

Ah, that explains it. Thanks! On a related note, 40 frames per second is more than I expected. Movies get by with 24-30 fps, cartoons with even less. Is there a reason for this generosity, like redraws are noticable at lower rates? Or is AGS just showing off?