R0J0hound's Forum Posts

  • Basically that. I’d have it replicate what’s on screen though. Or just a layout sized area centered on the screen.

  • So the issue is “Sprite: has LOS to sprite” is picking itself? The solution is to use a different object. A family with that sprite is one solution

    Which would look like this: 

    For each sprite
Pick otherSprite by comparison: otherSprite.iid <> sprite.iid
Sprite: has los to otherSprite
— do something

    You can also do the same with another dummy sprite. The idea is you create one per sprite instance. So there is a setup step, and an update step. Well unless you pin them together. 

    Start of layout
— dummy: destroy
— for each sprite
— — create dummy

Every tick
— dummy: set position to sprite

For each sprite
Pick dummy by comparison: dummy.iid <> sprite.iid
— do something

  • Trig functions in construct take degrees instead of radians. To fix your formulas just replace 2pi with 360

  • I get that you’re using unbounded scrolling but if the map is fixed you could just put the whole thing within the layout bounds.

    Since you’re doing it for control you could replicate obstacles on screen to the layout bounds, do pathfinding there and just move the player from that. You just have to deal with the offset from the screen to the layout bounds. Bear in mind pathfinding will be done with only partial knowledge of the map. Guess this is similar to shifting things around to make the on screen stuff be on the layout.

    Third option could be rolling your own pathfinder. The pro of that is more control. The con is more work to make it match what the behavior does.

    One idea could be using Dijkstra's algorithm from the player’s position to the target. Instead of a 2d array of the cells you could do a sparse array with xy pairs as keys for cells. Or you could use astar. The idea is we have more options for how we define the graph of walkable nodes. The behavior uses a 2d grid of cells within the layout bounds. What i mentioned above is a sparse 2d grid of cells with no bounds. Beyond that there’s navmeshes or similar stuff.

    If your obstacles are mostly convex then you can get decent pathfinding with raycasts and wall following.

    Kinda just throwing a bunch of ideas out there.

  • I prefer using multiple events over wait. Seems cleaner to me and keeps the events running in place.

    Honestly when new objects are pickable is one of the ugliest parts of the event system. If you don’t understand it it’s confusing, and annoying when you do since it feels like you’re doing code juggling to work around it.

  • It’s actually sooner than the next tick. What you can do is split that into multiple start of layout conditions.

    So instead of this which doesn’t work since the for each doesn’t have access to the newly created sprites. 

    Start of layout 
— repeat 10 times
— — create sprite at random(100), random(100)
— for each sprite ordered by sprite.y
— — do something

    You can do this which will work. The second start of layout has access to the newly created instances. 

    Start of layout 
repeat 10 times
— create sprite at random(100), random(100)

Start of layout
For each sprite ordered by sprite.y
— do something

    In general any instances you create in an event aren’t pickable until the next “top level” event. A top level event is an event that isn’t a sub event of another event. They can be inside a group though.

    An alternate way that’s popular in the community is to use a wait. It effectively delays events from running until way after the created objects are pickable in general. I say way after since the shortest wait is 0 which seems to delay till the end of the event sheet.

    That would look like this: 

    Start of layout 
— repeat 10 times
— — create sprite at random(100), random(100)
— every tick
— — wait 0 seconds
— — pick all sprite
— — for each sprite ordered by sprite.y
— — — do something

    Which works fine in a simple case like that but it makes it really hard to follow the order events run with heavy use.

  • You probably should have asked this in the Construct 2 section since it uses a C2 only plugin. Anyways, I won't be able to debug/modify your capx but here is an example of the idea I posted above to do box collision response.

    dropbox.com/scl/fi/od9ncndg8fnsioaijjgr4/cloth_verlet2.capx

    It's not really building onto what your other capx does since I made it from scratch. But if you copy the sdf function, and add events 15-16 to yours before you update the velocity variables it should work.

  • Basically you start with equations for the path the objects would go if the stayed at the same speed.

    Position = start_position + velocity*time

    That can be split into two formulas for x and y motion. And you’d also have one equation for the target and one from the bullet. Then you just solve the equations for the bullet velocity. Or just the bullet angle if you make the speed fixed. It’s just a matter of using algebra to solve it.

  • So you have ten instances of one type and the type has a Boolean you want to set when there’s another instance nearby? I think using the variable name “nearest” is throwing me off, “near” could make more sense if I’m understanding it right.

    A common way to reference other instances of an object type is to add a family and add that object type to it. Here I named the family “other” and the events could look like this: 

    Every tick
— sprite: set near to false

For each Sprite
For each other
Compare: Sprite.uid <> other.uid
Compare: distance(sprite.x, sprite.y, other.x, other.y)<50
— sprite: set near to true

    An alternate way is to use sprite(iid).x to reference other instances. No family needed. 

    Every tick
— sprite: set near to false

For each Sprite
Repeat sprite.count times
Compare: Sprite.uid <> sprite(loopindex).uid
Compare: distance(sprite.x, sprite.y, sprite(loopindex).x, sprite(loopindex).y)<50
— sprite: set near to true

  • Your link doesn’t work. It wants me to login

  • Short answer is no. Long answer is maybe.

    You can already load textures at runtime. To use additional textures in an effect there are two parts in webgl. On the shader side just add another sampler uniform.

    To make it reference a texture you need to select a texture unit, bind a texture, and finally bind the shader program and set the sampler uniform to the texture unit index you’re using.

    Construct’s renderer doesn’t use too many texture units so you could use an unused one to bind a texture to. To do that all you need is to get the webgl context.

    The part I’m iffy about is setting the uniform on the shader. To do that you need the shader program for that shader. And that’s something that construct keeps track of. Possibly could be other ways to get the shader handle.

    Anyways that’s just a general outline for how it could be done for webgl. Construct doesn’t provide anything to help with that nor does it do much to prevent that.

  • Unless you can start a local server with JavaScript you wouldn’t be able to do it via python implemented via webassembly. The same limits apply. To bypass the browser limits you’d need a plugin for nwjs or webview2

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I don't really want to make another cloth example. I've made like 10 and posted them all on this forum from one time or another.

    To move a point out of a box one way I've found useful lately is to use an sdf (signed distance field). Logic is basically this: 

    var dx, dy

function sdf(px,py)
-- dx = (px-box.x)*cos(-box.angle)-(py-box.y)*sin(-box.angle)
-- dy = (px-box.x)*sin(-box.angle)+(py-box.y)*cos(-box.angle)
-- dx = abs(dx) - box.width/2
-- dy = abs(dy) - box.height/2
-- return distance(0,0, max(0, dx), max(dy,0))+ min(0, max(dx,dy))

var d=0
for each point
-- set d to sdf(point.x,point.y)
-- if d<radius
-- -- point move radius-d pixels at angle angle(d,d, sdf(point.x+0.0001, point.y), sdf(point.x, point.y+0.0001)

    You'd have to modify it slightly to work with more than one box. There are probably other ways to do it too.

  • There are pros and cons to either. Basically text is simpler to use and look good with high res stuff, but is visually poor when doing low res stuff. Spritefonts are drawn faster and give more control over the look of the text but take more setup and don’t scale up well for high res stuff.

    Text object

    Pros:

    * simple to use. Pick a font and any character is available.

    * since it utilizes the canvas’ text renderer characters edges will look smooth no matter the text size.

    Cons:

    * it works by the text being drawn to an image and copied to texture. So it takes up video ram and copying the image into the texture may not be the fastest.

    * text looks fuzzy when full screen scaling is set to low quality. So probably not the best for low res graphics.

    spritefont object

    Pros:

    * it works by just drawing characters as quads and using one texture. This is pretty fast with construct’s batching renderer.

    * useful for low res games since you have more artistic control over the look of characters.

    * very easy to use with monospaced fonts.

    Cons:

    * have to make a texture with all the characters you want to use.

    * the texture can be fairly large with a lot of characters since the texture atlas isn’t tightly packed.

    * you have to provide the spacing numbers if you want to use a variable width font. There are tools that help with that though.

    * scaled the text is only as detailed as the texture. So scaling up will be blurry or pixelated depending on the sampling.