R0J0hound's Recent Forum Activity

  • Whoa. Thats a lot of code. Hard to pick out the relevant parts. Well, as long as it works for your use case.

  • That example sets the zelevation so that probably overwrites a zelevation tween. So you could probably tween a value and add it the action that sets the zelevation.

  • What solution did you end up with?

    My first thought is you could mark all the squares horizontal, vertical from the start square and limit the end square to one of those. 

    Pick cell by expression
(Cell.x=start.x) | (cell.y=start.y) | (abs(cell.x-start.x)=abs(cell.y-start.y)
Pick cell closest to touch.x,touch.y

    Alternately you could do some math to calculate the end tile on the closest 45 line. 

    set ang to round(angle(start.x,start.y,touch.x,touch.y)/45)*45
Set step to abs(ang)%45=0?cell.width:cell.width*sqrt(2)
Set dist to round(((touch.x-start.x)*cos(ang)+(touch.y-start.y)*sin(ang))/step)*step

Set endx to start.x+dist*cos(ang)
Set ends to start.y+dist*sin(ang)

    Basically it finds the closest 45 degree line, then projects the touch position onto that, and rounds to the nearest cell.

    There may be a simpler solution too.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • So it doesn't work because it can go vertical or horizontal sometimes? We can modify the formula further to only have angles at 45 degrees. Probably this:

    round(((sprite.bullet.angleOfMotion+45+360)%360)/90)*90-45

    For a single object you could also basically do the motion manually with two variables for the x and y velocity, then use overlapping at offset to see when to bounce. Logic would roughly be: 

    start of layout
-- sprite: set vx to 1
-- sprite: set vy to 1

sprite: overlaps wall at offset sprite.vx, 0
-- sprite: set vx to -self.vx

sprite: overlaps wall at offset 0, sprite.vy
-- sprite: set vy to -self.vy

every tick:
-- sprite: set position to self.x+self.vx, self.y+self.vy

    However that doesn't work well if you have multiple moving objects that you want to bonce off each other.

    For a more deluxe and precise way you could move overlapping objects out of each other and calculate the collision normal at the same time to bounce off of. Construct doesn't have a built in way to do that so here is a way to do it between axis aligned boxes by utilizing an algorithm called the Separating Axis Theorem.

    dropbox.com/scl/fi/ac5ihr1qp0xpmoj7mtskh/perfect_bounce_w_sat_collision.capx

  • Change angle to sprite.angle or whatever name you gave the object.

    Or since you are using the bullet behavior with “set angle” to no, you’d want to use the action:

    “Bullet: set angle of motion” and use dop’s formula with

    round(((sprite.bullet.angleOfMotion+360)%360)/45)*45

  • Do the ai bots cause significant network traffic to the site?

    I’ve seen multiple stories about sites where the ai scrapers didn’t respect robots.txt and used up the site’s network data limits from crawling daily.

    But maybe since construct is more niche it’s not a big issue.

  • Here's one of those ideas implemented. To use you just need to set the collision polygon to cover the object and set the two image points to the left and right of the base of the objects. Sorting should work fine as long as the bases of the iso objects don't overlap, and even then it seems to mostly be fine.

    dropbox.com/scl/fi/yuhfzrh8qie1u1946gzh4/iso_sort_6.29.25.capx

    The nice thing about this method is you aren't restricted to blocks aligned to the iso grid, so you can have thin walls or blocks with rotated bases.

    Keep in mind this is for if all the blocks are on the ground. aka no stacking or floating blocks. If you need those then the idea would need extending.

    Currently it just doesn't try to sort between two objects if their bases overlap. I'm kind of curious if it would work better to instead figure out how much on one side of the line or the other the object is and use that. But that's an idea for another day.

  • With iso if the objects are all the same size you can just y sort by the bottom corner. The objects could also vary by their z height and that would still work. So the idea of breaking the long objects into chunks is an idea.

    To sort different sized objects you won’t be able to sort two objects based on one point on each object anymore. If it helps, try the case of just two objects, and figure out which should be in front of the other.

    You can do that by comparing the iso positions of the sides of the base. Or approximating the object shapes by a line from the left and right corners and calculating which should be in front of the other. Or if you want to be super deluxe you can utilize some kind of collision detection algorithm in isometric space and using the collision normal to see which should be in front of the other.

    Anyways after that you’d have a way of sorting pairs of objects. From that for each object you can make a list of other objects that they are in front of. Sorting that is called a topological sort, but basically it involves first drawing the objects that aren’t in front of anything. Then drawing the objects that are in front of only the already drawn stuff.

    Unfortunately it is possible to come up with impossible to sort cases. But in general as long as the bases of the isometric objects don’t overlap you should be fine.

    Here’s an older but useful link about isometric sorting.

    bannalia.blogspot.com/2008/02/filmation-math.html

    Just some ideas.

  • To check for transparent pixels the general steps would be: 

    Position a drawing canvas so it covers a sprite
Paste the sprite onto the canvas
Wait
Snapshot canvas
Wait
Then read alpha at touch.x-canvas.bboxleft, touch.y-canvas.bboxtop

    There are two waits so it’s not something that will complete fast. So if you can snapshot the canvas less often then you’d only need to check the alpha expression. But that depends on what your game allows.

    In theory you could take all the sprite images and put their pixel alphas into arrays at the start of the game. Then it would be fast to access and you’d just need some make to convert a touch position to where on a transformed sprite to read the array from. This will be slow up front but instant after. But also consider having to set this up to begin with.

    Also consider that a touch won’t be pinpoint accurate so you can get away with an approximate collision polygon.

  • Since you mentioned rotation, here is an example of one way to do it that handles either oval being rotated. And as mentioned in the previous post it is completely independent of view scale, scrolling or rotation. The math is done across three actions to be more readable since combining it into one formula isn't very pretty. The trig functions are just used to rotate the xy position.

    dropbox.com/scl/fi/f30qzkjny5nl2fed85udn/map_map_to_layout.capx

  • OnscreenMouse.x/y should be the coords on the hud layer, but since it’s on a normal layer you’ll need to convert it with the layerToLayer expression or just use mouse.x(“hud”) or mouse.x(1) which gets the mouse position on the hud layer which is cleaner.

    Considering your replies to the other examples it sounds like you want something different than what I suggested. More like mapping a position on the oval on the hud to a position on the other oval on the layout.

    If that’s the case then you needn’t worry about the view size, scale or scroll position.

    Relevant change to my suggestion would be to replace the view size and scroll position with the layout ovals size and position.

    And to handle the ovals being rotated? Well it involves some trig or we could utilize the move at angle action to avoid it a bit.

  • So the black oval is like a scaled version of the screen rotated 90 degrees, and you want the mouse over that to translate to a position over the view?

    Let’s try and simplify it a bit first. If you make the oval not rotated and move the origin to the center then the calculated xy position on the view would be:

    (Mouse.x(1)-oval.x)/oval.width*viewportWidth(0)+scrollx

    (Mouse.y(1)-oval.y)/oval.height*viewportHeight(0)+scrolly

    Note: mouse.x(1) is the mouse position on the hud layer.

    Now let’s make it work if the oval is rotated 270 degrees like you have. Basically (x,y) rotated -90 will become (y,-x), but you have it vertically flipped (y,x). So swapping things around a bit the xy formulas will be:

    (Mouse.y(1)-oval.y)/oval.width *viewportWidth(0)+scrollx

    (Mouse.x(1)-oval.x)/oval.height *viewportHeight(0)+scrolly