SUGGESTION: Views/Loops/Frames

Started by monkey0506, Sun 04/12/2005 04:44:19

Previous topic - Next topic

monkey0506

It would make it a lot easier to access the views for animations and things if we actually had access to them.  Basically I'm thinking something along the lines of:

Code: ags
managed struct Loop;
managed struct View;

managed struct Frame {
  readonly import attribute int Graphic;
  readonly import attribute int Delay;
  [readonly] import attribute bool Flipped;
  readonly import attribute Loop *OwningLoop;
  [import void SetGraphic(int sprite);]
  [import void SetDelay(int delay);]
  };

managed struct Loop {
  readonly import attribute Frame *Frames[];
  readonly import attribute int FrameCount;
  readonly import attribute View *OwningView;
  readonly import attribute int ID;
  };

managed struct View {
  readonly import attribute Loop *Loops[];
  readonly import attribute int LoopCount;
  readonly import attribute int ID;
  };


Yeah...I've only been thinking about this for a while.  That sounds pretty good to me though.  Regarding the stuff in brackets in the Frame structure, I think it would probably be okay to allow the user to change some stuff dynamically.  Unless that would create major complications within AGS (like for example if the user tried to change the currently displayed sprite...so maybe it wouldn't work).  But it's just something I've had on my mind for a little while...

[EDIT:]

I forgot the ID attribute for Loops.  Of course the ID attributes of Views and Loops would mainly be for backwards compatibility.

Pumaman

Interesting comment. I was wondering whether to do this originally in 2.7, but the main reason I didn't was that it would lead to a huge number of managed objects floating around, if there was one for every frame of every loop of every view.

I'll need to analyse the performance of the script system before deciding on this one.

monkey0506

That's understandable.  But I did forget one thing...Frames can have sounds associated with them, so that would have to be included.  I realize that with a lot of objects to manage things get complicated...It would just make it a lot easier on the user end (IMO) if we had access to this information.

Traveler

Just a quick idea (without having experience with the scripting language so far): how about creating a managed object for these graphics objects when the script actually accesses them? If the script doesn't refer directly to frames in a view, don't whip up the managed objects for those frames. his would help cut down the number of objects going around without being used.

Pumaman

Yes, that's certainly a possibility, it's something I'll need to consider.

SMF spam blocked by CleanTalk