Ashley's Forum Posts

  • The ACE table is only ever loaded once, on launching the IDE, and is never requested again.

    OnPut is called when you place a new object type in the layout.

    Serialize is called when you save or load the project.

  • Grids of points can overlap with none of their points touching! All the points just fall in between the other points. It won't do at all! Collision polygons are the standard used by physics engines and other algorithms like lighting. We may as well use collision polygons and then you get your physics polygon automatically.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Both - I'm thinking C2 will try to guess the polygon, and you can manually tweak it if it's not good enough.

  • > now rotated objects overlap when their rotated bounding boxes overlap

    >

    AWESOME. Been wanting this feature for a while! Is it as fast as normal box collisions, or is it somewhat more computationally intensive than normal box, but still less than per pixel?

    It always does an ordinary (axis-aligned) bounding box check first, which is trivial and 99% of the time determines the objects are not overlapping. The rotated-box check is only a bunch of arithmetic though so should be very fast as well, compared to per-pixel checking.

    I think it's worth pointing out there won't be per-pixel collisions in the HTML5 runtime - Javascript isn't fast enough. The Classic runtime uses C++'s raw speed as well as special CPU features to make it practical. There'll have to be collision polygons instead.

    Thanks for the check failure reports, I'll have a look soon!

  • Download Construct 2 public preview 36

    Link to release 35

    As promised, this build brings global and local variables!

    However, first of all, there's been an improvement to collisions: now rotated objects overlap when their rotated bounding boxes overlap, as opposed to using unrotated bounding boxes which are always much too big for rotated objects. This makes collisions much more useful now, even though there aren't fine collisions just yet.

    Back to variables: the main change is both global and local variables appear, and are added and edited, in the event sheet itself!

    <img src="http://www.scirra.com/construct2/releases/r36a.png">

    Variables at the 'root scope' (at the top of an event sheet, or anywhere they aren't a subevent) become global variables. These work exactly like global variables in Classic: they keep their value between layouts, and you can use them from any event sheet, not just the one you created it in.

    Variables which are subevents to another event become 'local variables'. You can see in the picture above they have a different icon too. These work slightly differently. They reset their value every tick back to their original value. Also, they can only be used in their 'scope'. This means any 'sibling' subevents. For example, in the above picture, 'MyLocal' can be accessed by any subevents of 'every tick', but not anywhere else. They're intended to be a temporary holding space for calculations, like you might have used a 'temp' global or instance variable for in Classic. Their scope is similar to how scope works in programming languages. This has the advantage that you can reuse names where scope does not overlap. You could have a 'sum' local variable in one subevent, and another 'sum' local variable somewhere else in that event sheet, used for another purpose.

    As an added bonus the expressions panel lists all variables available in the current scope under the System object:

    <img src="http://www.scirra.com/construct2/releases/r36b.png">

    Local variables turned out to be a very complex feature to write - there may be bugs in this version. Let me know if you find any.

    There are three more things to watch out for:

    • You can drag local variables around like ordinary events. However, this changes their scope. This can mean events already using the variable can no longer access it. In this case, those events disappear, and a balloon tip appears at the mouse notifying you this happened. You can just undo this or drag it back and they'll reappear, though.
    • Copying and pasting or dragging around events referencing local variables is tricky, because you can't paste them anywhere outside the scope of the local variables they reference. If you try to do this a message appears and you are prevented from doing it. This could be annoying for day to day use though. Let me know how you find it. Perhaps it could be worked around with a "do you want to add missing local variables?" type prompt.
    • You can't yet put an expression in the initial value of either a global or local variable - this should be added in a future build.

    Anyways, hope you enjoy, let me know if you have any thoughts or more ideas!

    Changelog

    • [Feature] Global & local variables (see above)
    • [Change] Previously collisions only tested axis-aligned bounding boxes. This doesn't work well for rotated objects, which often register collisions when close but not touching. Now collisions are tested with object-aligned bounding boxes (i.e. the box rotates with the object). This is much better for collisions between rotated objects until fine collisions come in future.
    • [Fix] Browsers sometimes hang for a moment while they compile the javascript runtime. This could cause objects to teleport since the value of dt is very large for one tick. This has been fixed by capping dt to a maximum of 0.2 (equivalent to 5fps).

  • They're the exact same as global variables when at the root scope. Otherwise, they're not global at all!

  • We just decided local variables are forgotten every tick anyway, and global variables work like they used to, so nothing special happens when you change layout. Variables declared at root scope become global.

  • Do you know, when David is going to finish the graphic editor? That's probably last thing, that's stopping me from using C2 more.

    Hopefully not more than a couple of months - we're not fulltime just yet. I'm well aware this is the biggest shortcoming in C2 at the moment, we're going to sort it out ASAP.

  • Yes, the syntax checker knows which variables are available in the current scope.

    I'm siding with not persisting values for local variables. If you want a persistently stored value I don't see why you wouldn't use a global variable instead.

    Local variables are intended for small clusters of events where you need somewhere to temporarily dump a value, but you don't want to be forced in to using a global or instance variable. I think for this purpose, non-persistent local variables are fine.

    In programming languages, local variables by default are not persistent either - they're the same kind of temporary holding space.

    Does that sound fair? I can do the initial release with non-persistent local variables, and everyone can have a play with it and see how it works out. If it turns out it would be really useful to persist them I can always change it later.

  • I was considering having them reset to their initial value every time the event ran. If they persist their value they're exactly like global variables, but only accessible within their scope. Does that sound like a better idea?

    I'm not sure: if they persist, in the example in the original post, the second time you click the Xsum and Ysum values increment from their old sum values, which might be unexpected.

  • Initialising a local variable with an expression like Sprite.X isn't going to be supported immediately - it's a little complicated - but it will come in a later build. For the first release if you need an expression all you need to do is follow with a 'set variable' action.

    They're not limited to one event: they can be accessed in all its "sibling" subevents and subevents to all those events. It's like scope in programming languages: you can use local variables everywhere inside the curly braces they're defined in, but not in code outside of that. This gives another advantage: you can re-use the names in different scopes, such as having 'sum' in one subevent in one place, and another 'sum' in another subevent somewhere else.

  • Hi all,

    Just thought you might like to see how the next build is shaping up. I've been working on global variables, as per request in the last poll, but also adding in a 'local variables' feature as I go.

    If you ever needed a temporary number to store a value just for a couple of events, local variables are perfect. Previously you'd have to add a global variable or stow it away in an instance variable. The problem is those are visible to the rest of the project. Lots of these temporary variables end up 'junking up' the project with random bits of data.

    Local variables are a new type of event block. They look a bit like comments, but declare a temporary variable that is only usable in its "scope". At the top level, they're global variables, but in a subevent, they become local and are limited to use within that one subevent.

    For example, to calculate the average position of a bunch of objects, you need a temporary place to store the sum of X and Y values. With local variables it looks like this:

    <img src="http://www.scirra.com/labs/localvars.png">

    The variables Xsum and Ysum don't appear anywhere outside that subevent, so they don't mess up the project.

    This is a totally new feature for C2! I'm not aware of anywhere a feature like this has been done before. You'll be able to play with it in the next build! If you have any ideas that would make this extra-awesome, let me know

  • newt: despite the shortcomings of our documentation I don't think your original reply was at all helpful. Your reply basically amounts to "give up and go somewhere else". Please stick to answering the question in the thread!

    Anyways, try turning off your antivirus just while you export - it may see a new EXE file being generated and block its creation for security reasons.

    Also, make sure you're exporting to a folder you have permission to access. For example, if you're not an administrator, exporting your game to the root C:\ may fail, because it's access is protected. Try exporting to 'my documents'.

  • Construct 2 is still very early in development - anyone looking for a game creation tool for actual day to day use will probably stick to Classic. However, you should keep an eye on C2, we're hoping it'll overtake Classic one day.

    Krush and others: we are planning a C2 .exe exporter, it's just it's too early for us to tell ourselves when or how it will be developed. So we're being deliberately vague rather than making a guess which might turn out to be wrong. I'm hoping that an .exe exporter turns up much sooner than "a couple of years", though.

  • 1 - is it normal that in the sprites, transparecy isn't supported?

    Full alpha transparency is supported - it's just we haven't got an internal image editor yet, so we launch the system image editor. By default this is Paint, which doesn't have transparency support. Install Paint.NET and you can use alpha.

    [quote:1u97i0ld]2 - when do you think to release the "full version"?

    No idea I'm afraid!