R0J0hound's Forum Posts

  • Yes, you could use overlapping at offset and some picking with a family I suppose.

  • —

    The canvas plugin is causing the cpu usage when webgl is on. Basically it has to copy the canvas to a texture every tick. If you disable webgl it's fast or alternately you could use the paster object instead.

    dellong

    Nice examples. I didn't think of using the circle for the rainbow, but it looks effective. The only issue you'll run into by fading the canvas like that is the images never fade away completely do to rounding, unfortunately there's nothing that could be changed to make it better. It's more noticeable on certain monitors or if you look at the screen from an angle. Still it's a good effect that I'll use again.

    bilgekaan

    If you're interested in existing solutions you can look here for one using sprites:

    viewtopic.php?f=147&t=164029&p=992930&hilit=trail#p992930

    It can be tuned to not use as many objects if performance becomes an issue.

    For trails with textures the paster object would need to be used.

    newt

    Paster's draw textured quad action handles this well, notion special needed to be done for repeating textures.

    /examples31/draw_path_paster.capx

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You'll have to destroy and re-create the joints.

  • Here's a simplified capx that most of the time creates all the combinations without two of the same type next to each other. It uses an array that stores all the combinations with some text like "sprite:0". Then the array is shuffled by swapping values while trying to keep each two of the same type from being next to each other.

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

    As far as moving the objects or using families, you can do anything you like there. All this does is create the objects. Think of the "create" function as a create action with a family as a parameter, only this follows your controlled random requirement.

  • Considering you're using the physics behavior you can do it by changing the rotation of the layout and setting the direction of the gravity.

    eg:

    set gravity to 10*cos(layoutAngle), 10*sin(layoutAngle)

  • I'm not super familiar with what i did in the example anymore and it's too much trouble for me to use a multitouch device to test but you could possibly do the following. Considering I haven't made any math errors.

    Basically keep track of the current and previous positions of the touches and then use a dot product to get a signed distances in particular directions (parellel and perpendiculat to the box's angle). Basically that's to get the scaling factors in either direction. Next in order to actually scale in those directions I used another dot product like above and then used some trig to get a resulting position. Likely the math could be simplified further if you like.

    global number oldtouch0x=0

    global number oldtouch0y=0

    global number oldtouch1x=0

    global number oldtouch1y=0

    on touch 0

    --- set oldtouch0x to touch(0).x

    --- set oldtouch0y to touch(0).y

    on touch 1

    --- set oldtouch1x to touch(1).x

    --- set oldtouch1y to touch(1).y

    touch id 0 is touching

    --- box: set position to self.x+(touch(0).x-oldtouch0x), self.y+(touch(0).y-oldtouch0x)

    global number ang=0

    global number xscaling=0

    global number yscaling=0

    global number dotn=0

    global number dotd=0

    global dotx=0

    touch id 1 is touching

    --- set dotn to cos(box.angle)*(touch(1).x-touch(0).x)+sin(box.angle)*(touch(1).y-touch(0).y)

    --- set dotd to cos(box.angle)*(oldtouch1x-oldtouch0x)+sin(box.angle)*(oldtouch1y-oldtouch0y)

    --- set dotx to cos(box.angle)*(box.x-touch(0).x) +sin(box.angle)*(box.y-touch(0).y)

    --- set xscaling to dotn/dotd

    --- set dotn to cos(box.angle+90)*(touch(1).x-touch(0).x)+sin(box.angle+90)*(touch(1).y-touch(0).y)

    --- set dotd to cos(box.angle+90)*(oldtouch1x-oldtouch0x)+sin(box.angle+90)*(oldtouch1y-oldtouch0y)

    --- set doty to cos(box.angle+90)*(box.x-touch(0).x) +sin(box.angle+90)*(box.y-touch(0).y)

    --- set yscaling to dotn/dotd

    --- box: set x to touch(0).x+xscaling*dotx*cos(box.angle)+yscaling*doty*cos(box.angle+90)

    --- box: set y to touch(0).y+xscaling*dotx*sin(box.angle)+yscaling*doty*sin(box.angle+90)

    --- box: set size to (self.width*xscaling, self.height*yscaling)

    touch id 0 is touching

    --- set oldtouch0x to touch(0).x

    --- set oldtouch0y to touch(0).y

    touch id 1 is touching

    --- set oldtouch1x to touch(1).x

    --- set oldtouch1y to touch(1).y

  • Kat Editor

    The cap file is a lost cause. The most I could retrieve is 48 of the 52 images in the file. After that the file is all zeros, so events, object types, etc cannot be recovered.

    I pm'd you a zip with the recovered images.

  • The rules as written don't really give good results:

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

    A few notes on the capx:

    An array instance for each object type is used to keep track of what frames can be picked.

    A family isn't used since you can't specify what member of the family to create, but no matter it only added two events.

    There are a total of 9 different frames in the capx so it just created nine rows of nine to test the idea.

    It looks good toward the beginning of the run but the end of the run almost always looks the same. However it may look better if each sprite had the same amount of frames.

    Probably these rules would work better to run through all the frames in a more distributed manner:

    never create the same sprite twice in a row. (unless there are no other choices)

    the random object picked should be based on how many frames are left for a object. (So an object with more frames are more likely to be picked)

    Once all frames are picked, reset.

    mindfaQ's link may be applicable.

  • An action like this would do it

    set text.text to replace(text.text, "5", "")

  • You could use the Keyboard object and use Keyboard.StringFromKeyCode(Keyboard.LastKeyCode) to get the last key pressed.

  • every 4.0 seconds

    for each enemy

    --- create bullet at (enemy.x, enemy.y)

    --- bullet: set angle to 90*int(random(4))

  • Zebbi

    To do it without the paster object just make sure the areas on either side of the layout look identical.

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

    /examples31/loopScroll.capx

  • sweet

  • SamFisher

    The linear damping property can be used to give an object drag so it falls slower.

  • I didn't mean those games specifically, I just mentioned them because they run into the issue with floating point numbers.

    Basically floating point numbers are stored like this fo example:

    1.234 *10^10

    Two numbers are stored. The significant digits and the exponent.

    So just for example say it only has 4 significant digits and a two digit exponent you could represent various numbers like this:

    10 = 1.000*10^01

    192 = 1.920*10^02

    1,000,000,000 = 1.000*10^09

    Etc.

    The result is you can represent a wide range of values but the limitation is the numbers further from zero are further apart. Or in other words, there are more values closer to zero.

    For example take 10,000

    1.000*10^04

    The next higher number is 10,010

    1.001*10^04

    So with a number that big the closest another different number can be is 10 away. And the distance only increases with bigger numbers.

    Now the actual floating point format uses 15-17 significant digits, but in a similar way the differences from one number to the next increases at extremes.

    To fix the object distortion subtract the ships position from everything to shift toward zero so the the corners of the object's quad can be placed with higher percision.

    As your ship nears the edge of the Galaxy (maximum 64bit floating point number) you'll run into another similar issue. The ship with no longer be able to move by small steps, instead it will jump by larger and larger steps until either a position of infinity is reached or the step exceeds the velocity, at which point the ship will stop moving.