Disappointed over bad communications!!!

The issue is theres very little ashley can fix atm, and im afraid soon unity will have similar woes as their web export is going to have to be webgl due to the deprecation of plugins. This should involuntarily put a lot of pressure on vendors to fix crap.

QuaziGNRLnose good point. I recently noticed Unity moving to HTML5 as their web base. Also note: Unreal Engine 4's web export also uses HTML5. Heck, even Game Maker's web export is HTML5.

However, while Unity, GM:S. and Unreal have HTML5/WebGL export features, as far as I know they all have a one-and-done solution for mobile where Construct 2 is not even close.

In the very least, I suppose we should be happy that any web-specific "woes" should begin being hammered out simply by the fact that the top powers in the game engine world are either all turning to HTML5, or have already done so, rather than external plugin solutions.

Nesteris A very old post. With my English broken beyond repair. The whole topic was CC related but... Keep reading. Suprising how many similarities it has...

Best thing to do is to just use C2 for only desktop games in spite of what may have been indicated by Scirra in regards to mobile export / performance. You will be happier The wait on these technologies that don't really care about gaming (e.g. chromium) is not bound to make you happy any time soon.

In fact I'd bet that it's extremely likely that C2 will be deprecated / abandoned for C3 by Scirra way before web technology is developed enough for C2 to put out reliable mobile games. At least at the rate we're going now. I imagine C2 will stop being developed so will eventually fall out of compatibility with the always-evolving web tech. But C2 is still a great tool for 2D desktop games, so focus your energies on that. It's kind of a shame but it is what it is.

Oh you mean like this bug report that I totally didn't submit? You know this never got fixed either, at least fully.

Well let's be realistic here: if you want an audio bug investigated, you can't have any other logic for other features of the engine in play because you have an audio bug!

This implies that if there is a bug, it is likely something you did to cause it - like maybe a bullet is going the wrong way for audio to work correctly.

But what is really happening is there is a glitch behind the scenes in the engine that is conflicting between audio and bullet. So if you submit a capx with just audio events, you won't be able to reproduce it, and therefore nothing has to be done except close the bug report - yay problem fixed!

There have been numerous bugs with audio that can't be reliably reproduced with a dumbed down capx. And because of that they will not get investigated, let alone sorted out.

That however doesn't mean it isn't a C2 bug, it just means you can't reproduce it with a couple of events and no other behaviours in the project.

Woah! As a newcomer to Construct 2 and after reading throughout this entire post, it seems that the root of the problem is the lack of any other programmers. Seriously, with my time here, I've learned that there's only one or two people that develop Construct 2? I mean it's quite impressive at first but now it seems like that's beginning to be the problem. Yes, it is your product and you can do whatever the hell you want to do with it, but for a product to advance and a company to flourish you need helping hands that aren't just your customers.

You've ridden this solo for long enough, it's time to get other people involved with what you're passionate about, in order to improve it.

As for my experience with Construct 2, and using it as a mobile video-game development tool. It's been going. That's about it. I've gone through so many game ideas and thrown away so many. NOT because of performance issues, simply because they were just bland game ideas. Although, now that I've gotten a grasp of what I want, I soon lost myself within game development and began testing on mobile with a physics based engine game. Constant testing soon revealed that I do have to be frugal on what I can do, or at least smart on how I go about doing it.

I think the root of the problem is less to do with additional help and more to do with problems out of Scirra's control. Perhaps this is why Ashley has decided to spend additional time working on a new editor in the meantime. I have been using C2 since the early adopter period and if I wasn't already aware that they had such a small team I would never have believed it.

One of the reasons that C2 is so great in my opinion, is that it allows you total freedom to do whatever you want with the events. This is why when you report a bug it has to be minimal, the potential for user error is huge (and I'm sure all of us would rather Ashley spend time productively as we reap the benefits).

Maybe what we really need is to focus our energy into pressuring Chrome and other 3rd parties Scirra relies on to work as intended.

> so why do games wrapped with CocoonJS Canvas+ are faster than games wrapped with Crosswalk?

>

I don't know, it's a closed source engine.

Well, we have already said it several times. It is precisely because it is not a full browser. It is designed for a fast gaming experience.

Out of curiosity... Tom Ashley how much time it would take for your guys to create a working, native desktop wrapper like Nodekit? Pure desktops. Win,linux,mac. Nothing else. How much time/money you would need?

Serious question.

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 >_>