Ashley's Forum Posts

  • Nice engine, I love this effect Would definitely make for a creative game.

    Does this help simplify the math?

    Qarp(a, b, c, x)

    Quadratic interpolation. Returns lerp(lerp(a, b, x), lerp(b, c, x), x)

  • PUT THE TWO .INI FILES IN YOUR C DIRECTORY (C:\)

    Aaaagh! Don't do this, use the AppPath expression to load it from the same directory as the application! There's never any need to force people to put files in a fixed directory! (Sorry, pet peeve)

    [quote:3k6b3mud]to the devs: any idea if you'll support japanese (unicode?) characters in the future? i tried it from .ini files and from .html files and neither let me display japanese characters.

    Hmm, not sure if we can do it soon. It's a bit late really - we didn't start off with support for unicode, so it'd be a lot of work going through Construct's code changing it. Maybe for a version 2 type thing...

  • The Mask and Erase effects are definitely the way to go for this. You don't need the canvas object - it would actually be slower. Mask and Erase are very simple effects and don't require pixel shaders - they should still be very efficient. All you need to do is draw a circle on a sprite and give it one of the effects (one erases the transparent areas, one erases the solid areas). It even works with alpha blended sprites to erase smooth edges!

    A drop of 50fps is not always bad news - the difference between 1050fps and 1000fps is pretty much negligable, whereas 100fps to 50fps is significant. In other words, a difference of a fixed number of FPS is a fairly meaningless statement. 1 divided by the framerate is the time in seconds it takes to render each frame - you can use this to work out exactly how much extra time it takes to process an effect, per frame.

  • It's also difficult to determine the point of collision efficiently - the collision engine checks 64 pixels at a time for better performance, which also means it can only tell to within 64 pixels where a collision happened anyway. Having it any more accurate would be a lot slower, and as deadeye mentions, highly problematic anyway.

  • What's with that site? I can't find anywhere a description of what OpenPandora actually is, but I can deduce it from the tech specs and photos...

    Linux support is a frequently asked question, and the short answer is: in the distant future, maybe, or when we get more developers than three part-time volunteers.

  • The funny thing is, I bet Google already helps out loads of people with their problems...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • No - not mode 7 itself - it's a software rendering engine. Construct is entirely hardware accelerated, so it would make sense to do the same thing but in true 3D. However, we are concentrating on 2D features for up to Construct 1.0. Have you had a look at 3D Box?

  • Your game is not framerate independent. In other words, when the framerate changes, the way the game behaves changes. This is not good! If a player was playing on a slow computer you don't want the game to change for them as well.

    As Arcticus said, read about TimeDelta. If you say 'Always - subtract 1 from value', the value is subtracted once every tick, which is different speeds depending on the framerate.

  • There is no need for a for-each. The event

    + Always

    -> Add 'timedelta' to Sprite

    adds timedelta to every sprite object. It runs about twice as fast too, since it does them all in one action instead of one at a time and repeating the action!

    On the other hand, I'm quite pleased with how fast for-each actually is. It seems to have a fairly low overhead per iteration.

  • Nice example! I wonder if I can come up with a blob...

  • 'ELSE' doesn't make sense after a 'For each' loop - 'For each' is actually logically false (because of how the engine works), so I think the else event will actually run like an 'always' event.

    I think the best way to handle Z ordering is to come up with some combination value: if you loop by .Y + .Z ascending or something, it might be able to factor in both. I think you'll need to tweak that expression a fair bit to get it right though...

  • Physics should still respond to time scaling - I remember testing it - it should change speed appropriately. But you're right, it would be useful to have velocities working in pixels per second, but the maths behind it is a bit tricky (I'm not sure how to represent forces in terms of pixels...).

    You can upload files to the upload forum - us admins have omnipotent attachment powers

  • Addition is hardly an expensive CPU operation... I wouldn't worry about that! Storing the creation time is another perfectly good way of doing it - whichever is easiest, really.

  • Can you upload the .cap that crashes to the tracker? That way we can fix the crash instead of trying to avoid it...

  • Yes, that would be useful, thanks.