nerdError's Forum Posts

  • Thats insane, thank you! Wish there were some built-in tools like this

  • > XHXIAIEIN Tips like this are super valuable. I think people really need something like a Construct Cookbook or CheatSheet that shows the best practices for doing things the right way.

    Maybe this is something the community would be good at putting together rather than Scirra?

    Since the community are the ones trying to squeeze out the performance in real projects, whereas Scirra is just making the tool and is probably not use to the same challenges that we are use to facing.

    Yeah that's kinda the point also I wanted to mention is that Scirra perspective is probably pretty different, as creators of C3, from the people who are actually using C3 as a tool everyday in real life projects. And what I often felt while reading the forum is that Ashley just doesn't have a same perspective as people talking with him, and that's why there is often a lot of misunderstanding. And like, boths sides are right but in their respective realms

    And that's why maybe like you said there should be a community effort, but in cooperation with C3 devs, to make a, yeah, some kind of Cookbook with best practices and maybe additional insights on how things work internally from the devs that will help to actually understand stuff on a deeper level and use it more effectievly

    There was a similar thing my friend done (its in russian though), with some insights he managed to dig from a lot of testing and digging the internals. Though he made a ton of bug reports from it and a lot of things might be fixed/changed already, but you get the point

    We talked a lot about such stuff and yea, there is a lot of things. Yes, all this probably doesn't matter for most projects, but it does matter a lot for people who actually make something cool and big (not saying its me, but I've seen many other people like this). I think it very much worth it to consider them, because they are much more likely to make things that you will say "wow it was done in C3??? so cool!" about :)

  • > And in terms of documentation, i understand all the complications. My only wish is that internals of the C3 were explained better. Like how renderer works, how it optimizes things and such. Even just in broad terms. And even if some of it may become deprecated, it's still a hint and better than completely nothing

    >

    nerdError If you are looking for a renderer overview have you read this blog post yet?

    https://www.construct.net/en/blogs/ashleys-blog-2/construct-webgl-renderer-works-917

    Yeah, i know there are even more blogs that shed some light on rendering, and yes digging through them helped, but as Ashley said, info in them is often pretty old and either way its pretty fragmented and far from helping to get a full picture

  • I think this fair to bring up but not an overall fair example. For one, 9 Patch setting changes are brand new from about a month ago - If there's performance issues, report it, and if it's by design or impossible to resolve, often a documentation tweak occurs.

    Things I mentioned are there from creation of 9patch plugin, and it worked like this forever. So no it's not related to the recent updates and totally fair in my OP

  • Even taking your example with 9-patch: perhaps some settings mean it has to swap textures for each patch, versus rendering it all with the same texture. Changing texture may cause more draw operations (and may not, especially with WebGPU multitexturing). But so what? Going from 100 draw operations to 1000 might mean you are going from 0.5% utilisation to 5% utilisation of the overall system capability

    Sorry for being to aggressive. That's just all the hours i spent on this make me a little emotional.

    Those 1000 draw operations can really matter on low devices, especially mobile. I had both lowend mobile and laptop to test, and decreasing amount of draw operations from 1500+ to ~500 is exactly what made games hit comfortable fps on both of them, because of the GPU bottlenecks. And again, I wasn't building some crazy ambitions game, it was just a clicker game with somewhat good visuals. Construct 3 is mainly used now to make web+mobile games, and that's where low ends devices are the main target basically. So all this is pretty important for sure

    And in terms of documentation, i understand all the complications. My only wish is that internals of the C3 were explained better. Like how renderer works, how it optimizes things and such. Even just in broad terms. And even if some of it may become deprecated, it's still a hint and better than completely nothing

    Maybe all of this is obvious for people who work with graphics, but for people like me who don't, it's not. Again i was only able to kinda understand the basics only thanks to spending hours analyzing Spector.JS reports. And yes it made my projects much more performant

    Like for me even just looking at draw operations count helped a lot. It's worked out as much more reliable performance indicator than CPU usage (and especially non-existent GPU usage). Even though i understand it's not that simple, but it good enough.

    For me it would be already a epic upgrade to the debugger to have more information about the render process, memory usage and such things

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Even though I'm a big fan of C3, I really hate all the performance quirks it has. And you can mostly only find them by extensive testing and measurements (which with addition of all the random fluctuations and hardware dependency can be very time consuming and just lead to nothing). Well, also there is good amount of bugs too

    Ashely often says that people care too much about optimization and like "in 99% cases your game will perform great anyway, dont worry lol"

    But in C3 you can ruin optimization of the game with so many random small things, and it explained nowhere. Docs are really bad in that. There is so much hidden things that are never explained, and they matter like A LOT, both for how your game works and how it performs.

    Also events have so much overhead just by default. Only reason I was able to make my games perform good on mobile was using JS (because JS's "for..of" is literally 1000 + times faster than 'for each' in events, it's insane) and also using render debug tools like SpectorJS. Without that, it just a complete guess game and so many wasted hours

    For example, just changing 9patch settings "Edges" and "Fill" to "Tile" leads to CRAZY performance cost. With 100 9patch objects, the amount of draw operations increased from 23 to... 1213, that's a 5173% increase just from changing a few settings on the objects that doesn't seem like they matter at all. Is it mentioned anywhere? Of course not

  • Doing complex things with events can be very tedious and frustrating. Construct's "no errors" agenda can really hurt the debugging process, you need to place safety nets everywhere and it all becomes hard to read. Also events are generally slower than code, in some places MUCH slower. So I really recommend you to learn basic scripting stuff and use it where it makes sense, though PLEASE write code in TypeScript. Thank god Construct 3 now has built-in setup for it. Vanilla JavaScript is pretty dangerous to your mental health

    Also, test your game on low-end devices, the earlier you start the better. Just doing testing on your mobile is really good (even if the game is not meant to mobile).

    I agree that caring about performance too much is bad, and the main goal to actually make stuff first. But still, "don't care about performance lol" mindset can do bad things to you. You can ruin performance really fast if you don't know what are you doing. Especially since most popular usecase of C3 is making web+mobile games, and performance matters a lot there.

    C3 is pretty bad at debugging performance, and this topic deserves its own article, but you can get some basic ideas with googling and practicing yourself and it would already help a lot.

  • It is a really cool feature, I will definetly use it often! My layouts are biiig :D

    Though, I wish one could click on an object on the layout and in addition to "Find all references" option there will be "Show in the instance bar" one.

    It's nice to find objects trough the instance bar, but I wish it could be done the other way around too.

  • It's kinda funny that on almost every topic I read Ashley say "dont worry about performance. difference is not really noticable. 99.9% of projects doesnt need this" and so on. And then guess what? Peformance was literally the main problem i had with C3 through all those years. And i make pretty simple games! Some things in C3 cause absurdly bad performance and you will never read about that in docs, and the only way to figure out is to extensive testing and comparing different approaches. Without WebGL debugger and literal months of trial and error i would've never made my games playable on mobile or low end devices.

    In most cases i agree with Ashley, but...

    Ashley "dont worry about performance" Gullen

  • Is there a way to make sprite fonts sharper? No matter in which size or scaling i make them, they always look so blurry compared to default Text

  • Use Text.TextWidth and Text.TextHeight expressions.

    Hm, for some reason i remember that they didn't do what i wanted, but maybe i just used them wrong. Thanks for the suggestion!

  • I want to measure actual text size (not the Text object size)

    So, i want to get this (bounding box or something like this)

    Or maybe at least get a width/heigth of some text in specific font and size.

    I know about measureText js function, but it doesn't seem to help much, but maybe I just used it wrong

    Tagged:

  • After a bit more testing and observation today, I'm almost certain that it's tied to autosave.

    As soon as my project autosaves, I can expect a long manual save straight after, no matter what (while using project folders). Meanwhile, disabling autosave results in no longer getting a long save time intermittently.

    Interesting guess, i will check it later! But yea, for me it definetly not the project files size, and also it's not tied to actions i make, it's just seems random to me, so it easily can be related to autosaves

    UPD: oh, i saw Ashley answer on GitHub, seems like you were right! Im so happy this problem will be fixed, I was struggling with it for a year at least now!

  • Are you saving to a c3p file or a folder?

    I noticed that oddly enough saving to a single c3p file is much faster than saving to a folder.

    That was about a couple of years ago, I didn't try using folders again since then though.

    Yeah, I'm saving to a folder, because editing scripts outside of C3 won't work otherwise

  • Check the number of files in Images and other folders.

    Each animation frame is saved as a separate file. And if there are many thousands of them, the project will take a long time to load and save.

    Well, yeah, I have 1200 images in the folder, but they all have a total size of 700 kb. I mean, it's just nothing. It should take a less than a second to process them all, computers are fast enough nowdays. And, anyway, what can I do about that? C3 doesn't allow me to handle sprites in any other way

    And yeah, I think saving each animation frame to a separate file is a bad idea, just because of how Windows works, as I know, and again, can't do anything about that.