keepee's Forum Posts

  • Hi all, I need some help making an adjustment to this plugin but I'm not sure if Yann is around anymore

    I'm trying to get rid of the anti-aliasing-like smoothing that polygons draw with. I need jagged pixel outlines, (the equivalent of 'point' sampling rather than linear sampling)

    I was looking through polygons runtime.js and it's a lot more complex than I thought. Started tinkering with it but idk what I'm really doing.

    some (maybe?) important lines:

    line 269 has a mention of linear sampling when in webgl mode, I set this to pointSampling, and it had no effect.

    line 770 is the 'draw polygon' action.

    My hunch is that I should add a line that changes a setting, I found this:

    ctx.imageSmoothingEnabled = value;

    from here: https://developer.mozilla.org/en/docs/W ... ingEnabled

    and I tried adding it in a few places, but I think it's only for canvas2d rather than webgl, so it had no effect.

    Any ideas or pointers?

    thanks

  • you're right

  • i know zenox98, i'm saying more people should be more aware of the unpin

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • using effect params for pre-calculations is a good idea.. now i wonder if that's what the original shader creator intended..

    ill look into pre-multiplied alpha, thanks for the response R0J0hound

  • it's just not as fast as "remember line number+scroll

    I agree it's not an ideal solution, but pressing F2 takes you instantly to the next bookmarks so you don't have to scroll. So it is still faster than scrolling to search results. Scrolling also gets slower with more events.

  • This is the ribbon http://i.imgur.com/pIiC9vr.png , I haven't used it for years

    Everything you might use the ribbon for, can be done with keyboard shortcuts... https://www.scirra.com/manual/64/keyboard-shortcuts

    ...or with the quick access toolbar at the very top of the screen: http://i.imgur.com/RmqSxqE.png

    To add buttons into the quick access toolbar, right click to customize it

    Removing the ribbon will save you 100 pixels of precious vertical screen space

    I've seen too many screenshots of people with tiny screens and huge ribbons so I felt compelled to share this info.

  • I understand your problem and I agree with your suggestions

    Bookmarks can help you a little bit though

    Search > Ctrl+F2 to place bookmarks > Esc to clear search > F2 to cycle through bookmarks, including your search results

  • revert to bounding-box in tiled mode

    I think it's unusual for someone to want a tiled sprite without using bounding box collision mask, so if the 'tiled' option didn't affect collision masks at all, I think people would still manually set them to be bounding box.

    If the 'tiled' option is clearly described as something that -only- affects rendering, then I think that confusing trap can be avoided, or at least it's no more confusing than how people could already accidentally have a collision mask that doesn't match their sprite image.

    but either way.. i understand now that this is a big technical problem as well, so that seems fair enough that tiled sprites aren't a thing

    thanks for the responses C-7 R0J0hound Ashley

  • Okay now I'm really confused

    to test out the dest end and start uniforms, I added this:

    vec2 testSize = destEnd - destStart;

    I previewed that just to see if it wasn't giving me a syntax error, and somehow it fixed the problem completely. Now, sprites vTex coordinates work the same as tiled backgrounds.

    It's strange though, because I did not make the line above affect any of the rest of the code. vec2 testSize isn't referenced anywhere else but it's made the vTex to be screen-relative just by being there.

    the code is literally just: 

    void main() {
	vec2 testSize		= destEnd - destStart;
	gl_FragColor		= vec4(vTex.x ,vTex.x, vTex.x, 1);
}[/code:opumu9fb]

