Ashley's Forum Posts

  • Wouldn't it be just as easy/better to have TimeDelta enabled by default in the way the events work?

    No, this is not possible. Consider this, to make a sprite rotate 360 degrees every second:

    + Always

    -> Rotate sprite 360 * Timedelta degrees clockwise

    Why not make the 'Rotate clockwise' action automatically multiply its parameter by TimeDelta? Because if you call it one-off, this messes everything else up:

    + Upon pressing spacebar

    -> Rotate sprite 90 degrees clockwise

    Here, if you hit spacebar four times, the sprite makes a complete rotation. If you automatically tried to apply timedelta as above, it would only rotate a few degrees... that's not what you'd expect to happen!

    [quote:1jxbj8rr]one time I tried, Construct gave me some sort of runtime error when I tried to test my game out

    Did you report this bug?

  • I have to say - I personally would much rather code a game to allow for the small variations TimeDelta produces than override or avoid using TimeDelta at all. Not using TimeDelta will cause you problems, period. And possibly problems worse than the one you're trying to fix.

    Deadeye: I cannot imagine how varying framerates and timedelta would cause large variations (ie. a "mile"). That can't be right. Can you reproduce an example where the variation is that significant?

    If your game is a pixel retro platformer consisting of a player who can jump exactly 32 pixels high, running around a level of blocks exactly 32 pixels high, of course timedelta will cause variations. Sometimes you'll make it, sometimes you wont. The correct solution here is to make the blocks 25 pixels high or so, so you have a chance to clear them! If you turn TimeDelta off or override it, you either end up with V-Sync off and horribly torn up display (and highly dubious gameplay speed on low end systems), or have your game run twice as fast on one computer as another (ridiculously unfair on players).

    Design your game to take in to account variations. Not using Timedelta has its own serious problems.

  • That's a very vague definition. You can't just bolt on 'intelligent' movement in a generic way. What exactly are you after?

  • Um... what would it do?

  • I only get about 330fps without even spawning anything; that's not very good for my 8800 GT, are you using any blur effects or motion blur? I can't see anything obvious that would slow down the graphics that much.

  • Thanks for the kind words

    (By the way, is there a variable for application path?)

    Have a look at AppPath.

    [quote:3raylbnu]When I last left Construct, you guys were just beginning to implement Python. Has it become the dominant way to write games for it now?

    Quite the opposite... Python is currently broken, and isn't working at all We're hoping to fix it in the next build. Once it's working again we're not going to leave either scripting or events behind; scripting is deliberately designed to work in tandem with events (eg. for processing complex expressions or intensive loops and algorithms that are difficult to express in events). In the meanwhile, we've still been developing the eventing engine, such as ELSE (and if/else if/else if chains), OR, advanced functions, subevents, for-each/for-each ordered/one-line loops and so on.

    I don't think anyone's managed to make a game entirely out of Python yet, it would be interesting to see how that works out. But Construct is definitely still centered around the event sheet editor.

  • Can you post a .cap file with the problem?

  • I realised it's time to face reality with timedelta and start incorporating it into my work..

    *hears applause from ash*

    *applause*

    Seriously, framerate independency is the way to go. Not many people think it's a big deal, but it does make for a better game.

  • Do i need to make a seperate layer?

    Yes - the mask/erase effects cut a hole in the layer they are on. So you want to put them on their own layer, and 'force own texture' should be enabled on that layer.

  • Use & for string concatenation. + is for addition.

    Eg. "There are " & Balls.Count & " balls in play"

  • Well how about that, I banned Google

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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