I addressed this recently in this forum post.

An new exporter that doesn't solve the issues it set out to solve? Perfect execution, no notes.

You didn't address it. You ignored it and - somewhat insanely - expect game developers to deal with whatever a user has installed on their system, which is a sadly unsurprising lack of judgement when it comes to how game development works.

And while I'm at it, NW.js works fine on Linux. Sorry you can't get your own engine working on the platform when its users are able to without issue, but switching to a new wrapper supported by one developer vs one supported by thousands of experienced developers is laughable no-go.

Sometimes this happens and it is my least favorite part of software development, but: sorry folks, this is not our fault. The problem is with AMD's software. You can ignore that and insist it's our fault anyway, or that we do something about it anyway, and nothing will happen, because it's not our fault and it is impossible for us to fix the root cause.

Ordering in a bunch of expensive equipment in what is normally a hopeless effort is not something we're willing to do. Like I say I would fully expect that to cost us money and result in a dead end - because it's not our software that's broken.

So there's apparently a workaround with an old setting. I guess you can keep using those old Construct releases then. It is a total mystery to me how the old setting could possibly have anything to do with this whatsoever: that setting just sets a flag in the browser engine asking it to reduce the latency of display. What that does I don't know, and why it works around the problem I have no idea, but it also caused a whole bunch of other bugs and problems, so if we bring that back we get all those problems back, which I don't want to do either. As ever, the only way to really solve problems is to fix the root cause, which is in AMD's software.

Your choices are: continue to insist we act on it anyway, which will be fruitless, or actually get in touch with AMD (don't ask me how, we're not AMD) or the browser vendors, either of whom may be actually able to do something about it. Those of you who actually want to see the problem fixed, please choose accordingly.

For those of you who think "just make a 3D engine, how hard can it be?" - food for thought.

For anyone looking for a solution to a major engine issue and not unhelpful misdirection or shifting of blame, there is an addon now available in the Construct Community Discord to deal with the rendering issues related to poor support for AMD GPUs. Created by a third-party developer who has been near single-handedly making a 3D engine that works within Construct in their spare time.

Whether it does need to be Scirra or the users, definitely feels like a huge issue and should all be focused in one thread to report this (assuming amd sorta have a public bug thread we can all chime in on) and not scattershot randomly to the companies.

The issue began occurring after a change in Construct. It's a Construct bug. The likely root cause - a specific change in Construct - has been found and was posted on the Construct Community Discord. Hopefully the community can solve the engine issue, as per usual.

Are you sure that there are not other approaches that could make an integrated 3D engine work, or new APIs that would smooth integration? It seems to me that it ought to be possible to basically import existing Construct objects in to a 3D engine, so you can get the same result as using a 3D layer in Construct, but with that layer rendered in a 3D engine. Therefore the workflow would be the same as it is with addons now - using the Layout View to compose levels, perhaps using placeholders for 3D models and so on - but the runtime renders using a 3D engine instead of Construct's engine. It may be complicated, but I suspect it is possible to do something like that. If it is not possible, I'd be interested to identify why and what APIs could potentially be added to solve those problems.

3D engines are vast and complex pieces of software with a wide array of tools and features. I'm afraid I am skeptical that the requests for 3D features will ever be limited to just a last few. We've done a lot of 3D features now, often with people saying that's the last thing they need, but the requests keep coming. For example more recently, we did implement 3D direct rendering for effects. It was a pretty complicated change and resulted in a few difficult bugs along the way that needed to be figured out, including a regression that made its way to a stable release. But straight away, it turns out that's not enough and there are more features necessary. I'm afraid I am of the view that even if we did what you ask, people would go a little bit further, get stuck again, and then file a feature request saying "the last thing I need is XYZ..."; then if we did that, people would go a little bit further, get stuck again, file another request... and on and on, until we've reimplemented a full 3D engine. We've already gone a fair way down that path and I am getting increasingly reluctant to go further down it. This is why I am instead trying to explore alternative options: if you integrate a full 3D engine, you get all those features you'd ever have requested all out of the box. Then instead you work on ways to improve integration, rather than reinventing a full 3D engine in Construct itself.

