Ashley's Forum Posts

  • There is also a developer who improved this weapp-adapter: github.com/finscn/weapp-adapter/blob/master/README_EN.md

    That link lists 5 known bugs in the WeChat game library, some look really nasty and difficult to work around, and I bet if we ported Construct we'd find a lot more. So I think my intuition was correct - supporting it would be a nightmare!

    There are two kinds of browser tech: real browsers that are tested against the industry-standard Web Platform Tests, and adapters that try to fake it and end up broken in all sorts of difficult ways.

  • is foreach simply duplicating the overhead of a single event, in this case 40k times, while the former is only the overhead of 1 event and the resulting cpu usage is the internal time to generate the sol based on the condition?

    Yep.

    The event engine has some overhead (surprisingly small - enough to perform close to GML compiled to C++). 'For each' requires the event engine to repeat the engine overhead for each instance - it will re-run all following conditions, actions and expressions once per instance. However normal events run all conditions, actions and expressions a single time, but with a single long list of all the picked instances.

    It's analogous to this in code: 

    const instancesArray = [ /* 40,000 entries */ ];

// Normal action
runAction(instancesArray);

// With 'For each'
for (const instance of instancesArray)
{
	const singleInstanceArray = [instance];
	runAction(singleInstanceArray);
}

    The first approach has the overhead of runAction once, passing 40k items, and the second approach has the overhead of runAction 40k times, passing one item each time.

    So yeah, don't use 'For each' unnecessarily.

  • Nice work! Happy to see a companion plugin in the works. It looks like you've used pretty much exactly the approach I intended.

    To pass more complicated data structures, so far I am passing a JSON string back from the wrapper.

    Yeah, I think that's the best solution. Passing complex data types over a DLL boundary gets very complicated, and JS already has built-in support for JSON, so just sending a string of JSON data is probably the best thing to do for more complex data types. If you need more advanced JSON support in C++ I can recommend this C++ JSON library.

    Some of the commands require handles which cannot be passed back, so I keep them as statics in the wrapper (global now, but should be private in the class).

    Yep, that's fine. If you need multiple handles you can do something like assign them tags and use the tags in the event system to identify the handle, and look them up on the C++ side.

    I need to figure out ways to debug the DLL.

    In Visual Studio, you can set the debug command to run the wrapper app executable. Then make sure the .ext.dll is a debug build of your DLL (just copy paste it over the exported files if necessary). Then when you click the debug run button in Visual Studio, it should start up the app, detect your debug DLL, and then stop on breakpoints you've set so you can properly debug it. (There's also OutputDebugString() and other debug output methods for a console-like output if that helps.)

    It should be possible to set up a workflow where Visual Studio builds the debug DLL directly over the WebView export, so you can change some C++ code, start debug, and it automatically builds, runs and then debugs your new code.

  • In fact, I noticed that in the development documentation of the mini game, there is an weapp-adapter which may be used to simulate the support of the browser environment.

    I had to use Google Translate to read the page, but the English translation mentions:

    The running environment of the mini game on iOS is JavaScriptCore, V8 on Android, they are all running environments without BOM and DOM, and there are no global document and window objects. Therefore, when you want to use the DOM API to create elements such as Canvas and Image, an error will occur.

    This suggests to me it's still not a real browser engine.

    You can have a go at it yourself if you want, but it will probably be a nightmare, because Construct assumes there is a real browser engine.

    Honestly by far the best direction forward is for them to just use a normal WebView.

  • I'd also add: if you choose to stay on an old version of Construct, and you run in to a showstopper bug, you still have a way out: update to the latest version of Construct. Even if there are regressions when you update, you can file issues with us and we'll provide official support and sort everything out.

    If you use engine hacks, that becomes impossible, and basically you're just screwed. That's why it's a uniquely worse situation.

  • Truth of the matter is i burnt myself once by using a lot of Rex' old add-ons back in the day and ever since then i stay away from 3rd party things, even though there's great stuff being done.

    If we were able to fully block all engine hacks like other engines, then it's unlikely anything would have gone wrong in the first place, and everyone could trust that third-party addons will work reliably. I think that would be a much better situation.

  • If in the future a disaster happens because of my own addons, please let me know and I will do my best to help in any way I can, as quickly as I can.

    I appreciate that, but my point is in the scenario I described previously, there is no solution. Nobody can help the person stuck in that situation: we can't, because they use third-party code, and you can't, because the hack has become impossible. They are on their own. The only way to prevent this is to avoid modifying the engine internals in the first place. I know software development is complicated and a bunch of difficult stuff happens over time anyway, but that situation I described is basically catastrophic. It ends in reviews like "I worked for a project for 5 years, a Construct update broke my project, and then they refused to help me". In that situation that's pretty much true, and is the kind of review that could cause major reputational damage to the company, and make other developers think they better not go anywhere near Construct.

    I'd point out most other game engines rely on compiled binaries which are not feasible to modify, so hacking the engine is off the cards. People just use workarounds instead and can still get a lot done that way. The problem of being able to hack the engine is basically unique to Construct because JavaScript has historically had poor encapsulation. It now has better features for that like private fields. I'd quite like to update the engine to use that to prevent the possibility of disaster, and force the use of workarounds instead, which would bring us in to line with how most other game engines work. But it would probably permanently break most engine hacks. That's something I've always tried to emphasize is a possible outcome, and it could happen at any time for any other reason too, including inadvertently. This is why the software industry invented encapsulation and if you ignore the lessons learned over decades of software development, you'll probably eventually learn them again the hard way.

  • skymen - your approach sounds like probably the most responsible way to go about that kind of development. However it will only reduce, but not entirely eliminate, the risk of compatibility disasters. As I said we went through a lot of this with Construct 2 already, and this subject is all well-understood stuff in the professional software industry. If you really want to minimize the chance of disasters, the solution is: stick to the public, documented, supported APIs.

    There is still the risk something like the following happens - and I still worry that it will eventually happen if people continue tinkering with the engine internals:

    • Someone reads your post and thinks "sounds like it's been fine for 6 years, I'll use it anyway!" and adds some engine hack for something important in a big project.
    • Later (perhaps years later) we update Construct in a way that makes it impossible to use the hack any further, due to completely changing the internal details the hack relied on.
    • That user is now stuck on an old version of Construct.
    • Suppose later they then run in to a showstopper bug that is fixed in the latest version of Construct. Now they're in development hell: they can't stay on the current version of Construct because it's got a showstopper bug. But they can't update to the newest version of Construct with the fix, because the hack they used in their project won't work. They have no good options and can't rely on official support.
    • This could ruin their game launch. They may feel so burned by the experience they never use Construct again.

    If people are still tinkering with engine internals and this has not happened yet, the main reason is luck, and I fear sooner or later our luck will run out.

    If you run in to a missing feature or limitation, there is a third option you have not listed: work around it. It may not be perfect, but it's a pragmatic option and is pretty common in the software world.

    I don't know how your "Animate text" addon really works, but I'll use it as a hypothetical example. Suppose you want to add a "wavy text" animation to some text. First of all it's already possible with an event sheet, so you don't have to hack the engine for that. Suppose you want to create an addon to make the task easier anyway. You might think the only way is to hack the engine internals and add a new special animated BBcode tag to the built-in Text object. But that's not the only way. You could also create a standalone plugin that just generates strings of BBcode using the existing 'offsetx' and 'offsety' BBcode tags and vary the offsets over time.

    Sure, it's a bit less efficient as it has to keep re-parsing the BBcode strings. But JavaScript is super fast and I suspect it's probably fine for most reasonable use cases. So that feature can be achieved reasonably well without having to do any internal engine hacking at all. Better yet, it can be shared between the Text object and SpriteFont object, and anything else that supports those BBcode tags (including perhaps some HTML features), so it's a more flexible design. So it has its trade-offs, but overall I'd say it's a better design, and will be supported permanently, as it only uses officially supported features.

    I suspect that all too often people run in to some limitation and assume they're either stuck or have to hack the engine. I don't think that's true. Usually there is in fact a couple of feasible alternative approaches and workarounds. Occasionally I do add some new feature that's been requested for some time, and in the process of doing it, I realise it was reasonably possible by some other means and point that out, but by then it's a moot point. So I do think this comes up more often than people realise. It's not an all-or-nothing situation of either hack the engine or it's impossible. There's usually lots of stuff in the middle you can do which will be fully supported. Hence my advice: stick to the public documented features, and work in terms of that - and it's probably still possible to do a lot more than you think.

    Meta comment: this thread is becoming a bit of a sprawling mega-topic that covers lots of different topics. That tends to make the discussion chaotic and frustrating. Usually it's better to start separate threads to discuss separate topics. This is covered by our Forum & Community guidelines, so if this gets too out of hand I may lock the thread and ask people to start new threads with a more focused single topic of discussion.

  • Use the 'Set binary item' action of Local Storage to save the Binary Data object which contains the recording to the local browser storage. Then 'Get binary item' will be able to read it back later on.

  • The default theme matches the system setting. If your system is set to use a dark theme, then Construct will already default to the dark theme.

  • if I pay for a month and then immediately cancel, will I still be able to use the full software for the month I paid for or will it be cut off?

    Yes, you can use the remainder of the period you've paid for when you cancel.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Preview should work the same as export. It was specifically designed like that to avoid differences between preview and export. If it doesn't, please file an issue.

    In your case it looks like you are using relative paths in both cases, but after export the server or upload process actually changes the folder structure. There's nothing much Construct can do about that: it expects export to work the same way as preview. So the best approach is to make sure the publishing system preserves the same folder structure.

  • Construct follows the same API patterns as used by the browser (e.g. addEventListener). If we deviate from that I think it actually overall makes coding harder, as you have to learn different patterns, and remember which pattern fits to which feature. This kind of inconsistency annoys me regularly when using third-party libraries which deviate from the browser way of doing things (e.g. using on instead of addEventListener). It also reduces the use of Construct in education, as if your early coding is using the same patterns as industry-standard code, then you're already learning useful real-world skills instead of tool-specific details.

    Still, there's nothing stopping anyone using the coding feature to write a library that does that kind of thing! You can always write code to "layer on top" a differently-designed API that works like you want.

  • I don't think those are good analogies - software is pretty abstract and personally I don't think maintaining a reliable software platform that other third-party developers build on top of has much relation to a restaurant. Tweaking random bits of internal code is fundamentally unmaintainable. This is widely understood among professional software developers. There is no way to make that work. The solution is a public documented API which you promise to support. That is what we have done.

    I think a better analogy is: imagine a block of flats where any resident is allowed to make any structural, electrical, plumbing, gas, or water alterations, to any part of the building, at any time, without permission from anyone. Chaos would ensue and the result would probably be extremely dangerous. This is not a reasonable way to run a shared building. There are rules about what you can and can't do, and who is allowed to make which changes, specifically to prevent that end result. Residents who complain that they can't just break open a few walls and run another gas pipe through several neighbor's flats are not being unfairly restricted in their freedom to do what they want with their flat - the rules are there to make sure the building can continue to function and be properly maintained in the long term.

  • I am sure people would still ignore the warnings, cause compatibility disasters for themselves including corrupting their projects, and then contact support and ask us to help rescue their project. Or we update Construct, it breaks the custom code change, and then the situation I described previously plays out again.

    As I keep saying, things are also much more complicated than they look: often people think "oh, I just change this code here", but it actually causes another bug somewhere else. This is so easily the case with the Platform behavior that even when we make small changes ourselves, it can result in several regression bugs spanning the next few months of releases. So you could easily end up descending in to a nightmare of constantly breaking things. Which isn't much better either - especially if you only discover shortly before release that your own change caused a showstopper bug, and you're doing something unsupported so we won't help you. I am sure people would still contact us and beg us to help them, so again it comes back to us anyway.

    I think the key point is it's not merely making changes - support is essential to software development as well. I don't think it's realistic to say "oh you can do that but you won't be supported". Not supporting customers is not a good option.