Ashley's Forum Posts

  • 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.

    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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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.

  • While we are arguing for days why we don't want Construct to be even further black boxed, the creator and technical lead of Godot just started a Youtube series where he explain in details the Engine internals.

    Once again, repeating myself, source code is not an API. We are talking here about an extensibility system where a first-party codebase interacts with separately installed third-party modules through a defined interface with encapsulation. There's that, and then there's getting a copy of the entire codebase in a game engine, which is something entirely different.

    So you guarantee the runtime will never be obfuscated like the Editor SDK ? Just better encapsulation but everything will still be readable for us ?

    I haven't been talking about obfuscation here, only encapsulation. I am not sure where you got the obfuscation point from. Even so, as the warning has always said - we reserve the right to change undocumented features at any time. So the very purpose of the warning is to say "we might do that, and take the possibility seriously".

    isn't the best way to deal with it is to FIRST make improvements to the SDK with an active cooperation with 3rd party dev during several months/years and only then starting to progressively encapsulating ?

    No, because the current SDK is unmaintainable and risks disaster, and the longer it is used, the greater the risk.

    Add a license to get an unecapsulated version of C3.

    I think this thread has shown, if we say "don't do XYZ, it's unsupported and we won't help you", in the end people do it anyway and then still expect us to help them. We had a warning specifically reserving the right to change and remove all undocumented features at any time and say "tough luck" to those affected, but in the end, in practice, doing so is not feasible because of the backlash, and we are going to have to go to great lengths to avoid the consequences of doing the very thing we warned we might do - an outcome the warning was also meant to avoid. In practice saying "this is not supported" is not realistic as at the end of the day customers facing disaster end up begging us for help anyway, and we usually still try to help them because are we just going to refuse to help them finish a project they had been working on for years? So the commercial reality of running a business like ours is you end up helping everyone anyway, even if they did things you specifically warned against; the only way to prevent that happening is to enforce it with measures like encapsulation that make it as hard as possible to get to the internals and prevent anyone doing the unsupported stuff in the first place.

    Some companies provide source code. Good luck to them - it sounds like a nightmare to me. Perhaps they just have enough staff to support the desperate customers who get themselves in to a huge mess, or maybe they really do just say "tough luck", but I don't know how they would get away with that in practice. If you decide you absolutely require access to source code for your game, then perhaps Construct is not the right tool for you - there are tools out there which provide that, and it's not something we intend to do for Construct. We do intend to have a public, documented, supported API with encapsulation though, which anyone can do anything they like with, and we promise to support indefinitely.