It switches the drawing mode to the collision mask, so you can change the mask in your sprite without effecting the sprites image.

Should include a reason for the post, so people not in chat know why it's there, and/or a link back to the original thread it's related to. Then someone else might come along and know how to fix the problem maybe.

My bad, typo.

It should pick the correct one automatically and let you placed the player in front or behind it, without worrying about any of the others.

Well I'm willing to concede that I screwed up and made it 16x18 and not 16x16. BECAUSE, it perfectly shows why pow2 should ALWAYS be used! Oh yeah, I came out of this smelling like roses, lol.

But seriously though, it does clearly demonstrate how very easy it can be to be off by just a few pixels, and what a big negative effect that can have on a game.

So if/when I do do a pow2 tutorial, I'll be references this thread as a perfect example of why pow2 should always be used. See cause like.. I made this thread as part of a tutorial.. you believe that, right? RIGHT??

> Your 16x16 .cap actually uses a 16x18 texture

>

Nice. I think maybe you should look at a tutorial before you make your tutorial LMK

Hehe, I kid!

Haha, it was intentional, I swear *hides*

Thanks for explaining it, though I knew most of it, I think it'll help clear things up for begionners.

Yep, mostly of use just to the really green users, and np.

Brilliant Idea!

Only 1 word comes to mind for improvement.

Sliders

And not the whitecastle kind!

Outline should work properly if you turn off text antialiasing... but then all text will appear kind of jaggy.

Text in the runtime always looks jaggy for me. Inside layout it looks how it's supposed to.

Your 16x16 .cap actually uses a 16x18 texture That's not power of two, so power of two rendering is disabled! If you resize the texture to actually be 16x16, the framerate goes up.

Just to clarify some of the comments here, in practice the framerate for tiling power-of-two textures (16x16, 128x128...) should be roughly the same. Power-of-two textures can be drawn more efficiently - there's basically a single command which is "tile texture N times". That doesn't work for non-power-of-two textures though, so instead for each and every tile Construct has to issue a separate "draw this texture once here" command. That introduces a very large overhead of command data going to the GPU which is the main cause of slowdown when many tiles are visible on-screen.

Well that is even weirder then, cause it was 16x16 when it was saved, lol. Though assuming it was user error on my part. It still had a similar slowdown for someone else who did their own.

Though I am hoping it is user error on my part

Playing again.

Subscribe to Construct videos now

Looking good Minor

What about...

Two text objects, one a clone of the other. Use Blur movement (not regular blurs) twice, one at 0 angle one at 90 degree angle, make that text black, and the blur amount 2. Then a white text object over it. Looks fine.

Though also so does the dropshadow plus method suggested earlier (didn't try the older dropshadow btw).

Course anything to do with text, just looked default in the runtime, and I remember something was said about that a while ago, I think it's actually a known bug.

> Would drop shadow work?

>

Tried it but it doesn't look too good.

Hmm. I suppose using premade text is out of the question too, as you'll want it dynamically updated right?

Could always try spritefont plugin perhaps? I've never used it though.

Isn't there also a new text effect David made, which makes text look a bit better. Maybe apply that and the outline one?