[url=http://i.imgur.com/PdERKrZ.png]http://i.imgur.com/PdERKrZ.png[/url]

This image shows how with the line above, the vTex is relative to the screen but with the line above disabled, the vTex becomes local to each sprite.

  • I have a dream that TiledBackground doesn't exist and instead 'Tiled' is a property that you can set on Sprite objects

    That would be amazing, would solve so many headaches in my project,

    1. I have many cases where I need to write basically the exact same code twice, once for sprites, once for tiledbackgrounds, simply because those objects cant be put in the same family together. And if you want to go one further and have a Family be applicable to Tiled Backgrounds and Sprites, you need to create and code the same family twice. For example some families in my project: PhysicsSprite, PhysicsTile, StructureSprite, StructureTile, ZoneSprite ZoneTile, things like that.

    2. shader vtex coordinates work completely different for tiled and sprites, how come?

    3. animated tiled objects would be awesome

    So anyone know what's up? Is there some incompatibility in design or code that i'm not aware of?

  • I've found that it only appears correctly when used on TiledBackground objects (this is what i've been testing on)

    vtex coordinates work completely differently for Sprites and Tiled backgrounds

    to test this, i made a shader that goes from dark to light as the vtex coordinate goes from 0 to 1

    gl_FragColor = vec4(vTex.x ,vTex.x, vTex.x, 1);

    The top layer are tiledbackgrounds, the bottom layer is sprites.

    http://i.imgur.com/QLqltO2.png

    As you can see, the TiledBackground coordinates are relative to screen space, but the Sprite vTex coordinates are relative to the object.

    Anyone know how I could get the Sprites to behave the same as the TiledBackgrounds? Maybe something to do with destStart destEnd?

  • https://drive.google.com/file/d/0B6fT24 ... sp=sharing

    //checkerboard effect
 
precision lowp float;
varying vec2 vTex;
uniform sampler2D samplerFront;
uniform float pixelWidth;
uniform float pixelHeight;
 
//params
uniform float squareSize;   //size of checkerboard squares in pixels
uniform float strength;     //amount of lightening and darkening to apply
 
void main() {
    vec2 screenSize     = vec2(1.0/pixelWidth, 1.0/pixelHeight);
    vec2 grid           = floor((vTex * screenSize) / squareSize);  //checkerboard grid coordinate, 0,0 is top left square
 
    float checkerboard  = mod(grid.x + grid.y, 2.0)-0.5;            //-0.5 for dark +0.5 for light
 
    vec4 front          = texture2D(samplerFront, vTex);
    front.rgb           += checkerboard * strength;
    gl_FragColor        = front * front.a;
}[/code:2frdzt6h]

Hi all, I made this checkerboard effect for a selection highlight for an in-game level editor. It started as a modification of @chrisbrobs colorcheck effect so thanks to him [url=https://www.scirra.com/forum/effect-colorcheck_t163486]effect-colorcheck_t163486[/url]

The differences are that it's no longer proportional to screen size (parameter is 'squaresize' rather than 'squarecount'), it now adds and subtracts the source pixels with a strength parameter rather than overriding them completely, and I cut out the colorization because I did not need it.

This was my first effect and I have some questions:

[b]Is there an easier way of getting absolute screen-space pixel coordinates? [/b]
Having to calculate the screens size from 1/pixelWidth and 1/pixelHeight, and then multiplying that to the vTex coordinates seems wrong. 

[b]If void main is called for every pixel, is it unnecessary to put certain calculations in there?[/b] 
For example, the screen size calculation above should only need to be done once. Other shaders seem to do things like this as well, is this because the performance hit is negligible?

[b]Why isn't alpha reserved when I only adjust the rgb? [/b]
On the last line I multiply front by front.a to ensure the transparency of the sprite is reserved, but I am not sure why this is necessary:
front is a vec4, sampling the RGBA of the pixel
front.rgb is then adjusted to apply the checkerboarding 
but front.rgb is only the first 3 values in the vec4, shouldn't the front.a be left intact?

thanks

  • Awesome! it all seems to be workin great now.. thanks man, you are legendary

  • The reason why only one gets opacity reduced is because one of the balls still has itself in CollisionOtherObject.

    I changed the cap so both balls get lifted away from the ground and made the text display the first number is Ball.UID then the next numbers are CollisionOtherObject

    So here, 12 and 13 are colliding, but they both have 13 as their CollisionOtherObject

    https://dl.dropboxusercontent.com/u/533 ... jBug2.webm

    https://www.dropbox.com/s/qkbi7a4amw3ap ... capx?raw=1

  • Yea, I tested it a bit more and found that all of the objects' other collisions get replaced by itself:

    https://dl.dropboxusercontent.com/u/533 ... bjBug.webm

    https://www.dropbox.com/s/lp6i6sm0027vw ... capx?raw=1

    Filtering out with CollisionOtherObj != Ball.uid is a good idea for the ball itself but my real problem is how it loses collision with the ground