Ashley's Forum Posts

  • Yeah, it looks like a bug that you can't drag a subanimation back out. Submit it to the tracker.

    I'm still debating if sub-animations were a good idea to implement. It's tempting just to turn them off. There's a vague case for having them for two reasons:

    • Organising animations
    • Having more complex animation structures, like "Stopped" and "Walking" animations, then subanimations for carrying different weapons/wearing different clothes/whatever. So you'd have subanimations under "Walking" like "Walking with nothing", "Walking with sword", "Walking with shield", "Walking with sword and shield". But I think this could be better done with separate sprites for the different things, and just have one generic walking animation.

    What do you think? Should we have sub-animations? People often ask what they are for (and the above two things are the only thing), so I guess it isn't intuitively obvious.

  • I just tested it, and it seems to work alright. With OK / Cancel buttons, clicking the X in the messagebox window triggers Cancel, and with just an OK button, clicking the X triggers OK. This is intentional, and Windows tells you that OK was clicked if you use the X on a messagebox with just an OK button, so it's obviously intentional.

  • Have you tried putting in a text object tracking the total object count? The runtime can give 'out of memory' errors if you continuously create objects and don't destroy them. All objects except ones marked global are destroyed when you change a layout, so if you're spawning a lot of global objects, they will still exist after you change layout.

    If you send me your .cap (to ) I can take a look and see what's going on. You'd need to provide clear instructions though and make it simple to see the problem (sometimes people send me really complicated games and say "just get to level 15, then...")!

  • Yeah, I've sometimes needed this too. Another workaround is to put the actions in an 'always' subevent, and toggle the subevent.

  • Cool! Can you scan the page so we can read what they said?

  • No, the runtime can't force shaders not to draw outside the object's bounding box, but behavior if you do so is undefined. Pixels outside of the bounding box will be whatever is left over from previous rendering operations that need an intermediate stage. Also, if there is a second effect in the chain, the next shader only processes the bounding box, and the bounding box is the only area copied to the display, so in some cases it will be truncated anyway.

    Basically, although you can, you should not write shaders that access outside the bounding box.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The plugin SDK is just a C++ written DLL, so anything you can do in C++, can be called from the plugin.

  • The effect is processed on the object's bounding box on a fullscreen texture, so the texture coordinates (0,0) refer to the top left of the screen, not the top left of the object. For the texture coordinates of the object's area, use the boxLeft, boxTop, boxRight and boxBottom variables.

  • There's currently no way to directly call a DLL from Construct events, but you could make a plugin using the Plugin SDK to call the DLL.

  • Construct uses the latest DirectX updates, and from what I've heard, either WINE doesn't emulate DirectX well enough, or it's not kept well enough up to date. It seems these tools are just not mature enough.

  • They're really simple. They just repeat stuff.

    + On spacebar pressed

    + Repeat 5 times

    -> Add 1 to global variable 'test'

    When you press spacebar, 5 is added to 'test' (it adds 1 five times, instantly)

    + Start of layout

    + Repeat 100 times

    -> Create Star at random(640), random(480)

    Creates 100 randomly positioned stars on startup.

    There are some variations like For (loop over a range of numbers), For Each (repeat once for each instance of an object), and so on. You can read more in the Conditions article.

  • See the Function Object.

  • Families show the private variables which all the objects in the family have in common. You can use the Family Manager to quickly add a variable to all the objects in the family.

  • I'm saying there's no point talking about whether loading levels from files or using the layout editor creates smaller files. As you say, the difference is negligable, so the more important things to worry about is if you want to spend the extra time writing a level editor, and so on.

  • You can also use families to generalise all your different kinds of bullet and projectiles, using private variables to set how much damage they cause, what kind of explosions/effects they create, etc.