Editor SDK, Editor Tools and SDK V3

Well, up until you mentioned it, I was not aware that using the basic JS DOM manipulation API was considered undocumented and unsupported by the editor SDK, and I genuinely thought this addon was supposed to be fair game since I really tried to make everything as self contained as I could. I wouldn't have made it open source and so thoroughly documented had I thought it actually posed the risk you are describing.

As a show of good faith I have privated and removed all 3 addons and their repositories. I will release them again once the new and supported equivalent feature exists and I can make them work in a safer way.

Alternatively I can also remove all of the code that handles the new dialog UI layer (which is most of the code) and only keep the code that opens a popup if you think that is safer in the meantime (this would only require changing the window manager addon as the other 2 addons don't handle any DOM outside of their own window).

Frankly the editor SDK is already pretty much unused by most addons I've seen and completely unused by all addons I've made so if a potential "SDK V3" keeps it backwards compatible then by all means feel free to plan for this move as it wouldn't affect me in any way at all.

I've looked into Shadow Realms, and I can't find any planned release date for them. Are you planning sdk v3 for when they eventually get standardized, or do you have another temporary solution in the meantime?

Does encapsulation cause performance degradation?

I've heard people say that, but I wonder if that is actually the case.

Yes, this did happen with the rollout of SDK2. The biggest issues were fixed, but there is still a small performance overhead, and in certain cases pre-SDK2 Construct releases can be a tiny bit faster.

From what I understand, the SDK3 being discussed here applies to the editor API, so it shouldn’t affect runtime game performance. That said, there have been reports of the editor lagging or freezing for some devs. Here is one from just two weeks ago. It also runs out of memory on large projects. I really hope SDK3 encapsulation doesn’t make those issues worse.

And yet Gamemaker seems to have hit after hit every year while Construct‘s games usually have negative Steam reviews because of performance issues ;) Not trying to be salty but we also have to look at things a bit realistically. I doubt even that the issue is C3‘s engine or Javascript but simply that high performance web game STILL are trouble to bring to Steam in a reliable manner (see Gamepad vs. Steam overlay in Webview atm). I'm kinda contemplating just using Electron if i ever publish to desktop in the future.

Talk about disaster: steamcommunity.com/games/1219240/announcements/detail/511820969218671190

But yea that‘s another topic just the GML comparison isn‘t as impressive as it might sound on paper i‘m afraid 😅 Also please note that Gamemaker supports Javascript now as well... And i genuinely love C3, the user experience is superior but at the end of the day when it comes to RELEASING games it's far more of a hassle than most other engines except for web, for that it's beautiful and i worked with "real" web developers who were sceptical about using C3 at first but then very impressed about the performance and ease that they could add their code to my game for stuff like share buttons etc.. Just that strange, unwarranted Gamemaker fixation sometimes rubs me the wrong way lol

We were talking specifically about JavaScript performance. It doesn't sound like you were talking specifically about that, so that's bringing in a whole other set of discussion topics.

I'm happy to benchmark performance issues, and usually the engine does have very good performance. If you're referring to performance problems, I'm not sure exactly what you're referring to - there could be all sorts of different things going on, ranging from GPU selection for dual-GPU systems (something I'm hoping to address in the next release cycle), graphics driver issues that are (surprisingly common) system problems rather than anything to do with Construct or browser engines, or actual issues with the Construct engine. It's helpful if you can be more specific, and file issues following the guidelines so we can properly investigate.

No software is perfect, and all software has its bugs and issues. The number of open issues isn't necessarily a perfect measurement, but given that we currently have 53 open issues, GameMaker have nearly 5000, and Godot has over 12000, then I wouldn't say it's necessarily the case that everything is going so much smoother for everyone else.

This is really going quite off-topic for this thread though, which is something we address in our Forum & Community guidelines - it's probably best to start new threads to branch off new discussion topics, rather than chucking everything in to one thread that was originally about the addon system, which tends to get pretty confusing and aimless.

All good Ashley, i'm not questioning the quality of Construct or you as a developer, i'm merely commenting on the fallacies of comparing JavaScript performance against the competition which usually means "you-know-who" ;) And again, if you read through ANY issue people usually encounter with Construct performance or otherwise it's always at the point where any sort of desktop or mobile deployment happens which is always a bit of a shame because as i said, it performs beautifully in the editor and plain HTML5. So it's more about how much does JavaScript performance really matter when there's so many other factors that other engines using slower programming languages don't need to deal with. Luckily i'm probably exempt from these problems because i make stupid little adventure games and not bullet hells :D But all good, didn't mean to hijack the thread, enjoy the holidays! ^^

This might be a mad idea; but is there not a way to build a parser and or extension/coding system that can effectively convert internal details altered code into safer non-broken code when it's identified as broken?

If not got another idea;

can't there be like a underlying program that effectively is interwined into construct 3 in a performance friendly way that is able to keep a ghost version of the working engine and alter changes to it and can be time-framed based also on various specific and particular lines of code ; etc where the break and bug is identified to happen; so then it can be reverted in real-time this means you can basicily re-edit the engine in real time and at any specific line of code in a safe sense as unbroken states and or broken states and work around it???

*Effectively making a real-time editable time-machine of construct 3 internal details at code level and being able to identify broken and non-broken aspects before it's too late and is literally broken if that makes any sense even when updates happen to the engine*

It's more and or less git for construct 3 at software code level but it's compiling to test for problematic state; etc.

*This definitely can be done*

Eventually after working prototype is finished it could be improved over-time then the entire industry can reduce this problem to the max and lay this silly problem to rest eventually ;) ?