Realistically, anyone wanting to do modern 3D with all the bells & whistles would be better served switching engines to something built to handle that task. This is a fine stance to have. But that full feature set isn't something everyone needs, and for many games built with C3 - indie games, with small teams - would not provide benefits outweighed by the events system, the one truly unique selling point C3 has. If users have to resort to entirely separate rendering pipelines and shoehorn them into C3, then C3 has lost all benefits and users may as well use those other more 3D-focused, javascript/web tech-based engines directly, because at that point, doing it in C3 is more of an impediment than a benefit, and WYSIWYG-style editors already exist for those other gamedev tools.

A majority of the efforts needed to have working - if a little retro, which is in and selling games these days - USEFUL 3D in C3 is already done. There are multiple examples above, including of projects that have already been commercially released, or will be shortly. Some of it required engine hacks to get working. The idea is that, moving forward, those hacks would no longer be necessary with SDK v2. That's the whole point of this discussion and has been since long before the announcement of a revised SDK to, ostensibly, deal with the current situation of engine hacks being required to do things developers need to do for their C3 projects that feature some amount of 3D content - even in mostly 2D projects with small 3D elements, or in project with more 3D visuals but still strictly 2D gameplay - the kind of thing (currently, with a few hacks) C3 already excels at.

What exists here, in this thread, is an "out" for Scirra. 3D can be done by those interested, capable, and dedicated to doing so, with comparatively little - much less than implementing full 3D yourselves - effort on Scirra's part. It has already happened. That door is not closing again. This is unlikely to change unless Scirra goes out of its way to actively - and maliciously - prevent end users from doing so. The remaining question is whether Scirra would like to make that easier or harder for some of its paying end users - power users - who will do it regardless.

Moderator note: this comment removed for the reasons described in this post. Please see the Forum & Community guidelines.

Isn’t no official response fine? Ashley only responds quick to shoot down an idea. We could also extrapolate what the possible reply could be based on previous replies on this topic. Typically we never know something was being worked on till it was basically done. There’s probably a reason for that. How many times has someone started working on something and for whatever reason couldn’t get it working? He could be working on something or doing nothing related to this.

So, it seems a non-public response was made, likely to avoid the obvious and deserved community - what's left of it - fallout.

For those wondering, the short version is: it would take effort, so no, despite it obviously being possible, given we all have eyeballs to see it working with a comparatively simple hack made by someone in their free time.

Fantastic work as always Mikal.

We get so many feature requests it's difficult to even respond to them all, especially when they are long and detailed.

You should already be able to choose individual images per 3D shape instances using a sprite in a container. If you are proposing something to improve performance, you should include benchmarks - guesswork does not make for a good case.

Ashley, I have to say if you're going to respond to something in the future, please consider taking the approach of reading at least a little of it first instead of just posting different variations of the same non-response that makes it very obvious you did not. I'm sure this is where you'd like to express some frustration in not getting things 100% your way, but it really is very frustrating for end users that it seems best for anyone who's not an absolute beginner or has used any other software in their lives to just nope out of these forums and never, ever attempt communication with the people running them or developing the product.

I wish I could say that is just my position, but it seems to be the general consensus amongst a majority of experienced users, quite a few of which told me my original post was a waste of time because we all knew what your response would be - and was, because it's that predictable.

On a related note, these claims you made about working with Safari/Apple on iOS - which I took the time to read - mostly apply to dealing with Scirra in any fashion as well.

assets.publishing.service.gov.uk/media/6229ae538fa8f526d520d0b8/Scirra_Ltd.pdf

This line in particular from your writing stands out:

"It's difficult to objectively measure software quality and demonstrate that Safari is inferior in this regard. However to those working in the field there is a clear quality difference..."

Oh, that second sentence. What a bugger. Consider how would you - and do, since you basically just did it in your reply - respond to such a line from a Construct user.

Difficult to deal with, non-responsive to user needs, new developments (that would be useful for users in a real-world scenario) etc. Sounds pretty familiar to us. It's interesting that you believe it's a problem when you personally have to deal with it, but not when your users do.

Take the above as some paying user insights to seriously consider as you're looking to grow your user base, and I would imagine revenue stream, in ways that don't involve just raising prices and the subscription triage they invariably cause. Because that's what they are.

Good luck.