madster's Forum Posts

  • Sweet, Gary Coleman XD

    ADDENDUM: around 128x128 is for large enemies, 64x64 makes good smallish enemies. More or less than that and you'll wind up with either one huge enemy or a jillion small ones.

    (the game spawns enough enemies to fill the screen depending on the image size)

    Drag the images from the forum to your enemies folder!

    Edit: here's a burger: <img src="http://www.udec.cl/~jfuente_alba/burger.png">

  • I don't think it is a problem actually.

    One has to blow up the error almost on purpose. I could do one example anyway, but there would be glaring ways to fix it without having to rewrite anything in construct.

    I'd say it's more of a design issue on the game's side. I've worked with SDL and it had a terrible timer resolution, yet I managed to make smooth accurate movement using a few tricks here and there (which are perfectly doable within Construct but somewhat unnecesary).

    That said, it would be nice to redefine Timedelta before behaviors touch it. Is that doable? One could rewrite timing at will that way without having to renounce behaviors.

    Right now it *can* be done (look at my frameskip example ) but you have to forget about any behaviors that use Timedelta.

    Edit: it would seem I'm contradicting myself I'm not. I'm just saying that while rounding errors do accumulate (in everything), one can just avoid accumulating them. Just look at Euler versus Verlet integrators in physics, both come from the same Newton equations, but one of them accumulates rounding error while the other cancels it.

  • 50) Add Post Processing Filters 'on top'.

    That'd be a cool thing to have. Like, during compositing, it's often helpful to add that last effect to your composition to give it that last little edge - like, a sharpen filter on top of everything to make the details come out.

    Seconded sorta.

    In DX and GL this is done with a fullscreen square with a special shader. In Construct you'd have a fullscreen empty sprite with an effect. Then again, the effects wouldn't have access to the layers below.

    One COULD write an effect that did offscreen render, so that one would put it on each layer and you could use that data in the layer on top, assuming painter's algorithm for layers.

    The great thing about Construct's design is that you can "hit the ground running" with your game and with a little extra work you can make it do exactly what you want to.

    Then again, I don't know much about shaders. Halp?

  • oh you gotta use a 24-bit png. 8-bit palette transparency doesn't seem to work with Construct.

    In Photoshop: save for web and devices, PNG preset, set 24-bit manually. Transparent backgrounds from photoshop will be exported correctly that way.

    If you can't get a transparent background in photoshop, try duplicating the Background layer then deleting the original layer. You'll be able to erase to transparent now.

  • 47: the meaning of 'opacity' depends on the effect. As they are plugins, each should implement it by itself. Effects developers: more options!

    48: you're much better off doing a state machine. See flags below, only set the current state in a number, add the number as a condition to the events that can only happen in the current state. Change said state within the event.

    49: use flags. 1 to enable, 0 to disable.

    +On control "left"

    +global('movementEnabled) equals 1

    do stuff

  • http://www.udec.cl/~jfuente_alba/random_invaders.zip

    In this game you shoot stuff before it comes at you.

    What stuff?

    Well, what's the craziest stuff you can think of? make a .png (or .jpg if you must), put it in the "enemy" folder. Post it here! Collect random invaders!

    Size will be mantained, so keep the size around 128x128.

    Inspired by Megamania, old ATARI game.

    ADDENDUM: around 128x128 is for large enemies, 64x64 makes good smallish enemies. More or less than that and you'll wind up with either one huge enemy or a jillion small ones.

    (the game spawns enough enemies to fill the screen depending on the image size)

    Drag the images from the forum to your enemies folder!

  • n+1th'd!!

  • -> dx_ray(t)/dt = speed, it's chaning, because...

    -> d2x_ray(t)/dt2 = (2 * w * w * y * cos(wt)) / (sin^3(wt)) ... acceleration is not a constant value.

    And if acceleration was constant, speed would still be changing.

    But that's besides the point.

    I did say it won't synch up forever, but it can be matched to the tangent, which given the large radius will look good enough. Again: Like a tread moved by a cog.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sorry, learned this in physics a while ago.

    You just *can't* take a value and do calculations on it and expect the error not to grow.

    Timedelta is in seconds, thus 0.0001% of timedelta amounts to 0.000001* = 0.0001ms error

    that over a day is: 24 hours * 60 minutes * 60 seconds * 1000 miliseconds = 86400000 ms.

    the error thus will be bounded by 86400000 * 0.0001ms = 8640ms

    That is, off by eight and a half seconds.

    Of course, float's rounding error is not fixed and timedelta's error depends on the internal timer resolution, which could be QueryPerformanceCounter(). I read that one has microsecond resolution, which is nice. Still, it's not exact. It cannot be. Nothing is.

  • When you're animating you need to move the hotspot sometimes, and check with the other layers.

    Onion skin is a really useful tool for animators. Tweaking animations as it is now is kind of uncomfortable.

    I second onion skin request!

  • uhm. yes it can.

    Just calculate the speed at a certain distance from the center using angular speed, then either set the tanks to that speed or reverse the equation to get the angular speed.

    Won't synch up all the way along the axis, but if you pick an arc that stays long enough near the tanks the visual effect will be there. Like a tread moved by a cog.

  • if you want time elapsed from the beginning you're better off using Timer (system - get time)

    To fire off an event every certain amount of miliseconds with long-term accuracy, you could do something like

    +compare Timer%MyFiringPeriod less or equal than MyFiringPeriod*0.4

    +Fire once while true

    Timedelta will always have rounding errors which will accumulate to something hideous.

    Even if its precision was to the milisecond, rounding errors would still crop up when you accumulate.

    This timer, of course, will wrap after a certain amount of days (which I'm too lazy to calculate). Adjust accordingly.

  • Mind just went kablooie.

  • Gambit looks great and plays great, though I would have liked to see original graphics too. (but hey, congrats on your first playable!)

    Lion taming ftw!