I have a small question, why use db for unit of audio volume? instead of a linear number.

It makes sense for some applications when dealing with signals that can take values over very large ranges, but for applications intended for PC or phone speakers I agree, it's not very useful.

Some of you guys believe you can have all this...

1- A cheap solution (yes C2 is really cheap considering the updates and how the scene is moving fast).

2- Not learning programming in c#, java or js, everything must be click and drop.

3- An intelligent assistant to tell you how to do events correctly and how to not use 5000px sprites for mobile.

4- Push a button and magically it will export to all possible mobile devices with a perfect fps, with feature parity (and multiplayer too! ).

I understand the hope, but you have to be realistic in your expectations, even if it is hard to accept : you can't have it all today.

To make a polished and fun game in the mobile world today, it is a lot work or experience, or everyone would be able to do it.

And the comment "pay 10k to make exporter to iOS, android", is naive at best...that about the min. monthly salary of a capable developer. If it takes years to millions-dollars-funded companies to create exporters, it is probably going to take a lot more than a month to one developer.

The only thing I expect is what Scirra says their tool can do on their pages. It's not living up to that promise.

I don't think I was clear. I was looking for an object that can be resized in both the way a tilebackground is, and a sprite is. Not one command that does both, but I want to have both options available. If this is still unclear an easy way to understand what I mean is to take an image, and make a tiledbackground with it, and then also make a sprite with it. Resize each one in the editor and see what happens. The only difference is that I don't necessarily need it to tile repeatedly.

It looks like I can do this with Rojo's spritesheet plugin by modifying the width and height vs the subwidth and subheight.

Is it possible to crop a sprite at runtime? I want to shrink a sprite without actually shrinking the image, but cropping it as the sprite gets smaller. Exactly like what tiled backgrounds do when you shrink them, though I can't use those because I also need to be able to resize the sprite in the regular way.

So in essence, is there some way to get both of those functionalities in one object? Perhaps another plugin I'm not aware of?

The engine can't do it on mobiles because the exporters are lacking. Why do you want to argue semantics?

It's not semantics. That's like saying "the engine can't do it because it's actually incomplete, even though we advertise it as complete". Whereas you are trying to imply that "some engines can't do stuff, that's totally normal." A 2d engine can't do 3d stuff, that's acceptable. I wouldn't complain about that. Advertising that you support mobile and implying that it's ready for production when in fact that's not true is not acceptable. Advertising that you have a 3d engine when really it only does 2d would get complaints.

EDIT: Specifically there is no reason to think that 'HTML5 is not ready' unless you have already used the wrappers C2 depends on. So if it tells me it's ready for mobile, without being able to test it I think it's ready for mobile, and I buy it. For all I know before buying it, the HTML5 implementation C2 uses could easily have been ready for production. There is no global reason to assume that just because it's HTML5 it's not ready. People only find out it's not after they pay for it, and this leads to complaints. This should not be hard to understand or seem unreasonable.

Me saying HTML5 isn't there yet is not equal to saying its defective. It can't do everything you want it to do. Neither would any game engine in fact. You work with what it can do.

