R0J0hound's Forum Posts

  • You can reverse the damping with

    max(1000-distanceHereToThere, 0)

    Basically any distance above 1000 won't be damped, and any within 1000 will.

    With the above the damping increases linearly, but you can square it to make it increase in a more drastic way.

    max(1000-distanceHereToThere, 0)^2

    • Post link icon

    Oh, it changes when you save your project. The op sounded like it happened when using the save action in events when the game is running.

    I've never encountered this, but I think it would be useful to report as a bug even without a capx.

    • Post link icon

    You're saying the save action sometimes changes the value of a global variable? The thing is logically that's not possible since the save action shouldn't modify anything, and if it did it should be reliably happening. But that's just based on my experience.

    Let's take a step back though. The two possibilities is the issue is either with C2 or with your events.

    You can absolutely check if C2 is to blame by setting some text with that variable right after like this:

    set text to globalvar

    save

    set text to self.text&" "&globalvar

    If the two values ever differ then C2 is to blame and I'd hope a bug report could be made so Scirra could fix it.

    If they're always the same then the issue is elsewhere in your logic. This would be a case where it would be nice if the debugger let you step through events more. Regardless you can also do text debugging like above, the browser log action is also useful instead of just text objects. Basically find all the places that set that variable in the event sheet and log it. Then when you run your game and you see the variable change you can pause and look in the log. You can even save the event number in the log text like so to know what event is changing it.

    browser log "event 10: set global to "&globalvar

    Anyways that's just some ideas into hunting down the cause.

  • You have it outlined right there. Use an "on click" event and compare the animation frame. Also the "else" condition can be used for the other frames.

  • It actually looks like the path the 8-direction behavior gives you. The soft max speed could be achieved by maybe setting the max speed higher and let it drop down with:

    max_speed = max(current_speed, normal_max_speed)

  • stachir

    It may still be a bug with vsync and the browser on your device. Maybe something along the lines of this bug:

    https://bugs.chromium.org/p/chromium/is ... ?id=422000

    It references this site to test the vsync of your browser. If frames are never dropped the word "vsync" should look grey, otherwise it will flicker.

    http://www.vsynctester.com/

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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