Disappointment and obstacles

  • You are both fundamentally wrong. Obviously mobile devices (even laptops) don't have the power of most desktop computers, but that is not the point.

    The point is nobody using HTML5 and C2 is going to hit that limit. HTML5, and the JavaScript C2 produces isn't going to win any awards when it comes to performance.

    Kyatric, the missing gameplay isn't a concern. The stuff you mentioned rarely takes 3% or 4% of most games.

    Again, it is an excuse. When you are able to program something like "Infinity Blade" on a mobile device, then you can start talking about limitations.

    Although I doubt anyone would be complaining at that point. It is the not the limitation of mobile devices, but the limitation of HTML5 that is the problem.

  • Why are you here?

  • Why are you?

  • I am here because I thought it would be good platform for me, because I do not work well with normal typing syntax coding.

    I do not know where else to go to make ios apps and out of the three software I reviewed I liked Construct2 best so I bought a license.

    But I also like that I can make for web so it is a good fallback, even if it is just for fun.

    I now understand HTML5 is not exactly the gaming platform. Hey, if I did not know about this I would say "HTML5?" Isn't that HTML, hypertext markup language? Website pages? haha. ;)

    But apparently it is possible to make games using HTML5 or Construct2 would not exist, right?

    And apparently you should be possible to make stuff for iOS or else there should not be any exporters, right?

    Maybe it is a matter of 1. optimizing, optimizing, and 2. wait for wrapping software to catch up and optimizing THEIR code too.

    Oh, nevermind. I am happy you got into a discussion in my thread. So I am not just whining for no reason. But of course, I am doing the classic newbie mistake: see "make your own games", come of beautiful ambitious ideas of making games, trying to make it, only to get the hard truth thrown at you for your too ambitious ideas. ;)

    Now back to my project.

    The thing is that even if I removed the background (entirely gone nothing left, not even the object itself), and just it be empty layout, albeit still long strip, the game is ssllooooow at same fps rate in cocoon. So I start to wonder what's causing it to be so slow. Is the

    bullet behaviour causing this maybe?

    I have checked the event list for "every tick" and there's none.

    Or would it be all the collision checks?

    The "splash" animations every time the block is hit and some more similar stuff?

    I wish I had a separate monitor because my 5:4 ratio monitor... I can't see the debug window AND play at same time. ;) I can change windows, and see, but not see in action. hahaa.

    Now I have shrunk the level strip from 20 to 10. So it is 7680px high.

    Funny thing is that in my normal firefox browser on my desktop computer, when I had one solid 1024x15360px background it is less "choppy" than when I removed that and placed 10 pieces of different backgrounds 1024x768 each. (level shrunk since that). Or maybe it is because of my addition of ice blocks and its snowflake particle effect and animations..

    If it is the block's fault then I had an idea that may require quite a lot of "coding" but is to store all the block positions in array (or something suitable) and load the level's blocks when you arrive to that level, destroying everything else. But of course, I have to update the array when player destroy blocks, because my game allow to go back in levels as well as forth... Do you think this will improve the fps? Right now I only have 5 screens out of 10 filled with blocks, though..

    Or somehow, set the blocks outside the level area to not be checked for collisions.. hmm.

    Back to making ice block animations.... Yet more.. lol. This for the "gleaming" effect once in a while..

    And CTRL-C saved me.

  • helena - sounds like you've walked right in to the mistake outlined in that blog post Arima linked to (Remember not to waste your memory). A long epic background might be really cool, but mobile devices often don't have much memory and you have to be smart about how you use it. If your images are over 2048x2048 that can also severely impact performance on some devices, and missing images are probably out-of-memory errors. There are good ways and bad ways to design mobile games; desktop PCs can generally muscle through anything at all, but mobile devices can't, so you need to be careful how you design your games and test regularly on mobiles from the very start. If you share your .capx I could comment in more detail about what might be slowing it down.

    stevefromio - if you're so convinced that HTML5 sucks, perhaps you would like to select a different tool for game creation, and post in their forums instead.

  • I want to repeat that even with the background removed it is still same slowness. >_<; I might share capx but I would rather do it personally. Just let me know.

    Right now I am going to try to get Ejecta working and see if it is any better than cocoonjs.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • stevefromio - if you're so convinced that HTML5 sucks, perhaps you would like to select a different tool for game creation, and post in their forums instead.

    Ashley, how old are you again? I love Construct 2, and HTML5 is great, but there are other options, especially if someone is having problems. Chillax dude.

    Steve

  • helena - which ipad and which version of iOS are you running? I understand your reluctance, but posting your capx would make it easier to determine the problem. You can try deleting stuff until it's unrecognizable or the problem goes away to get some sort of clue.

    You are both fundamentally wrong. Obviously mobile devices (even laptops) don't have the power of most desktop computers, but that is not the point. The point is nobody using HTML5 and C2 is going to hit that limit. HTML5, and the JavaScript C2 produces isn't going to win any awards when it comes to performance.

    It actually is the point of this thread. Helena has a game working fine on her computer but not on her mobile device. The reason is the difference in power.

    As I mentioned, even coding natively won't help you if you do something like try to use more memory than a device has. It's true that JavaScript is not as performant as native objective c, but neither is action script, and that fact is true on desktop as well. It's simply a limitation that has to be taken into account when designing a game. The fact that desktops are so much more powerful makes the performance difference for JavaScript vs native on the desktop pretty much irrelevant.

    Kyatric, the missing gameplay isn't a concern. The stuff you mentioned rarely takes 3% or 4% of most games.

    No. Just... No. This is wildly untrue. If it were the case, then we could all be running the latest games on pentium 3's. Just having pathfinding alone would put a game way past the 3-4% mark. Add collision detection, ai and everything else and then multiply it by the number of instances on screen to get a vague estimate of how much CPU it'll use. It's a lot more than you think.

  • I wouldn't dare argue with a moderator.

  • You seem to be missing the point of what we're telling you (and it's beginning to seem intentional), so let me try to make this as clear as possible: your condescending and rude tone, attitude and behavior is the problem here, not your points.

    Don't be rude and you can discuss things with moderators and everyone else just fine. There's no need for rudeness. It just makes people unhappy and derails discussion.

  • Redacted due to foot-in-mouth disease.

  • This is my thread and maybe you can agree to disagree? :)

  • Sorry Helena, I hope it works out for you. If not, drop me a line to consider other options. Construct 2 is a great tool, and you should hopefully get this worked out soon.

    Steve :-)

  • Thank you. :)

    Realized only now that I have to pay 99$/year to Apple to test on my real ipad, through Ejecta. Not that I got it working on the mac, it get stuck at the login screen (game center) <img src="smileys/smiley11.gif" border="0" align="middle" />

    At least I am progressing nicely with the normal version. The question is however if I should still try on optimize before adding things or get down the basics first. Got another idea for special cover-blocks.. block with dropping that freeze the paddle for a while.

    Another solution is to make the web game nicely and then present it to someone more capable in proper coding and team up.. haha. But I like to develop.. ahh. :D

  • Just realize that you are doing everything right. This happens to all of us using browser technology. I been doing it for 15 years and you should see my white hair. It will all work out for the best in the end.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)