I see. Thank You again, tulamide. That's why I love forums, and especially this place. It's full of knowledge, and full of people with knowledge who can help each other to learn about something they are interested in and share a passion for.

Although I still think it's weird to essentially have the same condition behave differently, depending on where it is checked from. At least the different checking behaviour should be clear.

If I check for 'Is Overlapping', then I expect it to be a continuous check and not a one time result. And perform actions according to "as long as overlapping". If I wanted them to be executed once I'd use the 'perform once' expression.

But this way it would be useless in a while loop, unless I used the System Condition.

In other words, if I applied actions to the Sprite Condition, it would make no difference if they are in a while loop or not, this way. It would behave the same.

But tulamide, then I still don't understand this behaviour.

I do understand what You are saying.

Let me show You how I tested it and it didn't work (Events are in order):

+ Always

-> Sprite1: Set X to MouseX

-> Sprite1: Set Y to MouseY

+ While

+ Sprite1: Overlaps Sprite2

-> Sprite1: Set X to .X - 1

What should now happen (to my understanding), is that Mouse.X will always be overwritten, when Sprite1 overlaps Sprite2. This should result in Sprite1 always moving along the left border of Sprite2, whenever it tries to overlap Sprite2.

However what happens visually is nothing at all in this case. Because it behaves like in another test I did before, and just moves Sprite1 back -1px .X every Tick instead of in one.

Now when I do it like this:

+ Always

-> Sprite1: Set X to MouseX

-> Sprite1: Set Y to MouseY

+ While

+ System: Is Overlapping(Advanced) Sprite1 (PICK) Overlaps Sprite2 (PICK)

-> Sprite1: Set X to .X - 1

It works. (The Pick option doesn't even matter in this case, even when I didn't pick either it worked)

I see.

I never worked pixel based, because I prefer time based, but couldn't you just make your own push out routine?

If the player sprite overlaps the left side of the ellipse, then repeat sending the player sprite to .X - 1 until it doesn't overlap anymore.

That's a good idea. But then again, how are You able to state when it doesn't overlap anymore, when You don't know where the pixel border is?

EDIT: Okay, I just got it! <img src="smileys/smiley4.gif" border="0" align="middle" /> We just need to use a While Loop! While Player Overlaps, substract .X -= 1. Thank You!! I should think time based more often.

That means While loops inside the same Tick, until it falsifies?

2nd EDIT: Wait, this is weird. I guess I was happy a little too soon?

In theory, if While worked that way, and I am also thinking it should (from what I read now), it would be perfect and very useful. But I just made a simple test, checking the Overlap between two objects with the While condition.

I used the Overlap condition check from the Player Object, and set .X back -1, while it is overlapping.

However in reality the Player was set back -1 every Tick now, as long as it was overlapping. Not -1 in one Tick until it wouldn't overlap anymore. So You could watch as it was pushed back out in slow motion.

Then I tried the System Objects Overlapping(Advanced) condition and basically did the same as above. But this time it worked exactly as it should, it would be pushed back instantanously the next Tick.

Why? Please don't tell me it's another bug, lol.

I wouldn't know of any way of getting those informations, unless you know the shape of the object and calculate it.

But what you describe sounds like a typical job for a pixel shader. Is there a reason for trying to do it on the cpu side?

Thanks for Your time again, tulamide.

And yes, there is a reason. I am trying to use it for collision calculations.

Let's say we have an Ellipse Sprite, that we use as a collision mask.

Now if the Player Sprite, or any other movable Object Sprite overlaps the Ellipse in one Tick, let's say by 5 pixels, I want to position the Player Sprites border back exactly those 5 pixels it overlapped.

If for example the Right Pixel Border of the PlayerSprite overlaps the Left Border of the EllipseSprite by 5px on X, move the PlayerSprite.X -= 5px.

And similar procedures for .Y values and other borders.

I really need those pixel coordinates, to know where the border between transparency and opaque pixels is, so I can do accurate backplacing for the collision.

