Shubi's Forum Posts

  • Nepeo

    i just tried with another project of mine and it is giving some other kind of error, i am trying to recreate a minimal project to recreate the bug, as soon as i figure that out i will post a report.

    By the way all three people posted the same log and their was no "bug report" just a log that we could share, that's why i posted in forum and assumed that everyone else is facing the same.

  • medervolfr

    yeah there are three posts with the log/error description included still they need a bug report... its like talking to government. :p

    anyway i am filing a bug.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Edit : Did not see this has been posted already... https://www.construct.net/en/forum/construct-3/general-discussion-7/andriod-signed-apk-build-144783

    Any idea what's wrong here?

    the build fails with following log :

    Error: Checking Java JDK and Android SDK versions

    ANDROID_SDK_ROOT=undefined (recommended setting)

    ANDROID_HOME=~~/androidSDK (DEPRECATED)

    :wrapper

    BUILD SUCCESSFUL

    Total time: 0.896 secs

    Subproject Path: CordovaLib

    Subproject Path: app

    Task :app:preBuild UP-TO-DATE

    Task :CordovaLib:preBuild UP-TO-DATE

    Task :CordovaLib:preReleaseBuild UP-TO-DATE

    Task :CordovaLib:checkReleaseManifest

    Task :CordovaLib:processReleaseManifest

    Task :app:preReleaseBuild

    Task :CordovaLib:compileReleaseAidl NO-SOURCE

    Task :app:compileReleaseAidl

    Task :CordovaLib:packageReleaseRenderscript NO-SOURCE

    Task :app:compileReleaseRenderscript

    Task :app:checkReleaseManifest

    Task :app:generateReleaseBuildConfig

    Task :app:prepareLintJar

    Task :app:generateReleaseSources

    Task :CordovaLib:compileReleaseRenderscript

    Task :CordovaLib:generateReleaseBuildConfig

    Task :CordovaLib:generateReleaseResValues

    Task :CordovaLib:generateReleaseResources

    Task :CordovaLib:packageReleaseResources

    Task :CordovaLib:generateReleaseRFile

    Task :CordovaLib:prepareLintJar

    Task :CordovaLib:generateReleaseSources

    Task :CordovaLib:javaPreCompileRelease

    Task :CordovaLib:compileReleaseJavaWithJavac

    Task :CordovaLib:processReleaseJavaRes NO-SOURCE

    Task :CordovaLib:transformClassesAndResourcesWithPrepareIntermediateJarsForRelease

    Task :app:javaPreCompileRelease

    Task :app:mainApkListPersistenceRelease

    Task :app:generateReleaseResValues

    Task :app:generateReleaseResources

    Task :app:mergeReleaseResources

    Task :app:createReleaseCompatibleScreenManifests

    Task :app:processReleaseManifest

    Task :app:processReleaseResources

    Task :app:compileReleaseJavaWithJavac

    Task :app:compileReleaseNdk NO-SOURCE

    Task :app:compileReleaseSources

    Task :app:lintVitalRelease

    Task :app:mergeReleaseShaders

    Task :app:compileReleaseShaders

    Task :app:generateReleaseAssets

    Task :CordovaLib:mergeReleaseShaders

    Task :CordovaLib:compileReleaseShaders

    Task :CordovaLib:generateReleaseAssets

    Task :CordovaLib:packageReleaseAssets

    Task :app:mergeReleaseAssets

    Task :app:signingConfigWriterRelease

    Task :app:transformClassesWithDexBuilderForRelease

    Task :app:transformDexArchiveWithExternalLibsDexMergerForRelease FAILED

    35 actionable tasks: 35 executed

  • Hi,

    I have an idea to make a game with lots of physics objects and i have two questions...

    1. Is there a limit of joints(revolute) in case i want to make a single physics object to joint with multiple other physics objects
    1. Is it feasible to make a mobile game with lots of physics objects?

    And yes i have read all the posts and yes i know it is not advised to use many physics objects but what if the game logic demands 100s of objects, why physics behavior can't be any better in c3?

    Any opinion is welcome...

  • You do not have permission to view this post

  • Thanks everyone for helping!

    I got it working by choosing Custom on LOS.

  • If you want to have solid on sprites that you want to detect, then use custom on Los and define obstacles seperatly

    SnipG I did the same in my previous post, you should see the .c3p file . It isn't working that way either.

  • It is not working with custom object either...

    Here you can see for yourself...https://drive.google.com/open?id=1kZndM5TLmVoH4rOIIjWn4MhlyV3BkQ_9

  • I tried Line of sight behavior today, turned out it doesn't detect sprites having Solid Behavior or Physics Behavior,

    is this a bug? or is it by default and why?

  • Okay...Thank you very much!

  • Memory use does not directly affect performance. It's a separate measurement.

    Good to know that!

    Although i would still like to know the right size to design for...

    viewport or pixel size? (as shown in the table)

  • Ashley

    i am not saying the viweport size in itself will cause a performance lag, when i say the size affects performance i mean for example if i design my game for 700x1400 layout size then i need a background sprite of size 700x1400, simillarly if i design my game for say 400x800 layout size then i will need a sprite of size 400x800..... then technically wouldn't the second one would be lighter on memory and better in performance?

    Trending screen sizes are given below, as you can see the viewport sizes and pixel sizes(resolutions) are widely different from each other,

    Now, Lets say i want to deign my graphic size exactly for "Nexus 6p device"(first in list) so that my graphics would not need to scale up(lose quality) or scale down(unnecessary memory used) when running on the device, i am confused if i should design for ?

    viewport size or pixel size (resolution)

    412 x 732 or 1440 x 2560

    I am facing the same problem... is c3 going to implement it in next release?

  • Mobile Screens are getting bigger but their native webview is not very good in handling native games exported with c3, i have always experienced laggy game play on low & medium price range devices on even small games made with c3.

    As Graphic design plays a big role in memory management and can affect performance greatly. Thus games design need to be as optimized as possible for it to not lag.

    For example, i have made a game with layout/viewport size of 700x1400p considering trend of large mobile screens and 2:1 aspect ratio. All graphics are designed exactly for the same screen size (no upscaling or downscaling).

    I am wondering if i have used larger layout than required causing lag in performance. Also i am confused between mobile resolution and viweport sizes as they differ widely in size.

    Can someone explain the concept of resolution and viewport of mobile screens and which on should be considered while designing layout size and its graphics.

  • It was working alright for a day, now it shows this when i start the engine...

    Error report information

    Type: unhandled rejection

    Reason: Error: Cannot read property 'ǃpIN' of null TypeError: Cannot read property 'ǃpIN' of null at Function.ǃpRz (https://editor.construct.net/r151/main.js:2:320867) at Function.ǃpRz (https://editor.construct.net/r151/main.js:2:322022) at Function.ǃpRz (https://editor.construct.net/r151/main.js:2:322022) at Function.ǃpRc (https://editor.construct.net/r151/main.js:2:319983) at Object.ǃKzk (https://editor.construct.net/r151/main.js:159:47933) at Object.ǃKzk (https://editor.construct.net/r151/main.js:159:48085) at Object.ǃwBY (https://editor.construct.net/r151/main.js:159:45308) at async s (https://editor.construct.net/r151/main.js:159:91122) at async editor.construct.net/r151/main.js:159:93147

    Stack: TypeError: Cannot read property 'ǃpIN' of null at Function.ǃpRz (https://editor.construct.net/r151/main.js:2:320867) at Function.ǃpRz (https://editor.construct.net/r151/main.js:2:322022) at Function.ǃpRz (https://editor.construct.net/r151/main.js:2:322022) at Function.ǃpRc (https://editor.construct.net/r151/main.js:2:319983) at Object.ǃKzk (https://editor.construct.net/r151/main.js:159:47933) at Object.ǃKzk (https://editor.construct.net/r151/main.js:159:48085) at Object.ǃwBY (https://editor.construct.net/r151/main.js:159:45308) at async s (https://editor.construct.net/r151/main.js:159:91122) at async editor.construct.net/r151/main.js:159:93147

    Construct 3 version: r151

    URL: editor.construct.net/r151

    Date: Thu May 30 2019 16:14:22 GMT+0530 (India Standard Time)

    Uptime: 0.6 s

    Platform information

    Browser: Chrome

    Browser version: 74.0.3729.169

    Browser engine: Chromium

    Browser architecture: 64-bit

    Context: browser

    Operating system: Windows

    Operating system version: 10

    Operating system architecture: 64-bit

    Device type: desktop

    Device pixel ratio: 1

    Logical CPU cores: 4

    Approx. device memory: 8 GB

    User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

    C3 release: r151 (beta)

    Language setting: en-US

    WebGL information

    Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium)

    Numeric version: 2

    Supports NPOT textures: yes

    Supports GPU profiling: yes

    Supports highp precision: yes

    Vendor: Google Inc.

    Renderer: ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0)

    Major performance caveat: no

    Maximum texture size: 16384

    Point size range: 1 to 1024

    Extensions: EXT_color_buffer_float, EXT_disjoint_timer_query_webgl2, EXT_texture_filter_anisotropic, OES_texture_float_linear, WEBGL_compressed_texture_s3tc, WEBGL_compressed_texture_s3tc_srgb, WEBGL_debug_renderer_info, WEBGL_debug_shaders, WEBGL_lose_context

    After restart it starts working, but as soon as i change something in an event it crashes again...

    i was using beta version for the new "wait for previous" action , and now i am unable to work on my project. i am wondering, is there any way to revert my project back to r150 ?

    Or any way to fix this issue? or do i have to wait till the next release...