Frame Refresh vs Logic

Thinker

  • Posts: 16
Hi folks

Total newbie to Stencyl but have 30yrs IT development under my belt in various languages so the Stencyl interface is no problem for me, loving it so far.

A key issue I have immediately hit from working through the Crash Course is that it appears that the frame processing can whizz round and any logic coding within say the events section of an Actor Type, seems to have a time factor associated with it.    That is to say, it takes a number of miliseconds for Stencyl to work through the lines of coding in say a "When Updating" event and in that time it seems to me that the next frame might get underway before that logic is completed.

This became evident when I got the same problem many have had with the Invaders CC game where bullets don't disappear when they hit an enemy.  The logic coding exists for a Bullet actor to "Kill self" on collision with an Invader and the logic exists for an Invader Actor to "Kill self" on collision with a bullet.  In realtime, clearly one of these two events/conditions will get there first and if it happens quick enough, it will then impact the other.   In practice the problem most experience is that the Invader collision with bullet is detected and the "kill self" action is implemented  The bullet collision is also triggered but by the time it's logic code is parsed, the Invader object has been killed.  Result is the bullets remaining on the screen instead of being killed.   People's solution to this timing issue seem to be to put delays around chunks of code or logic.    e.g. Do XYX after 0.5 secs and so on.

This is, for me, where my concerns begin.  I'm, not asking here for help with the crash course assignment.  Rather I am trying to get my head around the fact that logic/code within different areas of the system clearly take time to execute and in that time new frames can be refreshed and the whole flow of logic seems to be compromised.  What I would like to know therefore, is whether there is some kind of "belt and braces" approach to coding logic to control all of this timing issue.  Trying to guesstimate how many seconds chunks of code might take to execute and thus insert "Do XYZ after 0.5 secs" seems to me, utterly flawed and haphazard.

Have I missed a trick here?    I feel that I need to be able to rely on all of the lines in a chunk of code to be executed BEFORE that same chunk of code gets executed again but that seems not the case.

Any help appreciated.


sdieters

  • Posts: 2068
i will be honest with you, but i have never heard or experianced something like that before in stencyl.
i have had huge lists of block without having any issues with it.

are you sure it has something to do with stencyl, rather then something with your OS or machine? ( i highly doubt that last one)
My new profile is TheIndieStation.
When you see a recent post with this name, i'm probably using my phone. So dont mind any typo's =p

Alexin

  • *
  • Posts: 3132
The frame rate is potentially different from the update rate. The former is usually 60 frames per second and corresponds to "when drawing", while the second is 100 step per second and corresponds to "always".

The engine is single-threaded so, in principle, Stencyl doesn't "draw" a frame while an update is taking place. What happens on the GPU side is might be another story though.
"Find the fun"
alexin@stencyl.com

Thinker

  • Posts: 16
I probably have confused people, apologies.

Simple example.   2 actor types.  bullet, enemy.
Bullet Events Logic:
  If Bullet collides with Enemy
       Kill self

Enemy Events Logic
  If Enemy collides with Bullet
       Kill self

As many people have discovered, this seemingly simple logic does not actually work.  Everytime a bullet collides with an enemy, one of the above 2 logic clauses will be triggered first.  When it does that actor will be killed and in the time it takes to do that, the other chunk of logic hasn't triggered.

Thus, in a given frame/cycle,   a bullet DOES actually collide with an enemy
The Enemy logic is triggered, the enemy is killed
The bullet logic is NOT triggered because there is no longer an enemy therefore as far as the bullet is concerned there is no collision.

It seems crazy to me that in a given frame/cycle such a collision can occur but that both sides of that collision are not triggered.

I know that a "workaround" to fix this is to put the "Kill self" command within a "Do after 0.5 secs" clause which gives the other logic chunk the time it needs to register the collision, but as a solution that just seems haphazard.

The time delay you have to apply really depends on all sorts of other factors that govern the overall speed of the game like any looping music, sound effects, other event coding and triggers etc etc.  Surely there must be a more belt and braces way of ensuring that both sides of a collision are registered / triggered within a frame/cycle?!

sdieters

  • Posts: 2068
never tought of that tbh haha. but i can asure you there is always a way to make sure some things happen at the same time. for example, in the invader project, you could only have this aplied to the bullet.

if bullet collides with member of enemy,
~kill last collided actor
~kill self

so in that case there is no need to have a code aplied to the enemy (apart from the moving part)
My new profile is TheIndieStation.
When you see a recent post with this name, i'm probably using my phone. So dont mind any typo's =p

Thinker

  • Posts: 16
Excellent thank you

Still concerns me that both sides of the collision are not nativey triggered

sdieters

  • Posts: 2068
stencyl is created to simplify coding for those who don't know any computer language. to achieve such a wonderful program, you need to cut every here and there =)

if you need any help on stencyl coding, either check out my channel @https://www.youtube.com/user/ArtificialStudioInfo, kingdome's channel @https://www.youtube.com/user/SunriseKingdom (hard to understand, but great tutorials), or just ask around here on the forums =)
My new profile is TheIndieStation.
When you see a recent post with this name, i'm probably using my phone. So dont mind any typo's =p

Thinker

  • Posts: 16
Cheers I will check those out.

