Setting priority of attributes and actors

tekkendptekkendp Member Posts: 49
edited November -1 in Working with GS (Mac)
Running 0.83 now - after a fews hours work, it does seem to be less crash happy (but the slow down is still there - but hey baby steps).

Anyway, I have had to big changes to the way my game pauses, as it looks like the preserve scene function has now been removed.

I'm now pausing by using a game.paused boolean attribute, with a rule for all actors that spawn, animate or move. The change attribute works like this :-

if paused pressed
change attribute game.paused from 0 to (game.paused+1)%2
(had to do it this way as just assigning 0 to 1 didn't work too well)

However, the above works somewhat randomly (sometimes one click works, sometimes it takes 3 or 4 clicks). So, is it possible to give the priority to specific attributes or actors, as I think this may help me out.

Cheers (hope the above isn't as clear as mud)

Comments

  • tekkendptekkendp Member Posts: 49
    Does anyone have any ideas?
  • rebumprebump Member Posts: 1,058
    I would play around with putting the various tests in the actor's main timing loops to ensure they are parsed regularly.
  • tekkendptekkendp Member Posts: 49
    Thanks for the response Rebump.

    All my actors (moveable ones) attributes are encapsulated in a rule that checks if paused is pressed. So before any action associated with the actor is performed, the check is done.
  • rebumprebump Member Posts: 1,058
    Understood, but with 0.8.*, the root level behaviors are executed only once unless they fall under a timer or a constrain...I think. I've never really been able to get a clear picture of the execution cycle (I believe it varies per behavior with most now requiring insertion in a timer). Seems like in pre-0.8.*, it was sometimes a tad flakey for behaviors at root level and I think that is what fueled the confusion. The way it is now seems more consistent.
  • tekkendptekkendp Member Posts: 49
    Rebump - thanks for the info.

    Not sure how I could include a timer into my pause system, as it more of reactive function, rather than a preplanned on. Reactive in that you don't know when the user is going to hit the pause button.

    This is why I asked the question. If we could control what attributes or elements get higher priority, then it would be easier to fine tune the game's performance to suit your needs.

    Still scratching my head on this one.
  • tekkendptekkendp Member Posts: 49
    Rebump - if you are reading this - thanks for your advise. I have rewritten a large chunk of my game, and now I can get pause working (it encapsulated in a timer that checks the pause status every 0.1 secs).

    Not perfect though - as there are times that you have to hit the virtual pause button a couple of times to get a response), but it 's a step forward - lost some smoothness though.

    So thanks again.
  • rebumprebump Member Posts: 1,058
    No problem. The use of small time frame timers is a double-edged sword. It can solve a lot of issues but it can also introduce performance issues when encompassing certain behaviors or groups of behaviors. As always, test varying the repeat frequency a bit. A move of the timer behaviors to the top of the behavior list may help a bit too since the GS engine mainly parses top to bottom (but no guarantee...per a dev in another post).
Sign In or Register to comment.