If you want to make the whole text red then you could also just use find(txtBox.text, "ball")

Scroll down to the Text section and several expressions you can use: https://www.scirra.com/manual/126/system-expressions

Ashley meant that you probably have a "DevicePixelRatio" that is not "1". And if that non-one value is also non-integer, your canvas size could become irrational, which would cause your entire layout to distort here and there.

The browser object can be used to inspect the DPR.

Okay, I found another explanation and think I understand now—a device's scaling from logical to physical pixels. It seems it isn't uncommon for devices to have non-integer DPR. (according to http://devicepixelratio.com/ )

So if I used 'crop' I could set scale to 1/browser.dpr to revert back to 1 and have no distortion? (then obviously upscale in integers as I please)

Do you know if the one pixel offset is before or after scaling? Also, maybe I'm not familiar with those events, but if the condition is "not overlapping offset at (0, -1)" would the condition be true if it was overlapping at offset (0, -2) or greater?

Platform behavior has a "is by wall" condition—is there a reason that won't work here?

Bullet behavior has a setting for distance traveled, I believe. So:

Bullet, compare distance traveled, if > (start.x, start.y, finish.x, finish.y) then destroy bullet

Of course those are just placeholder terms. If the player doesn't move you can use player.x & player.y, but if he does move either add instance variables for startX & startY, or just create a 'distance' variable and on created set distance to distance(player.x, player.y, touch.x, touch.y).

This is a better solution than creating invisible sprites as doesn't create unnecessary sprites, doesn't' have to check for the collision, and doesn't have the chance of (somehow) not hitting the invisible sprite—or hitting an invisible sprite meant for a different bullet.

Just use letterbox integer scale. No other modes can guarantee pixel-perfect display so easily. For example if you choose crop mode on a device with a non-integral devicePixelRatio (and your screenshot looks like it uses some kind of high-DPI display), then the canvas size itself can be fractional.

(non-integral DPRs are a terrible idea, but they exist, so we have to deal with them...)

Thanks for the answer. I think I get what you are saying—so if my monitor is 1280.5 pixel width then everything is fractionally scaled to account for that 0.5? or would it be, on computer, if the browser window size isn't at an integer?

Would that mean on most devices/screens others would not be seeing this as most are at integral DPR?

Using the full-screen is more prioritized for me than pixel-perfect on this project as I wouldn't want to waste space on mobiles. So if I can't find a solution for both I will probably just use scale outer.

If I could get your thoughts on my two ideas for solutions to obtain both pixel-perfect and full screen:

• Letterbox Integer Scale --on layout start/browser resize -> set canvas size to browser.screenheight & browser.screenwidth (this didn't seem to work when I tried but just realized maybe the screen size was larger than the layout size so couldn't complete the action—don't have Construct in front of me now)
• Scale outer --set scale to canvas.width/browser.screen width so that scale reverts back to 1 or 2*(canvas.width/browser.screenwidth) if larger than certain size, etc.

...(and your screenshot looks like it uses some kind of high-DPI display)...

I haven't researched some settings enough to make educated decision—fullscreen scaling; high-dpi; downscaling—so I posted a screenshot of the properties bar in case anything else affects this or any other recommendations. So I honestly have no clue regarding this part of your comment.

Thanks again and I would appreciate your thoughts on this.

...Does it make sense to do that and 'set canvas size' to browser width and height?

I can't seem to get that to work—not sure if setting the canvas size in events and 'letterbox integer scale' play nicely together.

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.