Ashley's Recent Forum Activity

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

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

  • That's a good summary, but the vertex stuff probably isn't worth worrying about. Vertices are actually only stored temporarily (they're re-sent every frame), not in permanent texture memory, so it works a bit differently. You only need to worry about textures.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Everyone chill! It's an important feature to have unicode, and it's especially crucial to non-English speakers, since it can be difficult or impossible to make a game in your native language without unicode support. Imagine trying to make a platformer for your friends in a program that doesn't support English, only Hindi characters.

    aolko, you do not understand how difficult it is to add unicode support to Construct. There are hundreds of thousands of lines of code, it's much more complicated than flipping a switch, and we only work on this in our spare time. So, in short, there will not be unicode support before Construct 2.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,451,291 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x64
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs