Disappointed over bad communications!!!

If we add global warming to the discussion ... we likely have covered just about everything >_>

And what did we all have for breakfast?

Ashley, not to be a pain, but just hoping you got my emailed *.capx. First one went through without most of the text, but I sent one the other day with attachment. I figured a few business days, but I'm getting a bit edgy because I simply cannot figure out what's wrong. : p

Between C3 development and C2 maintenance I'm pretty busy at the moment, please allow me a couple of weeks to get round to those .capxs.

Alright! In the mean time I know what to work on. Thank you for the reply. : )

Reading through the many posts I can understand the frustration that games may not be running smoothly when exported to mobile devices, I'm in the process of developing myself, but not at that stage yet.

Due to the way Construct works and provides users with a very simple way of game creation, I think a number of users abuse this and fail to optimise their product & a lot of the fault is their own. You can't really expect to create something & throw together numerous Hi Def sprites, god knows how many particle systems and physics going on, without testing, testing, testing and expect to work as you think it is supposed to in your mind.

I think a lot of users take for granted that they do not have to use/learn code in Construct 2, a coder will optimise, refine & sacrifice elements of a game to get the performance results they need on other platforms, where by it would appear by the numerous posts Construct 2 users seem to think they can get away without any of this?

There are always alternatives out there, so you could always learn to code and use an alternative engine, I’m no coder myself & unless I want to put the 10,000 hours in to become proficient, then Construct 2 allows me to experiment & potentially release my ideas.

troxx, my issue with mobile comes from engine specific issues, I believe. After r196 as other users have even noted, physics have become unstable. My game otherwise is 320x320, uses 16x16 sprites, and a tilemap also of 16x16. I mean damn, that is about as low res as it can get!

So that is why I need a professional eye.

DatapawWolf

Because of the way modern engines work, the difference between small sprites and big sprites in rendering time is usually pretty small, the main issue is with screen resolution and pixel shaders. If a pixel shader is covering more pixels thats what's going to slow things down, much more than just having a large texture. This means if a low res sprite is stretched it's still going to have almost the same GPU cost as a un-stretched high res sprite with a pixel shader, if that shader incorporates any kind of blending (and i'm pretty sure even if it doesn't blend). Modern engine architecture generally means tiles are more expensive than large quads, so it's not really a fair comparison to say just because your game looks lo-fi and has tiles like 16-bit era games it should run better. Tiled images are actually a lot more expensive in most cases than a chunked "Braid style" map, if you're not counting the memory savings.

Really the issue is that mobile CPUs are slow and a physics engine running through JS isn't going to be able to squeeze a ton of performance out of a mobile phone, especially running on-top of the expensive event/picking execution system. There's a performance tradeoff you get just by using construct, even if you barely have anything in your project.

