5 frame limit on background animations

[Trisk]

At CJ's suggestion, I'm posting about a problem I'm having to see if anyone else is having it too. I want to be able to do screen transitions by having the "camera" actually pan quickly from one point to another, seamlessly changing the rooms. For instance, in Prodigal 2 I have a bookstore you visit early on. I want to make each isle of the bookstore its own room, and have the main character walk along the end of them, with the camera panning quickly to the next AGS room.

I can't do this with a fullscreen object, because it obscures the characters in the room.

What I'm finding is that 4 frames just isn't enough and looks too jerky and goes by too quickly to have a good effect. I'm wondering if anyone else thinks that the 5 frame animation limit is too few?

If there is anyone else who would like to see CJ put more frames into the background animation, please sign in here. He said if he knows there is a demand for it, he will "up" it on his list of things to do.

Thanks,
Ben

[GarageGothic]

Can't you just RawDraw sprites of the animation frames onto the background?

[Shane 'ProgZmax' Stevens]

I definitely think background frames should be relegated to playing from a view so you can change them with a standard animate type call.  This would of course mean more frames .

[GarageGothic]

You could make something like this:

Code: ags

int backgroundspeed;
ViewFrame *backgroundviewframe;
int backgroundcounter;
int backgroundplaymode;

function AnimateBackground(int view, int speed, int loop) { //speed is the number of loops each frame will be displayed
   backgroundplaymode = loop; // 0 plays once, 1 keeps looping
   backgroundcounter = 0;
   backgroundspeed = speed;
   backgroundviewframe = Game.GetViewFrame(view, 0, 0);
   RawDrawImage(0, 0,backgroundviewframe.Graphic);
   }

function StopAnimateBackground() {
   backgroundspeed = 0;
   }

Code: ags

function repeatedly_execute_always() {
  if ((backgroundspeed > 0) && (IsGamePaused() == 0)) {
     backgroundcounter++;
     if (backgroundcounter >= backgroundspeed) {
        int backgroundcurrentframe = backgroundviewframe.Frame;
	backgroundcurrentframe++;
	int backgroundcurrentloop = backgroundviewframe.Loop;
	if (backgroundcurrentframe >= Game.GetFrameCountForLoop(backgroundviewframe.View,backgroundviewframe.Loop)) {
	   backgroundcurrentframe = 0;
	   backgroundcurrentloop++;
           if (backgroundcurrentloop >= Game.GetLoopCountForView(backgroundviewframe.View)) {
              backgroundcurrentloop = 0;
              if (backgroundplaymode == 0) {
                 backgroundspeed = 0;
                 return;
                 }
              }
	   }
        backgroundviewframe = Game.GetViewFrame(backgroundviewframe.View, backgroundcurrentloop, backgroundcurrentframe);
	RawDrawImage(0, 0, backgroundviewframe.Graphic);
	backgroundcounter = 0;
        }
     }
  }

EDIT: Now the code will proceed to use the next Loop in the View allowing for a huge number of background frames.

Most likely you don't actually need to draw the entire screen due to GUI's or letterbox bars at the top and bottom. In that case you can cut down the sprites to the actual background area to save memory and speed things up, and then just change the (0,0) in the RawDraw command to the right coordinates.

Probably it would be useful to add a "reverse" parameter too as well as a "blocking" parameter (only for non-looping mode of course).

[Radiant]

Sure you can do it with a fullscreen object, just give it a baseline near the top of the screen, and make it ignore walkbehinds.

[LimpingFish]

But wouldn't using a fullscreen object cause massive slowdown? Well, in anything over 256 colour 320x240?

[Shane 'ProgZmax' Stevens]

Depends on what you're doing.  The intro animation for my Leisure Suit Larry game uses a 320x240 object @ 16 bit color and has no problems, but then look at my fullscreen layered object animations in Mind's Eye and how they slow down the engine horribly.  Basically more than 2 large, transparent animating objects are really tough on the engine, but non-transparent stuff seems okay as long as you don't go crazy.  I still think built-in support for more background frames would be a good thing.

[LimpingFish]

I agree.

[Radiant]

In my experience high resolutions cause slowdown (e.g. 640x480 and up) as do using too many RawDraws, and using translucency (not mere transparency) mainly in windowed mode; full screen seems mostly unaffected by that. I coded most of ATOTK on a 350 MHz machine and I'm not overly worried about performance. META gets a tad slow at times, but it runs in 800x600.

[monkey0506]

translucency (not mere transparency)

