digitalsoapbox's Forum Posts

  • >

    > > Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

    > >

    >

    > Yikes. That is no good. Load order shouldn't affect behaviors like that.

    >

    > Ashley, have you had a chance to look at this yet?

    >

    The behaviors need to be updated in some arbitrary order. Construct 2 tries to hide some of this from users, but since it can't automatically figure out what your intended behavior is, you will inevitably have to deal with it at some point. At least like this, you have some level of control over it.

    This is why I prefer to use events whenever I can, since I have complete control over the order those run in. Behaviors could have this same level of control too, IF they provided the option of disabling their javascript tick functions and using an action to trigger them instead.

    I didn't mean "behaviors" in the sense of C2 Behaviors. I meant functionality (through events) shouldn't be affected by what folder something is in. Poor word choice on my part.

  • Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

    Yikes. That is no good. Load order shouldn't affect behaviors like that.

    Ashley, have you had a chance to look at this yet?

  • Ashley this is a bit of a big issue.

  • I can reproduce this as well. Could it be related to the fact that C2 editor works faster when you have your object in the subfolder?

    I don't know why that would change runtime behaviors.

  • Tested, can also reproduce. This would explain a number of weird bugs I ran into with Sombrero.

  • Well, I guess this post is gonna keep popping up so I'll respond:

    Chances are this won't be released, and if it is, it won't be any time soon. There's some annoying limitations with how it had to be handled because of how C2 works. And with C3 not yet supporting rendering plugins, and an already-announced runtime rewrite, it's not really worth the time or effort to push towards something that would be usable by others without my having to provide a lot of tech support, which I'm not interested in doing.

    If you want to achieve the kind of effect I've created here, your best bet in terms of accomplishing it quickly and easily is to use Unity, which unlike Construct has lighting features that aren't terrible and are geared towards actual use in games right out of the box, as well as the required texture rendering features that in Construct depend on 3rd-party plugins, despite it being a very useful feature to accomplish all kinds of visual effects in just about every other popular game engine.

  • The Chrome Dev Tools device tab should do exactly what you are asking for. Is it missing something? Asking us to reimplement an existing Chrome feature just seems like a waste of time. The dev tools device mode allows you to pick from a set of common device screen sizes, and also includes device pixel ratio emulation, touch input emulation, and other non-obvious features. There's a lot more to it than setting the viewport size. We may as well just use what already exists.

    Yes, I understand those other features also exist in Chrome Dev Tools, but for quick testing iterations the additional features are not especially necessary, and mouse can already be used (at least in C2, I haven't tried in C3) to test touch input. That's why the request covers only resolution/aspect ratio, which is enough to test most things when previewing on desktop, which is exactly what Unity (and other tools) provides in its preview options.

  • I Have this great idea of a 2d game. Although, im going solo on this project. I knew that C2 would be good for making a 2d game but not for 3d. Anyway, I just need to make sure if this engine has good performance or not? if so, i can publish to mobile devices using this engine

    C2 performance, especially on mobile, can be a bit flaky. If you're not doing anything complex, you'll probably be okay.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You should now be able to do that by changing the preview mode to "browser tab" in settings and using Chrome Dev Tools device mode.

    No, this is still not at all what I'm talking about.

    First, browser tab preview defaults to whatever the browser size is, and does not set it to a specific size. If I set the size manually, that also changes the size of the C3 editor the browser (same browser window, different tab). I suppose I could pull the browser tab off into its own window, but this is still far from ideal for preview OR debugging.

    Second, the request involves including a way to set a size to preview at that is separate from the Viewport size, while still allowing preview in a window without being surrounded by unnecessary browser components (in C3 terms, Popup style).

    I think the screenshots above make it obvious that what I've requested and what is currently available are not the same thing. Yes, I understand we can use built-in Chrome tools for this, but then we're back to depending on third-party features again instead of C3 handling it directly, which is better from a usability perspective. I'm a little confused on how I could be any more clear, so I suggest launching Unity - or just about any other well-known game engine other than Construct, but it's easiest to access in Unity - and view how it handles allowing developers to define preview window size very easily.

  • Collision tags with box2d asm.js would be killer.

    +100000000 for this.

  • If Nintendo sees it, they'll send you a Cease & Desist. They don't allow people to use their assets, or use their IPs in non-sanctioned projects, whether or not they're free.

  • Ashley

    But report filed here - it's pretty obvious something isn't working quite as planned, on standard DPI or high DPI displays: https://github.com/Scirra/Construct-3-bugs/issues/112

    And to return to the OP, being able to set custom preview sizes to allow easier testing of different resolutions & aspect ratios on desktop continues to be a thing that would be very, very useful. Either for desktop or mobile builds, dealing with these issues is a daily task, and right now it's the opposite of a streamlined, user-friendly process in C2 or C3.

    In Unity:

    This feature could slot into the C3 Project Properties pane pretty easily:

  • The scale, rotate and actual rendering work done by the shader is all done on the GPU so that aspect ought to be identical across all browsers (and even native engines).

    However rendering shader effects does involve quite a lot of complex rendering calls, so there is a significant CPU aspect to that, and that's what looks like has significantly improved in the latest Edge. I'd suggest focusing any measurements on the CPU side.

    To be more clear, it's not the shader doing rotation/scale - it's rotation/scale of the objects using events & actions. The only shader in use on the objects dragging performance down in my example is the Tint shader included with C2.

    So far I've tested on a higher-end Xeon, a top of the line SP4 and mid-range Surface Book (with Nvidia keyboard GPU). If I remove the Tint shader, the fps issues go away, Intel or Nvidia GPU, and if I turn off scaling/rotation of objects but leave the Tint shader on, no fps issues occur. I'm seeing more CPU usage in Edge 15 and it's not really thrashing the GPU as the recent, previous updates were. It's pretty strange behavior tbh, and seems to be an issue with Edge that I didn't run into at all last year, so I think something changed on their end. I'll poke my MS contacts to see if I can get any more info from them.

  • In Edge 15 with the Creator's Update, Edge performs approximately the same as Firefox on my machine. I can get 60 FPS on all three browsers, but the CPU usages are approximately 20% in Chrome, 40% in Edge and 45% in Firefox. So it looks like Edge 15 has been optimised and is now slightly better than Firefox. Can you confirm?

    I haven't spent much time in it since the update, but a quick test shows better performance if objects with shaders don't animate, and with scaling/rotation manipulation at runtime is still pretty bad. For reference, the example in the OP creates around 200 or so tinted objects.

    I'll spend more time and see if I can figure out what the issue is, but glancing at the Edge console the paint operation seems to be taking an unreasonable amount of time. Removing all object shaders and applying the default noise shader to the layout has similar results. This is on the most recent GPU drivers with an EVGA GTX 980 WC. I'll post here again after more tests.

    I won't deny that that's frustrating if you're wanting a solution for today, but I take a degree of comfort in knowing that the software is being built with tomorrow in mind as well.

    The problem with this argument is that it applies to literally every piece of hardware and software ever made, but to earn that kind of trust, what's working today needs to be as feature-full as promised, and it hasn't been. Timelines are not built on potential future functionality in a commercial setting - there's no reason this long-proven way to do business should be applied any differently to Construct.