Ashley's Forum Posts

  • Right click the sound or music folders in the project bar and click "Import".

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yes, it should be fine. The best way to measure framerate is actually delta-time - it's linear and frames per second is nonlinear. Basically, the difference in a real game should be nothing, it's only when you measure empty levels that you can see the effect the tiny difference has.

  • The problem was there was a function in the runtime - "GetObjectTypeByName" - that loops every single object type and finds the one with the given name, case insensitive. For behavior management, this was called once every tick. This meant if your project was huge (hundreds if not thousands of different object types), it was doing a fair amount of work per tick. I came up with a faster way that doesn't need to loop every single object type, so now it barely does anything every tick.

    Now for various reasons I think

    • it won't reach the 11,000fps of an empty layout in a new game, and
    • it doesn't matter.

    In the runtime there's a certain amount of work that must be done every tick, and some of these jobs invariably take slightly longer for large projects. However, the difference is (now) incredibly tiny. Remember: 11,000 fps means one tick lasts about 91 microseconds. That's obscenely fast. If that drops by half to 5,500 fps, each tick is now taking about 182 microseconds (less than a fifth of a millisecond).

    At the super-high framerates you get with Classic, tiny insignificant amounts of CPU work are vastly over-represented. For real games a change of 91 microseconds per tick has no effect. None. However when Classic is essentially doing nothing per tick, such a tiny change seems to be trashing your framerate. It doesn't matter though.

    So I think the big one has been fixed - but there shouldn't be any other significant performance issues. If in doubt calculate your delta-times instead of framerates, and you should see you're doing just fine.

  • No, not yet - right now a plugin's the best way to do it, but I was hoping to add a feature to the Browser object in future to do this.

  • The next build (should be out tomorrow) has a "stop" action for Audio!

  • You have to drop them in to your r1.2 <install directory>\Data and hit Preview inside Construct to use them.

  • I was having a quick look and almost immediately found something that may have been the problem - if anyone else wants to try, have a play with these runtimes:

    http://dl.dropbox.com/u/15217362/fasteruntimes.zip

  • We're going to do polygon collisions next.

    Construct Classic's pixel perfect collider is a bit unusual - it uses all the hardware tricks in the book to get it fast enough to be useful. Javascript doesn't have the same close-to-the-metal features that C++ has, so it's unlikely to be practical in Javascript.

    Still, polygon collisions should do just fine.

  • So if you add a new, empty layout with no events, running it unlimited is slower than a blank cap? That's odd. I think a while back Davo was investigating a bug where overall performance was dependent the number of different object types in the project. I guess he didn't solve it.

    I guess I should take a look back at Classic to solve this - it seems to have held up the biggest and best projects in Classic. If you send me your .cap (obviously I won't share it) I'll run it through a profiler and see what's going on. We're doing the big C2 launch on Monday so I can't guarantee I'll be able to fix this soon though.

  • You do not have permission to view this post

  • What do you want to use these extra controls for? I prefer not to do the work unless there's a provable case where it's necessary. We're constantly stretched to the limit of our resources.

  • 'Containers' in Classic is what you want - you can group together objects so they act as a composite object. However, the feature hasn't been added to C2 yet. It's on the todo list!

    In the mean time, as long as there are equal numbers of objects, 'Set A position to B.X, B.Y' will pair up an A to every B.

  • What we are most likely to do is package the HTML5 runtime inside apps, so your app works identically everywhere. Also, as a tiny team, it means we don't have to spend months working on new runtimes and exporters for each mobile phone out there (iOS, Android, Windows Phone etc). HTML5 is getting very fast even on mobiles so I think this is will be good enough for games.

    We want to finish off features for the HTML5 runtime first, so any other platforms are probably some way off. However, there have been calls for an OpenGL/desktop runtime (like Classic). I suppose if HTML5 covers mobiles well, then we'd do that next.

  • Vercingetorix, if you hit F5 (or manually refresh the browser), do the changes show up? How about if you close the browser and click preview again with no browser open?

  • Is it? The entire javascript runtime is written in the style

    if ()

    {

    }

    It works just fine. I think the semicolon insertion rules don't break that.