Ashley's Recent Forum Activity

  • > such as using 1000 sprites instead of a single tiled background

    >

    There are scenarios where "1000" sprites is needed, like in rts games

    Of course, but I meant this in the sense that the user could have trivially replaced all 1000 sprites with a single tiled background, their game would look and work identically, and the performance would be radically improved - but before they figure that out, they complain about poor performance and ask for native exporters.

  • I am a broken record on this subject, but it keeps coming up, so I'll keep asking the same questions back at those asking for native exporters: what is it you really want? Rather than focus on the technology choices, what is the end result you are after?

    If it's better performance: maybe WebAssembly can do that, while keeping the broad cross-platform compatibility of HTML5. And as ever, I struggle to find examples where our JS engine is not fast enough - almost everything anyone provides as examples are either GPU hardware limits (so a native engine would not be faster!) or just insanely inefficient game design (such as using 1000 sprites instead of a single tiled background).

    If it's more access to native features: I don't know what you're after precisely, but it can most likely be plugged in with Cordova or NW.js.

    Some people seem to think native exporters are a magic bullet that will solve all problems and make us incredibly rich. Here are some counter-points to consider:

    • it would make the product a lot more expensive. As others have mentioned, many appreciate the fact C2 is one of the cheapest product on the market for publishing to every platform.
    • it would make the product a lot slower to develop. If we support 10 platforms with 10 different codebases, every change must be written and tested 10 times, making development 10 times slower. We could use frameworks or libraries to help mitigate this, but some people seem to think it's a really bad thing to rely on third parties too much, so it seems like an odd direction to take, especially given browser developers have far more development resources than most cross-platform frameworks out there.
    • if you use any third party plugins at all, you can probably guarantee they are not going to be supported on more than one or two platforms. Even official features may not be supported on all platforms as porting issues crop up. This makes feature support a really complicated checkerboard across platforms, making porting a huge headache. Other products on the market suffer this exact problem.
    • there actually exist other products on the market that take the approach of writing native exporters, and they are struggling with all the above issues and appear to be behind us, which to me disproves the idea that "native exporters = commercial success".

    There are no magic perfect solutions in technology - don't think that native exporters would be flawless, or guarantee commercial success. In particular, I think the success of Construct 2 so far is significantly due to the portability and ease of development of HTML5, to the extent that I do not think we would have gotten anywhere near where we are today if we had gone with any other technology.

    • Post link icon

    digitalsoapbox - the issue was inherited from Chromium, it wasn't a NW.js issue. It's already fixed so it's just a matter of waiting for NW.js to update their Chromium version.

  • Streaming video through WebRTC isn't supported yet. It's not intended that you display User Media with the Video plugin, the User Media plugin itself acts as the video display.

  • Hasuak - please ensure your forum conduct is always helpful and constructive.

  • eli0s: items 2, 3 and 4 sound like they are already possible, 5 and 6 via existing third party addons (e.g. Spriter). It sounds like you're underestimating what's already possible.

    Game is on layout the size of single screen, and enemies fly trough it, but there no way of bouncing off bullets of the borders of the layout

    This sounds pretty easily solvable with events.

    If we had control over loading into vram, we can specify which sprites to load on start of layout or between transitions, and when they are called, there's no stutter.

    Placing an object in the layout view is how you tell the engine to load it in to VRAM on startup. If you don't need it on startup, just destroy it on start of layout - it still gets its textures loaded and can be created without stutter. So I think you already have the control you need?

    [quote:3rplp7ai]Multi-thread is difficult to get it to work well, big engines have it and little engines don't.

    It's not that simple. For the reasons outlined in the blog post, even big engines run a lot of their core logic on a single thread, because due to the architecture of modern computer systems multithreading it would have either little or negative effect. The blog post explains why this is the case.

    I wrote that blog post specifically to combat this perception that "C2 sucks for being single threaded and needs to be made multithreaded pronto", but it seems to have been ineffective! There is unlikely to be any real-world performance benefit to multithreading events. And again as the blog post describes, significant parts of modern browser engines are aleady multithreaded, and that is already in effect today with all your existing games. I think that is underappreciated.

  • Ah. I was just thinking of fixed-grid spritesheets like Pyxel Edit uses. If that's not the case, I assume C3 will take an approach similar to Unity's sprite atlases..? Will be interesting.

    In-editor spritesheeting is a goal of C3.

  • Stuff like units pushing out of object, to be used in games like rts or hack and slash etc.

    This type of problem is incredibly difficult, period. No matter which framework, technology or approach you use, getting a large number of moving objects to move co-operatively is very tough (I've tried!). This is not really something someone can just whip up a quick plugin to solve.

    As for other suggestions, I'm always curious to see concrete suggestions for features and the use cases you could use them for. We're always trying to hit a balance between making it easy to get results, but avoiding cookie-cutter engine features. Sometimes people are looking for a built-in feature to implement a large portion of their game logic, but that's not our intent. For any logic specific to your own game, there is no substitute for events. I don't think it should be viewed as a failure of the product if you have to use events, that's actually part of the design.

    Also i think C3 should go full on WebGL. Sorry to say this, but forget about canvas2d, there is really no point to have it. It makes everything more complicated than it should be.

    I agree completely! However around 10% of desktop devices, and maybe more like 25% of Android devices, still don't support WebGL. I'd love to ditch the canvas2d renderer but I think it's just too soon, I think we need closer to 95% support on all devices.

    I'd be happy with some memory controls, load sprites into vram, unload from vram, giving the developer more control (optional) over this is required for very large games to run well on weaker hardware.

    The engine already does this automatically on a layout-by-layout basis. The problem with adding more control over this is you create the opportunity for mistakes in memory handling to actually make things worse and use even more memory, or you rely too much on mid-gameplay texture loading which can cause serious jank, which is something everyone wants to avoid.

    [quote:2grxwa81]The biggest limitation I see currently is single-thread logic.

    See Why do events only run on one core? The blog post goes on to detail many features which modern browsers (and our own engine) run multithreaded.

  • It's simply a shortcut for the name of the current object. So if you are using an expression in a Sprite condition or action, where you would type Sprite.X, you can type Self.X instead.

  • opacity is an int

    It's a float actually

    As mentioned, invisible objects are not actually drawn at all, which is faster than using 0 opacity. The only reason you'd ever want to set 0 opacity instead of setting the object invisible is in case you are using a WebGL shader that changes the opacity so something is visible.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • See Performance tips

    On old Android devices the GPU may be blacklisted - check by opening Chrome and visiting chrome://gpu.

  • JavaScript doesn't compile, so it is interpreted at runtime by the browser/JavaScript engine

    Most modern Javascript engines use just-in-time (JIT) compilation to machine code. They use a flow something like script -> bytecode -> profiling -> machine code generation. This means well-written Javascript gets "truly" compiled and can reach pretty impressive levels of performance.

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 27 Oct, 2026

Twitter
Ashley has 1,833,592 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
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x6
    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
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs