R0J0hound's Forum Posts

  • The c3project is json based as I recall, and since everything else is intact it should be possible to rebuild it.

    You can get the basic structure by making a new project and saving it to get its c3project file.

    Then just manually add all the relevant parts. I think it’s mostly just a list of object types, event sheets and layouts. It may just list everything else in the the sub-folders though, I haven’t looked yet.

    Things like project settings you’d have to redo.

    Those ransomware virus’ seem like a real pain. If you can report their info somewhere hopefully they can be brought to justice. As is I wouldn’t pay them, but that’s just me. I doubt I’d get what I paid for, plus why would I trust more software that probably has a virus as well.

    Anyways I think it’s possible to remake that c3project file. Just need to look at an uncorrupted one to see the structure. The ui state stuff is generated by construct so it shouldn’t be needed.

  • When I was talking about the angular velocity I meant that the hits won't cause the objects to spin with the current math.

    Anyways, made a simple test of the bounce math and it seems to be working in all directions:

    dropbox.com/s/cuy6zjurxm4u2q0/bounce_math.capx

    The only difference is it utilizes a min() so it will only bounce when the objects are moving toward each other. Otherwise I guess you'd want to test your conversions to and from the bullet and custom movement behaviors in your project.

  • Looks ok as best I can tell by just looking at the events. I may be missing something though.

    The action to set the speed of the object when it leaves orbit is incorrect. It should be:

    LinearSpeed = angularSpeed*radius*pi/180

    And I’m pretty sure the orbit speed is an angular speed.

    The angle of motion looks ok. It works for cw rotation. It would be -90 for ccw, and you’d probably want to put the speed calc in an abs().

    As far as the bounce calculation itself, it bounces whenever the objects collide. You can modify it so it only bounces when the objects are moving toward each other.

    Set vrel to (obst.vx - player.vx) * cos(a) + (obst.vy - player.vy) * sin(a)

    If Vrel <0

    Set j to -(1+e) * vrel / (1/player.mass + 1 / obst.mass)

    ...and do rest of bounce stuff.

    Other than that the bounce may not be exactly what was expected since it’s treating the two objects as circles with the collision point directly between them. Boxes usually can have the collision point all over the place which will change up how it will bounce.

    That and the bounce won’t change the angular velocity as is which adds to making the bounce not look right.

    Both can be solved with more logic to calculate the collision point, as well as modifying the equations to take angular velocity into consideration.

  • I think you can enable/disable the depth buffer per layer. So turn off 3D on the hud layer and it should work I think.

    Haven’t tried it but it was hashed out in the releases after they added it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Oh yeah. Forgot about tiledbackground. Probably would be simpler.

  • You could use sprite mesh distort to do that. You just change the texture coordinates to display a different sub-image.

    Here it's using a spritesheet with a grid of 13x6 sub-images.

    dropbox.com/s/dog9plqg9vicvk5/card_spritesheet.c3p

    Toggle the set mesh point actions to disable the rotation.

  • The 3d shape was to enable the depth buffer on the layer. It's not needed if you change a project setting though.

    The trick here was to wrap a sprite with a 2d mesh into a sphere, but you could do other shapes too.

    Here's a cube. Pardon the events. I packed the vertex data in numbers 0-7. Can rotate around x and y axis, and still is one sprite. The trick was to collapse parts of the mesh that were not needed.

    dropbox.com/s/unnqd7exmaca6lk/mesh_cube.c3p

    So it would be possible to do papercraft, you'd just need multiple sprites, and you'd need to specify uv's.

  • Here is an example that deforms a sprite into a 3d sphere using the mesh deform feature. It also has horizontal 3d rotation.

    dropbox.com/s/lucl1153bmmr3qo/mesh_sphere.c3p

    Notes:

    - it's done by utilizing spherical coordinate equations.

    - you could get cones, cylinders, and torii in a similar way.

  • The new vanishing point feature can’t do that. It’s useful for some stylized effects or say you have a toolbar on the left half of your screen you can make the vanishing point centered on the right side area.

    To rotate the camera a bit like in that video you need to use a third party plugin. That guy actually used a camera plugin made by a user named mikal to do that.

  • Hi,

    Thanks for all the interest, and I’m glad it’s been useful. I ended up having to sideline further development for a bit. Life and stuff. Hope to get back to this eventually. Hopefully sooner than later.

    As to the requests:

    - Changing the texture filtering should be doable.

    - utilizing a sprites texture should be doable as well. Just have to take into account sprite sheeting.

    - I don’t have any immediate plans to allow adding/removing/modifying triangles from a mesh. Adding/modifying is a maybe. As is, I’d go with redoing the mesh from scratch per frame. I’m shooting with simple, easy to use and flexible. But I may change my mind after playing around with it.

    - I kind of like how the triangles are two sided, I can see how having single sided stuff allows for a texture on each side would be useful. May test later.

    - It would be nice to have some kind of animation like mesh deforms and skeleton skinning, but that would be a later feature as I’m not familiar with much of the various aspects of it. Currently, you can do stop motion style stuff with multiple object files. You’re only limited by memory there. Most any file format should be readable with varying degrees of difficulty. It’s the handling of that data that’s the most time consuming I think.

    - I have some ideas for collision detection and response. Ray casts would be nice too, but we’ll see how things go.

    My current tentative overall design would be:

    - Use tags for meshes, textures, and objects.

    - objects would be instead of the draw matrix. Instead you could specify as many objects as you liked. Each would have their own position, size, orientation and color. The you could change the mesh, and texture on the fly. While at it I’d like to make parenting too.

    The camera would treated as one of these objects so that would remove some redundancy.

    3D math within the event system gets busy looking fast so I’d like to add some more transformation features to simplify that. For example, rotate around an arbitrary axis, or moving at a 3D direction. We’ll see though.

    - rendering at least shadows from one light source would be cool too. It’s the type of thing that may be trickier than it seems. But as with everything else we shall see.

    Anyways. That’s the rough plan more or less.

  • Hi,

    I’m not updating this plugin anymore. It’s strictly C2 but the built in C3 canvas plugin may be useful.

  • I think this line idea would work as long as the base of the wall is some kind of convex polygon. Bear in mind it’s counting on all the walls being sorted correctly as the only things that will be changing zorder are the moving objects represented by points.

    “Z order sort” is more for sorting everting. Let’s call it an absolute sort.

    Here we are doing a relative sort.

  • So if everything is on the ground plane, and you make your level with all the blocks visually sorted. All that’s left is to move the player as he moves around.

    If each block has two imagepoints like in this image we can sort the player. Basically if they are below the line they are in front otherwise they are behind.

    The event would look like this: 

     glabal number x0=0
