The speed of light exists because that's the maximum speed this simulation can buffer environments for rendering and collision detection.

Since we are all Game Makers, what do you think ?

Maybe this whole world is Construct 3000 and our Lord Ashley Gullen [Not in this simulation, but the big BIGGER one] decided that 299 792 458 refresh rate is more than enough to account for all Box2D/3D/4D Plus Time Collisions ;p

I hear you Prominent, but I am actually worried about resolution, I made a game called "Pigazoid" on Apple and Android two years ago and I spend 90% of the time [excluding graphic creation time] on technical issues trying to get these two devices to run Pigazoid smoothly using Actionscript 3[Flash].

The experience was so bad [because I find myself programming pixel blitting and various hacks over and over again to juice out whatever little performance I can get] and the resolution was too late a decision to change that I have learned to take the resolution decision very seriously now.

Sorry to link to another forum, but because I was getting ready to make a Platform game for this:

I started searching around to have a sense of the resolution that most games are created on to balance speed and graphics.

http://www.rage3d.com/board/showthread.php?t=33917070

This post is an eye opener.

Apparently even today's title are released in 1024 pixels !

Yeah I am thinking of 1280 by 720...yes, having to compromise future prove [2 years hopefully ?] with playability.

Say you are making a HD game to match the 16 by 9 ratio of today's phone/tablet/WiU/Whatever.

What would be the resolution that you would use that compromises smaller resolution to speed that will be playable on most retina devices today ?

1920 by 1080 [which is insane at this point for HTML 5 games]

1280 by 720 ?

Or even smaller ?

How small will you go before you think to yourself "why don't we all go back to the 1980's if you want to make it so bad".

What is the optimum resolution for most of your 16 by 9 games for retina fellow game makers ?

I understand some might say "it depends on the complexity of the game with its bla bla bla", please don't.

All things being equal [which they are not I know], what is the usual resolution you use to make 16 by 9 games now ?

Manual:

Use high-DPI display:

Some devices have a much higher resolution display, with more dots per inch (DPI) than other devices. Setting this property to Yes will use the full resolution of the device for maximum display quality, although this can sometimes reduce performance. Setting to No will treat the display like a traditional low-resolution display, which reduces detail but can improve performance.

That is A LOT OF WORDS but what does it ACTUALLY DO ?

Say I have a 1920 by 1080 Screen and I create a project that have a window size of exactly 1920 by 1080.

What will setting Use High-DPI display to "No" do ?

Will it automatically lower res the whole thing and then blow it up again ?

If it does that what exactly is this "mythical" low resolution that it scales down to ?

Say I have a 1920 by 1080 screen and I create a game with a window size of 1280 by 720.

What will setting Use High-DPI display to "Yes" do ?

Will it scale up using a different algorithm compared to setting it to "No" ?

Even worst, what if you have a 1280 by 720 mobile screen and your project window size is 1920 by 1080 and what would setting Use High-DPI to either Yes or No do ?

There is no explanation as to what this simple dropdown list actually do in the background.

What does it actually do ?

Thanks.

It is not in the manual.

"Rate of fire

The rate at which to trigger On shoot, when the turret has both acquired a target and rotated to point in the direction of the target."

That is A LOT OF WORDS but ultimately didn't say that one thing that truly matters.

What is the unit ?

Seconds ? Milliseconds ?

Thank you

Ha Ha Ha

Thank you

This Sprite have a wrap behavior, I was expecting it to wrap.

The layout and the window size is the same size and the "wrap to" has been set to "Viewport".

This is easily replicatable.

Why enable/disable collision when you can just enable/disable the physics behavior for that object ?

They seems to be doing the same thing.

One option requires you to use a slower version of physics instead of Box2D asm.js so why not just disable the behavior ?

What conditions require anyone to Disable the collision instead of just disabling the physics for that object altogether ?