Ashley's Recent Forum Activity

  • Also feel free to ask any questions about the SDK in the plugins forum, or in the codebase forum!

  • I'm not aware of a hardware-accelerated implementation of any of the pixel-art rescaling algorithms, as it may not be possible to implement via shaders. I did look in to one pixel art algorithm a while ago and it relied heavily on lookup tables, and I'm not sure how good pixel shader processors are at that. Still, as David said, why rely on a special algorithm to give your games detail when you can draw in the detail? Or why not use a different rendering application to scale all your graphics before you put them in?

  • > If I remember my Physics correctly, all you need to do is calculate the centre of gravity, and make everything fall towards that.

    >

    Soo, do you stay indoors during the day, so you can stand on the ceiling instead of falling into the sun?

    No, because you have to take in to account the Earth's centre of gravity and the Earth's mass! (My example does not take in to account mass, which I noted). In reality, the centre of gravity you fall towards will be ever so slightly towards you from the centre of the Earth's gravity due to your own mass, but the effect is vanishingly small.

  • One more thing, are pick by comparison events as processor consuming as for each object loops?

    No, it's an ordinary filtering condition and doesn't run repeats. Nesting them doesn't cause further exponential processing - just further filtering of the handful of objects that are picked in that event. It is the repetitions run by the looping conditions like Repeat, For, For-each and so on that cause exponential processing when nested.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,428,037 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
  • x108
    Coach One of your tutorials has over 1,000 readers
  • x62
    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