Ashley's Forum Posts

  • console

    I think it is likely that the Xbox One update to Windows 10 will make it possible to publish HTML5 games to Xbox One, but we are holding off on making official announcements about that until we know for sure.

    it could also be described as a top-down FZERO, which the SNES could handle

    Obligitory "my SNES could run this", obligitory reminder that as far as I can find the highest resolution mode of the SNES was 512x239 8bpp which is 122kb per layer vs. a modern 32-bit 1080p game which is 8mb per layer or about 68x more bandwidth. Assuming you have the background and four own-texture layers, that's 340x as much bandwidth, not including higher-resolution textures, plus rotation and scaling, plus no sprites-per-line restrictions, plus transparency and alpha blending, etc.

    Construct 2 games fail hard on Mac OSX and Linux with games over 500MB, and most of that size is soundtracks.

    Maybe that's a NW.js issue, but it's surely solvable. I know that recently there were bugs that combined with the slow NW.js release cycle has made for a lot of waiting, but I think it is pretty clear that NW.js should soon be back to working effectively, and that's a far more sensible option than burdening ourselves with a multi-year fork of our engine.

    it's roughly a 2.4GHz dual-core Intel CPU with Intel HD Graphics 4000 GPU. Do you use a device with these specs when you test the examples people send?

    Yes! And the bottleneck on that kind of device is the fillrate on the weak Intel GPU. Which is a hardware limit. Which means making a native engine will be no faster at all. So that's actually a pretty good example of why making a native exporter is completely futile for improving performance on that kind of device: WebGL is basically already performing identically to a native app in that case. Intel CPUs are pretty strong even on low-end models, meaning the overhead of Javascript is really not an issue. The GPU fillrate is the real issue. Intel GPUs really suck. That's not our fault, or HTML5's fault, or Chrome's fault. It's just crappy hardware.

    I really think some people have the impression that if we write a native exporter, hardware specs will magically increase.

  • The "temporary sprite list" is pretty much exactly how it works already, and it moves those instances to the main list at the end of the top-level event. However if every condition also checked the temporary list as well as the existing list, that would add a performance impact to every event again, since now every condition has to check two lists instead of one.

  • It's defined by the browser. I think its every couple of seconds generally but it could depend on the download speed.

  • The reason objects aren't pickable until the next top level event is an architectural detail. It actually used to make them pickable immediately, but it led to crash bugs, so the existing system is a workaround to those bugs. The problem is that to make an object pickable it needs to be added to the set of instances in the object type, but conditions iterate this set when evaluating conditions. For example think about this event:

    + For each Sprite

    -> Create "Sprite"

    "For each Sprite" will iterate every Sprite instance, but the event itself modifies the set of Sprite instances. It's difficult to handle this case correctly without introducing a global performance impact to the event system, because every condition has to constantly check if the set of instances it is iterating has changed. (It's also interesting to think about how this event would turn in to an infinite loop if it also iterated the instances it just created!)

    The actual bugs IIRC were even more complicated, involving sub-events and function calls, which ultimately led to an instance being created half-way through the evaluation of a condition that was testing the set of instances in that object. In order to handle this case, created objects are picked (so you can access them in the event immediately), but they are not added to the set of instances until the end of the top-level event, which guarantees no conditions are iterating them. I thought about only doing this when this mid-iteration case was specifically identified as happening, but I thought it would be better to be always consistent rather than doing something subtly different depending on the parent events/function call context which would make for some pretty maddening debugging. So created instances don't "really" exist until the next top-level event, although they are picked.

    It's hard to see how this could really be different. We could make it only do the workaround when it needs to, but being slightly inconsistent depending on the context is generally a terrible idea, because in practice it means unpredictable consequences. We could add them to the instance lists immediately, and then a bunch of games start crashing. Or we could add a check to every condition to verify if the instances change while it is iterating them, which adds a performance overhead to every event. Given these options, leaving it until the next top level event is the best option IMO.

    BTW the stated goal of C3 is to rebuild the editor and keep the same runtime, so this is not really the kind of thing we intend to change anyway in the scope of that project.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • See Performance tips

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