R0J0hound's Forum Posts

  • 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 *********** 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

  • 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.

  • dropbox.com/s/bfxii1ius92fee0/card_fan.capx

    Basically put all the cards in the same spot. Rotate each a bit, and then move them at an angle.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This works on chrome 84 to load an image from the clipboard. Not sure if other browsers do it differently. It was a bit different than the mozilla documentation about the clipboard api.

    Writing to the clipboard is possible too but I had nothing to write.

    dropbox.com/s/yeoltfvz63hpasb/js_read_image_from_clipboard.capx

    For c3 I think you may need to change c2_callFunction to c3_callFunction, unless something else changed with new functions.

  • mid(line, 8, 100) is extracting the name. It starts at character 8 since “#recipe” has a length of 7 and I added 1 more to skip the space after it too. 100 is just arbitrary. I just needed something well over the length of the line. It basically just gets the rest of the line.

    int() also converts text to a number. It just gets any digits and then stops when it hits anything else.

    I used it as a shortcut to just grab the number at the beginning of the line.

    I turn it back into text and get it’s length so I can know what character to start at for mid.

    I guess I wasn’t consistent to use trim. I could very well have added 1 to account for the space

    mid(line, len(str(count))+1, 100)

    The trim is nice to use though. Gets rid of any unintentional trailing spaces.