R0J0hound's Forum Posts

  • You do not have permission to view this post

  • I see you used the second example.

    To know what source the power is coming from you could add another parameter to the power function to be the generatorID.

    So when calling the power function from the source nodes it would be

    Power(node.uid, 0, node.generatorID)

    Or however you want to identify the generator.

    Then in the function you can set the Id of the nodes from param(2),

    And when you call the function again, also pass param(2).

    If that makes sense. You’d probably want to reset the id for all the nodes in the same place that powered is set to false.

    I’m alway from my pc till probably Monday, and I don’t really use c3, although looking at projects from my phone is cool.

    So in general you just need to know if something is connected to power and what that power source is? Does the number of linkages from the power source matter?

    You say each component uses power. Is it distributed evenly over everything that’s connected? Or does each component use the power it needs and pass the leftover power down the wire?

  • I thought i'd have a go at this. Can be done with a flood fill.

    dropbox.com/s/7yyocrr06epdufe/power.capx

    It starts at the source, marks it as powered, and recursively follows the connected wires to power them.

    dropbox.com/s/z2ulq22r0qup7um/power_with_id.capx

    But if you want the distance from the source of every component then the above still works for one source.

    dropbox.com/s/vto9mwobq9uoqsx/power_with_id_multi_source.capx

    For multiple sources we have to spread one layer at a time.

    sources are all set to zero. loop over the 0s and set unpowered connected to 1. Once done do the same for two and so on.

    A nice reference. If we are just powering things it's basically a flood fill. Otherwise it's a breadth first search, which isn't too different.

    redblobgames.com/pathfinding/tower-defense

    -cheers

  • The whole screen is game to draw to as long as the bounding box is in the view.

    I haven’t explored c3’s renderer but it’s likely a batched renderer similar to C2. As such you’re limited to features exposed to to the renderer. Drawing to a texture is probably just an undocumented feature. C2’s renderer had it as a feature at least. It’s used for drawing effects and layers with force own texture. The paster plugin utilized this, although there is more setup and such.

    Now in C2 there was also a function in the renderer to complete all current batches. This was useful to let the renderer finish what it was doing and then you could do anything you desired with all of webgl as long as you preserved the webgl state to what construct had it at. This can kill the benefits of batching so I doubt this way would be officially supported. C3 probably has a similar undocumented function in its renderer.

    Examples in C2 are the dragon bones plugin and some more recent 3D experiments I posted capx for.

    Anyways, webgl provides a couple clipping ideas. One is scissoring. It limits what is drawn to a rectangle on the screen.

    The other is stencil buffers. You can draw anything to the buffer and then you can draw to the screen like normal and the stencil acts like a mask.

    Anyways just some ideas.

  • Instead of creating multiple canvas objects could you not just have 1 and just draw all the circles you need on that one object?

  • The original mode7 topic I thought had info on it.

    Anyways the gist of positioning stuff is:

    // get position relative to camera

    xx = (x-cam.x)* cos(-cam.angle) - (y-cam.y)* sin(-cam.angle)

    yy = 200

    zz = (x-cam.x)* sin(-cam.angle) + (y-cam.y)* cos(-cam.angle)

    screenx = xx/zz + xcenterScreen

    screeny = yy/zz + ycenterScreen

    if zz<1

    then hide object

    else show object

    However, the scale is probably off. Shaders deal with 0-1 scale in spots.

    It subtracts the cameras position from the points position, rotates it in the opposite direction of the cameras angle and then projects it to The screen.

    The shader merely does the opposite. The exact scales can be found by reversing the math found in the shader itself.

    Or you can find the scale by trial and error. Basically before getting the screen coordinates multiply some numbers against xx, yy and zz. Realistically yy should Just be the Ground height. Zz adjusts the intensity of the perspective and xx is the general scale.

    You could even open up the behavior that rex made to get the math he used which is based on reversing the math in the shader.

    I abandoned The shader long ago and don’t want to open it. It’s fiddly and needs to be rewritten. Fiddly in that the scale of things is pretty specific as I recall.

  • In rough pseudocode you can place them like this:

    start of layout

    for i from 0 to 10

    for j from 0 to 10

    -- create hex at (i*xspace+startX, (j+(i%2)/2)*yspace+startY)

    ex:

    dropbox.com/s/zv2ks44yr3lf14j/hex_grid_gen.capx

    also a great resource on hex grids:

    redblobgames.com/grids/hexagons

  • You're welcome. I was able to kind of browse it with the browser debugger when previewing a game. You can browse all the js files used, although the whitespace was stripped so i had to use a js beautifier to be able to better see what it did. I had poked around c2's collision detection before and it's largely the same, so I kind of knew what I was looking for.

  • I noticed that a bunch of topics I replied to are no longer there. Mostly topics by user o0o. I guess the forum allows users to delete topics they create?

  • I had to have a look at the collision code since i didn't think the collision polygon was triangulated, and it's not.

    the polygon collision code is made up of two parts: a check to see if a point is inside of a polygon and if two line segments overlap. Algo is basically this:

    O(1) if A and B in same spacial hash then continue

    O(1) if A and B bounding box overlap then continue

    O(n) loop over points in A, if any are inside poly B then stop, objects are overlapping

    O(m) loop over points in B, if any are inside poly A then stop, objects overlapping

    O(n*m) loop over edges in A and edges of B, if any two edges intersect then stop, objects overlap

    In general it tries to figure out as soon as possible if the objects overlap or not so it doesn't have to check everything. In front of each line I put the big O notion showing the complexity of each step. It starts with stuff that can be done with one check, then it's proportionate to the number of points, and finally it's proportionate to the number of points multiplied together.

    The main complexity that was probably the reasoning of the warning is the edge overlapping check. The max number of checks it can do is the A.pointCount*B.pointCount. So with the standard 8 point polys it's doing a maximum of 64 checks. Two 20 point ones could do a max of 400 checks.

    Edit:

    More points would make calculating an object's bounding box take a longer for objects with more points, but it's a linear increase.

    And what it's worth the physics object does triangulate the collision poly for it's uses. Actually with box2d it merely converts it into concave polygons.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Glad it worked and was helpful.

    -cheers

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Don’t use the behaviors. You can make the motion with events simple enough.

    Give the object you want to move two instance variables:

    Speed and ang. That’ll be your speed and angleOfMotion.

    Then the motion can be done with one event.

    Every tick

    — sprite: move self.speed*dt pixels at angle self.ang

    Then for the bounce it should be as simple as adding 180 to ang and moving out of the wall. Here’s what it should look like. The while and second overlap condition are in a sub event if that’s not clear.

    It moves out a pixel at a time but you can do a smaller step if needed.

    Sprite: overlaps wall

    — sprite: add 180 to ang

    ——while

    ——sprite: overlaps wall

    ——— sprite: move 1 pixel at angle self.ang.

    -cheers

  • Updated the example to write an image url to the clipboard.

    Internally it creates an image and a canvas, loads the imageUrl into the image, draws it to the canvas, gets a blob from the canvas, and sets the clipboard from that.