simstratic's Forum Posts

  • why not hide 9-patch objects from the "Paste Object" list?

    Sorry but I have to disagree with this. Your use case is very specific. The issue only applies to 9-patch objects and effects applied and with a canvas offset from the viewport. And you are only doing it because you don't want to apply the effects each frame to eek out extra performance in a project where most game objects are 9-patch. You would want to disable 9-patch object pasting entirely because of that, when it still works for the other 99% of use cases that other people have?

    I haven't seen your project or any screenshots, so I can only guess that it is a GUI heavy project? Have you benchmarked the difference with just applying the effects? Because the effects you mention in your issue, black and white, HSL - they are the lightest effects for a GPU to run - the performance impact should be minimal.

    Otherwise take the old school approach we used before shaders (effects) - pre-render the black and white, faded versions etc., and swap the object or just switch their visibility on/off.

  • Sorry event sheet was supposed to be attached:

  • Sorry my other reply was probably long and confusing.

    You could use the IID as the number for the Tile parameter. The problem is you have too many Tilemaps (128) compared to how many tiles are in your image (64). So you can reduce the number of Tilemaps to 64 and it should work.

    If you need 128 Tilemap objects, then you can scale the IID (divide by 2), so IID will fit the same range of how many tiles you have. See below for what I mean (note: I made some other changes to make it more optimized):

  • Oh sorry I don't want to give that impression, I don't know anything about the inner workings other than what is out there in the manual and Ashley's blogs, but part of it is just based on observation combined with experience with other engines, I guess you start to learn how to identify how things are probably implemented on the engine side. But I should make it clear, what I wrote above is just an educated guess, that why I'm still submitting it as an issue.

  • EDIT_2: THIS IS NOT CORRECT FOR CONSTRUCT - PLEASE SEE POST BELOW MINE. (2) is probably still applicable.

    dop2000 that is all a good sign that it is heavily optimized. There are two factors at play in your last example.

    (1) Polygon collisions are done by triangulating the polygon into a series of triangles (this may already be done when the project is exported). During a collision, each triangle is checked to see if it colliding with the triangles in the other object. As soon as a triangle collision is detected it can stop, i.e. it doesn't need to check all the triangles unless there is bounding box collision but NOT a polygon collision. There are different triangulation algorithms, some of which can favor large triangles which will be more likely to collide early. Spiky and concave objects will generally require smaller triangles.

    (2) The pink background almost shows what the bounding box would be (the one on the right would be a little smaller). The one on the left, the collision polygon occupies a much larger percentage of the bounding box, if the bounding boxes collide it is far more likely the polygons will be colliding, and an early collision will be probably detected and less triangles will be tested. Inversely, the one on the right occupies a smaller percentage of the bounding box, so you will get more cases where the bounding boxes collide, but the polygons do NOT collide, so it will have to check every triangle like I said in (1).

    The extreme case would be something like a very thin '+ or 'L' or '/' shape collision polygon that extends the entire height and width of the sprite. Because you would get many bounding box collisions, but less polygon collisions, so more triangles (points) would be checked.

    EDIT: One thing I forgot to mention, is long skinny objects (like a stick), when they are rotated in the game, will have larger bounding boxes, and hence more 'false positive' collisions where every triangle needs to be checked. So for these type of objects you want to minimize your points. All the above assumes a axis aligned bounding box collision optimization is being used in the engine.

  • I must have been dreaming about this - because I woke up and realized what you mean by the 'bug', i.e. the sprite being displayed in the tilemap. Let me try to explain what's happening. To improve performance - specifically batching to reduce draw calls - sprites, tilemap images etc. are combined into a spritesheet. Let's take a look at your project's spritesheet:

    There you see your tilemap image and sprite together in the spritesheet. Your tilemap image has 64 individual tiles, with tile number 0 at the top through to tile number 63 at the bottom.

    In the action Tilemap -> Set tile, the parameter 'Tile' is expecting a tile number, i.e. something between 0 and 62. But you are not giving it a tile number, you are giving it the Tilemap instance ID (self.IID). Each time you create your Tilemap object, it is creating an 'instance' of that object, and it is given an instance ID, the first Tilemap IID = 0, the second Tilemap IID = 1, the third Tilemap IID =3 and so on.

    At the start of your layout you are creating 128 Tilemap instances, so Tilemap IID will range from 0 to 127. So what happens when you reach tile IID = 64 and use this as the Tile (number) parameter in the 'Set tile' action? There is no tile number 64 in your tilemap image, but Construct doesn't seem to check that, and keeps pulling data from the spritesheet, assuming there is another tile there. Eventually your Tilemap IID and hence Tile parameter is so that large that it reaches the Sprite image in your spritesheet, and starts putting that data into your Tilemap.

    For those who are really interested and want to keep reading - would I call this a bug? Probably not. I would call it an 'unintended use case'. What's the difference? A bug is when your code is correct but the result is wrong. An unintended use case is when your code is wrong, but the engine still lets you do it anyway, and gives a strange result.

    I have reproduced it in a minimal project and will report it anyway just so they are aware. It will be up to the Construct team if they decide to 'fix' it.

    Because I think this might be interesting topic for some people - why might they decide NOT to fix an unintended use case?

    Assuming my theory is correct, the problem could probably be fixed by 'bounds checking' the Tile parameter in the Set tile action. It would do something like:

    if tile number > max tile number { tile number = max tile number}

    This would stop it from moving out of the tilemap image into the rest of the spritesheet. They might decide to do a fix like this to stop people from making the same mistake.

    But why might they NOT do a fix like this? Because it might have a negative performance impact on people who are using the Set tile action correctly. The bounds check adds an additional calculation that has to be done every time Set tile is used. For people who are for example, doing procedural generation on a tilemap, or using a chunk system to stream data into a tilemap for a large open world game, this could reduce their performance.

  • PS I meant to ask - do you have a picture of the effect you were trying to create?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Just an educated guess, but the engine probably does a bounding box collision test first, basically a rectangle that contains the entire object, and checks that against the bounding boxes of other objects. This is very fast to compute. If the bounding boxes don't collide, then there is no way the polygons collide, so no more computation needed. If the bounding boxes do collide, then then engine will then check to see if the more complex polygons collide.

  • indy2005

    There might be a way for you troubleshoot this while you are waiting for the Chromium team. They are talking about exposing a developer option in WebView which will tell you if it's actually using WebGL. But there might be another way to test this:

    - On the Google Play Store, download an app called WebView Test (developer is SNC Soft).

    - Open the app and press the globe icon in the top right corner. This lets you enter a web address.

    - Type in the address get.webgl.org (no www) and press GO. Once the page is loaded do you see a spinning cube?

    - Press globe icon again and type in the address webglreport.com (no www) and press GO. Once the page is loaded check both tabs for WebGL1 and WebGL2. Are they both green with the message "This browser supports WebGL(1 or 2)"?

    - Click the app icon in the top left corner, click WebView Info, screen grab and post here.

    - You should be able to test your own game inside the Webview Test app. From Construct on your computer, start a Remote Preview. Get that address and enter it in the Webview Test app. Does the game run the same as your APK?

  • Not a bug. You are just telling it to do weird things and it is doing it for you :) You have created some art with Construct.

  • To further clarify, Construct produces what would be called a hybrid app.

  • If they are specifically asking for a native app (compiled into machine code), then no, Construct will not give them what they want. Construct apps use JavaScript, for mobile they are put in a wrapper like Cordova, which gives it access to some native functions on phones, but it will not be a native app.

  • You are tagging a 2018 article. Currently it is in 3.2 stable and in future it will move to Vulcan based. Still today they are facing many issues related to 3d part but they "have" options of figuring out the issue . But does construct 3 have any options rather than requesting 3rd parties for solving issues? That is where native vs wrap comes into play

    It is a 2018 article but it is still relevant. 3.2 stable is the version of the engine, not the version of OpenGL ES, which is GLES2 after dropping GLES3 because of the driver situation. There's not more Godot can do about a buggy GPU driver than we can - report it to the appropriate third party.

  • It really upset me today. Initially I thought that it was due to mobile cornering,but now many are raising issues related to performance. I have invested a good amount of hard work on construct 3 and ....

    don't get upset, keep working hard and make the game you want to make. Chances are your game will run just fine.

    I'm new around here, I have only been subscribed to Construct 3 for a month, I have used many engines over the years, starting around 20 years ago with GameMaker, my point being I'm not a Construct 'fanboy' and I'm honestly trying to tell you about my experiences.

    I touched on this in my last post when I talked about Godot. But let me stress it again to try and comfort you. Every single engine will encounter some hardware, or operating system, or driver bug - something - that will affect performance for a small percentage of your players. Go into any of their forums and search "android performance" and you will find issues.

    Sometimes it's an issue we the game developer can fix, sometimes it's an issue the engine developer can fix, and sometimes there's nothing we can do about it but report it to the third party (like a GPU manufacturer) and hope they fix it. This even happens to the large companies making AAA games, but they have more 'political' power to get these third party issues fixed more quickly.

    Let me give another example. GameMaker uses an old version of OpenGL so probably there are less driver bugs. However it uses a fixed time step, i.e. it doesn't use delta time. So many people will make their game to run at a fixed 60FPS. They publish the game, and it all seems ok, but then a user comes along with an Android phone that runs at 45Hz or 50Hz refresh rate. Suddenly the game runs in slow motion, frame timing is messed up, frames are skipped, to put it simply, performance turns ugly. The solution, rewrite EVERYTHING to use delta time, including much of GameMaker's inbuilt functionality. Again, this isn't to insult GameMaker, it's one of my favorite engines, it's just to illustrate they all have issues in certain circumstances.

    So take a breath, finish your game, and always include testing on real devices while developing (this also applies to any engine).

  • I look at the phone in this case, Doogee N20, it was released in Oct 2019, I checked the ARM (Mali) database and it using a driver (r14) from Jul 2018 - so that driver was already a year and half old before the phone was released. There have since been 12 driver updates but they haven't been pushed out to the phone. And to me this is the big problem on Android. First you have buggy opengl drivers, and even if they fix the drivers, the phone vendors aren't pushing the updated drivers to their phones. Google knows this is a big problem, that's why there's this new initiative to push new graphics drivers out through the Play Store (so they will be independent from OTA system updates) see for example: xda-developers.com/arms-next-mali-gpu-updateable-drivers-google-play-store

    As for webview games, I think a small part of the problem is Chromium's approach of driver workarounds, and in worse cases, blocklist the GPU. I understand why they do it, but this is hiding the problem from the end user. Can you imagine if Microsoft did this on Windows? Oh, this game is crashing a lot using an AMD GPU, so we will just disable the GPU - there would be a riot. They don't do that, they leave it up to Nvidia and AMD to fix their driver issues, which they do - because if one vendor constantly put out slow or buggy drivers, PC gamers will rip out the GPU and put in the competitors instead. Unfortunately that can't be done a phone. And not many people when buying a phone think "ooh this has a Tegra GPU - their drivers are much better - so I'll buy this one". This all takes the pressure off the mobile manufacturers to deal with the problem that they should be responsible for fixing.

    As silly as this sounds, imagine if Fortnite or Candy Crush ran inside a webview. I imagine these issues would be dealt with really quickly - because a company with enough bite like Samsung - would go to ARM and tell them to fix it if thousands of players started complaining about their phones performance.

    And this issue is definitely not only webview games. Godot engine has been mentioned in this thread - for those who are not familiar - Godot compiles to native code - webview is not involved at all. When Godot 3 was released, they had developed a whole new renderer based on OpenGL ES 3 (which WebGL 2 is also based on), but when people started moving their projects to Godot 3, many experienced slow performance and hard crashes on Android. The source of most of these problems: buggy GPU drivers. And what happened? They basically threw the new renderer in the bin and went back to the old OpenGL ES 2 renderer. Source: godotengine.org/article/abandoning-gles3-vulkan-and-gles2

    That's not to bad mouth Godot, it is a good engine, but every engine I have used has issues, some of which are out of their control.

    The good news, if you read the Godot blog, at that time 36% of Android devices didn't support OpenGL ES 3 (Feb 2018). As of today, that number is down to 12%. So things are improving.

    But ultimately I think it is up to Google to pressure the phone and chip manufacturers to fix these issues, and get those fixes out to the users. GPU driver updates via the Play Store is a good sign they are doing this. That's why submitting issues like this to Chromium is good - the pressure will start to flow uphill.