Disappointment and obstacles

I have debated with myself and I have decided. You are welcome to take a peek in my capx.

I have been talking about ideas on optimizing but I haven't tried to implement any of them because I wasn't really sure what is causing the slowdown. The version you have, have background image included. You are welcome to remove the object to compare.

Bunny in Space capx, latest version (r157)

Thanks. <img src="smileys/smiley27.gif" border="0" align="middle">

Also realizing I forgot to fix the bug with the ball escaping, sometimes. I have tried to fix but I discoverd my fix is not fixing entirely. ;) Gotta remember to figure out a better fix. :) Just wanted to say if you test and see that ball do funny bouncy "stuck" dance on borders.

helena,

My 2-pennies worth:

Nicely organised event sheets I thought (I wish mine were that well laid out). There are too many collision checks and too many objects on the layout for optimum performance in mobiles (348 objects iaw debug and 648 collision checks per tick!!) - this is very high for any game like this, I think (I would strive for a max of about 100 or so for a mobile game). Your use of 9-patches doesn't allow you the option of enabling or disabling collision checks on them: if I were you I would use sprites of different sizes and to fit that job and then I suggest disabling collisions for those objects not on the screen - that'll save some processing power and might make it more playable on mobile/ipad. Seems a bit odd that you can check for a ball collision with a 9-patch object but you can't turn the 9-patch collision attribute off if it's off screen.

The backgrounds have collisions enabled which you can also switch off in the properties bar...

In my relatively limited experience of using C2 it is excellent for producing browser based games that will be played on a desktop or laptop computer. The android/ios export options are still embryonic and, although do-able for a Nexus 5, they don't work well on an 'average' phone: you will get much better performance from using another development engine if your primary aim is to deploy to mobile. But - and it's a big but - C2 is an excellent development tool. Depends on your intended market...

Id lay off the 9-patch objects, and just use sprite for those.

Then you have some sprites that are just one solid color, those can be replaced with tiled bg.

Thank you for being the first one to examine.

That's why I decided to show the capx: I am a novice by almost 2 weeks now. :D

Background have collision enabled, that's no good. hahaa.

Too many collision.. mm not surprised.

Ok, will change 9-patch to normal sprites OR do away with them entirely, I am almost on verge doing it already because I do not want to make the special cover blocks for them too... But the hard block would work best as 9-patch.. maybe only that would be ok?

Thank you again, now I know what's eating power, and now I am gonna optimize the collision checks.

Thank you again, I feel humble.

and newt, ok! I will look up if it will work with tiled bg for the follow camera, and for the overlap checks.

I also realize now I can change many of the objects to tiledbg instead for sprite.. The purely decorative ones, non animated. LOTS of work ahead. haha.

Doing all nighter, so I need go and get some sleep.

But maybe you could help me with one small thing meanwhile.

I disabled collision on all the blocks by default. Then I thought if I could do like this:

At start of Layout:

LevelPositionSprite is overlapping Block: Block set collision enabled

(and have similar event after level change)

but nope...

But of course, I need sleep too. ;)

helena - I think you missed where I asked what version ipad and iOS you're running? While old hardware/software can obviously affect performance, some hardware/software versions do so more than others.

helena I have no IOS thingies so I can't test on those, but I think I have spotted some issues on the game that might at least partially explain the slowness of the game.

I don't want to sound too harash, but I try to go directly to the point and explain on simple terms what to change. I do hope that other forum users check my findings.

Firstly: Avoiding unnecessary collision checks that tax the CPU

• Block and FuelBlock type sprites have Solid behavior. It causes a lot extra collision checks (about 1/3 of the collisions at the first level according debug console!)
• Lots of other sprites (including all Fuel-tube parts, black walls and TouchCenter) have collisions enabled without any use.

Events 24+25 are IMHO a bit funky

24) Ball is overlapping with Paddle

-> Ball on collision with Paddle

25) Ball is not overlapping with LevelPositionSprite

-> System: Ball.X > Paddle.X + 30

(also disable collisions of LevelPositionSprite)

Drawing issues..

Many large fully transparent sprites are drawn, perhaps better set them Invisible? (LevelPositionSprite, Touchcenter, touchRight, TouchLeft)

And now I am back and I can do some C2 work again.

Arima: I am so sorry I forgot that one. My ipad is ipad4.

Joannak

THANK YOU for taking a peek too. You said many things I already knew by now, and some new things too.

Now I hope I can figure out the "find all the blocks in the level range and render them enabled in collision checks" :)

And now I am going to remove the capx from my server, thank you. I might add again later improved version.

I figured out the "find the objects in the range" I talked about.

Easy enough, object X Is on Screen... yeah. :)

I effed up with the saves, so I lost the changes I did with the sprites -> tilebackgrounds, so I am redoing it now. No biggie, I know what to do.

Sorry, old ctrl+v, whoops. Editing now, typing from memory.

I am spamming my thread, I know.

I have optimized the game as you suggested (I think I got em all, or at least mostly) and some my own optimizations.

I decided to give it in a try in cocoonjs, not really excepting anything. But now it runs at 45-60 fps, before 5.

I notice, the more blocks one level has, lower fps. As the blocks disappears, and less collision checks to do, higher fps. naturally.

Fifth level is ice block level and that's the slowest level, only 25-30 fps. And I spotted a couple of bugs there too. Other than those the game runs as it should.

I feel more optimistic now. Thanks.

Grats.

helena Good to hear that the optimizations have indeed helped. I do have couple more points for the future (if you'll need)

When making collision checks, use square bounding boxes when it's feasible .. I noticed that many Sprites (Paddle and Ice blocks at least, also some other) use polygons.. Those complex polygons can eat (relatively) much CPU power but won't in real world affect the game play much.

Expecially check, if you could get some speedup by simplifying the collision polygon for the ball, since it's making most of the near.miss collisions during came.

As a visual note.. At least on previous version the paddle was light pink. It's nice color, but can cause quite a lot a eye stress for people trying to play your game. Especially when the background is light green. Also, please take into account the fact that quite many people are (partially) color-blind and details like that can make game unplayable. Perhaps you could add some extra color/contrast to the paddle so it would be easier to see.

Joannak, thank you, yet more suggestions!

Good thinking about the polygons. I am going to look at this, I think polygons is unnecessary in many cases.

And about the graphics. Oh, do not worry. I agree it is not ideal and I think it is straining eyes too, but now basically everything is placeholder sprites with exception for the blocks and their stuff, and the tube. I am also gonna replace the ball, I am not happy with it because of same reason you mentioned.

Regarding the tube. It is fuzzy now when I replaced it with tilebackground instead for sprite. Have to look it up.

Joannak, btw, have to give you compliment, you seem to just have been here basically as long as me but you already are like a guru. Wow, color me impressed. :)