To me with comments like this it just seems like you don't get how this works. HTML5 is not an application to be ready or not. It's a specification. Specific implementations are ready or are not ready. It's not that HTML5 can't do something in this case (though there are things that can't be done), it's that EVEN THOUGH html5 spec includes these things, Crosswalk/Ludei wrappers do not fully support those things yet because they are beta products. In essence it's like someone selling an incomplete runtime with unstable basic features as a complete product ready for deployment rather than a beta, leading people to believe it's generally complete and stable. It's not like an engine not having a feature, instead it's like an engine misleading you that it has stable features when those features are actually heavily experimental. This is true with C2 and mobile, and it's why you get so many complaints. Talking about "Oh the engine just can't do that" is just .. well it's just so off the mark I'm not sure why you insist on continuing this when you are clearly not appreciating the issue.

The question is, what kind of game do you want to make and is it possible with C2 and Crosswalk? If it isn't, you either change your game or you look elsewhere. That is the price you pay for using a HTML5 easy to use game engine. The price is compromise because again, HTML5 isn't there yet.

I understand that I can use another engine. I am doing just that. I don't see what that has to do with anything. C2 advertises its ability to make mobile games and doesn't say that HTML5 is not ready, instead Ashley preaches the opposite, that it's the same as native and blah blah blah. People use their money to buy it based on that. So they have every right to expect C2 to be able to make games rather than serving as a beta test for some buggy third party export wrapper.

Anyway I think this conversation is useless. People who buy a product because its advertised to be able to do something will complain when they can't do that thing with the product. You coming into threads telling them to go buy another product or that the product is fine because YOU are not having problems so therefore any problems they are having are not due to the product is just useless. I don't see why you do it, and I don't see how you can justify doing it without offering to buy them the other products you are recommending or at least covering their C2 expense. If you're not buying them another engine, covering their C2 expense, or fixing their bugs, there is no need to reply to their complaints.

When did I say Crosswalk doesn't have bugs? Are you kidding me? I noted it was improving quickly.

When you design for mobiles you compromise, especially so with HTML5.

Ok, improving quickly, but then your whole 'if someone isn't having problems then you shouldn't be either' stuff is both unnecessary and missing the point.

As far as your second statement, again missing the point. The test game I'm making for mobile would have no issues with a better export solution. So you only have to make sacrifices when designing for mobile if using C2 with such simple games. Using another engine this would have no issues, it's just so simple and not a real game, just a game designed to test the state of C2 before investing into a real project.

Anyway I'm not really interested in convincing you, I'm just interested in you understanding that your experiences do not represent other people's. For many people, C2 is not working as advertised. And those people just don't care that it's working for you or that you're willing to excuse its shortcomings.

If we're not talking about bugs but actual engine features, then if I use a particular native engine and I want to do Z and it doesn't do it, do I then blame that engine also? You do what your engine is capable of, if it isn't capable of doing what you need it to, then use another engine.

I'm not sure what you're not getting. HTML5/WebGL implementation in chrome / Crosswalk are incomplete, especially so on mobile versions of chrome. It's not that 'the engine is not capable', e.g. I can do a lot of the things on the desktop version of chrome / node-webkit. It's just that wrapper C2 depends on for mobile is in a BETA stage, Crosswalk labels itself as such. And yet here you are telling people that they aren't experiencing bugs, even though crosswalk itself calls itself a beta wrapper.

And if you use a native engine and it has bugs... what then? Here you assume its the fault of the engine itself. What if its not and its the fault of your implementation? Because I see other people's game running fine on mobiles, i would therefore have to assume its not the engine's fault. It may be a wrong assumption to you, but to me, if I see others achieving something using the same tools that I am but I am not achieving it, I assume its me and not the tools.

Lets agree that things could improve more and leave it here.

Your assumption that 'if someone can do X I should be able to do X' is not just a wrong assumption to me, it's a wrong assumption period. If someone can do X I can also do X, but I'm actually trying to do Y and not X, so your assumption doesn't apply. That's the whole point. The fact that you have no problems because you're trying to do X doesn't mean that someone trying to do Y won't have problems.

If I have a bug in my own implementation, which is surely possible, I can send code to other users to look over or look over it myself. But I'm talking about known issues in html5/webgl implementations of chrome, on which Crosswalk depends.

>

> The difference is that developers of said engines / exporters, native or otherwise, are working to fix those bugs, acknowledge them, provide timelines for fixes, etc. C2 tells you to 'hope for a brighter future' and some sort of Messiah like Intel or Ludei because they themselves are unable to do anything, given their setup.

>

Intel XDK have been very good with their feedback handling, they have given estimated timeline for fixes and have delivered. Currently its able to handle large complex games, audio issues are fixed, screen orientation fixed and its improving quickly.

Certainly its true, Ludei have been left wanting.

And maybe Intel will be the solution. Maybe not. We're still not there yet, for me, I have a well-done, optimized, polished mini-game done but publishing is not possible at the moment because of remaining bugs. So again, your assertions that things are fixed are not really relevant to me. And because of that I wouldn't even dare think to start a serious project in C2 for mobiles.

I was actually originally hoping to port the MOBA-style combat engine I built in CC to C2, but it's a big project and given my mini-game doesn't perform, I don't wan tot invest the time. Instead I started porting it to unity.

For starters, I am personally inspired by Magnetized and recently Street Kungfu, it just shows what one person can do quite quickly with C2. The former is already a success while the latter is new. I don't have a giant list for you, but I only need one, because if one man/game can do it, that gives me inspiration to work harder and be better. Again my view may differ to yours on this.

All of the issue you posted are not unique to C2 sorry, native engines have heaps of bugs too and plenty of device crashes. All you need is to view the feedback of users on even popular games made by massive companies. The fragmentation of Android is to blame. No matter what tool you use, you will be bug-hunting.

The difference is that developers of said engines / exporters, native or otherwise, are working to fix those bugs, acknowledge them, provide timelines for fixes, etc. C2 tells you to 'hope for a brighter future' and some sort of Messiah like Intel or Ludei because they themselves are unable to do anything, given their setup.