Halfgeek's Forum Posts

  • Helladen

    CJS is a wrapper. It's actually a Canvas with WebGL engine, or rather, half of what chromium is. On iOS8+, it's now much slower than the Safari browser engine and around 5-10x slower than the new WKWebView Safari engine.

    On Android, its about the same as the more recent Crosswalk version for my big games. The problem with Crosswalk is it can be stuttery or jitter on some mobile hardware, while running smoothly on others. It's quite strange. But then with my experience with CJS, on Android, it just crashes on a whole range of devices, including Samsung Tab2/3, S3 phones..

    CJS with WKWebView is unmatched for iOS though.

  • Nice, I'll have to test that out! Was operating under prior assumption just to be safe.

  • When I still had Ads, I was consistently getting around $2 per 1,000 impressions for a banner on the bottom.

    It was similar via MoPub/AdMob (about 80% fillrate) or when it was direct via AdMob (which higher fillrate).

    Reading around, it seems around $1-2 per 1,000 impression is a normal result for banners.

  • As long as you do not change the variable names, like global variables or instance variables of global objects which are saved etc, it should be fine.

  • —

    It's looking like we are a long way from a smooth running version of node, short of using 10.5.

    It's very disappointing, because it infers all those clever people working on chromium... didn't even play test games on it, else they would have noticed the obvious stutter.

    I was showing my C2 build preview on chrome to my nephews the other day, first time they seen it... 5 seconds in, they said "its a bit jerky, whats wrong?"...

  • TiAm Have ever you added "chromium-args": "--disable-gpu-vsync in package.json? You shouldn't have wasted your time.

    I've tried to compare...

    A= node-webkit without --disable-gpu-vsync

    B= node-webkit with --disable-gpu-vsync:

    A= runs smooth in start, then some seconds later, it starts to look Jerkiness in overtime, sometimes it appears smooth motion but not longer.

    B= runs smooth in start, no sign of Jerkiness in overtime, but there is mild jerkiness, looks kinda stable but not perfect.

    I believe B would be workaround to reduce jerkiness.

    Judge yourself.

    Tried option B in the latest NW, stutters are reduced but still present, very sporadic. It's frankly too distracting to enjoy any game when it happens.

    Reverting back to NW 0.10.5 resolves the issue and its very smooth. The problem is the Greenworks plugin v3 alpha for 0.10.5 doesn't have the Steam Overlay function, only the newer Greenworks v4 (which only works on NW 0.11.x!!) has it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    Since NW 11 stutter/janks, I've been using NW 10.5, I presume the process as described by Ashley in OP is identical (with Greenworks v3 alpha)?

    Edit: Hmm, It works fine with the v3 but with Greenworks v4, it crashes on startup, with error saying its missing the greenworks file. So I guess v4 is only specific to nw11 (I misread the "add support for nw11")...

  • I got this for a few months already:

    "Security alert

    This app is built on a version of Apache Cordova that contains security vulnerabilities. This includes a high severity cross-application scripting (XAS) vulnerability. Under certain circumstances, vulnerable apps could be remotely exploited to steal sensitive information, such as user login credentials.

    You should upgrade to Apache Cordova v3.5.1 or higher as soon as possible. For more information about the vulnerabilities, and for guidance on upgrading Apache Cordova, please see http://cordova.apache.org/announcements ... d-351.html

    Please note, applications with vulnerabilities that expose users to risk of compromise may be considered "dangerous products" and subject to removal from Google Play."

    — has said these security flags are fixed in Crosswalk 9, which is due to be released soon.

  • > Does the problem still occur when publishing with Crosswalk? Android's browser or web view has many bugs that the Chromium-based Crosswalk doesn't have.

    >

    Thanks for your replies!

    —: It was set "Full-screen scaling: High Quality" as default settings.

    Ashley: I did not try it with Crosswalk. My team have been used PhoneGap + Phaser to deploy games. But now, my current task is try to run Construct 2 with PhoneGap.

    I know it works just fine with Intel XDK Crosswalk with those settings, particular Fullscreen Scaling on High Quality, the image is crisp. I still have no experience with Phonegap, so others will have to chime in to help you.

    Crosswalk adds ~13MB to your apk, it is a concern for some, definitely.

  • Debug Watch or Profile mode is pretty accurate.

    Also its extremely high for a PC quad core to be that highly used in a small project, I think you have a code-leak somewhere. It's NOT normal for C2 games to abuse your CPU unless you set it to do it on purpose or accident.

  • These two options determine most of the final image quality:

    Full-screen scaling: High Quality

    Use high-DPI displays: Yes

    You don't need Downscaling on High, default Medium is fine.

  • > The texture size is always a power of 2. Even a thin line of 400 x 1 pixel becomes a texture of 512 x 512 pixels.

    >

    That's not quite right. Yes, on older graphics cards the texture size is padded to a power of two. But they are not forced squared. So, in your example, the 400x1 pixel line would become a 512x1 texture.

    For older graphics cards, 32x64, 128x8, 16x1024 are all valid formats that won't be padded, but taken as is. (Just a few examples)

    Modern graphics cards don't have any of these restrictions anymore. They deal with non-power-of-two textures natively, and graphic languages like OpenGL (which WebGL is based on) also support NPOT textures. WebGL's only limitation is that mipmapping and wrapping is not supported for NPOT textures. (See https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences#Non-Power_of_Two_Texture_Support)

    This is all true, except not in the case of Construct 2.

    Construct 2 will export your sprites to fit into the smallest power of 2 spritesheet that gets loaded into memory as a texture.

    There is also no usage of compressed texture so that even large black areas take up the memory budget. I understand the constraints, mobile hardware differ greatly, thus the base needs to be covered.

    Until it changes, devs need to be careful not to underestimate how much memory is actually used even for simple sprites and thus with any large project intended for mobiles, this needs to be taken into account during game design. Making a PC game offers a lot more freedom due to most PCs having 2gb vram, and many systems that use integrated GPUs like Intel HD3000/4000 etc, have a lot more due to using system ram as vram.

  • Starting to look really good! Keep it up!

  • I only use medium downscaling, have not had the need for high, which can cause a lot of problems with bloated memory usage.

    Also, it's correct that the final image within the GPU's memory is an uncompressed format. The texture size is always a power of 2. Even a thin line of 400 x 1 pixel becomes a texture of 512 x 512 pixels.

    The texture size is W x H x 4.

    A 512^2 texture is therefore 1MB.

    1024^2 texture is 4MB.

    2048^2 texture is 16MB.

    Most GPUs (ever since OpenGL 1.3 and Dx6!) these days do support compressed texture formats (S3TC etc) which saves a lot of memory use, but to use, game engines have to support it.

  • You need to be very capable at C2 first before attempting complex games (RPG, Strategy & bigger TD games are complex by nature). Start with tutorials then make a few simple games first.