I don't know of another way doing it accurately right now.

I can think of some workarounds, but they would all be huge time consumptions compared to this and would still lack the same precision, while similar.

It's driving me slightly mad. <img src="smileys/smiley1.gif" border="0" align="middle" />

I've been trying to find information about pixel coordinates and the likes like crazy today, without any luck. I've gotten another idea how to do what I wanted to do then.

But I still don't know how to do it, or where else to look for answers on this.

Is there a way to check how much (how many pixels) one side of an object has overlapped another objects pixel area?

Related to that I would also like to know if there is a way to retrieve the furthermost pixels coordinates of any side. Let's say the furthermost pixel on the left side of the sprite, checking from the hotspot. So meaning left relative to the hotspot.

I am basically just trying to find a way to exclude transparency of sprites in calculations. And starting with pixels whose opacity or alpha level is higher than a certain amount.

Okay, I found out what was happening.

It's a similar or the same bug I had a good while before, and I think I reported too.

One of the Events I used to trigger the SetAnimation to Attack, had an OR condition sandwiched in the middle, and it was in a Group.

When I moved the whole Event out of the Group and into the main Event List, it worked exactly as expected. Very weird behaviour though. I mean with the Bug.

And thanks for Your reply, tulamide. Yes, I was thinking about exactly that, how the previous Events' frame is being rendered in the present processing and what delays there could be. But knowing all that made it even more weird. How it could even set the Animation to 'Attack?, and IgnoreInput to 1, while Attack is playing, when that is only possible while Attack = 1. And since Attack only has 1 Frame, how could IgnoreInput be set to 1, when Attack = 0?

I was fairly sure I understood everything now, the flow and order in what things happen in a Tick in the Event List.

Today I was using the Debugger, because of an unwanted result, to see if I could find something there, without any real clue. But I noticed something else, that I found strange.

First let me give You the Events (in order, top to bottom, as they appear in the Event List, excluding unrelated Events inbetween) related to this:

If MouseKeyboard PressButton 'F' -> Set Attack = 1

---------ELSE------------------- -> Set Attack = 0

If Attack = 1 -> Set Animation 'Attack'

If AnimationPlaying 'Attack' -> Set IgnoreInput = 1

If AnimationFinished 'Attack' -> Set IgnoreInput = 0

(IgnoreInput just ignores input for movement)

Now in theory what I thought should happen (After pressing 'F') is this:

Tick 1:

• During the duration of this Tick, Attack = 1.
• Animation is set to 'Attack'.
• Now I don't know about this for sure, but since Animation has been set to 'Attack' in this Tick above, IgnoreInput should already be = 1, unless AnimationPlaying is only registered for the next Tick, when it has actually been finished rendering. (The AttackAnimation is only 1 Frame right now, placeholder)

Tick 2:

• IgnoreInput = 1 or 0, Depending on how Animation is registered by the program, as I said above.
• We see the AttackAnimation for the 1 frame it has.

But this is what I see in Debug Mode (after 'F' has been pressed):

• Attack = 1
• Attack = 0; IgnoreInput = 1
• Attack = 0; IgnoreInput = 0; Animation = Attack

After pressing 'F', Attack is first set to 1.

Then exactly as Attack = 0, IgnoreInput = 1.

Then exactly as IgnoreInput = 0, we see the Animation.

Could someone please explain to me how and in what order the Events are being read and executed and values assigned?

Thank You very much.

EDIT:

Weird, I just tried to replicate this behaviour with the Event Flow I described, in a new .cap. Now it behaves exactly as I thought. It must have something to do with other Events interfering then.

You could simply use the "OR" addition in your event

Player Animation Punch is playing > Do something

OR

Player Animation Kick is playing

OR

Player Animation Bite XD is playing

If You have about 35 possible different follow up animations for a character, that could get huge though. I was also considering that, as a last resort though.

Is it possible to in any way use the Sub-Animation System to check "If any of the following animations are playing/finished/etc. ..." ?

