alastair's Forum Posts

  • Yeah it's a quality of life improvement for sure! Especially if you use C3 every day. And it remembers my settings with a single screen, so I don't have to rearrange popups or window widths every time.

    Ultra wide is great.

    In regards to 4k, its basically the same as ultra wide, you just get a bit more height if you need it. But 4k monitors only go up to like 32", so you have to change window's scaling settings for comfortable use, which effectively lowers their resolution. Whereas with ultrawide you can keep it at native scaling as they can go larger than 32". Though I did use a 43" 4k TV for a while which was big enough to allow for native scaling, and that was a good for a while, but I've switched back to the 32" 4k finding that the smaller screen is a little more comfortable physically.

  • Thanks, great post!

    I use a billion timers throughout my events, they're so efficiently convenient!

    Sounds like it's better to let them go and to just use the old fashioned DT event method, I need all the performance I can get.

  • Here is an example of what I can see using C3 on an ultrawide:

    i.imgur.com/UBWr2kW.png

    i.imgur.com/L5vTHsv.png

    (cropped out my taskbar)

    It does not remember where popup windows are positioned unfortunately, and doesn't remember that they are popped out, so you just popout and position every time you use C3.

    Ah ok so that's not fixed yet. I think that was partly why I just went with ultrawide and 4k for my setups.

  • With 2 monitors, and you open and close C3, does it remember the positioning of everything across the 2 monitors?

    I think the minimum you'd want to use with C3 is probably 1440p.

    I've used regular full HD, ultra wide, and 4k.

    But I find that vertical space is the best aspect, so I prefer 4k as my main dev screen. Being able to see more events vertically + more things in object's property window is fantastic.

  • Whenever I see negative comments about C3 (mostly from users of it), it dumbfounds me.

    We love Construct 3 too!

    But sometimes people want to see it improve to become even better!

    Due to humans being emotional beings, this desire to see changes can lead to anger or frustration (negativity).

    Hope that helps your understanding!

  • Ashley says that saving to the game's directory is not good practice because of permissions issues.

    Therefore, I do what normal games do and save to user's documents folder.

    Yeah I just use the "write text" action too for saving files.

  • nwjs 71 is still the best one to use unfortunately. The linux export is still broken on all versions after that.

  • For my game, if they're on Windows, I make a folder with my game's name and put it in their user's documents folder. Then I save in that folder.

    I think most games seem to save in the player's documents folder.

    I use the NWJS extension to do this.

    I'm guessing Steam cloud could then use that save folder to keep synced?

  • I get this bug too! Do you know how it happens for you?

    For me it happens after previewing my game while it's fullscreen. My work around is to press Esc before closing preview, so that it's windowed.

    You can see my bug report here, but its claimed to be out of their control: github.com/Scirra/Construct-bugs/issues/7097

  • Thanks. If a device doesn't work with WebGPU will it automatically switch back to WebGL?

  • You do not have permission to view this post

  • Construct is basically the evolution of Clickteam's products. Clickteam, instead of making Fusion 3 after Multimedia Fusion 2, decided to spend over a decade focusing almost entirely on exporters to various devices, which meant the editor itself received minimal updates over the years.

    While Ashley took the opposite approach, ignore exporters, and focused primarily on evolving the editor/software of Fusion 2. And we've seen the fruits of that, countless updates and improvements!

    The fantasy dream would be if Ashley and Clickteam could harmonize their differences, and work together! Then we could have a great editor + exporters all in one.

  • You do not have permission to view this post

  • Thanks for explaining R0j0, I think I was also mixing up triggers and functions.

  • construct.net/en/make-games/manuals/construct-3/project-primitives/events/functions

    It seems like experienced users use functions more than others, and that it's a preferable to use them as often as you can.

    However, it's not super clear to me how functions function.

    How are triggers checked?

    construct.net/en/make-games/manuals/construct-3/project-primitives/events/how-events-work

    Rather than running once per tick, this event simply runs (or "fires") upon something actually happening. In this case, the event runs when the user hits the Spacebar key on the keyboard. It is never checked any other time.

    How can that work?

    How can it just miraculously know to run the trigger when that the button is pressed?

    Why doesn't the computer need to check every tick to see if that button is being pressed?

    Why aren't all triggers checked to see if they're true every tick?

    For me, functions feel magical and mysterious compared to regular events, where we know they run from top to bottom, being checked in a logical way.

    Does this mean triggers are always better for performance because they're not always being checked like regular events are?

    If you have hundreds of triggers from objects that are currently all destroyed, does that mean that these events/triggers effectively don't exist, they're never checked?

    For example, the trigger "On Collision", wouldn't you need to check that just as often as "Is overlapping"?

    And with ones like "On animation finished", wouldn't the engine need to keep checking to see what the animation is up to?

    Thank you for clarifying!