R0J0hound's Forum Posts

  • —

    In general any movement behavior that isn't disabled will set a Boolean in the runtime to tell it to redraw. I doubt the platform behavior is checking to see if the position has changed first. Even so that's a pointless optimization since if the behavior is enabled things should be moving.

    stachir

    You could replace the platform behavior with any other movement behavior and get similar results with the draw calls. Also that bit of code just makes those buttons not pressed when the game loses focus.

    Maybe look instead at the collision checks in the debugger with the platform behavior. As I recall there has been discussions about the number of them the behavior uses. Whether that's the cause of the cpu usage in your project I don't know, but if the highest usage is draw calls then it's more likely visual stuff like the number of things being drawn on screen, number of layers, effects,...etc.

  • The draw calls increasing when the platform behavior is enabled is expected. Basically if nothing visual (position, animation, angle...etc) is changed then C2 doesn't redraw the canvas, so the draw calls will be lower.

  • Just use:

    wait timescale seconds

    and the wait time will be one actual second as long as the timescale isn't 0.

  • Collision cells are a form of spatial partitioning. As I recall the cells are screen sized, so even when using them, your examples would still have to loop over all the objects.

  • Nice plugin. Here's a quick thought on the normal being wrong on flipped tiles. Normally the collision polygon have it's points ordered in the same way (cw or ccw). This is called winding. So when a ray hits an edge you can take the angle from one point of the segment to the other, and if the points have clockwise winding you can subtract 90 and get the normal.

    Mirroring will switch the winding and so will mirroring. So if something is both flipped and mirrored the winding will be the same as they are originally. Negative sizes of sprites have the same affect as flipping and mirroring.

    Roughly it would look like this, it might need to be swapped:

    If mirrored xor flipped

    EdgeAngle+90

    Else

    EdgeAngle-90

    That can fail though if the user creates a collision polygon with a reversed winding. It's not common but it has happened before. I didn't handle it and instead had the user correct his collision polygon, but you can handle it in code by either checking the winding of the polygon or sampling a point on one side of the edge to know which side is inside the polygon.

    As far as speed goes, the best improvement would be to do some kind of spacial partitioning of the objects you cast to. You can probably simplify the math too in areas but that may not be as significant of an improvement.

    Ps.

    You can also calculate the reflection angle without vector math.

    ReflectAngle = 2*normal-rayAngle

  • Ashley

    Thanks for the link, the vsync test is especially useful. My pc doesn't vsync and gets an average of 30fps. However the solution for me probably has to be to get a new pc, since my graphics card hasn't been supported by amd since 2010, and windows vista is no longer supported by chrome. I won't be upgrading though, unless I have a major hardware failure.

    On the plus side, anything I make in C2 will run fantastic on any other machine.

  • briggybros

    I bet it could, but I'm put off with the process of doing it. As I understand it can be done with:

    1. being able to compile NWjs from it's source

    2. looking up the windows interface to mice and see how to access other buttons.

    3. combining the two.

    2 is the easiest actually, and I'm stuck on 1, mainly because I don't have an os new enough for the required compiler.

  • It's just a style choice. It shouldn't matter performance wise.

  • You could do it with a second array we'll call "list" and has a size of (0,3,1).

    So you'd first loop over your array and check if any spot is equal to that certain value. If it is then make the list one longer and store the distance, and the current x and y in the array.

    After that use the sort action on list and the first value will be the closest and the last will be the furthest.

    Every tick

    --- set list size to (0,3,1)

    Array: for each xy

    Array: current value=certainValue

    --- list push 0 front

    --- set list at (0,0) to distance(X,y, array.curx, array.cury)

    --- set list at (0,1) to array.curx

    --- set list at (0,2) to array.cury

    Every tick

    --- list: sort

    Then the closest X and y would be:

    List.at(0,1)

    List.at(0,2)

    And the furthest:

    List.at(list.width-1,1)

    List.at(list.width-1,2)

  • you can do it with a normal for loop and the pick nth condition. Like the first half would be:

    For "" from 0 to Sprite.count/2

    Pick Sprite instance loopindex

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If at 60pixels/sec it's moving at 2 pixels per frame sometimes then your graphics card isn't really supported by browsers. I probably have the same issue with my blacklisted card, which never can reach 60fps with html5 on browsers even though normal exe games can.

    Basically there are three things that could be at fault: C2, the browser engine, your machine.

    You've likely played those retro games you mentioned on your machine without issue, your PC is capable so we can rule that out.

    Here in this topic we explored many ideas from the C2 side to improve things. Since they're not working it can either be C2 or the browser. We can do tests with C2 vs other html5 engines or straight JavaScript and see if any do it better, and if they do we can find what they do different. However, I don't think C2 is to blame.

    Even with a simple js to move a box isn't smooth for me on my machine. So it's the browser to blame I'd say. It's either the js engine or the renderer. As mentioned earlier in this topic I was able to take a JavaScript engine and add enough of it to partially run a c2 html5 export. Even though I ran it though Python and didn't do any optimizations for the renderer (sfml) it was buttery smooth with a very stable framerate at low object counts.

    So I revise my statement to say that I think browser's renderer's are to blame.

    This isn't a call for a native exporter, but if the renderer could be replaced things might improve. I say that as if it's easy, but it's probably way to hard to do. Especially since browsers can take so long to compile.

    It's not possible to make an entire browser, but I do think it's possible to build a basic runtime using a JavaScript engine as a base and some multimedia library with it to handle input, graphics and sound. Of course that leaves out every single other browser feature.

    Anyways in the end I lack anything really helpful here.

  • 99Instances2Go

    1)

    Gravity is an acceleration and is the same for everything so it makes sense to affect everything.

    2)

    I can't look at the capx but it probably has to do with sleeping. Sleeping is an optimization where if an object stops it can be put in an idle state so calculations don't have to be done on them. It then wakes up if anything moving touches it or you move it. You can adjust how likely objects will fall asleep.

  • Aritz

    You'll have to approximate it with a polygon. Both chipmunk and box2d only do circles and polygons.

  • It's a mathimatical reason. The angle() function uses atan() to do the calculation, which has a range of [-180,180). Also that range is often referred to as a normalized angle and is usuful at times. Having the angle in the range of [0,360) is mainly useful in the case you stated above, and I usually convert it over in a expression with: (angle(x1,y1,x2,y2)+360)%360

  • Yeah, putting variables in the type would be like a static variable because the type is created only once during the whole game. I've done that before with my isometric behavior.