global number y0=0
global number x1=0
global number y1=0

player overlaps block
for each block
-- set x0 to block.imagepointx(1)
-- set y0 to block.imagepointy(1)
-- set x1 to block.imagepointx(2)
-- set y1 to block.imagepointy(2)
-- compare: player.y<(y1-y0)/(x1-x0)*(player.x-x0)+y0
-- -- player: move behind block
-- else
-- -- player: move in front of block

    Sorting Player vs enemy, npc or other simple objects would be simpler. You’d just compare the y positions.

  • Best I’ve found is mostly covered here:

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

    The building blocks of that is to compare two objects to see which should be in front. Them you’d sort all the objects with something called a topological sort. You only need to sort the objects visually overlapping each other.

    As seen on that page there are some cases where the the sort will fail, so in those cases it would be good to be able to split the objects.

    That said, depending on your levels, you can design around that to avoid the failing cases.

    If everything is on the ground plane I think it should be possible to do something similar.

  • This may be a useful reference.

    betterprogramming.pub/making-a-verlet-physics-engine-in-javascript-1dff066d7bc5

    Notable difference to what you’re doing is when limiting the distance between nodes it takes the mass of each node into consideration.

    Another thought is to take mass into consideration when applying damping. Something like this:

    (X-px)- (1-damping)*(x-px)/mass

    For the gravity it looks like what you have is in line with verlet physics. You probably just need to use smaller gravity values.

    For collisions it would be a matter of pushing the nodes out of shapes in the closest direction. For circles it’s basically the same as what limits the distance between nodes. For a box it’s a bit more involved.

    You asked how to make it change length. Probably by changing the rest length. Adding/removing nodes on the fly seems like an interesting idea too but may take a bit more logic.

    As to make it more stable, you need more iterations. It’s trying to solve the limits one at a time so only the last one is perfect. Each iteration brings everything closer. Also the longer the chain is you’ll need more iterations.

    So you could limit the speeds of the player and enemy. Or if higher speeds are needed you could move over several smaller steps in a loop with that iteration loop to solve the limits.