Nepeo's Forum Posts

  • I'm going to be honest here GeorgeZaharia I know relatively little about Physics engines, they are pretty complex and I've never had to do anything complicated with one. We're embedding a port of Box2D here so my best guess is that your just looking at the properties that Box2D exposes. Ashley will know more, as he wrote the wrapper code for the behaviour, but his answer is probably the same.

    I imagine the reason why you can't see the module in the construct 3 version is that we've swapped from using a JS based port to one done in WASM which is a binary bytecode format. Chrome should still show you a human readable format for the module, but you won't be able to breakpoint it and it will appear as a relatively complex language.

  • I'm not sure why it's being rotated, but if you check the properties of the spawned block objects in the debugger they are at a 90 degree angle. I discovered this when I decreased the collision box considerably, which caused a lot of overlap in stack blocks. So I fudged it by changing the collision rectangle to 0.1 - 31.9 in both dimensions instead of just X, which fixed the issue.

    It makes more sense to fix the rotation though, as you'll end up with you texture the wrong way round.

    You may want to try disabling the bullet behaviour ( perf boost ) and clamping the object position to the grid ( prevent visible block height variation ) when the collision happens.

  • I had a look at your project, the falling blocks have been rotated by 90 degrees. So the small gap you've given for collisions is actually on the top and bottom.

  • andrewrutter there is a desktop beta version available on the forums that allows for saving projects as a folder of files instead of a single file. Some users using this with version control tools like git and SVN. In terms of versioning this obviously works fairly well, but some project level changes can touch on a lot of files, and merging such changes could cause conflicts. I haven't tried using this myself to comment on how much of an issue it is.

    This idea has previously been suggested here, and we have given an official response.

  • By the looks of your collision rectangle you probably understand this but I will explain why grid aligned games can be awkward

    In a typical collision engine 2 objects touching counts as a collision, even if it's a rare occurrence that should be the case.

    Most movement behaviours work along the lines of "If I move here will I be colliding? No, okay then move me there. Otherwise, I'll stay here". So when you have two objects moving exactly next to each other ( such as in grid aligned games ) it will appear to the object that it's path is obstructed, even though their overlap is technically 0 they are still touching each other.

    Some things you might want to check are:

    - your blocks are positioned at integer spacing

    - your blocks have an integer size

    - your blocks are not rotated

    - your collision rect is slightly smaller than the block

    - the size of the texture for your block sprite is the same as your instances ( prevents resizing of your collision rect )

  • Depending on how much JS manipulation you need you have 3 options. The first is to use the inbuilt "Browser" plugin, which has a couple of options for evaluating JS. So in this situation you could use the expression Browser.ExecJS("window.testMessage") to get the value.

    If you need to do more then the 3rd party JavaScript plugin is quite popular for this sort of thing. It offers methods for calling JS functions and getting the return value, which is generally safer and faster than executing an arbitrary string like I showed above.

    The final option is to write a small plugin using the SDK, this is an advanced use case but might fulfil a few more complex situations that you want. SDK manual

  • — it looks like we haven't exposed all the required parts to the public API interface, I will look at getting it added soon for you.

  • TheScythe I wouldn't exactly encourage editing the version, as you may corrupt your project ( so always keep a back up ).

    C3P files are basically zip files, with predefined internal layout. What you see with folder projects is that internal layout. I'm not sure which format your using, but the process is much the same.

    If your using a C3P then I would advise opening it ( not unzipping ) with some variety of archive tool like 7 zip, you can edit the files within the zip file without you needing to unzip it like this.

    You want to edit the project.c3proj file ( it's in the JSON format ), each addon will include it's own version number in the style "r137" which you will want to change. Additionally there is a project version in the format "13700". If you want to move to a point release then the values will look a little different, you should try looking at a project saved with the version you want to target if that's the case.

    I believe the issue is graphics driver problems when using webgl2 ( these generally don't produce any actual errors, just rendering problems like blank screens ). We have a device in the office that had the issues previously. If you are happy to share the project ( not an APK ) privately I can test it for you on that device and we can see about resolving it before the next stable release. You can contact me privately at iainkuc@scirra.com

  • It's already supported, although it's probably not made it as far as the documentation. You can bind a construct plugin property to a cordova dependency variable. When the user exports the property value is automatically added to the config.xml as the variable. Let me go check out what we say in the docs.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It sounds like a return of an old Android bug, it would be appreciated if you could file a new issue for us to investigate.

    To go to the current stable just visit https://editor.construct.net, it always points to the latest stable ( not beta ). You can choose a specific release on the releases page it will tell you to update, but you can ignore this.

    Projects saved with a newer version won't open in an older version, this is for compatibility safety. In most cases the project can be safely modified to open in an older version.

  • Go to your application(Android version) on the AdMob website, select "app settings" from the menu. You will see a label "App ID", it will look like "ca-app-pub-0000000000000000~0000000000" that is the ID you want.

  • igalencar use the debugger and inspect the instances

  • Ashley

    Hmm... maybe GC heuristics work differently in a worker?

    I expect the scheduler to behave differently at least, so yeah GC timing is probably different as well. I'm not sure what the threading behaviour of Orinoco is when your in a worker, so that could effect how long GC takes compared to main thread as well. JS execution time definitely seems to be different.

    It's hard to keep track of heap size and frame rate in dev tools when using worker mode because it tracks the main thread.

  • SnipG

    Not related but.

    What Nepeo said

    "VERY high spikes when you cross a loading threshold"

    This is pretty awful, sometime it feels like there is small spike(1-2 tick) but it somehow overflows into ~0.2sec. Not sure what causes it.

    Yeah as I said it's just kind of how that game works, I based the logic on a similar project I've been working on in my spare time (Voxelcraft) which has a similar issue. Ideally the work would be broken up or done on a different thread so as to not hinder the framerate.

    On the procedural terrain demo when you cross a loading threshold it has to:

    - break the tilemap up into "chunks"

    - serialise each chunk, and store it in the dictionary

    - update the world position

    - for each chunk either generate world data or deserialise from the dictionary and place the data in the tiles

    So there is an awful lot of looping, serialisation, deserialisation, noise generation and tile updates. All of that has to somehow happen during a frame, and it normally does! Performance can be tweaked by changing the size of chunks and blocks, to reduce the number of loops and iterations ( loops cost more than iterations ). Also persistence can be ditched to remove the need to serialise the world. One idea I did toy with is to use multiple tilemaps and move them around, it's more complicated but would reduce the amount of work significantly.

  • Measuring the performance difference is difficult, the most obvious way is the CPU Profiler in debug mode. But that doesn't really tell the whole story. For instance, the CPU profiler isn't good at showing spikes ( which cause missed frames and jank ), as it shows live performance if you have heavy usage for a frame or 2 you are unlikely to see an accurate representation of that.

    While working on the procedural terrain demo I spent quite a while looking at performance to make sure that it ran smoothly. Due to the way the game works it generally has quite a low CPU level, but has VERY high spikes when you cross a loading threshold ( which is quite often ). These spikes would often cause dropped frames, which is unpleasant while moving around. To test what was causing them I mostly used performance recordings from chrome dev tools, as you can see frame times and CPU usage flame graphs for the duration of the recording. I tried testing worker mode to see if it made a difference. However, due to the way OffscreenCanvas works Chromes framerate is technically 0 when your using worker mode... So it's difficult to even tell if your dropping frames! You can however check how much frametime you used, which is fairly close.

    Performance with worker mode is... different, before xmas I was seeing a notable performance improvement with the procedural generation demo, but now I'm seeing a fairly large drop. This may partly be due to changes I made since then ( reducing loop iterations mostly ) but it may also be changes by the Chrome team. It's hard to tell. It's biggest win is that if your game is using significant CPU time it won't slow down whatever work the main thread is doing ( DOM elements, mouse movement, scrolling, audio ) and vice versa.