R0J0hound's Forum Posts

  • It's a 2d game so it should be possible, even with vanilla C2 (no third party plugins). Basically there's two parts to it: visual and logic.

    For visual you can use sprites or tiledbg for the lines and for the filled in areas you can just break it up into multiple rectangles.

    The logic could be done by keeping track of the edge polygon of the level and dividing it and seeing if a the enemy locations are inside them.

    There was a topic about qix, but I forget if a completed example was made. There's a similar game called quolox or something where an example was made which could be useful.

  • Hmm... I'd have to think about it more. Instead of the gradual angle change what is the desired result?

    Yeah to add vectors together you need them in X y components.

  • Couldn't you do the same logic but just consider the total speed?

    if distance(0, 0, vx, vy) > maxspeed

    {

    //do nothing

    }

    else if distance(0, 0, vx+ax, vy+ay) > maxspeed

    {

    ang = angle(0, 0, vx+ax, vy+ay)

    vx = maxspeed*cos(ang)

    vy = maxspeed*sin(ang)

    }

    else

    {

    vx += ax

    vy += ay

    }

  • Shadowblitz16

    That's what the paste action is for. Just position and set the animation of a Sprite before calling the action. The second idea would need to be done with blend modes and the paste action as well.

    megatronix

    You could use that new raycasting plugin so you can cast rays to a collision polygon. Otherwise you could also come up with a way to create the lines from the sprites. Doom style maps could be tricky since a lot of tricks are used to go from wolf3d raycasting to that. Also it's not terribly interesting to me since I didn't get good performance with just doing walls, let alone floors. I'd need a way to make it much faster to make it worthwhile.

  • megatronix

    It could be a while, I don't have a whole lot of time as of late.

    The plugin doesn't really add much to assist with it. All the plugin would be used for is to draw slices of a texture.

    The rest would mostly be raycasting.

  • Probably a bug I suppose. Arrays probably don't save them either I'd imagine with the .asJson expression. It doesn't mean the variables aren't saved with the save and load actions (can't look at the source to check right now).

    Actually I can also see why it might not be a bug. As it is now any .asJson of a dictionary can be loaded into any other dictionary. If it saved instance variables too it would be like Sprite types where I assume you can only load a json string saved from the same type.

  • —

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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