jayderyu - thank you! that's exactly what I needed to know.

I'm still curious if doing this is a big no-no...can anyone with actual development and programming experience chime in?

Katala - I'm glad I'm not the only one who thought of it! However I'm noticing; I made a text file that has the memory usage, and when sprites get destroyed, the memory usage isn't going down (I think it might be when I'm using the debug editor, but because the debug editor cannot include event sheets, I'm unable to use it properly)

I've been thinking about this for a while, and wanted to see what other people thought. In a game, you have to keep animations and sprite sizes small in order to keep the memory usage as low as possible. Sometimes that makes it difficult to make a game look as good as most modern games look today. So I had a thought:

For long or large animations, could you do an "on animation finished" check, and in that event put a "create second part of the animation; destroy the first part"? And then "on second animation finished", "create first part of the animation and destroy the second part", effectively having the animation split as 2 sprites. In theory, they would never be loaded simultaneously clearing up the memory, and as long as what you're loading isn't too large, you wouldn't receive any hiccups.

I'm talking about this mainly for PC games, not mobile.

Would something like this work?

A0Nasser - The core team was really just 3 people; the rest were testers. Viktor would unfortunately not stand a chance on a tablet or phone; the game has way too many collision checks and art for it to have a solid framerate.

A0Nasser - Newt is correct - that's just the work of our brilliant artist, James O'reilly.

Valerien - you sir, are brilliant. Thank you!

Valerien - thanks. I tried your code, but instead of checking the x and y position of the camera, I checked the distance of the camera and player to see if it's less than 7 pixels, and if so, stop. It helps the problem, but doesn't exactly fix it perfectly. I understand the lerp function makes the camera always moving, what I don't understand is why the parallax only moves at an integer base instead of a float base when the camera is moving.

I have a camera object with "ScrollTo" on it, and multiple background layers that are parallaxing.

My event is something like this:

EVERY TICK
Camera > Set position to lerp(Camera.X, Player.X, 3*dt), lerp(Camera.Y, Player.Y, 5*dt).  [/code:28ako3ze]

This works how I want it to, but for some reason if I jump ahead and stop, as the camera lerps closer and closer to the player, the parallax layers seem to only move a single pixel at a time instead of a float (ie 0.4, or 0.01), making it feel weird and choppy.  Is this just because of the way lerp works (since it's never actually reaching its destination)?

Slightly off topic it seems to do this when changing opacity as well.

Any insight would be greatly appreciated.

newt - If I understand what you're saying, it wouldn't actually need to pick an instance. It would just be nice to say "run this action ONCE while the event above is true" without having complications from multiple instances of 1 object running the same event. Setting an instance variable as a "trigger once" creates the problem of "Ok, now it = 1 so it will only trigger once while it is 0 ... where do I set it back to 0, and when?"

It's not so much a feature as it is a time saver

Over the past couple days, I've been playing around with a new game. I've found some interesting things that I didn't know about before; mainly Trigger Once. I've always had issues in the past using this with multiple instances, but have finally realized that if 2 instances do something at the same exact time, because the trigger once is global it will generally break the event.

So my request, or rather inquiry, is this; is there a way to get a "trigger once" for a sprite event instead of a system event? I know you can do something like this to create a proper trigger once per instance:

If InstanceVar = 0

Do something and Set InstanceVar to 1

This will always work, but it requires more lines of code, instance variables, and can certainly certain complicate code that is much more complex.

I'm imagining "For Each" is a solution, but everytime I try and use it, it never works like I want it to.

I'm curious of everyone else's thought on this.

Ashley

Wonderful, thank you!