>
> > 
digitalsoapbox I just saw Sombrero's recommended specs on steam.
> >
> > OS: Windows 10
> > Processor: Intel Core i7
> > Memory: 8 GB RAM
> > Graphics: Nvidia GTX 980 or equivalent with 8GB VRAM
> > DirectX: Version 11
> > Network: Broadband Internet connection
> > Storage: 500 MB available space
> > Additional Notes: Best played with a 2 stick controller
> >
> > I think you should definitely use something other than Construct.
> >
>
> Recommended specs will always be high. The minimum specs should be able to be much lower considering the 2D nature of the game, however because of serious limitations that are endemic to Construct's codebase, which are continuously denied but easy to spot just by looking at the engine code, that hasn't been possible. Even low resolution pixel art games stutter, and that's not just due to garbage collection.
>
> It's simply not a tool for any sizable - or sustainable - game development, period, in its current state. Or seemingly in C3, based on the expectations of either a browser-based or wrapped-browser IDE, on either desktop or mobile, and certainly not on any console, marketing claims aside.
>
> I'm not even sure the appropriate words exist in the English language to fully express the frustration I had getting even acceptable, let alone good, performance in Sombrero - and I've been dealing with web-based tech professionally for around 20 years. While I understand some (Ashley) will blame others for performance issues, that's simply not the case here - the engine just can't cut it for anything large, and definitely not anything that is meant to run at resolutions expected out of modern desktop games, 2D or otherwise.
>
> Don't even get me started on collision (or often, lack thereof) issues, unstable frame rates, buggy native behaviors that Scirra refuses to fix (jumpthrough issues, for example), or missing features that are common enough that I can comfortably say they're available with any other option natively - and by "natively" I mean the actual definition of the word, not the one that Scirra misuses all too often to obfuscate performance issues that can be linked directly to C2.
>
> Anyways, live and learn. There's other tools out there without these issues. I'd suggest looking into them. The event system is cool, but the albatross it's currently shackled to is held together with duct tape and bubble gum that's icky and gooey and the seams are showing.
>
This is the kind of dialogue that should be promoted and out in the open between high level developers and Scirra - have you provided isolated cases of your concerns?
I have, but my experience so far has seen a refusal to admit need for improvement or understanding of what users who aren't just making simple mobile games or re-posting store templates on app stores are looking for in their development tools. It may be beneficial for Scirra to work more closely with some of their developers to understand what's needed, but maybe that's happening and we're all unaware...though it's not like there's really all that many larger games in C2 either way, which isn't a great sign.
Here's a great example of the kind of issues I repeatedly run into when trying to push C2:
- Create a new layout
- Set the window size to 1280x720.
- Add some sprites with collisions across all of it, or a tilemap with collisions enabled and some tiles placed in it that span across the layout.
- On the start of the layout, resize the window size to 640x360.
- Congrats! You've just broken collision cells.
Of course, this could be easily remedied by providing an action to force a recalculation of collision cells...but we don't have that. I have at least a dozen more examples I could put down off the top of my head, but based on my experience with trying to get things improved/fixed in the past, I don't see any value in spending my time putting them together to then be ignored or called "not a bug" or "not a supported behavior." For example, issues with the jumpthrough behavior where the character just falls through platforms with no real explanation, especially on slopes - which has been reported multiple times over multiple years by multiple users. In the case of jumpthrough, it's clearly a bug being hidden behind a statement of "it doesn't support that," since it works 99% of the time but the desire to put forth the effort to fix the 1% of the time where it doesn't (edges of collision cells, certain angles at certain x/y locations, etc.) doesn't exist.