R0J0hound's Forum Posts

  • 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

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • The names are abbriviations but the values need to be precise. This is to save/load objects and you don't want rounding to occur.

  • It gives the entire state of an object. You can look at the plugin's source to see what they are without the abbriviations. It's all abbriviated to save on space and because it's just data that's not meant to be modified.

  • Hi christina,

    I was looking at your capx again and did one slight tweak.

    I ignored the speed having to be able to evenly divide into 60, and using the minimum framerate action.

    Instead I tried doing rounding myself. So, instead of the pin behavior I set TWIN's position to (int(player.x), int(player.y)), and the scrollx to int(player.x) every tick.

    https://dl.dropboxusercontent.com/u/542 ... utter.capx

    Before the player itself was the most jerky and made everything else look worse. However after the change it looked acceptable to me. Any stuttering I got was basically the same as I always get on my machine, which isn't so much to do with js as it has to do with the browser's renderer I think (well, partially confirmed by a previous test I did that used the v8 js engine with sfml).

  • Look at the canvas plugin for an example of this. There are perfomance issues when having the plugin not use webgl when the rest of the game does use it. The issue is namely that the html5 canvas needs to be copied to a webgl texture to be able to be drawn.