R0J0hound's Forum Posts

  • I’d just scrap the whole effect and start from scratch. The way the effect works is it draws 8 copies of the image at offsets and sets all the pixels to a color.

    Transparency sounds like just another number to adjust that. The issue is blending the 8 images together. It’s the same issue as multiple sprites with 50% transparency vs the same sprites with 100% and the layer with 50% transparency. In my non flu thinking I’d do that in two steps. Not sure how that would be done in a shader.

    An inset outline could possibly be done by doing a Boolean blending with the offsets together in some way. Then simplifying it if possible.

    I don’t really want to mess with GLSL or JavaScript within construct. If I have to do that I’d rather do it elsewhere.

  • Set array size to (tokencount/4,4,1)

    Repeat tokencount/4 times

    — set array at (loopindex, 0) to tokenat(loopindex*4+0)

    — set array at (loopindex,1) to tokenat(loopindex*4+1)

    — ... and so on for 2 and 3

    Alternatively you can simplify it further

    Set array size to (tokencount/4,4,1)

    Repeat tokencount times

    — set at (int(loopindex/4), loopindex%4) to tokenat(loopindex)

  • I re-shared the images in that link. They are ways to approximate the collision point once the balls are overlapping.

    You still need the point when the balls collide. The two ways are either to use a loop to move the one ball forward by steps till they collide, or you could raycast from the white ball to the red.

    the loop way could be something like this:

    every tick:

    -- testBall: set position to whiteball

    -- testball: set angle to whiteball.angleofmotion

    repeat 1000 times

    testball: isn't overlapping redball

    -- testball: move forward 1 pixel

    The ray cast method it more complex but more percise. Basically a ray from the whiteball against a circle at the redball's position with a radius of whiteball.radius+redball.radius. I couldn't find where I've done that before, but it's a formula you can find online.

    Anyways after that you can calculate the bounce. This is pool so we could do perfectly elastic bounces. You really only need the normal (angle from one ball to another) and the velocity. The formula is pretty standard in physics. Here is a possible example, and a link to an article about it.

    construct.net/en/forum/construct-2/general-discussion-17/approaching-pool-ball-movement-56649

    construct.net/en/forum/construct-2/how-do-i-18/fake-physics-collision-123031

    In the end though it may not precisely match the path the balls will move with the physics behavior due to differences in frame time causing the collision to be at slightly different times.

  • I'd imagine it's not possible for most though. I'd recommend doing a bunch of simple projects to try out various ideas related to what you want to do, and see if you have the ability to do them. Then if you find you're able to do that you can try working all the ideas together. You should to be able to quickly see how much is involved and if it's something worthwhile to work at till completion.

  • Well, what is actually needed to make a game engine/editor? Be able to draw stuff, get mouse/keyboard input, a way to do the logic to put stuff together, and finally a way to read/write files. Not all vanilla construct features are well geared for much of that, but it would depend on what features you'd want your game engine/editor to have.

    Say you wanted to make an engine much like construct. The layout editor and event editor would mostly be a lot of busywork. Same with the runtime. Drawing images or dynamically loading images are some drawing primitives that may need additional plugins. It could take some strategy to keep stuff organized so you wouldn't get bogged down with too may events to deal with.

    In the end you may be fighting with constucts features to do what you want, so it may just be worth it to do the engine something lower level like js so there is more control and less friction.

  • Your project isn't following what I wrote in my post. Anyways here's an example:

    dropbox.com/s/6p5pefe0vex89e7/arrow_pin.capx

  • Opened your link. The technical issue was that when i download it on my phone it adds a .zip to the end of the filename and c3 won't open it then. Anyways I have no help other than it's not following what I wrote in my post. Here's an implementation of what i wrote:

    dropbox.com/s/6p5pefe0vex89e7/arrow_pin.capx

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • With canvas there is no solution. It uses a non webgl canvas which doesn’t use effects.

    For paster it is indeed copied from the c2 runtime, but it is modified to draw to a rectangle instead of the whole screen. Shortcuts were taken for some of the more elaborate parts of drawing effects. For one the effect parameters just use some default values instead of proper calculated values. And two, it just ignored how multiple effects were applied. As I recall the runtime would do some framebuffer juggling to draw the effect to a texture, then take that texture and draw the next effect to another, and so on.

    Anyways the c2 runtime does it with some temporary screen sized textures. Paster object’s can be any size, and we’d need temporary textures of the same size. So I had three possible solutions. Doubling or tripling the vram per instance, dynamically creating the temp textures, or some hybrid approach to try and reuse textures between multiple instances.

    Or the short version, it’s a missing feature that would require a full solution to be written.

  • I’m replying on my phone and I’m having technical issues opening your file in c3.

    There are some nice interactive tutorials here. One covers vector math with sin/cos. Angles on there are counterclockwise instead of construct’s clockwise but the math works the same.

    demoman.net

  • jobel

    Using sin/cos like that is basically what the “move at angle” action does. So setting the position could be like this instead, which is exactly the same.

    Every tick

    — Blue: set x to red.x + self.d*cos(self.a+red.angle)

    — Blue: set y to red.y + self.d*sin(self.a+red.angle)

    — blue: set angle to self.da+ red.angle

  • Give the object you want to pin three instance variables.

    a - angle from other object

    d - distance from other object

    ra - relative angle from other object

    Then to set it up you’d do an event like this: for this example we are pinning the blue object to the red object.

    Start of layout

    — blue: set a to angle(red.x,red.y,blue.x,blue.y)-red.angle

    — blue: set d to distance(red.x,red.y,blue.x,blue.y)

    —blue: set ra to blue.angle-red.angle

    Then the positioning would be:

    Every tick

    — blue: set position to red

    — blue: move self.d pixels at angle self.a+red.angle

    — blue: set angle to self.ra+red.angle

    That’s basically it. When there are multiple objects to pin to you’d want to store the uid and stuff.

  • [quote]changing to a 30 or 15 degree arc, would give a lot more track design variety, food for thought.[/quote]

    As it is now you can place tracks on a 64x64 grid, which makes making tracks pretty easy in the layout editor. Other arcs wouldn't line up to a grid as readily. I mean an in game track editor is another option, but saving and loading workflows are a bit awkward in construct games.

    Anyways this was meant to be more of a simpler proof of concept.

  • Cool examples AllenR! Looks like you had a lot of fun making them.

    I'm a bit late to the party, but I finally was able to try out an idea to make motion on the curves smoother. It also lets you place cars at exact distances on the tracks so spacing stays good too. Other than that it's pretty bare bones with only one track.

    Anyways here's the capx.

    dropbox.com/s/quzp15smcjkljd4/train_wip2.capx

  • I mean you don’t have to use behaviors at all. The collision detection and response would be the most complex to deal with though. It just depends on what you’re trying to do.

    Here’s an example for handling the horizontal motion utilizing physics. I used the joyx variable to handle the left right controls, because if they are both down they will cancel. If nothing is pressed or they are canceled then deceleration will be applied opposite the velocity. If instead only one key is pressed an acceleration will be applied in that direction. For faster turning the deceleration is applied too if the velocity is opposite the direction you want to go. I used a math trick a*b<0 if a and b have opposite signs. Finally the max speed is enforced by clamping the velocity.

    Global number joyx=0

    Every tick

    — set joyx to 0

    Left key is down

    — subtract 1 from joyx

    Right key is down

    — add 1 to joyx

    Joyx = 0

    — xvelocity>0

    —— apply force -deceleration

    — else

    —— apply force deceleration

    Joyx <>0

    — apply force joyx*acceleration

    — compare: joyx*xvelocity <0

    —— apply force joyx*deceleration

    Every tick:

    — set xvelocity to clamp(xvelocity, -maxspeed, maxspeed)