digitalsoapbox's Forum Posts

  • Yea. Technically it is still beta so "features may be missing" and Im sure ive seen Ashley say somewhere the live plug in is pretty much done so I think it is coming together.

    To be honest I was surprised the UWP performance wasn't better but it wasn't atrocious I'm sure there are a lot of construct games that could work with it. I would very interested to see the performance boost enabled by signing up for the ID program. And This 128mb issue something that could probably be easily sorted. I'm so far away from anything like releasing on Xbox that I'm not to bothered though it is just interesting to tinker. (Wow I'm feeling positive today must be good coffee !) It sure would be nice to see Sombrero on live though. digitalsoapbox you'll have to be the trailblazer on this one... Trailblazer , now that's a blast from the past... I was pro skills at that back in the day....

    There are currently no trails to blaze. It just isn't possible at this time. The 128MB issue - a requirement to deploy on the platform - is bigger than you think. That's really just a few sound files and sprites stored uncompressed in memory. Just LAUNCHING Sombrero takes about 300MB, and that's with loading most of the assets manually after start and nothing on the layout - just playing a video takes 300MB. If we had a way to reliably flush memory it may be less of an issue on startup, but memory issues aside that's still not taking into features that are required for XB1 games.

  • If Scirra hasn't addressed that in the their code, then that would be a bug that needs to be reported.

    Complaining, and making accusations of false advertising doesn't do anything.

    If they're saying the plugin is ready, that doesn't seem to be the case. If they're saying games can be deployed commercially, that's untrue. Missing features is not a "bug" - it's missing features. This is not a complicated statement.

  • thanks for the insight digitalsoapbox

    i dont get the 128 mb you are talking about,

    MS says that UWP has access to 1 gig when real world deployed in forground mode (450MB when in dev mode)

    Are you saying that we cant use more than 128 MB because construct games have to be able to handle a background mode and they cant?

    cant the games just quit if not running in foreground?

    [quote:12zl9hhc]The maximum memory available to an app running in the foreground is 1 GB.

    The maximum memory available to an app running in the background is 128 MB.

    Share of 2-4 CPU cores depending on the number of apps and games running on the system.

    Share of 45% of the GPU depending on the number of apps and games running on the system.

    https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/system-resource-allocation

    what I dont get is that with access to even these restricted specs and running through edge in UWP then most construct 2 / 3 games should kill it...

    but it seems they dont....... hmmmmm....

    Scirra

    Ashley

    dont you think it would be prudent to remove the "export to xbox one" claim in Construct 3 advertising until plugins and everything else is in place and xbox UWP performance is validated and any limitations can be stated in a caveat against an export to xbox claim?

    The 128MB limit on apps running in the background is a big issue and, really, the biggest game stopper with the stated limitations (performance is another issue and is Construct-specific, not platform or technology-specific), based on Construct's available functionality. Saying Construct 2 OR Construct 3 can export a functional, commercially-viable game to XB1 that would be allowed on the platform by Microsoft isn't true (again, at this time). Performance issues and current UWP limitations aside, neither support the feature set required to launch a game on XB1. I hadn't even realized that claim was being made about C3 but if it is, it's false advertising. It's simply not possible at this time.

  • I could be wrong....but if i recall correctly, digitalsoapbox who is the developer of Sombero, actually has some experience of getting it to run on the Xbox One's UWP platform also.

    Sombrero* but close enough .

    C2 games with any level of complexity don't run very well on XB1, period. This includes with the limits placed on Dev mode not being in place, which you need to be accepted into IDfca@XBox to get access to, and the limits are still somewhat lower than what's available to non-UWP tech, though even those limitations don't really explain the performance issues.

    Why this is the case isn't especially relevant (so any apologists can save their typing fingers), but until things are a bit tighter engine-side - in addition to the features required by XBox games still needing to be added to Construct - so I wouldn't get your hopes up just yet, considering C2's performance track record on consoles or lack thereof. Interestingly, Unity UWP deployments, while they can also have performance issues, tend to be more related to export options than what their HTML5 tech is capable of, and it's just a matter of editing the right files after export to get the kind of performance you'd expect, considering the hardware in the console.

    There is also the extreme memory limitations of a game running in the background when using Construct w/ UWP, which is very low, and considering Construct has no direct way to clear memory to get under the limit (around 128MB*), you'd be pretty limited on what you can do anyway. As in, less than you could do in a typical mobile game (where C2 performance can also be...questionable). While the memory limit is obviously not just an issue with C2, providing ways to sneak in under it certainly is.

    This could obviously all change in the future, but I can't say I recommend waiting for something that *might* happen when there are tools available that can make it happen now.

    *EDIT: The 128MB limit refers to what's available when a UWP app is running in the background

  • Considering that C3 uses the same runtime as C2, there's little to no benefit in porting to C3 at this time.

  • >

    >

    > This about sums up my experience. But if you say it out loud, and they're using your game as a showcase piece for C3, expect them to pull it.

    > ¯\_(?)_/¯

    >

    Is that surprising?

    Why would they support you if you keep voicing negative opinions?

    Is there some process in your mind where saying things like that magically makes things better?

    You don't like something, then don't use it.

    Seems like the same logic they used.

    Right?

  • No. C2 is the last version of Construct I'll ever use. I'm currently learning C# and once I learn it, I'm not coming back. There's a few games I started in C2 that I want to finish, but I'm ok with remaking them in C# if I can't finish them by the end of the year.

    I feel betrayed by Ashley with the announcement of C3, and I'm not supporting him any longer. There's no reason for C3 to be in a browser other than it being an excuse to charge a subscription and call it a "service." Not allowing people to own a copy of the software they pay for and locking them out of full access of their games if they don't or can't pay yearly for the subscription is wrong in my opinion.

    I'm sure in a few years years, he'll ask where did all those people who were against the subscription model go, just like he keeps asking where all those people who supported Flash went years ago, and I'll answer him right now so he doesn't have to wonder for long... We moved on to better things.

    Best of luck with C3.

    This about sums up my experience. But if you say it out loud, and they're using your game as a showcase piece for C3, expect them to pull it.

    ¯\_(?)_/¯

  • That only supports two motors, and controllers have more now. And if I had to hazard a guess, you're better off on asking 3rd-parties to add support for things that would be useful for game deployment.

  • This applies mostly to mobile device vibration. I think the gamepad vibration spec is still under consideration. Gamepads have multiple rumble motors and this spec only references a single vibration target.

  • Ashley

    Are there any plans to add this to C2, since you've said it uses the same runtime?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • If you think Construct 2 can't handle graphically intensive games, then as ever, rendering is bottlenecked on the GPU. So if you switch tool because of that, the hardware isn't going to be any faster, and the performance won't be any better.

    I think some people switching tools have hardware-bottlenecked games and are eventually going to realise it was never C2's fault. I do see a lot of games bottlenecked on the GPU, and everyone knee-jerk blames C2, HTML5, Chrome, or anyone or anything else. I don't know why it's so hard for people to believe they've fully utilised the hardware? The engine is designed to let you do just that. I'm happy to be proven wrong, please send me your projects and all that, but it usually only confirms the point. I imagine some people will wander from tool to tool always thinking everyone's engine is awfully slow, never recognising that hardware is a limited resource.

    Just to pre-empt how this discussion usually goes: now someone's going to shift the goalposts and talk about some random bug or some quirk that we fixed, or some other problem they had at some point, or start listing their personal laundry list of things they want changed. That has nothing to do with GPU performance. On this specific point, C2 is as good as a native engine, and I stand by that.

    I shouldn't be running into bottlenecks on a 970. Or a 1070. Even the low-end target of a 750 (which should be lower, but can't be because of issues with C2) for Sombrero. If I'm running into fillrate issues in C2, that I don't run into elsewhere? That's a C2 issue. Period. Maybe the F2B renderer would have helped, but it was abandoned quickly and hasn't been brought up since. No point in waffling about on it - C2 is slower than the competition in getting things on screen. The reasons aren't especially relevant in the end.

    So, no. No shifting goalposts. C2 simply isn't as fast as native, or whatever you want to call what other tools are doing. This is aside from issues with getting games running on as many of the platforms people buy games on as possible, which is also less of an issue with other engines, aside from the frankly embarrassing "support" for the Wii U, which was anything but, or the longstanding (years?) mentions of XBox One support that are still nowhere to be seen in terms of actually being able to RELEASE a game on the platform, with the features gamers expect. If I had to hazard a guess, we may end up relying on third-party support for that platform as well, much like Steam4C2 is much better than the support Scirra provides for Steam features, despite both being based on Greenworks.

    I'm not talking about issues with HTML5, either; I'm talking about C2 specifically, and I suppose C3 considering it's basically just C2 with a different IDE, higher costs, more complex plugin development, and less flexibility for developers to do their own local builds with their own toolchains for NWjs on desktop & mobile.

    You'd think that every dev that's made anything of scale in Construct having to move on to other game creation tools would be enough of a hint, but stand by your point as much as you'd like I suppose. The people buying games don't care about a game's tech, as long as it works as expected and provides good performance. It doesn't matter how easy C2 may be to use to make games if they have far higher hardware requirements, and are limited to less platforms than similar games based on different tech, limiting their market.

    Anyone who ever got their hands on the WiiU + dev kit had learned quickly that C2 games weren't going to run well on it (especially anything non-turn-based/action oriented)

    Jayjay

    If memory serves, since I've long ago returned my WiiU devkit, this was due to Scirra's stubborn refusal to support the way the Nintendo Web Framework handled hardware acceleration, which was available for HTML5-based games. And didn't a third party actually have to finish implementing the framework, since what Scirra provided was the bare minimum of feature support, and not what NWF was capable of, even outside of hardware acceleration?

  • You say that, but there is an overwhelming amount of people who say otherwise. A lot of C2 developers have switched to Unity because of performance. Who should we believe?

    Performance aside, I think C2 and C3's biggest problem is third party wrappers. I haven't found a wrapper that I haven't experienced some trouble with. If C3 was native, you wouldn't need to rely on HTML5 wrappers. Construct is fantastic for browser games, but it's a real pain trying to get it to work on other platforms.

    Listen to the developers who end up having to move on. We're far more familiar with the real-world performance of C2 and the endless issues with getting it to run well on multiple desktop platforms, let alone mobile or console (which have no real support) where performance just isn't there for anything graphically intensive in C2. We also have less of a vested interest in sweeping the issues under the rug.

  • Changing the subfolder an object is in does not change the order in which they're stored in the XML file, or it's ID. You can look at the XML files to see this.

    As for "presumably" - yeah. No. Presumptions don't help solve the issue. Especially when they're not accurate.

  • > *quote snip*

    >

    > I didn't mean "behaviors" in the sense of C2 Behaviors. I meant functionality (through events) shouldn't be affected by what folder something is in. Poor word choice on my part.

    >

    The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

    There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.

    C2 doesn't export objects in folders, it's all in xml files, where they're stored in the order they've been created, regardless of the "folder" they're tracked in through the IDE.

  • For the 96% of devices, WebGL is native performance. It's bottlenecked on the hardware.

    This is 100% untrue blaming-shifting nonsense. Performance on even powerful desktop GPUs is around half of what native provides for larger desktop games, and saying half is being generous, and reaching only around 50% of native performance involved a LOT more work than it would using other game development tools; hell, there's not even a way to set the canvas resolution easily in a way that takes into account object positioning, because you've somehow convinced yourself it isn't necessary (even though native apps support this with switching monitor resolution out of the box), and only offer "low" or "high" settings. Blame drivers all you'd like, but it's what literally every PC uses, so complaining about and/or blaming them is pointless navel-gazing. Blaming the only ways to export games for poor performance is highly disingenuous, since they're the only way to export and sell C2 games. I can't even imagine the gaps in logic that allow someone to arrive at your performance comparison conclusions.

    You've hitched Scirra's wagon to HTML5, and that's fine. But let's not pretend it's even close to a mature technology, from a software/development standpoint all the way through hardware support, for the creation of medium-large games. The performance simply isn't there, and you're flat-out wrong to suggest it's remotely close to performance of native with anything more than a very, very simple game with absolutely no bells & whistles.