QuaziGNRLnose since the update I specified there was a slowdown with something I am using (and I suspect physics because it's the only intensive behavior I have). Nothing, nothing at all had been updated besides one revision of the C2 engine, and all of a sudden I started having issues. Other users as well.

Also, I was just springboarding off the last post based on my assumptions about the resolution of graphics affecting the cost on hardware. It's good to know, so thank you.

Again, this is very frustrating, I still have no evidence at all of any slowdown with the Physics behavior. Mozilla have done benchmarks of the asm.js version that show it performs within 1.5x of native performance. Until I see evidence to back up claims that physics is slow, I can only assume you are either using physics so intensively that a native engine would struggle, or that really something else is the problem.

Some people blame the Platform behavior for being slow too. Likewise, I have no evidence of this.

I think there is a tendency to blame things for being slow without really understanding what is happening. If you think something is slow, use measurements to demonstrate, and share your results and the .capx you used.

Again, this is very frustrating, I still have no evidence at all of any slowdown with the Physics behavior. Mozilla have done benchmarks of the asm.js version that show it performs within 1.5x of native performance. Until I see evidence to back up claims that physics is slow, I can only assume you are either using physics so intensively that a native engine would struggle, or that really something else is the problem.

Some people blame the Platform behavior for being slow too. Likewise, I have no evidence of this.

I think there is a tendency to blame things for being slow without really understanding what is happening. If you think something is slow, use measurements to demonstrate, and share your results and the .capx you used.

Not using any of these behaviors and not sure if they are slow etc, but in general you're asking a bunch of beginners to figure out what is going wrong, which I think it's tough in many cases. Maybe have a process where you instruct them on using the profiler (give a case-specific example for each complaint?) to determine if a particular behavior is indeed the issue. The profiler itself may need to be more robust, e.g. to break down the top events that are using most processing time, so something liek 20 % on A, 10% on X, 5% on Y, 5% on Z, and 60% on everything else, with the ability to expand the 'everything else' category. This might make it easier for people to optimize their games and isolate true issues vs perceived ones. I'm not sure how possible this is with C2 but I know coding some intensive simulations in MATLAB the profiler that lists each operation line-by-line and % of computing time it takes to be invaluable in isolating these issues.

I submitted a bug report which was dismissed because it compared results in the smoothest renderer known to current c2 users - nw 10.5. I followed up with an example of frequent frame dropping in modern browser versions but the report was already dismissed and the results ignored.

Ashley, how do you measure high performance in physics behaviour? Being within 1.5 of native speed is useless to a game dev if every 10th frame is dropped and causes janking on non-NASA hardware. My bug report showed some quantitative evidence of what many users have been reporting here, that r196 reduced c2's game making potential (measurable dropped frames), even if the update increased the total number of objects that the engine could run at a janky 30 fps.

I just want a few objects to be rendered at a smooth 60 fps by the physics engine. I don't think the x thousand objects at a janky 30 ish fps is representative of how c2 will normally be used....

Juryiel it's not just experience. I usually don't have time to just sit down and write out all the tests involved in both comparing versions and creating a detailed bug report.

My game has been something I have been working with on the side, and this issue has only really come up in devices that are less powerful than my laptop. So of course if after 6 hours of work I export and only see ugly pauses in my game, I need to move on to homework or whathaveyou.

I will get something together as soon as I can. My plan is to simply export for web in r202, and then r195 - both the same exact project. And neither of them use anything implemented in between so I shouldn't have issues there. This should be the quickest way to get something visible available.

Edit: also, just to clarify, I keep saying this isn't a slowdown, but tiny obvious moments of lag that don't make the game unplayable, rather, frustrating.

I mean hell, otherwise physics area great!!!!! It's simply this one issue. That's it. Performance is AOK otherwise.

Juryiel it's not just experience. I usually don't have time to just sit down and write out all the tests involved in both comparing versions and creating a detailed bug report.

My game has been something I have been working with on the side, and this issue has only really come up in devices that are less powerful than my laptop. So of course if after 6 hours of work I export and only see ugly pauses in my game, I need to move on to homework or whathaveyou.

I will get something together as soon as I can. My plan is to simply export for web in r202, and then r195 - both the same exact project. And neither of them use anything implemented in between so I shouldn't have issues there. This should be the quickest way to get something visible available.

Edit: also, just to clarify, I keep saying this isn't a slowdown, but tiny obvious moments of lag that don't make the game unplayable, rather, frustrating.

I mean hell, otherwise physics area great!!!!! It's simply this one issue. That's it. Performance is AOK otherwise.

I agree, I think Ashely makes it very hard to actually bug report stuff. I think as a user, I'm not going to sit and blindly try to replicate a problem in some blank capx from scratch, or generate some tech demo illustrating some problem with C2 / HTML5, especially when it could be due to things interacting, but Ashely won't look at stuff otherwise, and is generally dismissive of bug reports without an extremely large amount of work done by the user. It's actually really strange to me especially when the number of complaints about similar things is so large. I think the profiler type thing would maybe help us provide Ashely with evidence without having to rebuild various things from scratch, and may help us to better isolate the problems. With that said I have given up on submitting any bug report, I am not here to put all my effort to beta test C2 and develop tech demos to emphasize bugs, especially considering how easily and readily they are dismissed without investigating. C2 really is the worst in terms of support I have ever experienced in a paid software package. I think the team is just too small for the number of customers they have I guess.

Maybe some compromise is possible here; I understand why Ashley normally has those specific standards for bug reporting, but perhaps in this case those standards could be relaxed for everyone to help each other get to the bottom of this one issue. Given that the jank/lag anomalies seem to be troubling to so many here, and doesn't seem to be going away on its own.

—

when I see quotes like this:

[quote:1e6w6cil]I'm not really interested in testing old node-webkit versions, since Chrome updates usually improve performance

I have strong feeling that Ashley really lives in some alternative reality

Juryiel

[quote:1e6w6cil]With that said I have given up on submitting any bug report, I am not here to put all my effort to beta test C2 and develop tech demos to emphasize bugs, especially considering how easily and readily they are dismissed without investigating. C2 really is the worst in terms of support I have ever experienced in a paid software package. I think the team is just too small for the number of customers they have I guess.

+1