simstratic's Forum Posts

  • Do you mean the view is like a FPS, where the crossbow stays in the middle of the screen, like the game DOOM? If so, you could rotate the objects around the crossbow. You could use the orbit behavior on the other objects. Or you could create an invisible sprite at the same position as the crossbow, and pin the objects to the invisible sprite, and apply the rotation to the invisible sprite.

  • A large layout should be ok...

    Are you able to share your project?

  • How about a tiled background, 9-patch, or drawing canvas set to a large size? What size is your layout? And the size of your viewport (in Project - Properties)?

  • Are you using a really large sprite somewhere? In Project -> Properties -> Advanced - what is your 'max sprite sheet size'? Maybe you have a sprite larger than this?

  • Jase00 For the record, I regret my last post. I should have just said 'hey some of the layout data is in his screenshot' and left it at that. But sometimes I get carried away, which I did in this case, and I apologize to the Construct team for it.

    AFTER I made that post I found Construct already catches that error, that's why instead of blowing up, it shows the screen including "oops there was an error try ... clear your browser cache", which does indeed solve the problem. In other words - what I suggested - they are already doing that.

    If it's related, and I stress IF, it probably gets them no closer to the root cause anyway (why is the size being saved as 0 in the first place) and that's when it all becomes speculation. Right now off the top of my head I could throw in a dozen different theories based on my experience elsewhere. These theories have nothing to do with Construct itself, and could be practically impossible for Construct to replicate, even with a huge commitment of time.

  • You reminded me of a game I played a long time ago, Arcanum: Of Steamworks and Magick Obscura, you could walk for hours, but unfortunately there wasn't much to see :)

    Well, no engine offers that functionality 'out of the box', so it would mostly be custom code, and in that case Construct should be as good as any other engine.

    You probably wouldn't edit a map that large by hand or your grandchildren might still be trying to finish it. So you probably want to read about procedural generation to generate large areas of the map. Then you would break those up into smaller areas and edit those by hand to create towns etc. that need more of an artistic touch.

    You have the right idea about in the game - only loading what is in the view (and usually a buffer area around the view). So you probably want to read about using 'chunks' for an open world game. Basically you take your world and cut it up into smaller squares - and you store that data on disk - and load/delete the objects from the smaller squares as your player moves around the world.

    If you are only walking in one direction, like walking forward but with some shifting left/right like an endless runner, then it's much easier.

  • It would be very useful to get a copy of the data that is causing problems

    DiegoM I think you can see this is his screenshot - cropped below - has most of the layout data:

    Looks the 'middle' has a frame height and width = 0, and size = 0. 'layersBar' which is docked at the bottom of 'middle' has a size = 'infinitypx' ('middle' height causing a divide by zero error?).

    Maybe you could catch size=0 or infinity when loading the layout, and reset to default in that case.

  • dupuqub Can you please try this. Open Construct, click Menu -> View -> Storage cleanup and post a screenshot of that here.

  • So I realized today, I can test this in Construct 3 by with running the Construct 2 runtime, and with the C2 runtime I am definitely still seeing an increase in GPU% (both in the debug preview window and the Windows task manager). And this isn't a really low end GPU either (Radeon RX 570). In Construct 3, there's an option with the C2 runtime for WebGL, if I turn that off, then I don't get any GPU usage (but I get higher CPU usage as it's software rendering). This makes me think you're not using WebGL in your project?

    I know which thread you're talking about (Chrome vs APK), and there was some fear mongering going on there. In the vast majority of cases, the performance should be very similar - there are these rare cases where it seems like WebGL is being disabled in the APK on a specific phone or GPU driver - the Chromium team is continuing to investigate. Honestly I wouldn't worry about it, but it's still good practice to test with an APK export occasionally.

  • I think you may be running out of space in the browser's storage cache... there is a limit on how much a domain (in this case construct.net) can store in the cache. How much free space do you have on your C:\ drive? Do you use the beta versions of Construct?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think it's because you can enable and disable groups during gameplay. So the group is essentially an IF condition, for example, IF Fantasma = true (enabled), then run the code inside the Fantasma group. Why would you want to take that away?

  • Nice work finding the cause and fixing it. Please still report it so they remember to fix the bug :)

  • So you got me curious and I did some testing today - and yeh - effects (HSL, B&W, probably others) seem to have a huge overhead on 9-Patches compared to sprites. Sprites I hit the CPU limit with lots of juice left in the GPU, but 9-Patches maxed out my GPU much sooner. I'm not sure why - every time I thought I had a theory, my testing didn't back it, so I'm afraid I'm no closer to unravelling the mysteries of the effects compositor for you.

    I should mention this is Construct 3. I don't know if you see the same in Construct 2, so it might be worth checking? If you create a layout with 20 sprites with an effect, and another layout with 20 9-Patches with same effect, do you see a big difference in GPU% when running the layouts? (BTW you have to force a screen redraw - so give the sprites and 9-Patches sine behavior or something to make them move)

    To answer your other question, when you can't test on a phone, a computer with integrated graphics will perform more similarly to a phone, they tend to have the same problems with fill rate, overdraw etc. Testing GPU% is tricky too, it can look really high when you first add a lot of objects/effects/etc., but leave it running for 5 minutes and it can drop significantly. I think when the GPU gets lots of new work it 'panics' and draws a lot of power to make sure the framerate doesn't drop, then it gradually winds down it's power until it is just maintaining the desired framerate.

    Finally a word of caution about the RAM, yes there's more of it, but there's probably more background applications fighting over it, whereas the GPU should be almost fully dedicated to the game. Test on a phone while developing if you can - I tend to do a build when I'm heading to bed and test it in the morning - because performance can be very different.

  • Is that first one "collision cells"? If so then it may not be checked in all circumstances.

    Yes I believe so, having read through how they work, collision cells is more user friendly name for spatial hashing, with some added optimization for handling moving vs non-moving objects.

  • Thanks for the correction and the information R0J0hound. I jumped in too early with some bad assumptions :) Didn't know we could look at the engine code in that much detail...