Disappointed over bad communications!!!

Irbis

It's not really possible. You need tons of engineers to get it done right and maintain it consistently for the unbelievable number of hardware/driver configurations. It'd never be better than NW. A better option would be to implement a proper native engine with SDL to handle the main issues of cross platform but it's a huge undertaking.

The situation on mobiles has gotten better, but only for iOS.

Android, we're still stuck with Crosswalk 7 because the more recent ones are based on a buggy Chromium, leading to erratic and terrible performance. Performance hasn't gotten any better since around Feb 2014. O_o Not that it was any good to start with, just tolerable with a lot of optimizations.

Also, physics is still a no-go for mobiles. There must be something inherently flawed, its as if the physics isn't hardware accelerated on mobiles. I've used native box2D in Eclipse before, it handles hundreds of physics objects on a weaker mobile. Try the same in C2, we're talking single digit objects.

> I had to quit just one game because of the performance, but because I was using a lot of graphics in HD

>

Lots of HD graphics is a classic case of hitting the GPU fillrate limit, which is a hardware limitation. This is exactly what I was talking about: you seem to think it's HTML5's fault and that a native engine would be faster, but it would still have the same hardware limitations. It's entirely possible this type of game would perform exactly the same in a native engine - no faster at all. This adds to my skepticism when people ask that we develop a native engine. It is not a magic bullet that makes existing hardware any better than it is.

well, I'm not so much expert about hardware and something like that... but about the logic of programming I'm good...

the project was this:

The problem of the html5 I think is the memory management and how the browser load all of the game... the browser have to load everythings... for example, I tried to make the same project in other software (not with all the logic, just graphics and platform gameplay) and works fine...

when you have to load 600mb of picture, the browser start to have some problem...

anyway, I know the html5 in the future will be better, a lot more, and the tecnology need to be better, and the most user who have the same problems, is because how they made the game...

another project I made with cocoonJS, works very well, and I load a loot of sprite with a very good graphics, and In my iphone5s run in 60 fps...

Ribis in the scope of C2, unless webGL is off, the game is not entirely loaded into memory, it only loads the assets that the current layout is using, and unloads the ones that will not be used on the next one when swtiching layout.

Ribis in the scope of C2, unless webGL is off, the game is not entirely loaded into memory, it only loads the assets that the current layout is using, and unloads the ones that will not be used on the next one when swtiching layout.

About that...

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

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

And what did we all have for breakfast?

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.

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.

—

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.

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.

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.