I've got an armful of AGS-related questions that I've not yet been able to find conclusive answers to, so it seems best to post them here (apologies if I've overlooked anything in the documentation or forums).
1) Views: What exactly is the reason for having views? I understand that certain loops in views denote specific animations (directional walking, talking etc) however I'm still struggling to understand why views are important when AGS Editor already provides another mechanism for organising the animation loops (subfolders). Is this a legacy design decision?
2) Animation speeds: This is documented already but the timings don't quite seem to be translating properly. A 40 fps AGS game has 40 ticks, so a character with an animation delay of 2 and a frame delay of 3 would spend 5 ticks displaying the given frame (0.125 seconds)? And so if the animation call is 'cCharacter.Animate(5, 3, eOnce, eBlock)' then the animation delay is overridden with a 3, meaning the same frame is on the screen for 6 ticks? (0.15 seconds).
3) Room Events: There are three room events surrounding room entry. Is this the correct order and circumstances in which these events fire? I'm not sure if the player's first entry also fires the standard room after fade-in event.
Player's first entry: Enters Room before fade-in -> First time enters room
Any following entry: Enters Room before fade-in -> Enters Room after fade-in
Any help appreciated.
AFAIK(!!):
1) Views contain extra information. Is the frame mirrored, delays, the same sprite multiple times, sounds, to name those that come to mind.
2) That can be a bit tricky alright. Animation delay and frame delay are added, then the frame is displayed that many game loops. However, using a delay of 0 seems to cause AGS to use the next frame every loop, so it's technically a delay of 1. Not sure what AGS does there exactly, mostly those issues are solved by experimenting a bit with different values.
3) before fade-in -> after fade-in (-> first time) should be the correct order.
Quote from: Khris on Mon 19/10/2009 16:10:52
1) Views contain extra information. Is the frame mirrored, delays, the same sprite multiple times, sounds, to name those that come to mind.
All of this information is stored in the sprite loop & individual frames, so I'm still unsure as to why Views are needed, from an architectural point of view.
Quote
2) That can be a bit tricky alright. Animation delay and frame delay are added, then the frame is displayed that many game loops. However, using a delay of 0 seems to cause AGS to use the next frame every loop, so it's technically a delay of 1. Not sure what AGS does there exactly, mostly those issues are solved by experimenting a bit with different values.
Hmmm. If a delay of 0 actually displays for 1 tick, then perhaps I should be adding a tick to the frame tickcount when converting to seconds. That would make sense as the animations currently run faster in XAGE.
Quote
3) before fade-in -> after fade-in (-> first time) should be the correct order.
So the after fade-in event fires even on the first entry? Thanks for your help.
Quote from: clarvalon on Mon 19/10/2009 19:09:40
All of this information is stored in the sprite loop & individual frames, so I'm still unsure as to why Views are needed, from an architectural point of view.
If you can recognise that Loops are essential, Views are, too. As you already mentioned, a View contains the Loops of an entity when it's facing
different directions, so when, say, a character moves towards a certain direction the engine would automatically choose the appropriate Loop for the animation (as objects are not always necessarily moving or animated, that's why they can be there without being assigned to Views and Loops). On the other hand, you mentioned sprite folders. In fact, sprite folders are useless to the engine, as a game only selects sprites according to their slot numbers, that's why we need Loops and Views to make our days for organisation of animations. Sprite folders are only useful to us to have stuff better organised when making a game.
Quote from: Gilbet V7000a on Tue 20/10/2009 02:13:39
If you can recognise that Loops are essential, Views are, too. As you already mentioned, a View contains the Loops of an entity when it's facing different directions, so when, say, a character moves towards a certain direction the engine would automatically choose the appropriate Loop for the animation
Absolutely. The point I'm making is that this mechanism doesn't need to be a view. There could be some other means of denoting which sprite loop pertains to which up walking animation, which left talking animation etc. Is a view just a means of convenience?
I'm not saying it's wrong by any means, I'm just wondering why AGS was designed this way. Once I understand the logic behind it it will help with my conversion, which currently struggles to perform the correct animations due to the way AGS organises them into views. They way views are locked means that it's not always possible at compile time to know exactly which sprite loop is to be animated. Perhaps
that's the point of views.
Quote from: clarvalon on Tue 20/10/2009 09:40:07
Absolutely. The point I'm making is that this mechanism doesn't need to be a view. There could be some other means of denoting which sprite loop pertains to which up walking animation, which left talking animation etc. Is a view just a means of convenience?
I think I'm lost here. There may be other means of doing so, but as AGS uses Views for this and currently has no other ways of implementation in it, obvious Views
are essential, unless for whatever odd reasons the system is changed to use some other ways.
As far as I know AGI (and much possibly SCI) used Views also and the
original intention of AGS was to make AGI/SCI like games. That even gives us another reason that there is no point
not to use Views.
My fault, I'm not explaining myself very well :)
My question here isn't so much how but why.
I know that AGS requires the use of Views as a container for all sprite loops. That's fine. My question is why that's the case. It would be equally as valid (or would it?) to have in the character properties, say, a field "WalkUpAnim" which referenced a unique walking up sprite loop number. I'm just trying to understand the benefits, from an engine design perspective, of bundling up these specific sprite loops into a View.
Thinking about it, the only use I can see from a end-user perspective is that you can create various loops on the same screen. Less clicking around to create a new animation.
I don't think I'm really answering anything here...
Quote from: clarvalon on Tue 20/10/2009 12:03:53
My fault, I'm not explaining myself very well :)
My question here isn't so much how but why.
I know that AGS requires the use of Views as a container for all sprite loops. That's fine. My question is why that's the case. It would be equally as valid (or would it?) to have in the character properties, say, a field "WalkUpAnim" which referenced a unique walking up sprite loop number. I'm just trying to understand the benefits, from an engine design perspective, of bundling up these specific sprite loops into a View.
Well yeah, but there can also be more animations for a character than just walking in all directions, e.g. a 'picking something up' animation, an "open a door" animation, etc. (not to mention talking animations) which can get awkward to have in a Properties panel, as you suggested.
Furthermore, Views can be re-used (this is unlikely for main characters, but can be re-used for some NPCs and objects). For instance, if you are using the same template for every room in your game, it's likely that many of the doors will look/behave the same. This way you can use the same "opening" animation for almost every door in the game, without having to re-do them in every Properties panel.
Peace
Scarab
If a character is going to wear a jacket or swim, one just needs to change the view number, as opposed to changing four (eight) loop properties.
So yes, I can see what you mean when you say it's just for the sake of convenience.
I guess it seemed natural at the time when AGS was born to bundle the directional loops together for characters, and then it stuck.
EDIT:
Scarab,
the usual way would be to use a custom function to do the pick up animation which would simply use a loop number depending on height and direction. A folder to bundle the loops would perfectly suffice for that from an organizational point of view.
Same for doors, those are in fact a perfect example of views being not necessary at all. A single loop is all the doors would need.
Quote from: Khris on Tue 20/10/2009 12:38:15
Scarab,
the usual way would be to use a custom function to do the pick up animation which would simply use a loop number depending on height and direction. A folder to bundle the loops would perfectly suffice for that from an organizational point of view.
Same for doors, those are in fact a perfect example of views being not necessary at all. A single loop is all the doors would need.
Well.... That shut me up :P
I guess I was just thinking about it the wrong way (i.e. loops live in views, therefore how can you use loops without views)
Silly, silly Scarab...
Peace
No need to start wearing a cilice :)
When I first read clarvalon's question about views, I immediately thought "course you need them".
The only thing I'd miss about them is probably that a big game could easily require hundreds of loops and managing the indexes would require a bit more work.
Quote from: clarvalon on Tue 20/10/2009 12:03:53
My question here isn't so much how but why.
I'm even more lost now. I was indeed saying the reasons
why. I don't think I said anything about
how to use them.
Reason 1:Quote from: Gilbet V7000a on Tue 20/10/2009 11:51:17
There may be other means of doing so, but as AGS uses Views for this and currently has no other ways of implementation in it, obvious Views are essential, unless for whatever odd reasons the system is changed to use some other ways.
Reason 2:Quote
As far as I know AGI (and much possibly SCI) used Views also and the original intention of AGS was to make AGI/SCI like games. That even gives us another reason that there is no point not to use Views.
(Further) reason 3:If you don't implement views, when the appearance of a character (or anything that has walking directions) has to be changed you have to do this four times, one for each direction (eight, if it has diagonal movement graphics), instead of just changing the View (I haven't read all of the discussions here but I think this was mentioned). Granted, there may be other ways to do this (e.g. a function like ChangeDirectionGraphics(loop up, loop down, loop left, loop right) ) but the question is not whether the current way has an advantage over others, as it's already done in this way and there isn't any need to change (see reasons 1 and 2).
(Further) reason 4:As others may have mentioned, Views can be convenience even for non-walking objects, like being used as a container of various animations that a certain object can use. Yes, there are instance that this is not needed, for there are always cases that a certain object would only have one animation. It
may benefit a bit if we can flexibly assign a loop or a view directly to an entity whenever we need but as we can already do whatever we want just with Views this may not be of high importance(again, read the above reasons).
Quote from: clarvalon on Tue 20/10/2009 12:03:53
I know that AGS requires the use of Views as a container for all sprite loops. That's fine. My question is why that's the case. It would be equally as valid (or would it?) to have in the character properties, say, a field "WalkUpAnim" which referenced a unique walking up sprite loop number. I'm just trying to understand the benefits, from an engine design perspective, of bundling up these specific sprite loops into a View.
I think you're overestimating the amount of design that originally went into AGS.
You need to remember that AGS has been around for over 10 years now, and originally it was just designed as something to make Sierra-style games with. Because Sierra used Views, it was natural that AGS used them too. It's a system that works and there hasn't really been a need to change it.
As has been mentioned by others, views allow you to easily package together sprites that are used for a particular costume or set of animations... it's just a way of organising sprites really, and allowing characters to easily switch between costumes by just changing a single property.