R0J0hound's Forum Posts

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's probably possible.

  • It's probably a bug in my code, but I can't test it without the webgl renderer being used.

  • —

    You could go at it from another angle. You could use a 1x1 sprite and just paste that, or you could just use a tiny tilemap instead of the paster object. If the map doesn't change you could also use the canvas plugin, since it only has a performance hit with webgl if you constantly change the texture.

  • You could do this:

    global number index =0

+------------------------------+
| while                        | set index to int(random(5,8))
+------------------------------+
   +---------------------------+
   | array: value at index <99 | array: set at index to 5
   |                           | stop loop
   +---------------------------+[/code:3re0ismd]
Basically pick a random index until the value isn't 99 before setting the value.

You could probably do it all without an array though.

  • I took a look and the events look correct. I don't use webgl so if there's a webgl related issue I won't see it. The minimap was oriented correctly, but the colors were faded except for the right and bottom edge. I have no idea why that occurs, but using a "additive" blend is on solution.

    Edit:

    Fixed the faded issue in the plugin.

  • I just tested it here and there is no issues going to a max speed of 10000. The speeds are in pixels per second btw.

  • mattb

    My behavior wouldn't work here because the isometric view is for 2:1 instead of 60 degree isometric. It could be an idea to somehow work with it, but I haven't given that much thought.

    My idea may not even be simpler. I've been working on a example off and on to get a working example of my idea. but I haven't put a lot of time into it yet.

    The z-ordering is too hard if all the cubes are placed. So only sorting them per hexagon is much simpler. To actually sort them i'd use the filimation approach which compares all the blocks and builds a tree graph of what is in front of what. Which is what my behavior does and works great for sorting isometric in most cases.

    The collision detection is simple enough. If the player and a cube are visually overlapping you can then compare their isometric positions to do a bounding box collision check in iso. You could populate a 3d array as a 3d grid of cubes as a lookup but it shouldn't be necessary.

    Everything is per hexagon and is the player overlaps multiple hexagons, then each would need to be updated.

    What i'm currently working on is a way to update the cube positions on a hexagon. For that I need to know which of the six sides the the blocks exit and the the order of each of the three axis (x,y,z). Like if only the y and z line were used like in your top right image: x in front of z, y and z the same, z in front of y. I can move any line forward by adding the same value to each isometric position, which won't change the visual location.

    The player's position can be different per hexagon because of this order, so to remedy the transmission from one hexagon to another, it needs to keep track of what line the current block it's touching is on (x y or z).

    It may end up not being easier than what you're doing but it works in my mind. Once I get it working I probably can identify some unneeded cruft and simplify it. It's just taking longer than expected because I haven't had much time to work on it.

  • Here's a discussion of ways:

  • With a tilemap I don't think any of them will help, since all those get a collision shape either by using imagepoints or using the size and angle of the object to calculate the collision polygon. Tilemaps are different. For them to work we first need to find the tiles the player overlaps, then treat each tile as a separate object. It's doable, but I'm very slow at coding lately and I have other things I'd like to work on first.

    Another way to do it is to use a different approach. Instead of figuring out the collision polygon, we could use collision checks with moving around a little to find the approximate angle of the hit edge. The closet existing capx to that would be this, but it would need more work to get it to handle sliding on more angles.

    By far the simplest thing to do would be to just use the physics behavior, which probably would look alright.

  • bloodshot

    Just multiply the speed by an value between 0 and 1 when it bounces

    Set Yvelocity to -0.5*abs(Yvelocity)

  • It involves finding the angle of the spot on the polygon the player hit and canceling the speed moving against the object. You can look here for a few examples you may be able to use in your game.

  • tgeorgemihai

    You probably could do that with only two paster objects. One to paste a players view and then a second that you paste the views to.

    Use paster if the game has webgl on, otherwise it doesn't matter, you can use either.

  • One thing I see that would simplify the z-ordering is if you only did a hexagon at a time. Actually with that you could easily enough handle collisions and movement within a hexagon very simply. You could mask out everything outside the hexagon. This does introduce a different problem though, transitioning from one hexagon to another which is mainly a matter of changing the player's position. That the point I'm stuck currently, just need to come up with a clever way to do that.

  • 1.

    No it doesn't, either is just as fast.

    2.

    First C2 filters down the possible collisions with collision cells:

    https://www.scirra.com/blog/ashley/6/co ... on-in-r155

    Next it sees if two object's bounding boxes overlap, and then it sees if the collision polygons overlap.

    Basically it goes from fastest check to slowest and stops further checks if objects can't be overlapping. The more collision poly points the slower a check will be.