R0J0hound's Forum Posts

  • It appears that when extend-box-horizontal or extend-box-vertical are both 0 the vTex coordinates are on the sprite, where the origin is the bottom-left corner of the sprite. But when either is non-zero then the coordinates are on the screen, where the origin is the bottom-left corner of the screen.

    The issue is if we wanted to scale from the center of the sprite we'd need to find the vTex coordinate of the center of the sprite, and I haven't seen any example of this in the plugins. Looking at some of the radial effects you can use the center of of either the object or screen, depending on what the vTex's are on, but it's not helpful if we want the center of the object when the vTex is on the screen.

    Trying to see what we have to work with, here are some of the variables that C2 provides for shaders (from glwrap.js):

    pixelWidth;

    pixelHeight;

    destStartX;

    destStartY;

    destEndX;

    destEndY;

    layerScale;

    layerAngle;

    viewOriginLeft

    viewOriginTop

    Poking around glwarp.js there seem to a couple more, like samplerFront, vTex...

    Also built in to glsl you have these:

    https://www.opengl.org/wiki/Built-in_Va ... der_inputs

    The bottom-left is always (0,0) and the top-right is always (1,1).

    You can calculate the width in pixels with 1.0/pixelWidth, the height can be calculated in a similar way.

    Interesting, but nothing really helpful. The only solution I can think of would be to add two more parameters for the center x and y and set them every tick. Then the math would be something like (x-center)*scale+center.

  • Describe the offset. If you set extend-box-horizontal to say 10 is it offset right 10 pixels? Maybe the vTex positions have an origin at the top left? So The points clockwise are (0,0), (1,0),(1,1),(0,1) perhaps?

    At any rate maybe you could offset it back using the built in pixelWidth var? So with a extend-box-horizontal of 10 and a extend-box-vertical of 5 maybe this would work?

    uniform mediump float pixelWidth;
uniform mediump float pixelHeight;

vec2 tex = vTex * (1.0-size);
tex.x -= pixelWidth*10;
tex.y -= pixelHeight*5; [/code:39h6zqw8]

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sprite's in the debugger show their angle in the range of 0-360 so I assume it's variables you have?

    Sprite.Angle gives it's angle in the range 0 to 360.

    The angle() expression gives a value of -180 to 180.

    If you just subtract from a variable it will naturally go to negative infinity.

    This will convert any angle to the range of 0 to 360:

    (a%360+360)%360

    This will convert any angle to the range of -180 to 180

    angle(0,0,cos(a),sin(a))

  • Have a look at the webstorage object for a way to save info across runs.

    https://www.scirra.com/manual/120/webstorage

    Also the browser object has a way to invoke a download to a text file, and The nodeWebkit plugin has a way to create a file when using nodewebkit export.

  • An effect could be made to do it, but I haven't seen any yet. One way to do it is using the Paster Plugin which allows you to specify the corners of a quad to draw on.

  • Here's a a way to do a line graph, as well as putting it on a box. Didn't use canvas.

    https://dl.dropboxusercontent.com/u/542 ... /plot.capx

    Minor

    I like how yours scales to the max value and labels the y axis. A very nice touch!

    edit:

    Just tried your latest one. Looks pro.

  • This post may help.

    Sampling pixels is a relatively slow operation that adds up when doing it multiple times. In javascript you can copy a whole pixel area to an array. The result is very fast sampling of any of those values. The expression in the canvas object is .AsJSON and it returns a json string that then can be loaded in the Array object.

    I added it as an experiment so it isn't very user friendly. For one the array size is [1, 1, width*height*4] and to access a particular pixel you have to do it with [0, 0, (width*y+x)*4+i] where i is 0 for red, 1 for green, 2 for blue, and 3 for alpha. Also all the pixel data is in the range of 0-255.

    With regard to performance, one rgbaAt() is faster than one .AsJSON, but .ASJSON becomes faster when you want to sample many pixels. Also the bigger the canvas the slower it is, so when you only need to check a smaller area you should paste the canvas to a smaller one and use .ASJSON on that.

    Also alternatively Another idea is to just copy the terrain to an array to read from and clear it manually when you clear parts of the canvas. Tedious, yes but gives good performance.

  • If my variable1 is 1 then the following conditions, actions and sub-events won't run.

  • Cool. Do you do any keyframe blending or is it just straight keyframes? Thought about adding rotation?

  • Here's an example that can get you most of the way there. You'll probably need to position the object overhead before pinning though.

  • Keeping track of what waypoint the car is on is a way to give a very rough estimate of the rank. You can get a finer rank by also considering the perpendicular distance to the next waypoint.

    So the event needed would basically look like this:

    For each car ordered by waypoint*1000-perpDistToWaypoint decending

    --- loopindex+1 is the rank.

    If the distance between checkpoints can be more than 1000 change it to some higher value.

    Ex.

    https://www.dropbox.com/s/y3xhf4wp2t6kh ... .capx?dl=1

    /examples26/laps.capx

    The perpendicular distance is the dot product between the waypoint line and the vector from the waypoint to the player. It can actually give us negative distances so we'll put it in a abs() so it's always positive.

    Player = {x, y}

    waypoint_to_player = {x-way.x, y-way.y}

    waypoint_line = {cos(waypoint.angle), sin(waypoint.angle)}

    perp_dist =abs( waypoint_to_player dot waypoint_line )=abs( {x-way.x, y-way.y} dot {cos(waypoint.angle), sin(waypoint.angle)} )

    = abs((x-way.x)*cos(waypoint.angle) + (y-way.y)*sin(waypoint.angle))

    vector

  • No, but from the best I can tell:

    solModifiers is the current selected object list state, or something to that effect. Basically what's picked.

    pushCopySol() Saves the current sol to a stack.

    popSol() Restores what was saved from a stack.

    More details about it can be found be poking around the source.

  • The most info you can find is from the manual:

    https://www.scirra.com/manual/26/runtime

    The function basically grabs the current position in the event sheet and runs the subevents from there multiple times. Once for each dictionary key.

  • Well you can't really disable it. The most you can do is change the "runtime" property (below the eye distance property) from direct-X9 to application. But then the game will have no graphics at all.

    Also if the server has a display then it has a graphics card. It sounds more like you need to install directx or something.

  • How does the eye distance have anything to do with the crash? Did it start crashing after setting it to 0? Eye distance is mainly for 3d objects and objects with ZElevation. Why do you want to disable it? If it's perspective you want to disable you can do it with the system action "set projection mode".