What meanest thou with this speak of "translucency"? AGS Error 404'd: Does not compute! Suggestions: "Partial transparency". Oh I see. You mean setting the *.Transparency property to greater than 0 but less than 100. Why didn't you just say so?


*on topic*

It would be nice if we could have more background frames (specifically if we could link them up in a view)...but there's usually a workaround.

For example, this:

I want to be able to do screen transitions by having the "camera" actually pan quickly from one point to another, seamlessly changing the rooms.

Sounds a lot to me like a job for the SlideRoom module, though I could be mistaking what you mean (not trying to just pimp my modules...the way I'm reading that he wants to do exactly what the SlideRoom module was made for....?).

P.S. Minor grammatical fix: "each aisle of the bookstore"

[Trisk]

Yes, there are certainly workarounds...with an engine as powerful as AGS, there always is...That said, GarageGothic, yours looks alot more elegant than mine. I shall probably integrate something like what you've put here.

As for fullscreen objects slowing things down, they don't. I've tested 640x480 at 24fps (film industry standard) and they run just beeeotiful. Only trouble, as noted, size.

Monkey, I like my aisles to be isles!  But no, you are misunderstanding me. I mean, for instance, changing the camera location from facing north showing the whole area, to the camera facing south showing the whole area. This means frames of animation as the camera moves and rotates...not just sliding an oversized background...all slidey. :b

I just mean the easiest solution to all this would be to up the background frame limit, as a 5 frame limit seems kinda arbitrary and low anyway...

[monkey0506]

So you mean you're wanting a 3D panoramic effect? If that is what you mean then perhaps you could make use of the Panorama module by SteveMcCrea. Unless I'm just missing the point again.

[GarageGothic]

I'm really very curious how you'll move the characters while the (I assume) prerendered camera pans and not make it look weird - especially as the characters were your original reason not to use a fullscreen object.

[Pumaman]

I just mean the easiest solution to all this would be to up the background frame limit, as a 5 frame limit seems kinda arbitrary and low anyway...

Although it is arbitrary, there is method to the madness -- basically, I didn't want to allow the room files to grow too big. If you've got five 640x480x32 backgrounds in a room file, it can grow to a few MB's in size, and allowing more backgrounds would increase the file size yet again.

Of course, times have moved on and loading 10 MB into memory isn't a big deal any more, so those restrictions can probably be relaxed now.

[Trisk]

Reeelax 'em! Reeelax 'em!  And btw, I watched MST3K episode 903: Puma Man last weekend and laughed my head off! Great episode! Awful movie!

Garage - verrry carefully. I actually only have my theories right now, and haven't been able to test them 'cause of the background thing. I will basically have to move the character(s) based on math, and tweak the math to get it right so that they move along with the background. I have a little room for fudging it as the character will be walking, which will hide a bit of jitter if I don't get it bang on.

I'll know how it works soon...I'm about to set it up and try it.  Should be a cool effect if it works.

[Pumaman]

As GG suggested, using RawDraw allows you to effectively have extra background frames, so you should be able to use that as a workaround for now.

[Ali]

Although it is arbitrary, there is method to the madness -- basically, I didn't want to allow the room files to grow too big. If you've got five 640x480x32 backgrounds in a room file, it can grow to a few MB's in size, and allowing more backgrounds would increase the file size yet again.

Of course, times have moved on and loading 10 MB into memory isn't a big deal any more, so those restrictions can probably be relaxed now.

I've been thinking about suggesting this, particularly because I'm playing TLJ and it has some terrific animating backdrops. I hadn't thought of using RawDraw, but I would find it easier if more background frames were allowed... possibly with a warning that the game won't run well on slower machines.

[GarageGothic]

I really think that it's a bad idea to encourage use of full-screen animation. It will just lead to lazy implementation and bloated file size. In most cases it would be far more efficient to use objects for the few screen areas that actually animate - which is how TLJ did it by the way. That also allows you to use different framerates/animation lengths for different objects (clouds drift slowly across the sky while the leaves are rustling in the wind), and also creates a much more organic feeling than the cyclic background animations.

[Ali]

In most cases it would be far more efficient to use objects for the few screen areas that actually animate - which is how TLJ did it by the way.

I'm surprised to hear that, however I'd have thought AGS would slow down considerably with a moving-sea/skyline object like the ones TLJ uses on the boat. I would have though the most practical approach to that would be background frames, but I may well be wrong!

[GarageGothic]

I didn't mean 'more efficient' in terms of framerate, I just meant achieving the same or better effect with simpler means. (I think the way AGS handles background animation doesn't cause framerate drops, but big room files means longer loading time between rooms, and more MB to download - and on machines with less RAM it could mean frequent swapfile access).