Ashley's Forum Posts

  • There's an even simpler way.

    + Always

    -> Set object opacity to 100

    + Mouse is over Sprite

    -> Set object opacity to 50

    Events are read in top to bottom order, so they all have 100 opacity, except for the one under the mouse. "Mouse not over object" won't be true and won't run until the mouse isn't over any of the object, hence the problem.

  • You should run the debugger and look at the sprIvoRobotnik object. You can see exactly what's happening. The minute you start the application, because it is created on the first layout and has a platform movement, it starts falling. Really really far, down and down, until it's also going really fast. So as soon as you get to your layout it's probably going fast enough to pass through stuff.

    Deactivate the platform movement on the first layout, then activate it on the layer where you can actually start controlling him.

    Secondly, and the debugger also shows this, sprIvoRobotnik is being positioned by the Start object left over from the first layout. Because it's global it still exists, and Start.X and Start.Y just so happens to refer to that one, off the bottom of the screen, instead of the second one you placed on the layout. To get around this, you can destroy the first start object on the first layout on start of layout, or simply delete it from the layout editor - it still exists on the other layout, so it won't destroy completely. However, since you're going to be adding more levels and positioning start markers differently on them, I would suspect you really dont want other start markers from other layouts hanging around, so don't make it global. That also fixes it, since non global objects are destroyed when you move away from the layout.

    Remember, if things are going wrong, get the debugger out!

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