R0J0hound's Forum Posts

  • Here’s one way. Is one color at y=0 and the other at y=480.

    t= sprite.y/480

    Set color to rgb(lerp(23,72,t), lerp(24,104,t), lerp(25,89,t))

  • Currently it takes all the polygons facing the light, loops over each pair and casts shadows on each one. Kind of brute force but I should work on any mesh.

    The meat of it is clipping a polygon by a plane. Then a shadow is cast on one polygon (A) onto another polygon (B) by taking all the edges of A and making plane with the light position, then clipping B by all those planes.

    An improvement would be to use a a binary space partition in conjunction with that to do that more efficiently so higher speeds with more polygons is possible. Google SVBSP (shadow volume binary space partition) for the algorithm.

  • I suppose you could. The binary object would help in decoding rom files. What did you want to try to emulate?

  • To address the mass not being taken into consideration:

    Force = mass * acceleration

    The units with the physics behavior is off by a factor of 50 or so. In practice that only matters if you want to use exact units. Most of the time you can just tune the numbers.

    There is no solution for the sleeping with what the physics behavior provides access to. If you can somehow access the underlying physics engine from JavaScript there may be a way to do it, but the behavior wasn’t designed for that, and you’d be fighting with the behavior.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Setting a 3d camera and using a fog effect should be enough to do it.

    Here I made the camera be a little behind the car and look at a little in front of the car.

    dropbox.com/s/thbtrfjyauqk9rn/mode7like.c3p

    For the 3d looking car it's probably just a car sprite on a 2d layer.

  • So I managed to to make a demo of realtime shadows between two cubes an a ground plane with a point light. It's using the shadow volume method using polygon clipping.

    dropbox.com/s/f9x1ov9fy7y7bpr/3d_shadow_volume.c3p

    You can drag the cubes if you click on the the middle of them. The fireflies in the shadows are from Z-buffer precision limits. The edges show sometimes as well since the shadows are offset slightly to reduce z-fighting.

    To fit it into 25 events it's currently limited to just the two cubes and ground plane. However I think I can see at least one more event I can squeeze out of it so we could have any number of cubes after some refactoring, but that's for another day. Overall it was an interesting test, but to make it simple to use in general would require a lot more work.

    Anyways, cheers!

    EDIT:

    made it so you can add as many blocks as you want and added block color.

  • Oh, strange. I would have thought a higher refresh rate would make collisions more accurate. It's the lower framerates that could cause objects to pass through walls.

    Sounds like a bug if collisions are failing at higher refresh rates. Ashley

  • Off hand you could make some functions that would both call console.log and write to a variable. Then you could invoke a download of that variable to a file.

    I suspect there is no direct way to access the debug console contents since this is JavaScript and browsers limit what data you can reach for security reasons. Google may prove me wrong though

  • One possible reason could be the game is running at a lower fps on your students pc than the other ones. Maybe her machine has another app or a windows service running in the background that’s affecting it.

    You can check that by setting a text object to fps in an every tick event.

    With a lower fps the object will move faster in a frame. As an example say you have an object moving at 1000 pixels/second then:

    At 60fps the object will move 1000/60 or 16.66 pixels in a frame.

    And worst case at 30fps (construct doesn’t let the time step get lower than that last I checked) then the object will move 1000/30 or 33.33 pixels in a frame.

    So thin walls with fast objects can be a problem with low fps since they can have moved past the walls without collisions. Or even if a collision is triggered and the object is most of the way through it will be pushed out past the wall.

    You can also check the refresh rate of the monitor. 60hz is standard but many monitors have have higher at 90hz, 120hz,…etc.

    Anyways that’s my best guess what’s amiss. Fast speeds, thin walls and something causing a fps drop.

    If that’s not the issue then you can also check the browsers error console to see if any errors are listed. But I don’t think any are likely.

  • Probably any of my examples can be improved. I go to the point of getting it working a basically stop. There are things that likely can be changed to make it faster. Also if finding a path takes too long it can be changed to do it over multiple frames instead if need be.

    The tweaks are endless. Probably the newer examples I’ve made are better. My goal is to make capx as simple as possible and do what is desired.

  • You do not have permission to view this post

  • I mean the example above is pretty instant with finding a path.

    Besides events you can make a plug-in and do what you want with JavaScript. You can also run js with the browser plug-in if you want to do that instead.

    Events just are easier and more flexible especially with interacting with other things in the engine. You can often improve performance by refining the algorithm used.

    JavaScript can perform faster but you also have to deal with debugging it inside your game.

  • An event based AStar algorithm is quite doable. If you search for posts by me that mention “astar” you’ll find a lot of examples. I’ve seen other users post examples too on here.

    If you want to make your own I’d recommend the site redblobgames. It is one of the best references of how to do it.

    The part of the algorithm you’ll want to modify is the part that looks at the neighbors of a location. For grid based it’s the four directions. For hex based it’s six. For node based it’s whatever other nodes that are connected. And since it will be event based you can have the obstacles different for different purposes.

  • Event sheets are their own thing. I just call it construct event sheets. It has similarities to other programming languages. The expressions are very similar to c/JavaScript, but the conditions and picking are fairly unique.

    Html5 and JavaScript is mainly how things are implemented behind the scenes. But that’s mainly an implementation detail. They could’ve implemented it in anything. But since the primary export is html5 that’s what they decided to focus on.

  • Construct 3 isn't a 3d engine. Easiest would be to just fake as much as you can. But here are some thoughts on various ways to do shadows such as "shadow mapping", "shadow volumes" and "ray casting". In construct there are limits but we do have math, distort meshes, canvas and shaders that can be used in creative ways.

    Shadow mapping

    This is a common way to do shadows where you first render the scene from the point of view of light to a depth texture and then use a shader when drawing from the camera's view to tell what is in shadow.

    Construct can only render one view at a time and the canvas has no depth. However you probably could make an effect that takes the depth and draws a color. Then you could change the view from the light, use the effect to draw the depth as colors, snapshot the screen, then use that texture with another effect to draw the shadows.

    - you need to have the camera and view matrices. It's not readily accessible but you can calculate them manually.

    - you have to write shaders. You are also limited number parameters in C3 shaders so you will have to adapt any online guide about shadow mapping.

    - not suitable for Realtime since you have to dedicate a frame to draw the depth.

    - on top of that capturing the screen can take a bit.

    - Lastly and most importantly It can't work because we can't access multiple textures in shaders in C3. I can't think of a workaround for this.

    Shadow volumes

    Uses polygon clipping to find what area of each polygons are in shadow. Often done along with BSP trees to be more efficient.

    - you need a list of the vertices and faces. C3 does not provide access to those so we'll need to calculate and provide them ourselves.

    - BSP trees are needlessly complex to implement in events, but even with them this shadow method doesn't scale as well with higher polygon counts.

    - will give perfectly crisp shadow edges, and will be 100% black without further trickery.

    - will have to draw the shadows over the mesh with distort meshes. Probably will have to move slightly toward the camera to avoid z fighting.

    - This is the closest to being feasible in vanilla C3 solution, but it may not fit in 25 events.

    - may only be fast enough for Realtime with low poly counts, but it would have to be made first to find out.

    Ray casting

    This is an alternate idea to make the 3d objects from canvas' wrapped with distort meshes. The idea is to shoot a bunch of rays from the camera and when the mesh is hit you'd calculate where on the canvas object was hit and color that.

    - it would be pretty slow so you'd only be able to shoot a few hundred rays per frame. But over time it would be better shaded.

    - It would also not scale well with higher poly counts.

    - as with the other approaches it would take a fair amount of 3d math with matrices and vectors.

    Overall even without the limits of the 3d in construct those are all fairly involved to do. The second way seems almost doable but likely just as a novel demonstration.