Ashley's Recent Forum Activity

  • Construct 2 is not available for free - it was taken off sale and has been retired since 2021. However Construct 3 is backwards compatible with Construct 2 so you should be able to import your C2 project and continue working there.

  • Moved to Construct 2 forum. As Construct 2 was retired in 2021, it may not be possible to export to iOS any more, as the publishing requirements tend to update every year and only C3 has been updated since then. Further, historically it has not been possible to side-load apps on to iOS devices for free due to Apple's restrictions - you have to have a developer account which costs $99/yr (last I checked anyway). There is a lot of regulatory activity around this at the moment though, so it may be changing, but perhaps only in certain territories like the EU.

  • Hold Alt when clicking the preview button and you can start multiple local previews. See Keyboard shortcuts

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If a problem occurs only on certain graphics cards, usually that's a sign of a graphics driver problem rather than anything to do with Construct or your project. Graphics driver bugs are pretty common and unfortunately notoriously difficult to deal with.

    My advice would be to make sure 'Ignore GPU blacklist' is unchecked when exporting. If it is checked, then it may run in to known problems with certain GPUs/drivers, whereas leaving it checked means it reverts to software rendering in those cases, which is slower but at least should appear correctly.

    • Post link icon

    The current status of WebGPU support is in this thread which is kept up-to-date as the situation changes. I would like to see WebGPU enabled by default by the end of the year, but it may happen sooner or later than that depending on how the roll-out process goes.

    As this thread was originally for preliminary documentation which has now been moved to the manual, closing it.

  • That code will still work in TypeScript, but you will lose access to instance variables, behaviors and effects unique to the object classes, as those come from the type definitions on the class in the InstanceType namespace.

    It's still possible to have it work though - essentially this comes down to multiple inheritance (e.g. you want PlayerInstance to derive from both InstanceType.Player and Entity), and if you look up mixins you should find a couple of ways to approach that. Where possible I'd recommend composition over inheritence though - i.e. make an Entity a property of the class rather than a base class.

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,541,485 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x69
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x38
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs