R0J0hound's Forum Posts

  • +1

    Good suggestion.

    I suppose you could use sprite.AsJson and the "load from json" action to copy all the properties of one object to another. Just pick the object you want to use as the default and save the .asJson to a global.

  • It's more of something that should change with the paster plugin. I'm on a mobile right now so I won't be able to find the link, but a search for paster and tilemap should yield a solution.

    Basically to paste a tilemap you move the part you want to paste into the scroll area along with the paster object, then paste it, and move everything back.

  • I'm pretty sure the effects are compiled before the start of the layout, so the constant become unmodifiable. I suppose if you could edit the source and re-compile the shader at runtime the constant could be changed, but there isn't anything in place to do that currently.

    I'd go with the idea in your link and test how it performs.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I should. I'll work on getting it put in a tutorial.

  • You can use the 8direction behavior to move the object but you can't use the solid behavior for the walls because the behavior will just stop when hitting a solid.

    At this point we can detect collisions with the overlap condition. The part we want now is some kind of collision response to keep the object out of the walls and do other stuff like sliding.

    The simplest collision response would be to save the object's position before moving and the if it overlaps a wall after moving then undo the move by moving back to the saved position. The drawback is this won't do any sliding and if moving fast the object will stop short of the wall.

    Another method is to move the object a pixel or so at a time until it's not overlapping. All that's needed is a direction. If we use the opposite direction of the motion we'll get the object to stop at the edge of the wall, but not slide. If we instead find the closest direction to move out we can get sliding. We just need a good way to find the closest direction.

    One idea to find the closest direction would be to save the object's position then try moving out in each of the four directions of the wall, and measure the distance moved for each. The closest direction would be the one with the shortest distance. You'll want to do this for each wall. With this you'll get wall sliding but you can get some jumping when hitting a corner which may be kind of like your third picture but not quite.

    One thing to consider is so far all that's being done is correcting the position of the object, but we will also need to correct the velocity of the object. Sliding would basically be setting the velocity perpendicular to the side of wall (or normal) to zero. The normal is also the same as the closest direction that the object moved out.

    Setting the velocity along a direction to zero can be done with some math.

    Var vx= object.velocityX

    Var vy= object.velocityY

    Var dot= vx*cos(dir)+vy*sin(dir)

    Set velocity to (vx-dot*cos(dir), vy-dot*sin(dir))

    Dot is the velocity along a direction and we're subtracting it from the velocity.

    You can avoid the position jumping by not moving out in the closest direction. Instead move out in the opposite direction, keeping track of how far we move out as this is the remaining distance to move. Then we need a way to find the normal of the collision. From that we can the correct the speed as with above and then try to move again with the new velocity, or basically just move in the same direction of the current edge with the remaining distance. This can be repeated as many times as nessisary but usually it's fine to do it once.

    One way to do the normal detection is to use overlaps at offset to check the positions around the object

    Var dx=0

    Var dy=0

    Overlaps at offset(1,0)

    --- add 1 to dx

    Overlaps at offset(1,1)

    --- add 1 to dx

    --- add 1 to dy

    Overlaps at offset(0,1)

    --- add 1 to dy

    Overlaps at offset(-1,1)

    --- add -1 to dx

    --- add 1 to dy

    ...etc

    Then the normal should equal angle(dx,dy,0,0)

    This requires that the object is all the way pushed out first before finding the normal.

    All this will cause a very high amount of collision checks and the object may jitter when repeatedly pushing out of walls due to pushing out a pixel at a time not being precise enough. Both can be solved by implimenting raycasting which can be used to find exact collision points and makes finding the normal simpler, that is once it's all setup which isn't really simple.

    Of course I may be overthinking a lot of this, and even after getting wall sliding working a few times I think it could be made a lot simpler. Instead of handling everything with equations to handle all cases you probably could get by by coming up with a list of cases and handling them one by one. For instance the third case in your image to move around a corner. For example:

    object is moving down

    Wall is below

    ---wall not below to the left

    ------ move object left

    ---wall not below to the right

    ------- move object right

    Just do that for all four directions. Still you'll still need some good collision response like above.

    Anyway I hope some of the above is useful in some way.

  • Until I add such a trigger you could use a sprite to do all the loading and on the loaded trigger paste the image into a paster.

  • sqiddster glitchg

    Here's an overview of all the variables the C2 provides for effects.

    All vertex positions, unless stated otherwise are in relation to the screen where (0,0) is the top-left and (1,1) is the bottom-right.

    varying vec2 vTex

    This is the vertex co-ordinate of the current pixel

    uniform sampler2D samplerFront

    this is the source pixels. AKA the object's texture or the result of the previous shader.

    uniform sampler2D samplerBack

    this is where stuff is being drawn to

    uniform float pixelWidth

    1.0/width or in other words a pixel width in vertex co-ordinates

    uniform float pixelHeight

    1.0/height or in other words a pixel height in vertex co-ordinates

    uniform vec2 destStart

    The top-left vertex co-ordinate of the rectange being drawn to.

    uniform vec2 destEnd

    The bottom-right vertex co-ordinate of the rectange being drawn to.

    For example a rectangle that covers the entire screen would have a destStart of (0,0) and a destEnd of (1,1)

    Usually they define a rectangle that covers just the object, but depending on the xml settings it can be larger.

    uniform float layerScale

    uniform float layerAngle

    ^ In radians I think.

    Both these are basically the same as their counterparts in C2

    Now the folling two aren't used in any bundled effects but they'd have the same values as ViewportLeft(0), ViewportTop(0) and scrollx and scroly respectively.

    uniform vec2 viewOrigin

    Top-left of screen in layout pixels

    uniform vec2 scrollPos

    Center of screen in layout pixels.

    uniform float seconds

    Time.

    uniform float opacity

    Current object/layer opacity in the range of 0.0 to 1.0

    In glwrap.js there are these others: aPos, aTex, matP, and matMV but they are only used in the vertex shader and I'm not even sure you can access them from a pixel shader.

  • If the shader is working with shadertoy it should work fine as is I imagine, since they're both webgl.

    Here's a helpful link:

    http://www.shaderific.com/glsl-qualifiers/

    "varying" is only for data shared with the vertex shader. In C2 those variables are fixed and usually I just find what values are varying from other shaders.

    "uniform" is only for the shader parameters you can set later.

    You can omit the precision specifiers and a default precision will be used. You can even change what that default is. So if you just have a variable you use in the shader it's fine to just write "float foo" or "vec2 bar".

    You should be able to use "const" the same way as with shadertoy.

  • It's one of those number precision things with computers. There is a limit to the number of digits of a number can be stored. JavaScript uses 64-bit floating point numbers to store numbers and according to this:

    http://en.wikipedia.org/wiki/Double-pre ... int_format

    It can store 15-17 significant digits, which is on par from what you found.

  • isasaurio

    I suppose you could just give the ball an elasticity greater than 1 to make it bounce more.

    bladedpenguin

    Only the main timescale works. Individual timescales aren't used because all the chipmunk objects need to have the same timescale for the simulation.

  • You'll need the time when he reaches full speed. Then you can calculate it with:

    Acceleration = 2*distance/(time^2)

    If he reached full speed after one second the acceleration would be 150pixels/sec^2, but I'd guess the max speed was reached before one second, so it wouldn't be correct.

    You can calculate the speed for any range of frames with:

    Speed = distance/time

    Where time = frames/60

    From your info the speed from 75 to 90 pixels would be 90pixels/sec according to that formula, so he'd already be at max speed.

  • With some programming languages you can, but with python and js you can't, at least not fully.

  • Joannesalfa

    I have, but I'm wrapping the html5 api to sfml. It's not an issue using a graphics library since I'll only be using a small subset of it. The issue currently is I haven't been able to build the V8 library yet.

    That game seems to go fast, but I have no idea if it's faster.

    Nesteris

    Because it's interpreted. So is Javascript for that matter but it's faster because portions of the code is compiled to machine code when it's run.

  • Well according to benchmarks JavaScript is anywhere from 3 to 60 times faster than python.

    http://benchmarksgame.alioth.debian.org ... g2=python3

    Python is still garbage collected and yes it can be used for games, even 3d ones. Usually though for 3d the engine part is made in C and python is used for the scripting parts that don't need to be fast as possible.

  • Lunarovich

    I've had a look into it and the bug occurs when I use:

    for x in instances[/code:2a9uzrdq]
in my code.

"instances" is an array so x just loops over the indices of the the array (0, 1, 2...).  But when it fails x's value is "random".  Looking in rot.min.js the Array object has these two methods added:
Array.prototype.random
Array.prototype.randomize

Adding methods to the Array object will break Array.foreach since it will now loop over the the methods after the indices.  I can fix it in that particular case in my code, but any other plugin or part of C2 itself that uses Array.foreach will break as well.

The solution would be to do something like this to redefine the other prototype methods of the array to compensate.
[url=http://kenegozi.com/blog/2009/04/13/javascript-and-the-extended-array-prototype/]http://kenegozi.com/blog/2009/04/13/jav ... prototype/[/url]