R0J0hound's Forum Posts

  • I thought I was getting better results earlier.

    C2 in chrome:

    60fps till 800

    60fps till 2900 with the "for each" disabled

    godot:

    60fps till about 800 as well.

    I think what's being measured from this is the speed of events or gdscript.

    Looking at the bunny mark here:

    https://pixijs.github.io/bunny-mark/

    I get 60fps up to 5900 with the chrome

    and this:

    http://www.goodboydigital.com/pixijs/bunnymark/

    gives me 60fps up to 20,000. I guess js isn't actually that slow?

  • bjayfont

    I don't really have any plans to add collision stuff to this, it's a visual only plugin. All collision stuff would have to be done by other means.

  • You'd either have to modify the behavior so you can get at the shadow shapes or you'd have to calculate the shadow shapes with events the same way the behavior does it. To do the latter you'll need to be able to access the points of a collision polygon, but since you can't access that with events you'll either need to make a plugin to access the points or add a bunch of imagepoints in the same places. After that you could use some math to see is the player's location is inside those polygon shapes.

  • The audio scheduling example included with C2 may be useful to play multiple sounds in between ticks. Just set the interval to 5/speed, where 5 is the number of degrees per sound and speed is in degrees per second of the rotation.

  • updated link

  • Maybe this could help, it's a different way to look at the problem without using arrays. It first creates the rooms with door in between so everything is connected. Then as a second pass it has a chance to add a few more random doors to make looping passages.

    https://www.dropbox.com/s/45t57qr04dzht ... .capx?dl=1

    It's similar to what i've done previously here:

    roguelike-map-system-untiled_p590128?#p590128

  • [quote:3hsueik9]Will be possible?

    Yes, but I'd be happy if I never had to write a shader again.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The use is probably identical to what you can do in C2. You use the browser object to be able to run js code. However to use code in a file you need to load it first.

    Here is a c2 example that uses jquery to load the file:

    nima-web-based-2d-bone-and-mesh-animation-app_p1110744?#p1110744

    This one does it without jquery which is important since c3 no longer has jquery included.

    https://www.dropbox.com/s/7ueb6v9l7395o ... .capx?dl=0

    It still won't work if imported to c3. The c2_callFunction needs to be changed to c3_callFunction.

    It has the benefit of being a way to try javascript code with your project without making a plugin. However it's much less readable and more error prone.

  • illugion updated link

  • Yeah, sorry about that. I just fixed the link and didn't reply

  • The action that shows an object with an id of zero is after the wait action, and the wait action has been a common source of issues. It could be a bug in this case that the wait doesn't save the picked waypoints so that a waypoint with id 0 is picked after a wait, or some other event is changing the id of the waypoint before the events after the wait can run.

  • The wait action is probably causing the trouble.

  • cool

  • Mayfly

    The difference could be a lot of things. I have no definitive answer because I haven't taken the time to break it down and test it further.

    The prediction is based on an exact collision point, but the physics behaviors never collide at that exact point. Typically the collision occurs after the shapes are overlapping. So the objects are pushed apart first and then the collision point is used, but that likely is a bit off. There are a bunch of other little things such as the pushing out could be over several frames and there may be a tolerance to allow a little overlap.

  • One possible explanation would be events are not converted to JavaScript, instead they are converted to a bytecode of sorts that is interpreted by the runtime which in turn calls the functions in plugins and the runtime. CC did basically the same thing.

    Now JavaScript engines are really good at analyzing js code and generating fast machine machine code on the fly. That's how js performance can often rival a compiled language. My thought is the events bytecode is basically data and the javascript engine is unable to streamline the data as it does code.

    A fairly complicated solution could be to compile the event sheet to javascrict. Sounds simple but probably is a huge can of worms.