Ashley's Forum Posts

  • This is possible with ordinary events, you've probably just got things in the wrong order. A .cap would help. However, I'd advise instead of fully disabling collisions to prevent a collision event running, just add an extra condition to the collision event! eg.:

    + On player collision with obstacle

    + Player Z is whatever

    -> Do actions

    This is much more robust - it still allows collision checking with other objects, and it probably works the way you want it too as well.

  • The 3D box object is kind of experimental right now. Log a feature request for this and maybe we'll get round to it some time, but FYI I'd expect this only to be possible with power-of-two-sized textures (eg. 256x256, 512x512 etc).

  • Use the Sprite's built-in 'rotate toward...' actions in the angle category. If you use simple less than/greater than comparisons with angles, it won't work correctly over the 0/360 degree changeover. The rotation actions take care of this for you.

  • The 'Get RMS level' or 'Get Peak level' expressions sound like they do exactly what you want.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • Mipey's suggestion would work, change IgnoreMouse to 1 and the event stops running. Or, put all the events in a group, and disable the group when you want the events to stop running.

  • Crashes are never features! They're ALWAYS bugs! Report them via the tracker please!

  • You can also make use the following expressions:

    ScrollXLeft - left most visible pixel

    ScrollXRight - right most visible pixel

    ScrollYTop - top most visible pixel

    ScrollYBottom - bottom most visible pixel

    Also, if you're feeling devious, you can adjust the display zoom to zoom in slightly with bigger resolutions, and therefore display exactly the same content. If your textures are high resolution and were slightly downscaled originally, you really do get more texture detail using a higher resolution.

  • I don't think any of us should be laughing at anyone else - if they did release a good product, we'd be the fools then (but as I said, game on if they do!)

    If their main problem was announcing too early, they could remedy the situation by providing screenshots, tech demos, works-in-progress, and regular updates. I still don't see why they don't do that. For me their main problem is not their community appearing childish - it's that their refusal to provide anything substantial about their product - not so much as a screenshot - makes them look like a hype machine promoting vapourware. Remember the Phantom console, or Steorn who generated PR by claiming to have invented perpetual motion? They look like them now.

    As GMG said, folks, keep it civil. It's at least polite to keep it sensible and mature when discussing (potential or otherwise) competitors. I see a lot of other forums delete threads as soon as there is mention of competing programs, and you can kind of see why, but if I can help it I don't want it to be like that here!

  • Out of curiosity, why does your game require moving objects in exact units of 1? There are ways to get a timedelta'd game to do this too.

  • Why not use a behavior? That seems the obvious thing to do. The bullet behavior would be suitable. Or, use Mipey's suggestion, which is basically to move the object a small step every tick (which is what the behavior does).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I wouldn't do that if I were you, running physics on an object can be very CPU intensive, so the last thing you want is hundreds of tiny objects running physics. Physics works best with as few larger objects as possible.

  • That's what TimeDelta is for... you can code near-enough pixel perfect games with timedelta and vsync. I never really intended anyone to use fixed framerate for games. Having all your graphics shredded by display tearing seems a high price to pay for this alleged pixel perfection, too. I don't think any modern commercial games are written with fixed framerate engines.

    Also, the concept of fixed framerate games running the same speed on all computers is a myth. It will slow down if the computer can't reach the fixed framerate. Not so with timedelta games.

  • 1024x768 is too big for a windowed game; I use 2048x768 dualscreen and it's annoying to have a window bigger than one monitor, and by the stats a lot of people still use it single screen anyway.

    The screen is also redrawn fully every tick so there's the issue of rendering speed if you have a lot of heavy rendering going on - smaller windows will generally render faster.

    Then there's the issue of VRAM usage - textures are always put on power-of-two sized surfaces in VRAM, and the runtime has to create several textures the size of the window sometimes for purposes like effects rendering. If your window is bigger than 1024x768, these runtime textures now have to be put on 2048x2048 sized surfaces, which could potentially use a lot more VRAM.

    You can use the 'change display resolution' though to set whatever resolution you like at runtime; this would be handy for users to pick what they want. It might be wise to start up the first run with a small window, allow the user to pick their display resolution and fullscreen setting, then use the system actions to set them when the game begins.