Ashley's Forum Posts

  • The best way to do this is by writing a custom pixel shader effect, because these run really quickly on the graphics card. See Pixel Shaders.

  • Did you try putting d3dx9_39.dll in the Construct directory? If that doesn't work, you probably need a real DirectX install, which means you just can't get it to run from a USB disk on a crippled-access computer. Construct also exports the preview to the Application Data\Scirra directory, so if you can, you'll need to paste d3dx9_39.dll there so the runtime can find it too (but first the IDE has to work).

  • Makes sense, otherwise the Else, at runtime, attaches itself to the event above the toggled event as well!

    Best log it on the tracker as a bug so we don't forget.

  • This is corrected in the next build. When you change direction, the deceleration and acceleration are added.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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