Lou Bagel's Forum Posts

  • Where is the scaling set ? Layer scaling ? Could it a rounding bug ?

    If you disable all scaling, and use "letterbox integer scale" as the "fullscreen in-browser" mode, it should be pixel perfect.

    It was an event, on layout start set layout scale to 2. Even with removing that event the crop setting with no scaling I can still see distortion. (on all objects, not just player)

    Crop is stated as no scaling. Rounding bug? Is there a way I could tell?

    I know that letterbox integer scale keeps pixel perfect. Does it make sense to do that and 'set canvas size' to browser width and height?

  • Trying to get a full-screen pixel-perfect setting—as in pixel art with no distortion and no black bars.

    I'm trying out crop setting (for 'fullscreen in browser') which states no scaling. Scaling is at 2, sampling is point, pixel rounding is on and sprites are at integer locations.

    If you watch the gif below his eye still distorts while walking. I captured in debugger so you can see x & y coordinates are at integer locations. Not sure what else can cause this...

    Property settings, just in case it is something else here:

    Any ideas what is causing this?

    Any other way to get full screen, pixel-perfect? I am thinking about trying 'scale outer' then checking the size of the screen and using math (haven't figured it out yet) to set the scale so it will be back at an integer interval.

    Thanks

  • Yes, the function part looks correct. Is it working fine?

    If the "trigger once" part I mentioned is working fine the way you have it then good—I was just unsure what the result would be.

    One thing you could think about is adding more states—if it makes things more organized for you.

    0 = spawned

    1 = moving

    2 = charging (not moving and waiting to shoot)

    3 = firing

    4 = pause, then set back to 1

    Just a thought, but not necessary—however makes sense to you

    Tip on the timers. Use one tag, call it "state" or "AI" or something.

    On Timer Tag "state"

    -for each enemy

    --state = 0

    --else state = 1

    --etc etc

    It can make it easier if the timer needs to be interrupted (destroyed, stunned, etc.) just one timer to stop and restart or can just change the state if don't want to restart the timer. Also, I've heard you want to do a 'for each' as a sub event for the timer in case two instances' timers go off at once. It will only have those that timers go off picked, not all, but can run them separately.

  • I believe the 'system trigger once' is causing your problem in the 'for each' loop. I'm thinking that will run once at the beginning of the layout and never run again because of the 'trigger once'.

    I'm not sure why you even have that separated—why can't you put those actions up with the 'on created'?

    I don't believe this is causing the problem you are referring to but be careful of using the system 'wait x seconds' in this fashion. Especially if these enemies can get destroyed. If one gets destroyed during the wait the following actions will still run but may be unpredictable. In my case it picked all instances to apply the following events—took me forever to debug. Timers are much preferred.

    Also, in the function, you don't pick any of the enemies so it most likely will pick all of them. So each time one enemy is supposed to fire all of them will. (Pass the UID of the enemy as a parameter of the function then 'pick by ID' as the first sub-event)

  • Thinking about what to title it—some ideas:

    Survive The Night

    Nightfall Cometh

    Camping with Zombies (haha)

    No rush to decide as there is plenty of time and plenty still to do.

  • Kind of to echo what 'sup with that?' I think it matters more on how you event them than the behavior. I'm sure there are differences but I'm not technical enough to know, but the problem is likely arising from you how are event-ing them than the behavior you chose.

    I think it is important to pay attention to your events that run every tick—and that doesn't mean just "on every tick" events, that means any event that doesn't have an arrow next to it. So if you have a ton of those you multiply those by every enemy and that's how many computations run every tick. At least try to package them into one and use the 'else'. That would be my first recommendation.

  • And if it is the 'animation' jerking too much, not the sprite's location, I would still think it has to do with the origin. Did you check the origin on every frame of the animation?

  • But I'm still not sure what this means exactly:

    ... the animation jerks too much.

    This is your original question/problem and it is still unclear. That's why I suggest posting an animated gif of it—probably easier to see than describe.

  • I'm pretty sure a venus fly trap doesn't move until it is ready to strike...

    So probably just need a few different animations and change the animation when player gets close. Compare X to see which side the player is on.

    Or use separate sprites for head and stem (ignore my ignorance of plant terms). Then set angle of head to player so it is always pointing towards the player and follows him.

  • What type of movement behavior? How do you have it setup/what are your events?

    Consider posting screenshot of what is happening and/or your events so it is easier to help you.

  • You are welcome!

    ...and I just realize instead of choose(0, 1)... you can just set state = choose("left", "right")

    Let me know if you have any questions

  • It sounds like the mirrored is what is causing the jerking—is the origin in the middle of the sprite?

    I assume the mirroring is done from the origin, so the closer the origin is to the center of the sprite the smoother the toggling of the mirroring should be.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • If you are doing system-global variable > instance.variable I don't believe it is picking any of those instances, so all are picked. If you do sprite instance.variable < global variable then I believe it would pick only those instances that are true.

    I would recommend though:

    on layout start

    -for each (menu)

    --if instance variable < etc etc

    ---then animate x

    --else; animate x

    I'm not entirely sure if that is necessary but is usually safer.

  • My guess at the problem, despite very limited information:

    Are you using 'for each'?

    You probably have a 'picking' problem, as in picking all of them. Therefore it is applying it to all of them.

  • I get what you are saying, and that is fine if that is the way you want to do it. What I meant was one should always be disabled, thus not being used simultaneously. When enabling one then disable the other.

    My question still stands though—how familiar are you with path-finding? Disable the bullet behavior and debug the path-finding behavior. Use the debugger and a text box to figure out what is going on there.