Let's say we have a main animation called "Attack", and below that a lot of possible follow up chain animations in sub-animations. So in that case "If any animations of type "Attack" are playing, do this...".

Thanks in advance.

Am I right with my observation of the behaviour of the Function Object?

Let's say further down our list of events we have a "Call Function" Action next to an event.

But we check for the Function before that Event. We check "On Function" in our Event List above "Call Function".

Now in one Tick, we check the Event List from top to bottom.

The first time the Event "On Function" is checked, it is ignored.

Now when the Event (containing the "Call Function) itself is actually checked, it will first perform all Actions for that Event, until the Action "Call Function" is encountered. If it encounters "Call Function" in the Actions list of an Event, it will stop reading Actions after this and instead check all Events from top to bottom again for "On Function" with the same name. And it will execute all of the Actions for those Events first.

When it is finished doing so, it will continue reading the Actions from the Event in which "Call Function" was just executed.

Am I right?

I think this checking behaviour is pretty important to know to use the Function Object properly and avoid unwanted results. It should be noted in the documentation. I only noticed this because something strange was happening, and I am constantly running with a very low Fixed Framerate to check what my code is doing, how exactly it is being checked and run. But I imagine if it runs faster, and things are harder to see, the processes going on, and their order are often harder to understand, if something is just seen for 16ms (in the case of 60 FPS). That could lead to bugs, that You later can't understand.

The way the Events are checked in one Tick should always be clear to the user to avoid confusion.

I don't see such a big problem.

If You did the jumping animation of the wolf close to its real jumping behaviour in life, the two front legs should be reaching forward, with the back legs spread to the back (in mid-air). And when he is landing, he should be landing with his two front legs first, and as they are touching the ground, the two back legs would come forward and probably touch the ground close to the front paws (slightly behind or in front of). Then the front legs make a slight step forward again, to ease out the body.

(Just google "wolf jumping" to see what I mean.)

So basically this should be able to look pretty natural, if You mimick its real moving behaviour.

Of course depending on which angle he is jumping from, say from below, or from above onto the surface, You'd have to change the angle of the animation a little.

For example, if I had the full animation, as I described above, I would generaly do it like this:

Let's assume the mid-air sprite is 100px wide. And the hotspot (for determining its position) is in the middle of the sprite. I roughly guess the size of the paws as 10px now, so the sprite needs to be on the surface with at least 10 px, to move onto it.

Assuming You're jumping from the left:

If Wolf is Jumping AND If Mid-AirAnimation is playing AND If Wolf.Left + 90(px) Equal or Greater than PlatformSprite.Left AND Wolf.Bottom Collides with PlatformSprite.Top -> Play LandingAnimation; Move Wolf.X with about 90px. (because body is easing out in animation and taking a step forward for landing)

Of course You would have to slightly adjust it for different jumping angles, like I mentioned before. <img src="smileys/smiley1.gif" border="0" align="middle" />

Thank You for the fast reply, Ashley.

But if V-Sync works that way, shouldn't the lag theoretically get worse each second then? Like I wrote in my example with the counting of the second?

In other words, reading of the code is not affected by it. So I might press a button, the program realizes it exactly on time, as fast as it can, but the graphics card draws the necessary frames to the buffer, and sends them to the screen only as it is ready.

To my current understanding, since we have two things basically running at different speeds, the distance between the two will get bigger with time. Like in my example.

So the frames lagging behind will get more with time, but it doesn't happen in reality. That's what I don't understand.

Indeed, why not just limit the speed of the processing cycle of the events? So it will only always check the list of events/code with a time interval given by the the Hz of the screen refreshrate. Shouldn't that solve the problem very easily?

I mean I just don't understand if fixed framerate has no problem with lag the way it works, why doesn't the program just recognize the users screen's refreshrate and then set the fixed refreshrate to that of the screen.

In that case I don't even see the use of v-sync, it seems very limiting.