Would be a case of disabling collisions with the physics objects when certain conditions are met, wouldn't it?

is not overlapping?

Dear friend,

i have tested myself....

Create a video in mp4 about 400x300 pixels....but the size should be 1,6Mb (H.264)

Ok now you should Convert From mp4 to gif here: http://www.zamzar.com/ and became 5,5mb if i don't make errors,

Then you should Optimize your gif here: http://ezgif.com/optimize choose heavy optimization or what you want....and the gif became with this program.... 3,2Mb... that is enough.....Ok.....

OK ... The quality is not the best... but work fine.....

Best regards,

Lestroso <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy">

http://www.fasasoftware.com

That is the size of the file, but not the amount of graphic memory that will be needed.

In memory all files are completely decompressed, so while a small image file may be helpfull for downloading, while playing it's size is not related to that but to the actual image size in pixels times 4 bytes (R,G,B,alpha).

give the object timer behaviour

ball on collision with box

• object set speed to 300
• object start timer tag: morespeed

object on timer : morespeed

• object set speed to 200

I don't understand the gravity question, sorry..

Doesn't the system pick all event work for families?

Or just giving the family the effect instead of it's members?

Sometimes could mean there are conflicting events sometimes..

So providing a capx would be the best idea..

Many different ways

on touch start

bullet is not overlapping object- shoot bullet

on touch end

bullet is not overlapping object- shoot bullet

is touching

bullet is not overlapping object

system trigger once - shoot bullet

From a video of 400x300 pixel after it process described before from original mp4 of 1600kb is become to gif with 3600kb, that is good...

In preview over wi-fi my gif works fine ..about 30 seconds with about 334 frames and then i have added the soundtrack...

Simple calculation based on this info:

334 (frames) x 400 (pixels width) x 300 (pixels height) x 4 (bytes per pixel) = 160.320.000 bytes = 160 Mb of image memory for this animation.

I think this explains why this is a very bad idea..

I'm not sure if what I'm asking is possible or even should be tried, but would there be a possibility to limit the fullscreen feature to a maximum size?

The trouble I'm having is that while perfect on mobile the sizes of the sprites in my game make them look like childrens toys on my PC..

I'd like the game to be played from the internet in a browser, both on mobile as on desktop and limiting the amount of blow-up on PC might solve my issue..

I guess if at all possible it would require some tinkering within the index.html file.

Anybody got any ideas or is it a case of back to the drawing board/accept the limitations?

My guess would be particles..

Many many ways to do this, but a simple first solution would be to give the sprites an instance variable (let's call it movepixels) and set it to the amount of pixels you'd want to move it..

then on clicked - move sprite.movepixels pixels

now it should be different for each box (if you set the variable to different numbers, that is)

The flash is now set up to happen when player.y<enemy.y and the platform is not falling..

I guess you'd want the else statement somewhere else..

moving the condition player.y<enemy.y to the subevent platform is falling would do the trick for now..