I WILL get to coding soon enough don't worry but in terms of understanding the structure, basic elements of flash projects, events, triggers etc I think Stencyl is pretty good.  As with Access Basic/Visual Basic one has to gain exposure to all of the various attributes/properties that are available in the language.  I'm really happy to be doing this kind of programming again, should have done it ages ago, it's just that in career terms, "Developers" are not given the status or reward and recognition they deserve because senior management need to justify their roles and protect them.  Such is life !

sdieters

  • Posts: 2068
you don't have to tell me how life can be a b*tch when it comes to careers haha.
i have bin struggling for the past 3 years just to be able to go back to school again
My new profile is TheIndieStation.
When you see a recent post with this name, i'm probably using my phone. So dont mind any typo's =p

Epic428

  • Posts: 1118
It is also very possible that the first actor that kills itself executes code in the background which actually removes itself prior to the other actor executing its commands. As a result of this, if it runs that code and removes every known instance of itself from the tree, then it no longer exists in the collision list for the other actor.

Think of it in terms of this:

Bullet hits enemy.
Enemy registers collision and executes kill self command.
Engine then proceeds with the killing and removes that actor from the tree including the collision list.
Bullet now runs it's code.
Whoops bullet appears to not be colliding because the command to kill self for the enemy was executed and the killing occurred in the same frame thus removing it from the list.

I'm not 100% if that is how the engine operates, however, ideally it would work the opposite where the actual killing of itself occurred the following frame, allowing for any other references to the instance to continue executing their commands should there be any.

It's possible, that if the engine works using the former method, that it is done that way due to the limitation of a specific platform or two. I know in flash GC is done on the following frame, so it allows references like this to continue completing their tasks on the current frame.
James Moore - Official Support & Documentation.
We cannot and will not respond to PM's asking questions. Please make a new thread in the forums if you have any questions, Thank you.
For better support and faster response times, please post your logs regarding any Stencyl related issues. Debug > Logs > Generate Logs

Thinker

  • Posts: 16
Hi Epic

Yes that's pretty much exactly what I have described.  It just seems a crazy situation to me.  Your opening line in your psuedo coding there is:

"bullet hits enemy"

By definition that means enemy has hit bullet.  For the system not to recognise that, and not to even just make a mental not of that is imo a flaw.
Really I don't care what coding is written for each actor type, the fact is that EVERY COLLISION HAS 2 SIDES,  A meets B and thus B meets A.   At present, from what I can see, Stencyl isn't coping with this.   The order of it's logic processing seems off.  For every collision it ought to be FROM THE OUTSET flagging that A collided with B and B collided with A and be doing that BEFORE any subsequent logic code for actors is executed.   Just my 2penneth.



Alexin

  • *
  • Posts: 3132
Killing an actor does not remove it from the system right away. It disables its events though.

An actor is actually killed after all the "always" events have run (possibly multiple times due to what I said in my previous post) and removed from the physics system. It happens before the next frame.
"Find the fun"
alexin@stencyl.com

Thinker

  • Posts: 16
Alexin

My point remains.  Why on earth would the frame logic not determine both sides of any given collision at the outset of each frame.   How can it be possible for A to collide with B in a given frame, and for the system not to thus recognise from the outset of that fame, that B has collided with A?  That just seems silly.   For me the system logic should run like this:

Frame 1
   Event - Actor Type A has collides with type B
   (1)  -   Make mental note to run all collision logic associated with actor type A colliding with B
           -   Make mental note to also run all collision logic associated with actor type B colliding with A
   (2)  Now run logic code associated with A colliding with B
   (3)  Now run logic code associated with B colliding with A

Unfortunately item  (1) above is not happening.  The system seems to detect the collision, then go wandering off to run say the logic code associated with A to B collisions WITHOUT first making a note that B has also hit A.    By the time the system has finished parsing the A to B logic code,  Actor A has been killed off, and thus the system does not then consider B to have collided with A.   That's flawed programming imo.  It could surely lead to all sorts of complications.  What would happen if actor type A were to hit 2 or more actor type Bs simultaneously?  e.g. if actor Bowling Ball were to hit actors Bowling Pin 1 and Bowling Pin 2 at the same time?   Surely in the frame where that collision occurs the system should recognise and note that:

Ball hit Pin1,   Ball hit Pin 2,  Pin1 hit Ball , Pin2 hit Ball

All from the outset.   

rob1221

  • *
  • Posts: 9424
If you do the collision detection in a scene behavior, then it will work as you describe.  Alternatively, have one of the two actors control all of the reactions to the collision.  The system hasn't been changed because it is very easy to work around.

Thinker

  • Posts: 16
Rob

Having 2 actors control the collisions is proving buggy and I believe it is due to the number of collisions happening in the game some of which must be happening concurrently.  The workaround that has been suggested is to first Kill Self and then Kill Last Collided Actor.  This logic I think fails when there are lots of collisions.

This is happening in a Space Invaders type game where the player's ship is constantly shooting bullets and the invaders are constantly firing lasers toward the player.  In between the invaders and player are a number of shields as per the original game.   I have an event in the Laser actor that says:

When Laser collides with Shield
   Kill Self
   Kill Last Collided Actor

Generally this works, but occasionally a laser will collide with the shield and stay on screen throughout the game.  I can only assume that there was more than one collision in that frame update and the "Kill Last Collided Actor" command killed the wrong actor.    Kinda frustrating.