TiAm's Forum Posts

  • > Rotating objects frequently (rotate behavior or setting angle every tick) is one that doesn't show up in that list, but it can really slow things down, especially if you are rotating large objects.

    >

    so Nate goes and makes a game where almost *every* object constantly rotates...

    Really don't think it matters on desktops. Maybe if you had thousands of objects, but even then, I don't think offscreen objects are drawn at all, so I assume having them rotate wouldn't matter.

    I was under the impression that mobile GPUs would be pretty good at elemental operations like translation, scaling, rotation, etc. Did you experience this on CocoonJS as well? I'll have to test it.

    I've haven't used Canvas+ much. I basically went into development figuring that CJS Canvas+ could break at any time since it's not officially supported anymore, so I couldn't place my faith in it. Also, I wanted my game to be able to run on lower-end devices, even with crosswalk. A masochist, I know...

    Anyway, I'm certainly not saying you can't do rotation on mobile, just that, in my limited testing, it's much more expensive than translation and scaling. I didn't totally geek out and dive into why since I'd like to actually get my game finished...

  • Rotating objects frequently (rotate behavior or setting angle every tick) is one that doesn't show up in that list, but it can really slow things down, especially if you are rotating large objects.

    Also, the current 'stable' of crosswalk supported by xdk (v10) is a godawful mess that looks terrible at anything less than 60fps; if you really care about perf, use v7 instead. Just be aware that google may remove your app at some nebulous point in the future.

  • Got this too. It's happening to my test device.

    Game runs fine, then crashes. Same error msg. Running Android KitKat 4.4.2.

    Third party wise, all I'm using is Phonegap Game. Also using internal google play plug (works on crosswalk, but Phonegap Game has features the official plugin doesn't, and vice-versa).

    Anybody else seeing this?

  • jayderyu

    I ran into this too. My current project is a straightforward mobile game, but it does have one large object that can be freely rotated on a per-tick basis (a steering wheel).

    I read some about rotation being an expensive calc, and tried some benchmarks which confirmed that rotating a dozen or so moderately large sprites is enough to slow things way down on a low end mobile.

    This lead to some googling and perusal of stackexchange. TL;DR version: it's really not just us. I found native android devs struggling with the same issues.

    Rotation is actually a complex process, and even on a powerful desktop, really good rotation algos are non-realtime. There are faster algo's for realtime usage, but on a wimpy mobile device, it's really asking a lot.

    I doubt there is anything particularly wrong with the way rotation is implemented in c2; just consider it's usage carefully on mobile.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • digitalsoapbox

    [quote:3kesw8a5]...fragmentation is bad, as you mention below...

    No, (some) competition is good. Competition between FF/IE, and subsequently FF/Chrome, is what has built HTML/JS into the powerhouse it is today. Right now our export options are largely a chromium-based monoculture, with the exception of iOS8 Webview export. I'd love to see Mozilla/Microsoft alter that landscape; in the case of Microsoft, it seems they may be planning to do just that.

    [quote:3kesw8a5]What's the benefit of this [redist runtime] over their cross-platform universal app support with HTML5/JS/WebGL?

    I think we ought to have both options. Relying on a built in engine, like with Webview on iOS8/Android L, is a great solution in many ways, especially for keeping the app size down, but that layer can (and will) be updated and can (and will) break. When it does, I want to be able to package my app with a specific version of that runtime that I know will work, bloat be damned.

    [quote:3kesw8a5](Re CJS Webview+ export)If it's not cross-platform, what would the benefit be to cross-platform developers? What happens when CJS goes the way of the dodo in lieu of other options with more features and better support? CJS support is terrible, period.

    I think you are confusing Canvas+ (a proprietary creation of CJS) with Webview+. See:

    https://www.scirra.com/blog/154/evolvin ... rt-options

    [quote:3kesw8a5]Fragmentation on Android is dropping and is the most popular mobile platform worldwide based on sales figures and install base alone. That's an odd thing to describe as a commercial failure. Every Android device I've tested on - and I test from 2.3 up to 5, across about a dozen different devices from a list of different manufacturers - has no trouble handling anything designed for their specifications...

    Fragmentation is still bad. Android L is a significant step forward, but it looks like it's going to be years until it achieves a majority market share.

    Most popular platform? Sure, can't argue that. But as for monetization, I'll let the data speak for itself:

    http://blog.monumentvalleygame.com/blog ... in-numbers

    http://bgr.com/2014/06/26/ios-vs-androi ... r-revenue/

    http://www.businessinsider.com/android- ... lem-2015-1

    [quote:3kesw8a5]...As for Chromium/Crosswalk, I'm quite happy with 60fps 1080p performance with thousands of sprites on mid-range Android hardware, so I've no idea what you're talking about here either...

    ...and with this, we've just crossed over into the twilight zone. <img src="{SMILIES_PATH}/icon_e_geek.gif" alt=":geek:" title="Geek">

    Anywhere I can find a video of a mid-range (under $250 unlocked) android device spitting out 60fps/1080p/1,000s of sprites in the context of an actual C2 game exported with the current crosswalk stable(CW10)? Because really, I would love to believe this is possible, but I just don't. Then again, I've been wrong before... <img src="{SMILIES_PATH}/icon_mrgreen.gif" alt=":mrgreen:" title="Mr. Green">

  • What would really make C2 exporting better would be some competition for desktop (and potentially, console) distribution. Right now it boils down to: NW.JS. And that's it.

    Firefox may be terrible now, but project silk looks to be a dramatic improvement that should bring the fox on par with chromium (when chromium is behaving that is). What about Mozilla making their own version of NW.JS?

    Ditto for Microsoft: what about a 'redist runtime' version of Spartan that offers support across Windows Desktop, Mobile, and XB One?

    As for mobile, it would be great to hear from more people using CJS Webview+ to distribute on iOS8, because so far all I've heard is that it is phenomenal performance-wise, but the only person I know of who is using it for sure is silverforce.

    I'm becoming more and more convinced that Android is a poor platform to begin with, given it's poor commercial potential, poor performance relative to the raw system perf (even for native apps), high input latency, massively fractured OS/Hardware, dismal state of chromium/crosswalk for android, etc...

  • FredQ

    Thanks for the feedback. You've given me a little hope.

    At the time, I tried all three files types, but I could never get them to work on export. Previewed great in chrome, and works in the xwalk shells. What version of crosswalk did you build with? Was your WebM VP8/Vorbis or VP9/Opus?

    I have a WebM version of the video I'm trying to play, so I'll give it another shot.

  • Has anybody ever managed to get video working in crosswalk? I gave up on this awhile back, but recently I noticed that video working in all the crosswalk shells posted by imaffett, which got my interest piqued again.

  • If it ends up costing you a lot in time and/or money to port to Android, just stick with iOS. All the big devs say the same thing basically, their revenue share is 80/20 or even 90/10 in favour of iOS vs Android.

    Exactly. The two things that began to change my mind: me reading one of your posts about how your game ran nearly as well on an iPad as on a desktop computer with a i5 3570k, and this article about Monument Valley's numbers.

    Still, the beauty of C2 (when it works) is that its very easy to port to multiple platforms. So if you build a game for mobiles, its a no-brainer to include Android! As such, an Android wrapper that is 50% to 500% faster is tremendously helpful.

    I'd love to see it, but I think Ashley has made up his mind about wrappers, and honestly, I can see where he's coming from. Scirra isn't Unity, and I don't expect or want them to become that. There's no way they can handle the extra workload.

    I'd love to be able to export to android in the future, just for the simple pleasure of seeing iPhone-less friends play my games. But anymore, it seems like 90% of our export woes have to do with android (okay, NW.JS isn't flawless, but it's a breeze compared to crosswalk). I'm starting to think it's a problem that doesn't merit a solution.

  • I'm starting to wonder if Android is even worth it.

    Let's say we all woke up tomorrow to a magical universe where android performance was equal to 'native'...then what?

    You still have an ecosystem that is very difficult to commercialize due to epic-level piracy, with a user base that overwhelmingly prefers free(mium) content, of which there is boatloads.

    You still have to deal with thousands of different hardware configs, many of which don't work well to begin with.

    You still have to figure a way to rise above heaps of festering shovelware (Poo Toucher 2: The Poo Knight Rises!) that is the end result of the very 'easy access' policies that make android attractive in the first place.

    But then there are Ads...and they are so easy to implement! We all love ads...right?

    . . .

    The nail in the coffin: we don't live in a world of ponies and rainbows, and the reality of android performance is that it is all over the place, and will likely stay that way.

    Meanwhile, iOS 8 is on 70-80% of Apple devices, and from what I've read and heard, perf rocks. The marketplace is less crowded, piracy is much lower, app sizes are reasonable, and there are only a handful of very well engineered devices to design for.

    Me? I'm shopping for a Mac.

  • Having tested all 4 wrappers now, here's my assessment (based on observations of my own game):

    CW7: Still the best perf; has the least jank/jagging, and the best framerate (about 10% over CW11/12).

    CW10: Definitely the worst. Framerate is more unstable, and is the lowest overall: about 15% lower than CW7, and 5% lower than CW11/12. Jank/jagging is more frequent. Given that others have experienced even more severe regressions with CW10, I wouldn't dream of releasing an app with it.

    CW11: Slower than 7, but better than 10. Still halts and janks more than it should. Usable is the word. Similar perf to the current Chrome Stable for Android, with the exception of higher cpu use (all CW releases are that way, and my chrome cpu use was similar til I switched to ART runtime from DAVIK, so salt grains are implied).

    CW12: I really can't discern a clear difference between CW11 and CW12. I think it halts/janks a hair less than CW11; conversely, the FPS is slightly lower (1-2fps, admittedly margin of error territory).

    I also tried one other game whose capx I had available: Propaganda, by Egyptoon. This was a version I had optimized myself; it's a relatively low-impact game ala Flappy Bird. Here matters were worse: while CW7 gave excellent performance (60fps during gameplay, looked silky smooth), all subsequent versions (CW10/11/12) produced lower framerates, but worse, completely unacceptable motion quality, as if every other frame were being missed about half of the time. I think the moving background exacerbated this issue, which is likely present in my game, but harder to notice given that the background is fixed, and the actors don't move very rapidly.

    All tests were run in WebGL mode; I tested canvas2d a bit, but it always seemed to have jerky display and a lower framerate, so I did not test it extensively.

    Personally, I've decided to release my game with v7, and upload a CW11/12 build later on if Google starts complaining again or takes the game down. If they do...I'll blame it on Google.

    I would definitely fast-track CW11/12...without it, XDK is looking a bit of a lame duck. Even with it, it seems we are getting stuck with the fallout of Wirth's Law...

  • imaffett

    Will give all these shells a go. Really grateful for all your involvement on this; it looks like we are starting to get a better picture of what our options look like. It's a shame that CW7 still seems to be tops on perf, but it looks like cw11/12 are usable, especially in comparison to CW10.

  • Given Ashley's input, the best idea -- Tinimations -- would be to load in a tons of sounds across stages to see what happens. Maybe try the 32-bit version. Does NW.JS finally start to unload assets when it gets near 3GB of memory? Does it crash? Does it halt terribly when it unloads assets, or does handle it gracefully? Maybe this isn't a problem; more testing is needed.

    Let's assume for a second that NW.JS doesn't handle this sort of 'threshold' unloading well; that it halts badly, or hangs up, or causes audio glitches. I guess my question would be: is it possible/practical to implement audio buffer unloading? If both = true, I'd say do it.

    I get the 'android style' memory management argument, but I suspect this is a case where that might not work out so well. Case in point: do you really want a giant chunk of memory to be GC'd during a frenetic moment of gameplay...or during a between stages load?

    Here's hoping I'm wrong...

  • Pretty sure sound is decoded into wav (well, not exactly wav, but an uncompressed format, BASE64 I think) when it's 'preloaded' or played. Ergo, the bitrate on import matters ziltch. Since your game has a heavy focus on music and sound, you definately want to stick with 256-320kbps for everything.

    This problem could likely be fixed by a new action that would allow us to 'unload' these decoded sounds, so they aren't piling up across layouts.

  • The only theory I have as to why this happens, is that I introduce new music and sfx on every stage. I read this is never unloaded?

    According to a little test I just ran, this seems to be the case.

    Since audio is decoded into memory as wav, it can take a lot more memory than the original files; assuming music and effects for a stage took up 50mb at 128kbps, that would balloon to almost 600mb in memory (assuming tracks were stereo). Of course, we have a lot more memory now-a-days...but if it's adding up across every stage...

    Ashley

    We have preloading...what about an 'Unload Sound/Music' action? Would make music-heavy games like Klang feasible, and would also be invaluable for mobile games, where ram is much more precious.