Ashley's Forum Posts

  • The change was made for TypeScript support. When using TypeScript, Construct generates TypeScript definitions for every object class including types for instance variables, behaviors and effects. As these are all different for every object class, it has to generate a separate base class for every type of object class, hence InstanceType.Player rather than a generic ISpriteInstance. However InstanceType.Player only has type definitions for TypeScript, and (assuming it's a Sprite object) itself derives from ISpriteInstance. So if you're using JavaScript there's basically no difference. The main reason to change it is to keep everything consistent, so if you change to TypeScript or back again you can continue to write code the same way. If it would be a pain to update all your code though, you can just leave it and it should keep working the same.

  • Please don't go out of line and remember who your product is aimed at and who pays an annual subscription for it.

    The education market makes up around half our business. Teachers want features like the BBC micro:bit and have been excited to see it added.

  • I can't see anything wrong in what you've described. As ever, the quickest way to get help is to share a project file demonstrating the problem so we can try it ourselves.

    • Post link icon

    Naturally everyone wants lower prices and more for their money. However one point I think is underrated is that you should choose a tool with a sustainable business model. Developing software is time-consuming and expensive. Open source is a different model, but of commercial companies, if their product is either free or extremely cheap for the majority of customers, then how are they paying all the engineer salaries and business expenses to develop it? In my opinion there's a couple of tools out there which to me look like they have unsustainable business models. I think they might fail in the next few years, or have to resort to desperate measures like Unity did with the runtime fee after they ended up losing close to a billion dollars a year (and they still haven't yet solved that problem). That's the flip side of free or very cheap tools. What if you're half way through a project years in development and the business fails or has to resort to desperate measures? It could put you in a really difficult situation with years of your work at stake.

    Sure, everyone wants to pay less, that's part of business. However our model is obviously sustainable. We can keep this going indefinitely. Can you say that of every other commercial tool out there? We've been running for 13 years now and we're still going strong; over the years I've seen several tools appear, get hyped up, reach some level of success, stumble, and then ultimately fail. Are you willing to risk investing years of work in a product that might not have a future?

  • Look at the manual entry and you'll see loadImagePixelData() must be passed an ImageData object as a parameter. However your code passes it an array with four elements.

  • When you preview, only spritesheets changed since the last preview need to be regenerated. So if you preview, close, then preview again, the next preview should be very fast as it essentially skips the preparing images phase. So it should already be skipping the vast majority of images, and given that, the setting you propose would probably have little effect. It is also designed to limit how many spritesheets it processes in parallel, specifically in order to limit the peak memory usage and avoid out-of-memory errors, while also working in parallel making use of multi-core CPUs in order to process as quickly as possible. So I have to wonder why this is a problem for you - are you constantly changing large amounts of images in between every preview? Are you dealing with lots of extremely high resolution images or something?

  • To prevent abuse, both windows and iframes cannot normally assign focus to themselves automatically. The user must click or touch inside an iframe to intentionally give it focus. You can encourage that with a "click here to start" type button. Unfortunately as gamepads aren't able to specifically direct input to a window, I don't think you can use a gamepad to transfer focus.

    One exception may be that the parent frame may be able to transfer its own focus to the iframe with something like iframeElem.contentWindow.focus(). That might require a user input too, but I'm not sure, I can't remember the browser rules around that off the top of my head.

  • As fewer browsers support Ogg than WebM, if Construct exported Ogg, it would cause worse compatibility issues for publishing your project. WebM Opus is near-universally supported by all browsers now, and after years of resistance from Apple, is the only free and open audio codec to reach that point.

  • It sounds like you are using an exceptionally large amount of images. See the manual guide on memory usage - if you're doing something very inefficient you can quite often easily reduce the memory usage by 50-75%.

  • I don't see how changing when the suspend happens changes anything about what happens when it suspends. If you want to do something custom when the game suspends, use the system 'On suspended' trigger.

  • There's no limit and I can't think of any downside to having a lot of them other than it might be hard to organize if you have, say, hundreds of them.

  • When I move to macOS for some testing I always end up getting the email client too, but it's because it's a different shortcut. Make sure you're really pressing the right keys and not something like control instead of command!

  • There is also a known issue with WebGPU that rendering fails on Intel Gen12 LP GPUs. See this issue.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I apologise for the confusion over "obfuscation" versus "encapsulation". These are different things. Writing long posts about deeply technical topics across all sorts of areas is difficult and I'm only human and can make mistakes or phrase things badly sometimes.

    I am interpreting "obfuscation" as doing something like minifying the entire runtime source code with Google Closure Compiler. This will do things like rename parameters and variables in methods. It does nothing to prevent people accessing internal APIs. To that extent, it doesn't seem relevant to this conversation.

    Encapsulation means blocking off internal details to make them inaccessible unless used through the documented API. This is the main thing I'm talking about here and is the main concern as it has backwards compatibility implications.

    I'm not sure why anyone would be concerned about obfuscation. The main topic of conversation seems to be about encapsulation, as it blocks off access to the internal engine, whereas obfuscation does not by itself necessarily do that.

    However, we reserve the right to use obfuscation. In fact I think we used to, and then for complicated technical reasons had to change that. We might change it back. You should plan accordingly, as per our long-standing warning.

    I would point out this long-standing warning has always made it clear undocumented features could be removed at any time. Use of undocumented features is at the addon developer's risk. Nobody else can be held responsible for the consequences other than them. We could remove all undocumented features in the next release, and say "tough luck, we warned you". To those of you saying people with access to the source code know what they are doing and understand the risks they are taking... this is a similar situation, we warned people, we are going to do it, and now people seem to take issue with the fact the thing we warned them would happen is going to happen. It puts us in a very difficult situation. It's also why I'm very skeptical of any more "don't worry, it'll be fine, people will understand" type solutions when this has clearly failed in this case.

    So, as I said before, we are not actually going to remove all undocumented features in the next release. However we will move forwards with a plan for a v2 SDK over the next year or two, which should give enough time to design a suitable SDK and deal with the inevitable difficult backwards compatibility issues that come up. Let me be clear: we did not have to do this, as we reserved the right to say "tough luck". However as it is clear this is untenable and obviously unpopular, we are promising to do the necessary work to make sure this transition goes smoothly. This does mean designing a new API in co-operation with the addon developer community, and I would hope this ultimately ends up a comprehensive, capable API that does pretty much everything addon developers could reasonably want to do, short of unfettered access to the internal engine. I would ask for co-operation during that process so we can end up with a reliable, robust, maintainable SDK in the long run, and not the risk of disaster that we are constantly running at the moment.

  • I am not sure about the technical feasibility of that. It sounds very complicated indeed, and getting a better answer would require quite a lot of research work.