Aphrodite

Yes, thanks for testing the phone too. That's an interesting result; it shows that chrome is decoding slower period, even when the number of cores is only one (so threading wouldn't matter). Unfortunately, it seems like chrome is particularly slow at decoding ogg.

glerikud

Thanks for testing. Can you post those result on the bug report too? It helps to reiterate to the chrome devs that this speed discrepancy can be replicated on many different devices.

Sounds interesting, will be sure to give it a try. So, it can play, for example, a WAV file loaded as a C2 resource? Can it do so without substantial delay? If so, that would be awesome.

Thx for sharing!

Edit: Doesn't seem to be a play action...?

I didn't try NW.JS 12, but I also get an error exporting the test project above with nw 10.5. Disabling minify fixes the problem.

Must be something to do with the minification botching a var name/string.

Do you have an android device? Can you spare a few minutes? If so, you can help diagnose a problem that significantly slows down loading on android when using chrome or chromium based exporters (Phonegap, Crosswalk).

1. DL the latest chrome for android

2. DL the latest Firefox for android (yes, there's FF for android. It's actually quite good.)

3. Run the following test in both FF and Chrome. http://www.scirra.com/labs/bugs/webaudiodecode/

4. Test both OGG and AAC and note the time taken for each. You should end up with 4 different scores, 2 for each browser.

5. Go to this chrome bug report: https://code.google.com/p/chromium/issu ... ?id=424174

6. Star it.

7. Post your results, along with your device details. Particularly, your cpu information (model, how many cores).

7a. If you don't know about your cpu, use the following app to find out: https://play.google.com/store/apps/deta ... puid.cpu_z

That's it. BTW, while everything helps, scores for single core, hexa(6)-core, and octo(8)-core devices are particularly useful.

—

Glad you were able to hit your target.

R0J0hound's suggestion sounds like a good one too, maybe for some of your heaviest processes.

I'm never actually dealt with the RTS gametype, but I've read that it's one of the most difficult game designs to implement efficiently. I hope you can enjoy the challenge...

Damn...I'm surprised A.I. is chewing up so much. I've also got a 3570k, and I can usually get away with quite a lot of chaos before cpu gets to be a problem. If you have 50 actors (drones) that are, by themselves, chewing up 50% of your cpu...that just doesn't sound right.

—

I know this is a bit OTT, but in that stress test of yours, what is chewing up most of your resources? Cols? A.I.? Draw calls?

Colludium

Wow, that's awesome! I had no idea NW.JS could do that!

Edit: So far I'm just trying 10.5 (can't DL 12 'til after midnight local...long story).

Anyway, with 10.5, this is the best I've seen airscape run. However, going 'auto' resolution and fullscreen still drags me down to 40fps. That being said, the stuttering is much less severe; I would consider the game playable like this. Also, 1366x768 works really well; solid 60fps, soooo smooth.

Will give 12 a run later; hope it works even better!

Colludium

How did you try the Airscape demo in the new NW.JS? Or are you talking about a different bench?

I've been on 10.5 forever...wonder if it's finally time to update...?

By the way, just to counter all that downer talk: this has become a really awesome document. I haven't looked a it in a few weeks, so most of this is completely new (to me).

In particular, I'd never heard of Duff's Device loops. Why, exactly, are they faster? Would there be any way to hard-mod a bit of the engine code to give them a test run?

For anyone that wants to run the tests:

http://jsperf.com/duffs-device

It looks like we have a troll

http://i.imgur.com/BAsp1pv.png

Would it sound jaded if I were to be surprised that it took this long... <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing"> <img src="{SMILIES_PATH}/icon_rolleyes.gif" alt=":roll:" title="Rolling Eyes">

jayderyu:

You can roll back, right?

> If there are customizable windows, and associated actions. Then the architecture can already support the request down the road. Either by Scirra or some one else.

>

Extensions are great and all, but I want the main software to function well from the get go. I'm already going trough nightmare of custom extensions in other software I'm using, and I don't C2 to be this way.

This +1000.

I know the whole point of this thread is to articulate how C3 should be more open to tinkering and third-party-extensions, but megatronx makes a really good point: we need basic functionality that works. I just don't want to see C3 typified by this response from Ashley (and/or other devs, if there ever are other C2 devs):

"Yeah, that's a good idea, and it's on the todo list, but you know, you can just add it yourself with the sdk."

Also, while I can think of all sorts of awesomeness that could come from custom IDE elements, such a feature must be designed so that extensions can be rolled into a capx on export (hopefully such a feature can be extended to plugs/behaviors/effects too).

Otherwise, we are going to be looking at an expansion of the dependency-hell that already affects many C2 projects due to third party plugins/behaviors/effects.

Anyway, don't mind me, just being the devil's advocate. Now, where's another parade I can piss on... <img src="{SMILIES_PATH}/icon_twisted.gif" alt=":twisted:" title="Twisted Evil">

sqiddster

What about this:

http://muizelaar.blogspot.com/2011/02/d ... webgl.html