j0schi

Whoa, thanks for the suggestion about creating/destroying some objects during the menu/loading/etc! I never would have thought of trying that.

eli0s

Wow, I glad/sad to hear your experiences with firefox. I hadn't tested with it in awhile, and my version was ancient. I assumed that was why it was performing so poorly for me. I updated to version 33, only to find that my game still stuttered terribly. That being said, my recycling fork exhibited noticeably less jank than my old create/destroy engine.

Colludium

Are you saying that the recycling approach gives a worse result on your older system, given the same test load (identical number of sprites)?

I have yet to test a platform that has given me worse performance when recycling objects. I do have pretty good hardware (3570k, 16gb ram, ssd) but I usually run off of my iGPU, and was doing so in this case. My other computer is a netbook circa 2009, and thus, won't even run a blank layout. So...I'm caught at the extreme ends of the scale.

I've got a friend with a low end dual-core laptop (pcmark is somewhere around 2000) and iGPU...I'll give his system a try when I can.

j0schi

Ashley already linked these, but again:

Chrome Bug Report: Chrome issue 424563

Firefox Bug Report: Firefox bug 1028893

Nobody has commented on the firefox bug in two months (Ashley was the last). If nobody complains, this won't be fixed.

Well, I hacked it into my game last night. Didn't take but an hour or so, but:

a. My game is way less complicated than Penelope, and...

b. To maximize the benefit, I'll need to restructure some of my logic. That will take more work.

In my case, I added a boolean called Active to my player bullets family. Then I went to where bullets were normally destroyed (when colliding with enemies, and when going offscreen) and, instead, simply moved them offscreen, disabled collisions, and set Active to false.

I then went to where I was creating them, and simply looped thru (Active != true) instances by iid(loopindex), repositioning them, re-enabling collisions, and setting them to (Active = true).

After that, I went to where I was moving my bullets, and added the (Active = true) condition. This way, inactive bullets won't be flying around in the offscreen netherland.

Finally, I added logic that slowly spawns in (Active = false, collisions = off) bullets offscreen when entering the game layout, stopping at about 1600 instances (the highest number of player bullets that can be onscreen at any one time). This gives me a sufficient cache for the rest of the game.

The result of all this was a marked improvement in performance, as tested in chrome(preview), firefox(preview), node-webkit(preview), and node-webkit(export). Overall CPU usage was reduced by 20 t0 25% in chrome/node, and performance skyrocketed in firefox by almost 110%. The caveat there is that firefox performance was poor in both cases...I haven't updated it to a current version in awhile. I'll test it again tonite with firefox 33.

I'm actually very glad that you brought this up - gave my a nudge to test this myself!

I remember Ashley making mention of something like this sometime ago with regards to someone's question about performance with individual rain drops as sprites. He suggested then that it'd be more efficient to move the rain drops to the top of the screen when they hit the ground, instead of destroying and recreating them.

Hah, that's funny...that's where I got the idea too!

I did a test yesterday and found much the same thing: with large numbers of objects, there is a noticeable gain with 'de-activation' vs create/destroy.

I'll check your capx out later today.

I've been working on a bullet hell shooter for awhile now. The performance is pretty good, but I'm trying to make some further optimizations.

One thing I'm wondering is if anyone else has compared activating/deactivating objects -- ie., moving them offscreen and disabling collisions, etc. -- vs creating/destroying objects. I'm specifically interested in cases involving high numbers of small, short-lived, similar objects, such as bullets and explosions.

Right now I simply spawn bullets as needed, and destroy them when they go offscreen. I was under the impression that this was a workable approach since C2 did some form of object pooling, but I can't find any reference to that now. The highest onscreen object count I'm dealing with is between 1000-2000.

Faking a link to libudev.so.1 will work, but it's a crude hack and can break other linux programs. There are some other ways to work around the problem...see the suggestion by TenLeftFingers in the link anubis666 posted.

Bottom line though is that none of the solutions are end-user freindly. This is a compatibility issue with node-webkit export, not with the C2 engine itself. Eventually it will be rectified (supposedly when node hits version 1.0, iirc).

Voted up a bunch of stuff. Put in three votes each on ogg/opus support, and also...midi.

What can I say...I'm a sucker for midi and I'd love to see all browsers implement it.

P.S. I notice the top request is to have IE auto-update. Of course, it would make all these new features alot more relevent if it didn't take another 5-6 years for people to upgrade...

Patching would look different on different platforms. I'm sure you could do it, but you would probably need to use some sort of third party tool to extract the game file (.apk, .exe, whathaveyou...), replace any modified files with new ones, and repackage the app.

Obviously, you would need to encapsulate said logic as a script or macro within the patch, as no end user is going to go to that effort themselves. Then you have to hope that the program can be re-packaged succesfully. Not a trivial process.

Or...you could redownload the game.

I already wrote above, that I consider Construct 2 an integrated environment and also one that could be used by kids to learn programming (via game creation). Having to learn yet another program to paint and to switch between the two apps via the OS facilities (e.g. ALT+TAB) is extra burden. That's why I suggested at least having a button to open the file in an external tool you define (like Paint.net or Gimp [or Photoshop etc.] for example) and to use shell notifications to monitor the file for changes.

Actually, that's a really good idea, IMO. Knowing how to use something like photoshop/gimp is a vital skill anyway. I really don't think the internal image editor should have any more work put into it. Any IDE efforts should go toward more functional improvements (better search, etc).

My guess is "every dt seconds" will in practice will have the possibility of running less than a "every tick" event.

As I understand it the "every dt seconds" event could be done like this:

> global endTime=0

endtime >= time
--- Set endtime to time+dt
--- do stuff
[/code:3w07yjcm]
So if it ran on a slow frame it could not run on the next frame if it was a fast frame.  Although it could still be acceptable, unless absolute precision is needed.

That's true. I suppose you could get a little closer by averaging the last 2 or 3 dt values and using that value instead.

Whoops, bit of a brain glitch there...I was thinking of *dt applications, or using 'Every X seconds'. I guess if you literally went 'Do X every dt', it would function identically to 'Do X every tick'.

Actually...that brings an idea to mind. If you were making a framerate dependant game, and you wanted an action to repeat every few ticks (say every 3, or 4), you could approximate that without using a timer by going:

Every dt*(TickInterval) seconds.