Arima's Forum Posts

  • R2 is the newest version.

    http://www.scirra.com/forum/topic48884.html

  • You can do a lot of that with the instance bank plugin. http://www.scirra.com/forum/topic62131.html

  • You can already do this with the move at angle action. Simply enter angle(self.x, self.y, targetx, targety) for the angle.

  • 3 seconds per frame is 0.33 fps, Vs 3 fps. That's not 100% faster; it's 10x as fast; 900% faster

    Did you make sure to set collisions to bounding box as well in both c2 and cc?

    Lol whoops, no. I really screwed up that one in multiple ways. :P Let me try that again.

    To get the math right and a more accurate percentage I ran a second test, being more careful this time: 730 instances of both sprite and sprite 2, no rotation, just collision checks, none overlapping, using bounding boxes (the test would be incomparable using full collision, because it would wary wildly depending on sprite size and number of collision polys):

    CC 55fps, 0.0181s per frame

    C2 17 fps, 0.0588s per frame

    I think that results in C2 being about 31% the speed of CC there.

    4fps VS 9fps is over twice the speed, over 100% faster.

    Technically that was wavering into 5 fps, so I just made it to about 100% - I should have been more accurate, it was 4 a bit more often than 5.

    More accurate version:

    CC 53 fps, 0.0188 per frame

    C2 21 fps, 00476 per frame

    C2 being about 40% the speed of CC.

    The first test creating instances, 1.2s/1.8s results in c2 being two thirds the speed.

    So it seems the result is higher - CC seems to be about 1.5-3.2x faster.

    Unless I screwed up again. :P

    Also, more work CANNOT be done per frame at low fps, assuming rendering always finishes first; It just can't spit the logic out fast enough. Rendering finishes in a fraction of the time, and the cpu is just chugging, trying to finish calculating the event sheet.

    Of course it can - that's the entire result reason why it's a low FPS in the first place. I'm asking it to do more work than It can manage in a 60th of a second. If a processor could manage 60 calculations per second, at 60 fps it could manage 1 per frame, at 1 fps it could manage 60 per frame. Therefore, more work is done per frame at 1 fps. Regardless if it is the CPU or GPU that cannot keep up, either one has to wait for the other (though the CPU works one step ahead since the gpu renders the previous frame concurrently). In these tests, the GPU was waiting on the CPU.

    Interestingly, even seeing the result is back where I estimated originally before these tests, I don't feel like I care. I guess it's because c2's speed is sufficient for what I want to do, and device speed and browser optimizations are only going to improve.

    While I wouldn't mind that extra speed, I guess the reason I feel this way is because I'm not sure I would use it. I can understand why others would want it though.

  • Agreed, fixing the stickies.

  • You can't currently. This is something I would really like too that CC had. You can mimic the effect with storing uids as variables.

    Ashley - any chance of the pairer object from CC getting added to C2 eventually? It was a lot simpler than using variables.

  • Mobile hardware is way, way weaker than desktop. There are a lot of things that could be contributing to the frame rate problem, including overdraw (the graphics card redrawing pixels multiple times, like if something is drawn over the background - I read somewhere that on average current mobile hardware can only redraw the entire screen about three times in a 60th of a second), intensive stuff like usage of physics, too many collision checks, etc.

    As mentioned, you can find out what's causing the problem by backing up your project, then deactivating code or deleting objects and trying again to find out what's causing the hit.

    Don't use phonegap. It doesn't have hardware acceleration so it's nowhere near as fast as cocconJS.

    Also keep in mind C2's preview/preview over LAN is way slower than C2's exported HTML. If you want to see C2 at full speed, export rather than preview.

  • To determine just how much faster CC's event execution speed really is I decided to do some performance tests.

    Create 40,000 sprites:

    CC: 1.2 seconds

    C2 exported html: 1.8 seconds

    C2 preview: 18.5 seconds

    Edit: I screwed up this next test, redid it on the next page

    3000 sprite instances checking if not overlapping 3000 sprite2 instances, rotate sprite 1 degree

    CC: 3 fps

    C2 exported html: 3 seconds per frame

    C2 preview: 10 seconds per frame

    check sprite var=0, set sprite var to 0 and rotate 1 degree 50 times per frame on 3000 instances

    CC: 9fps

    C2 exported html: 4fps

    C2 preview: 2fps

    While these tests aren't covering everything, they are common and I think give a good basic comparison.

    So CC appears to be anywhere from about 33-100% faster (though those percentages are not entirely correct due to more work being able to be done per frame at lower frame rates).

    Collision detection, the area that was 100% faster, is probably an exclusive case considering I remember it being mentioned how many hardware specific optimizations were made for that in CC, and they might not even apply to other platforms like mobile since some of those optimizations required MMX.

    While the speed difference seems to be more than 20-30%, I think as much as I would like the extra speed I'm beginning to side with Ashley on sticking with HTML5. 33-100% extra speed would be nice, but I thought it would be more - probably because I run C2 games most of the time in preview mode, which slams the event execution speed hard.

    I'm beginning to think that the benefits of HTML5 outweigh the benefits something like haxeNME would have (not to mention how long it would take to make that new exporter, and therefore the delay in other added features).

    At least for what I'm making, C2 has sufficient speed for very close to everything I want to do with it - the only speed problems I've hit have been one thing on mobile and something I wanted to do on desktop that CC couldn't handle either. Obviously that is not the case for everyone's projects, but I think C2's speed is sufficient as is, and performance improvements are still being made - not to mention the optimizations I can make.

    I think people might be getting a bad impression of C2's speed from the preview, thinking that's its full speed. It has checks so as shown it can be a LOT slower than the exported HTML. I was getting a negative impression before I did these tests even though I knew the exported HTML is faster. I didn't realize how much faster it actually is.

  • Wow, awesome!!

  • Awesome, thanks for the info.

  • Ashley

    Two questions: First, does pathfinding use only 1 extra core, or does it use more if they are available?

    Second, I'm trying to optimize for mobile as much as I can - when running an event like this:

    Sprite.var=0

    Sprite.var2=1

    • rotate sprite

    I'm wondering, does the second condition, under the hood, have to still process those sprites that were deselected from the first condition in any way to run the check? Such as, does the JavaScript still have to loop through all the instances to even determine if they are currently picked before checking if the condition is true?

    Same for actions. Do actions have to loop through all instances, even deselected ones, to perform that action?

    Even if very small, is there any remaining performance impact at all from deselected instances in events?

  • I would love it added so that objects don't overlap each other too much when pathfinding. I managed the same effect using physics in a test I did a while ago in CC, but that gets pretty processor intensive doing it that way with a lot of units.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Tokinsom - have you seen the plugin for node webkit that allows file i/o? It doesn't look as user friendly as CC's options but in theory it should allow you to read and write files in a more traditional way. Won't work during preview, though, which is annoying. :/ I really think preview as exe should be implemented.

    http://www.scirra.com/forum/plugin-nodewebkit-nodejs-fs-module_topic60723.html

    That said, I actually agree about the exporter topic - I really think C2 should export to haxeNME, then it would get native Windows, Mac, Linux, iOS, Android, BlackBerry, webOS, Flash as well as HTML5 in one exporter. It would be all the best parts of CC and C2 in one package and everyone could work whatever way they wanted.

  • > You can't judge a tool's capabilities by the content created with that tool. Games take a long time to make, and C2 hasn't been out that long.It is the only way to judge a tool's capabilities. If a tool looks good and feels good but creates bad or limited results (just a general thought, this is not aimed at C2), it shouldn't be judged as a good 'game creator'.

    That's just not the case. That's looking at a tool without using your imagination at all. People create completely amazing things with things that weren't originally made for that purpose routinely.

    If the full potential of paint and a paintbrush was revealed by what was made with them, why should Leonardo Da Vinci have ever bothered painting the Mona Lisa? Why should anyone have looked at something and thought they could make a wheel out of it to make their job easier? If people determined that the maximum potential of something was only what has already been done with that thing, then no one would ever make any scientific or artistic progress on anything at all.

    To say that construct 2's maximum potential has already been reached - I can't understand why you'd think that. The very first games made with construct two were incredibly basic, so if that revealed the limits of its potential how did anyone ever surpass it?

    Following your logic, Stencyl would be the much better game creator than C2. Better interface, better integration of support (like drag'n'drop whole premade block sequences), better response time, etc. Then have a look at apps made with it...

    From what I have seen of Stencyl I disagree it has a better interface, but I haven't used it. I think that's a matter of opinion. I judge Stencyl the same way - I sincerely doubt it's maximum potential has been reached either.

    Imagine the difference of an inexperienced and developer trying to make something in the same program. Construct two is still new, and professional developers I hear often like to wait until a new engine has had something made with it that proves its viability. At that point you'll be seeing more and more impressive stuff.

    > True, there is functionality missing from C2 that CC has, but it's being added regularly.So you're arguing based on possible features that might be there somewhere in the future? That doesn't fit to your statement 'In fact, ...'

    >

    > > Regardless, even in its current state, I don't recall many games that were made with CC that couldn't be made with C2 (thumb war being the most notable example, but even then if C2 had sprite distortion it might be capable, though it might require a fast machine).

    > >

    > > There are also plenty of examples of stuff C2 can do that CC can't - probably more examples at this point, and those examples are probably more relevant to the majority of users (exporting to mobile, mac and linux, for example)./QUOTE] The contradiction of the two passages is why I answered. Such a contradiction was also in the passage, that I reacted to at first.

    > You say "if C2 had sprite distortion it might be capable". But it hasn't. On the other hand you ignore the same option for CC. Because if CC had an exporting plugin, it would also be capable of exporting to mobile, mac and linux. See? It doesn't make sense to compare things that might have been integrated, but aren't.

    In that case, I'm referring to the fact that construct two is being actively developed, a benefit that construct classic does not have, and Ashley has mentioned the possibility of sprite distortion in construct 2. Exporting to mobile is not coming to construct classic. Regardless, that does not change the fact that complex games can be made in construct two now with the features it already has.

    I'm also not ignoring that construct classic can do some things that construct two can't, I've mentioned that it can.

    > First, what you are looking for is not the best result for the users of your app,

    Completely incorrect. What I get out of C2 provides a better experience on more platforms and therefore is better for the users, many of whom couldn't play at all otherwise by not having windows.

    > but the most comfortable editor for yourself. There's nothing wrong with such a wish, it's just not the point. The result is what counts, the gamer doesn't care if you could produce a game comfortable or with literal pain - a gamer just wants a good game.

    The editor is entirely relevant to the discussion here. You shouldn't ignore the effect a difficult to endure development environment has on the resulting game. With how hard loot pursuit is to work on, it results in it taking more time to make and eventually it became so hard to work with that I had to ditch some of what I wanted to put in it. A good development environment that makes development easier and smoother will make the resulting game better and provide that game faster, which is better for the users.

    > And second, you indeed confuse complexity with sheer quantity. See, thumb war indeed is a complex game - yet it doesn't have 10000 events, 500 objects or thousands of animation frames.

    Also incorrect. Quantity and complexity are not mutually exclusive. Loot pursuit is both.

    >

    > > honestly, I don't understand why people talk like CC is the actual great version of construct when C2 is so much better.Because of its output! The result is what counts. And CC produces rock-solid, fast and amazing executables.

    Aside from event execution speed, I'm not sure why you think the output is so much better from CC. With the new node webkit EXE export, there's a good chance if you made the same game in both no one looking at them would be able to tell the difference. Also, in my experience, CC does not produce rock-solid executables. I've gotten quite a few crashes with them, for example when using or.

    >

    > > - capable of even outrunning CC's rendering speed by a good margin with a recent graphics card.No. It starts with the fact that any WinXP user (which still is more than a third of all installed windows versions) will experience software rendering.

    I hadn't heard that - a quick google search doesn't reveal anything about it, can you provide a link?

    > But even if we take that out of the comparison... Let's create a simple executable: 4000 sprites (based on 4 different sprites with 1000 copies each) of size 128x128 on a FullHD fullscreen, and, if you want to reduce it to rendering speed, no rotation, no movement, and just a start of layout event to create the sprites. I bet CC will win the rendering speed challenge.

    4000 wasn't anywhere near enough to get the fps below 60, so I added a 0. 40,000 sprites, 10k of each, using chrome for C2 (what node webkit uses for exe export):

    Textures not stacked (graphics card has to swap textures for each object): CC: 18fps. C2: 37fps.

    Textures stacked (graphics card does not have to swap textures for each object): CC: 30fps. C2: 50-60fps.

    As Ashley blogged, C2 has faster rendering than CC. https://www.scirra.com/blog/102/html5-games-faster-than-native

  • Subscribe to Construct videos now

    Yes, that was a real bug the game had at one point. I just added the reactions to it. :)