madster's Forum Posts

  • that's a nested loop:

    for each weapon do: for each enemy do: set weapon to enemy

    result is:

    -For Each EnemyWeapon ordered by EnemyWeapon.UID Ascending

    --For Each BadMan ordered by BadMan.

    -choose EnemyWeapon 1

    --choose BadMan 1

    ---set EnemyWeapon 1 to BadMan 1

    --choose BadMan 2

    ---set EnemyWeapon 1 to BadMan 2

    --choose BadMan 3

    ---set EnemyWeapon 1 to BadMan 3

    -choose EnemyWeapon 2

    --choose BadMan 1

    ---set EnemyWeapon 2 to BadMan 1

    --choose BadMan 2

    ---set EnemyWeapon 2 to BadMan 2

    --choose BadMan 3

    ---set EnemyWeapon 2 to BadMan 3

    etc etc.

    As you can see, at the end you'll assign every EnemyWeapon to the last BadMan.

    You probably should use something other than a nested loop. Look into containers (http://sourceforge.net/apps/mediawiki/construct/index.php?title=Containers), you could set BadMan and EnemyWeapon in a container and you'd be able to do:

    -EnemyWeapon: Set position to BadMan.ImagePointX("RightHand"), BadMan.ImagePointY("RightHand")

    without even having to specify ordering.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'd like to point out that this includes an example of how to absolutely move an object with the proper physics reaction.

    How about doing this speed-setting with a hidden proxy physics object for a platform object?

  • A Tips and tricks thread could be useful ...for stuff that doesn't really belong in the wiki I mean.

    Plus the tips and tricks can be discussed and improved (or if it doesn't make sense one could point out why).

  • Or you can use a sprite with Additive and just stretch it

    This is what I'd do, though thanks for the plug

    Do a thin filled box and preblur slightly it on an image editor, then cut a 1px wide sprite from that and stretch it to infinity and beyond (do use additive or some other effect).

  • Free as in beer

    You're free to use it, not to make it run in hardware other than Nvidia's.

  • some candidates for possible multicoring is the Physics behavior, the RTS movement pathfinding

    Plugins can be multicore with no issues, right? given it's C++

    There's OpenMP and soon OpenCL to use...

  • Monopolies mean the product cannot be superior as there is nothing to compare against.

    Also, they're usually to blame when the product quality decreases, as there is no incentive to improve, but there is to reduce manufacturing cost.

    So anyways, what I mean is that physics APIs can be implemented in OpenCL, not that you'd have to roll your own physics in OpenCL. And if Physx gets implemented in OpenCL, we'll have choice again. Which would be cool.

  • with picking.

    When a condition matches an object, the actions will apply only to the objects that fulfilled the condition.

    For example, if you have

    +on collision door with car

    • set value 'door_opening' to 1

    +compare global('door_opening') to 1

    • set door position to 0,0

    there is no relationship between the sprite that triggered the event to the action. But if instead you do something like

    +on collision door with car

    • set door position to 0,0

    only the door that collided with the car will be set to 0,0

  • I'd like to be able to retrieve music position, as one can do with normal channels.

  • the window kind of spazzes out if I set it to MouseX, MouseY

    I'd imagine, since on moving the window the relative coordinates of the mouse change.

    Use absolute mouse position instead

    EDIT: http://www.udec.cl/~jfuente_alba/dragwindow.cap yup, it works. Can't get the window edge sizes though, so it jumps a bit on grab. Guess that could be fixed too somehow.

    EDIT2: removed window frame thus no jump. Any key to get rid of the flashing annoyance.

  • zip password support would be nice

    at least for decompression

  • Man.

    I can't draw. I look at your stuff and I realize I can't draw at all.

  • the idea is after a while one would get the *feel* for where one's gonna land, and this feel is harder to get the farther you are teleporting (since distance increases geometrically).

    I got this idea after watching the movie Jumper and then playing the game and lamenting how horrible it was

  • Another quick gameplay mechanic experiment

    http://www.udec.cl/~jfuente_alba/teleport.exe

    Hold shift to teleport. Distance grows exponentially, be careful not to dissappear from the layout!

    You'll teleport in the direction you are facing RIGHT BEFORE YOU LET GO. This is so you can decide first to teleport and then where to land also allows a teleport feign.

    Edit: I know teleporting speed needs tweaking right now it picks up too slow, it's time squared. I'll adjust a proper curve when I use this in a game.

  • I made a similar example once but instead of repeating a high number of times it just consumes a time pool.

    The time pool was refilled on each frame, so you could have fixed frame rate logic (good for exact collisions) with dynamic frame rate graphics. It's somewhat similar but not exactly the same and only useful if the graphics rate stays way over the fixed logic rate.