Ashley's Forum Posts

  • If I remember my Physics correctly, all you need to do is calculate the centre of gravity, and make everything fall towards that. This example shows that, but I don't think it's quite perfect (it doesn't take in to account that objects with a bigger mass have a greater effect on the centre of gravity). It shows the right idea though.

  • Well, .cap files even from 0.8 in theory are still compatible, and we have a very good compatibility code that allows us to add, remove, or completely change sections of the file format as necessary, while still being able to load the old format. So we'll never change the format in a way that breaks all existing files.

    Being beta sometimes we need to make changes in order to fix bugs which might affect - but not completely invalidate - older files. The physics bug deadeye was referring to actually only affected .cap files that were started with a couple of the more recent builds. The default world scales were incorrect, but the value was ignored. So I corrected the default value and fixed the bug that made it ignore the value - but this meant old files were now making use of the incorrect default value. The change was very simple (change two properties to 3.3% and it worked exactly like it did before). This was, like any other similar situation that has arisen or will arise, detailed in the changelog. If you keep up-to-date with the changelog, it's a trivial change. Very old applications in the newest version might suffer a few of these minor changes, and it becomes more difficult to track down all the tweaks after more builds get released.

    The official line is that you shouldn't start any really serious projects in Construct until 1.0. This is true, but it becomes less of an issue the closer we get to 1.0, and large-scale applications are very good for testing Construct. You should back it up regularly however, including to separate media (this is just generally good practice with any software). Construct includes anti-corruption code - every time it saves or autosaves it verifies the data it generated is valid and can be successfully loaded. In theory, this means your .cap file is never corrupted (overwritten with data that cannot be loaded). However, there might be some other obscure as-yet unknown situation that causes an invalid file to be saved (even mature commercial applications sometimes do this). With regular backups, I'm fairly confident your work would be safe, but take precautions in case it is not.

  • I agree that more primitives should be added to the Canvas object. However, DirectX 9 has no built in way of drawing an ellipse. Any implementation we came up with would be along the lines of create a texture with a big circle in it, then draw the texture resized to how you want your ellipse. So if you're worried about the pasting-a-circle-sprite method being inefficient, it's not. It's how you have to do it!

  • What is this profiler you're using, Ash?

    AMD CodeAnalyst. There are better ones, but CodeAnalyst is free. Only works on AMD processors but Intel have their own equivalent, but I've forgotten what it's called. Profilers automatically tell you which functions in the source code the CPU has spent most time executing. You need the Construct source code to use it (what a surprise, you can get it too!), and to build with debug symbols (/DEBUG) so the profiler has access to function names.

    Then you run under the profiler. In this case, SystemObject::cForEach had the majority processing time, hence the above conclusion.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Now that Rich mentions it, there's also a 'Simple platformer' template that demonstrates exactly what he described!

  • From the main menu choose New -> Template/example. There are a few things you could check out there, the 'Scrolling basics' may be of specific interest to you. Also, check out the Learn page. Try running through the Ghost Shooter tutorial there - it's a top-down scroller, but the scrolling principles are the same (plus you'll learn general usage of Construct). Lastly, it's incomplete, but have a poke around the Wiki.

  • I have had a brief look at the .cap you sent me. I'm replying here because some of the information might be useful to others.

    To be honest with such a large .cap, it's difficult to make sense of that many events, and I did run it through a profiler - which said the 'For Each' system condition is using the majority of the processing time. I don't think it's the line of sight object, although you have nearly 200 objects using line of sight - even at timed intervals, 200 line of sight intervals might be a fair bit of processing. To be on the safe side, you should minimise the CPU overhead by only checking line of sight queries for objects within a certain range, objects just on-screen, etc. If you do this, remember conditions are checked in top to bottom order, ie.:

    + Enemy is on-screen

    + Enemy has line-of-sight to player

    This event is faster, because it picks the N objects that are on-screen, and does line of sight checks just with those objects. If you order it:

    + Enemy has line-of-sight to player

    + Enemy is on-screen

    This processes a possibly expensive line-of-sight operation for all objects - on and off-screen - then of these, discards the ones offscreen, which is a waste of the processing power you just spent on them.

    Still, judging by the profile results, you have a very CPU intensive 'for-each' loop somewhere. I can't find it with all the events you have, but hopefully the information is useful to you. An ordinary 'for-each' event is usually very fast, even with thousands of objects - I think you must be nesting loops somewhere in a very inefficient manor. For example:

    + For each A

    + For each B

    iterates A x B instances, and

    + For each A

    + For each B

    + For each C

    iterates A x B x C instances. If you have 500 instances of each, this is the difference between 500 iterations with a single for-each, and 125 million iterations (!) with three nested for-eaches (thats 250,000 times as much work). So you can see how nesting exponentially creates more work for the CPU with high object counts - you should be careful with code like that.

  • You can't execute console commands - but you can launch EXE files using the 'Execute file' action in the System object.

  • Yeah, I'm just taking shots in the dark here unless I can see your .cap. Send it over and I can run it through a profiler.

  • Right click the layout, Hide/Lock objects, Unlock All (Ctrl+Shift+U). Also, there's only one third party plugin at the moment, so we haven't needed to make a plugin database yet.

  • This is by design. See Containers.

  • Congrats! Our first third party plugin

    How did you find using the SDK? Any particular problems?

  • How many objects are you talking about here? The size of a level itself has nothing to do with how fast it runs, it's just essentially numbers that control scrolling - so it's entirely the object count and the processing the game does. To see if it is the LOS, try (backing up your game then) deleting the LOS related stuff and seeing if it runs much faster. If it doesn't, look elsewhere.

    Objects offscreen are not drawn - and that's about it. They'll still be processed by events, check collisions, etc. Pathfinding with the RTS movement can be a CPU hog too if used wrong, are you using that?

    Also, if you're using shaders, which ones are they? A lot of shaders can slow down performance, especially on lower end cards.

  • Please keep to English on the forums, non-english posts can't be moderated!

  • Loading collision masks from files is not yet implemented. I'll try have done something about it by 1.0.