Ashley's Forum Posts

  • This is a constant pain and probably won't go away until we add a bundled-DirectX files feature (depending on if that's legal).

    The dialog has a button you can click and it takes you straight to the DirectX download page. I really can't think of a way to make it any simpler. Any ideas?

  • Mr Wolf, there's no point compiling events to C++. The entire event engine and all plugins are already written in compiled C++, the interpreted part is simply some lightweight code to decide what to run. That's already fast enough. Where events are slow it's usually due to the list-based processing of the SOLs, and that would be pretty much identical in a "compiled-to-C++" event system. So I doubt it would even run any faster!

  • Construct already does this. If a group is inactive, the events are not even looked at. If an event has 20 subevents and a condition in the parent event is false, none of the 20 subevents are even looked at.

  • OK! We're not going to remove sub animations

  • Ooh OK. Well, there's several explanations in this thread now

  • Referencing bash?

  • Have you read the TimeDelta article in my signature? It should cover it as you want. The idea is that objects move at a constant speed in real-world time, independent of the framerate, rather than speeding up if the framerate is higher. So:

    Set X to .X + 1

    Every second, this will move the object 1000 pixels sideways at 1000fps and 10 pixels sideways at 10fps. A difference of 100x in speed depending on the framerate!

    Set X to .X + 1 * TimeDelta

    This will move the object precisely one pixel every second, no matter the framerate. Obviously multiplying by 1 is redundant, but it makes it clear that it's one pixel per second.

    If that number is a private variable or some such, you still need the TimeDelta! It makes no difference if that number is hard-coded or a variable, you'd still need to do it like this:

    Set X to .X + Object('Speed') * TimeDelta

  • Use a 'for each' loop, under the System object.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • In the context of Construct, the difference between these two calculations is negligable (although linkman is right that the square root is technically more intensive). The overhead of the events probably measures 100x or 1000x the performance difference between two such low level functions. The only thing which matters is: is it fast enough?

  • That's a nice plan, GMG, and has been discussed before. That's definitely on the cards.

  • I'm always interested to hear ideas! I'm pretty split on the zero-based/one-based thing though. On the one hand, 1-based is the most intuitive to non-programmers. On the other, the math often works out better zero based (eg. looping to set object positions from an origin), and the rest of computing works zero based (and one of Construct's goals is to teach the basic principles of programming and logic). There's also that if we change it to 0-based in C2, it will create confusion for a lot of users moving over from C1. One thing's for sure though, that one standard should be agreed and everything should use it!

    Despite the initial pain I think moving to 0-based in C2 is the best thing to do. 0-based indexing is easy enough to get your head around, and is closer to how computers and programming really work.

  • You could also try looking at the implementation of the system expressions in System.cpp:

    http://construct.svn.sourceforge.net/vi ... iew=markup

    The ExpRoutineTable array at line 436 maps the expression string (eg. "lerp") to the routine (&SystemObject::eLerp) - if you then search for SystemObject::eLerp (without ampersand) you'll find the implementation:

     3887 long SystemObject::eLerp(LPVAL theParams, ExpReturn& ret)
 3888 {
 3889 	// Calculate linear interpolation:
 3890 	// lerp(a, b, x) = a + x(b - a)
 3891 	double a = theParams[0].GetDouble();
 3892 	double b = theParams[1].GetDouble();
 3893 	double x = theParams[2].GetDouble();
 3894 
 3895 	return ret = Lerp(a, b, x);
 3896 }
[/code:1y4dyv82]

You can use that to find the implementation of any system expression.  Does that help?

  • There is no specific order of bug fixes other than really severe ones get quicker attention and obviously simple ones can be fixed quicker too. Some will probably never be fixed like the ELSE picking bug, because the engine simply is not designed to be able to do picking like people want there. Those should probably be closed off as 'won't fix' or 'postponed' (for C2). I've considered removing it, but that'd probably cause more problems than it fixes.

    There's still around 200 bugs open on the tracker and I doubt they will ever all be fixed. Parts of Construct are very old and not written well because we were still learning how to program when the project started! Those parts are extremely difficult to change.

  • The usual way is to have a sprite which you set the width to distance(gun.x, gun.y, target.x, target.y) and the angle to angle(gun.x, gun.y, target.x, target.y), which effectively draws a line between the two. (Note this does not reference the angle of the bullet at all)

  • Interesting to see a new game creator coming about, but it's still very thin on details of the creator application itself. The StencylWorks page now says it's directly inspired by Scratch - is that an edit since you guys saw it? Still, I'm a bit disappointed since I always thought of Scratch as being an educational tool or toy (no disrespect meant to the Scratch folk though, looks like they're doing a good job). Stencyl might fall in to the awkward system of having a rudimentary event system with scripting for everything else, like GameMaker (where I think the pros consider scripting the only decent way to make games).

    The games from a technical standpoint seem very simple and since I'm used to V-synced floating point scrolling, the Java scrolling looks pretty shakey to me. (if it's software rendered that's going to be hard to fix)

    The java/web-play system is cool and we don't have anything like that, but Multimedia Fusion does now, so I think they'll have a tough time persuading any MMF users to move over, especially considering how simple the games look.

    I still don't like their secracy. Their entire userbase is incredibly overhyped, so I wonder how much down-to-earth reviews they really hear.