I am having trouble converting pixels to metres on my game
how many pixels is a meter in Box2D?
Is an example of my problem, but does not solve it.
This is because this solution, while it works, will not go cross browser, that is, if the conversion rate is something constant like 50px to one meter, than on a device with 400x800 resolution, the objects will appear big, whereas on another device with 4000x8000 resolution (exagurated) the objects will be tiny.
I can understand some solutions to this, but the main reason why I am finding this so hard to implement is because one browser or phone might be 16:9 ratio, whereas another might be 14:7, and these differing ratio's are the kicker, since my entire game is held on the screen as it is not a scrolling game, it is just a simple physics game.
Because of this I understand that It is easier to have to world be a smaller size, and convert it back up when rendering, but these problems that I have mentioned have stumped me, and I was wandering if anyone had any feasible solutions.
Since your
entire game is held on the screen
I suggest you the following:
Decide how many "meters" you need your window width to be. Say you've decided:
any window width (W) is always N "meters"
Then k = W/N where k is a scaling multiplier meaning a part of window width within 1 "meter".
So if W = 400px and N = 100m you have k = 400px/100m = 4px/m.
And when other screen is W = 4000px you have k = 40px/m.
That way you can translate your "meters" to pixels by multiplying your dimensions in "meters" by k and your objects will be always scaled to the screen size.
In JavaScript it looks like:
var N = 100; // window width in "meters"
var k = window.innerWidth / N; // px in 1m
// let's count something simple
var U = 10; // speed in meters per second
var t = 10; // time in seconds
var S = U * t; // distance in meters
var S_px = S * k; // distance in pixels (scaled to the window width)
Related
Is there a reliable equation to work out pixel size to MM? Or is that not possible cross device?
We are working with a bespoke system that delivers content to many devices with different screen sizes, it can detect the screen width in MM, but we would like to accurately convert this to pixel size to deliver correctly sized images dynamically using a simple jquery script!?
Any ideas?
Cheers
Paul
What i did :
<div id="my_mm" style="height:100mm;display:none"></div>
Then:
var pxTomm = function(px){
return Math.floor(px/($('#my_mm').height()/100)); //JQuery returns sizes in PX
};
tl;dr: If you don't know the DPI of the device, you won't be able to deduce how big the pixel is in the real-world.
Pixels on their own are not real-world units of measurement.
They can become a real-world measurement if you take into account the DPI value of the device that displays them.
The formula is:
mm = ( pixels * 25.4 ) / DPI
So 8 pixels viewed on a 96-DPI screen setting:
( 8 * 25.4 ) / 96 = 2.116mm
All this assuming the device is not scaled/zoomed.
old post but I stumbled upon this today and had to make it work.
the trick is to create an element with dimensions styled in inches and request its width, this will give you the px per inch.
function inch2px(inches) {
$("body").append("<div id='inch2px' style='width:1in;height:1in;display:hidden;'></div>");
var pixels = $("#inch2px").width();
$("#inch2px").remove();
return inches * pixels;
}
function px2inch(px) {
$("body").append("<div id='inch2px' style='width:1in;height:1in;display:hidden;'></div>");
var pixels = $("#inch2px").width();
$("#inch2px").remove();
return px / pixels;
}
now if you need millimetres, just do px2inch(10)*25.4.
You would need to know the DPI of the device and if the display is scaled or not. That would mean that you would have to have a database of the physical screen dimensions and screen resolutions of each device.
No need for jQuery.
function xToPx(x) {
var div = document.createElement('div');
div.style.display = 'block';
div.style.height = x;
document.body.appendChild(div);
var px = parseFloat(window.getComputedStyle(div, null).height);
div.parentNode.removeChild(div);
return px;
}
pixels = xToPx('10cm'); // convert 10cm to pixels
pixels = xToPx('10mm'); // convert 10mm to pixels
Please notice that values in pixels are depending on what resolution the browser of the device tells you. Some browsers (on some phones) lie about this and tell you something different than the actual screen resolution in an attempt to be compatible with older sites. Main important thing is to never port conversion values from one device to another but always use real-time calculations. Even on a desktop the user can change the screen resolution.
To learn more about the units, check out this (short) article on W3:
https://www.w3.org/Style/Examples/007/units.en.html
i use this simple function
function pix2mm(val,dpi){
return (val/0.0393701)/dpi;
}
test outputs it 300,600,900 DPI
var r = pix2mm(100,300); // converting 100 pixels it 300 DPI
console.log(r); // output : 8.4 mm
var r1 = pix2mm(100,600); // converting 100 pixels it 600 DPI
console.log(r1); // output : 4.2 mm
var r2 = pix2mm(100,900); // converting 100 pixels it 900 DPI
console.log(r2); // output : 2.8 mm
DEMO : https://jsfiddle.net/xpvt214o/29044/
You cannot reliably calculate this since there is no way to detect physical screen size.
Based on the #Dawa answer above, this is my solution:
var mmToPx = function(mm) {
var div = document.createElement('div');
div.style.display = 'block';
div.style.height = '100mm';
document.body.appendChild(div);
var convert = div.offsetHeight * mm / 100;
div.parentNode.removeChild(div);
return convert;
};
Just note that the 100mm height, will give you a better precision factor.
The calculation will be instant and the div will not be visible. No need for jQuery
Late but may be useful.
1 px = 0.26458333333719 mm
Milli Meter Pixel
1 mm = 3.779527559 px
So if you have lets say 10px. It will be equal to 10 * 0.26458.. = 2.64mm
ref : https://everythingfonts.com/font/tools/units/px-to-mm
Enjoy :)
I need to scale lots of text nodes in the browser (support of all modern desktop and mobile browsers).
If I am right there are two options that offer good performance: scaling text objects in Canvas or scaling text nodes in the DOM using transform:matrix.
I have created a scenario to test both versions but the results are inconclusive. Uncomment testDOM() or testCanvas() function to start the test. (I am using JQuery and CreateJS framework because it was convenient. It is possible to use vanilla JS but I don't think that is the bottleneck here). (It matters what portion of the screen you actually see so please switch to full screen view in codepen).
http://codepen.io/dandare/pen/pEJyYG
var WIDTH = 500;
var HEIGHT = 500;
var COUNT = 200;
var STEP = 1.02;
var MIN = 0.1;
var MAX = 10;
var stage;
var canvas;
var bg;
var canvasTexts = [];
var domTexts = [];
var domMatrix = [];
var dom;
function testDOM() {
for (var i = 0; i < COUNT; i++) {
var text = $("<div>Hello World</div>");
var scale = MIN + Math.random() * 10;
var matrix = [scale, 0, 0, scale, Math.random() * WIDTH, Math.random() * HEIGHT];
text.css("transform", "matrix(" + matrix.join(',') + ")");
domTexts.push(text);
domMatrix.push(matrix);
}
dom = $('#dom');
dom.append(domTexts);
setTimeout(tickDOM, 1000);
}
function tickDOM() {
for (var i = 0; i < domTexts.length; i++) {
var text = domTexts[i];
var matrix = domMatrix[i];
var scale = matrix[0];
scale *= STEP;
if (scale > MAX)
scale = MIN;
matrix[0] = matrix[3] = scale;
text.css("transform", "matrix(" + matrix.join(',') + ")");
}
requestAnimationFrame(tickDOM);
}
function testCanvas() {
$('#dom').hide();
stage = new createjs.Stage('canvas');
createjs.Touch.enable(stage);
createjs.Ticker.timingMode = createjs.Ticker.RAF;
canvas = stage.canvas;
devicePixelRatio = window.devicePixelRatio || 1;
stage.scaleX = devicePixelRatio;
stage.scaleY = devicePixelRatio;
console.log('devicePixelRatio = ' + devicePixelRatio);
stage.mouseMoveOutside = true;
stage.preventSelection = false;
stage.tickEnabled = false;
stage.addChild(bg = new createjs.Shape());
bg.graphics.clear();
bg.graphics.f('#F2F2F2').drawRect(0, 0, 2 * WIDTH, HEIGHT);
canvas.width = 2 * WIDTH * devicePixelRatio;
canvas.height = HEIGHT * devicePixelRatio;
canvas.style.width = 2 * WIDTH + 'px';
canvas.style.height = HEIGHT + 'px';
stage.update();
for (var i = 0; i < COUNT; i++) {
var text = new createjs.Text("Hello World", "10px", "#333333");
text.scaleX = text.scaleY = MIN + Math.random() * 10;
text.x = Math.random() * WIDTH;
text.y = Math.random() * HEIGHT;
stage.addChild(text);
canvasTexts.push(text);
}
stage.update();
setTimeout(tickCanvas, 1000);
}
function tickCanvas() {
for (var i = 0; i < canvasTexts.length; i++) {
var text = canvasTexts[i];
text.scaleX = text.scaleY *= STEP;
if (text.scaleX > MAX)
text.scaleX = text.scaleY = MIN;
}
stage.update();
requestAnimationFrame(tickCanvas);
}
testDOM();
//testCanvas();
My questions:
Is it possible to improve the performance of my tests? Am I doing something wrong?
The first 5-10 seconds are significantly slower but I don't understand why. Does the browser somehow cashes the text objects after some time? If yes, is the test unusable for real world scenario testing where the objects don't zoom in a loop for longer period of time?
According to the Chrome Profiling tool the DOM version leaves 40% more idle time (is 40% more faster) than the Canvas version but the Canvas animation looks much smoother (after the initial 5-10 seconds of lagging), how should I interpret the Profiling tool results?
In the DOM version I am trying to hide the parent of the text nodes before I apply the transformations and then unhide it but it probably does not matter because transform:matrix on absolutely positioned element does not cause reflow, am I right?
The DOM text nodes have some advantages over the Canvas nodes like native mouse over detection with cursor: pointer or support for decorations (you can not have underlined text in Canvas). Anything else I should know?
When setting the transform:matrix I have to create a string that the compiler must to parse back to numbers, is there a more efficient way of using transform:matrix?
Q.1
Is it possible to improve the performance of my tests? Am I doing
something wrong?
Yes and no. (yes improve and no nothing inherently wrong (ignoring jQuery))
Performance is browser, and device dependent, for example Firefox handles objects better than arrays, while Chrome prefers arrays. There is a long list of differences just for the javascript.
Then the rendering is a dependent on the hardware, How much memory, what capabilities, and the particular drivers. Some hardware hates state changes, while others handle them at full speed. Limiting state changes can improve the speed on one machine while the extra code complexity will impact devices that don't need the optimisation.
The OS also plays a part.
Q.2
The first 5-10 seconds are significantly slower but I don't understand
why. Does the browser somehow cashes the text objects after some time?
If yes, is the test unusable for real world scenario testing where the
objects don't zoom in a loop for longer period of time?
Performance testing in Javascript is very complicated and as a whole application (like your test) is not at all practical.
Why slow?
Many reasons, moving memory to the display device, javascript optimising compilers that run while the codes runs and will recompile if it sees fit, this impacts the performance Un-optimised JS is SLOOOOOWWWWWWWW... and you are seeing it run unoptimised.
As well. In an environment like code pen you are also having to deal with all its code that runs in the same context as yours, it has memory, dom, cpu, GC demands in the same environment as yours and thus your code can not be said to be isolated and profiling results accurate.
Q.3
According to the Chrome Profiling tool the DOM version leaves 40% more
idle time (is 40% more faster) than the Canvas version but the Canvas
animation looks much smoother (after the initial 5-10 seconds of
lagging), how should I interpret the Profiling tool results?
That is the nature of requestAnimationFrame (rAF), it will wait till the next frame is ready before it calls your function. Thus if you run 1ms past 1/60th of a second you have missed the presentation of the current display refresh and rAF will wait till the next is due 1/60th minus 1ms before presentation and the next request is called. This will result in ~50% idle time.
There is not much that can be done than make you render function smaller and call it more often, but then you will get extra overhead with the calls.
rAF can be called many times during a frame and will present all renders during that frame at the same time. That way you will not get the overrun idle time if you keep an eye on the current time and ensure you do not overrun the 1/60th second window of opportunity.
Q.4
In the DOM version I am trying to hide the parent of the text nodes
before I apply the transformations and then unhide it but it probably
does not matter because transform:matrix on absolutely positioned
element does not cause reflow, am I right?
Reflow will not be triggered until you exit the function, hiding the parent at the start of a function and then unhiding it at the end will not make much difference. Javascript is blocking, that means nothing will happen while you are in a function.
Q.5
The DOM text nodes have some advantages over the Canvas nodes like
native mouse over detection with cursor: pointer or support for
decorations (you can not have underlined text in Canvas). Anything
else I should know?
That will depend on what the intended use is. DOM offers a full API for UI and presentation. Canvas offers rendering and pixel manipulation. The logic I use is if it takes more code to do it via DOM then canvas, then it is a canvas job and visa versa
Q.6
When setting the transform:matrix I have to create a string that the
compiler must to parse back to numbers, is there a more efficient way
of using transform:matrix?
No. That is the CSS way.
My explanation may be unclear and if so, please leave a comment for further clarification.
I am trying to make the character to jump to the height of the screen.
So far, this is my code:
var limit = 0;
function jump()
{
ball.posy -=10;
limit++;
if(limit>screenheight)
{
//if character reached top of screen stop this jump() function
isjump = false;
limit = 0;
}
}
Above code will enable the character to jump up to the screen height. But if the screen height is smaller (for example, in some mobile device), character jump will be faster.
If there are any game developers who have idea, would you be able to guide me? :) Thank you.
ok the problem is that you need to know the speed of your jump first. now its is doing it depending of your screen for example:
function jump()
myjump += 10 // this is what you are doing now
{
so lets fix that function, how?
lets make that 10 variable depending on the screen height
lets say your screen now is 800px heigh so for a 800px height screen you will add 10px, but for a 400 heigth screen you only need to add 5px!!.
so how we do it?
with this simple formula
var scaleJump = 10 * (screenHeigth/800)
function jump()
myjump += scaleJump
{
so now if your screen heigth is 800 your var scaleJump will be = 10 * ( 800 / 800 ) = 10
and if your screen heigth is 400 scaleJump will be = 10 * ( 400 / 800 ) = 5
so problem solved!! it will increase 5 if screen is 400 and 10 if screen is 800, and scale as needed if anyonther heigth
to fix time
ok how do we know the time it takes to draw a frame?
since: fps = frames / second
so: 1/fps = seconds / frame
this is a differential equation where you have a deltaTime and a deltaDistance
DeltaTime is equals to:
1/fps
and DeltaDistance would be this, if fps were always the same, but like they are not I explain below:
10 * (screenHeigth/800)
now lets set a base speed wich you can change acording to your needs as I dont have your code I am not sure if this will move fast or slow, but you can test it and change it as you need it.
lets set speed to 1 (I dont know if it is fast or slow, just change it latter)
since speed = DeltaDistance / DeltaTime
so lets get the distance you have to add so the speed is the same:
DeltaDistance = Speed * DeltaTime
now your code will look like this
var DeltaDistance;
var DeltaTime = (1 / fps)
var mySpeed = 1
function jump()
DeltaDistance = mySpeed * DeltaTime
myJump += DeltaDistance
{
I miss college :(
I'm building an image preload animation, that is a circle/pie that gets drawn. Each 'slice' is totalImages / imagesLoaded. So if there are four images and 2 have loaded, it should draw to 180 over time.
I'm using requestAnimFrame, which is working great, and I've got a deltaTime setup to restrict animation to time, however I'm having trouble getting my head around the maths. The closest I can get is that it animates and eases to near where it's supposed to be, but then the value increments become smaller and smaller. Essentially it will never reach the completed value. (90 degrees, if one image has loaded, as an example).
var totalImages = 4;
var imagesLoaded = 1;
var currentArc = 0;
function drawPie(){
var newArc = 360 / totalImages * this.imagesLoaded // Get the value in degrees that we should animate to
var percentage = (isNaN(currentArc / newArc) || !isFinite(currentArc / newArc)) || (currentArc / newArc) > 1 ? 1 : (currentArc / newArc); // Dividing these two numbers sometimes returned NaN or Infinity/-Infinity, so this is a fallback
var easeValue = easeInOutExpo(percentage, 0, newArc, 1);
//This animates continuously (Obviously), because it's just constantly adding to itself:
currentArc += easedValue * this.time.delta;
OR
//This never reaches the full amount, as increments get infinitely smaller
currentArc += (newArc - easedValue) * this.time.delta;
}
function easeInOutExpo(t, b, c, d){
return c*((t=t/d-1)*t*t + 1) + b;
}
I feel like I've got all the right elements and values. I'm just putting them together incorrectly.
Any and all help appreciated.
You've got the idea of easing. The reality is that at some point you cap the value.
If you're up for a little learning, you can brush up on Zeno's paradoxes (the appropriate one here being Achilles and the Tortoise) -- it's really short... The Dichotomy Paradox is the other side of the same coin.
Basically, you're only ever half-way there, regardless of where "here" or "there" may be, and thus you can never take a "final"-step.
And when dealing with fractions, such as with easing, that's very true. You can always get smaller.
So the solution is just to clamp it. Set a minimum amount that you can move in an update (2px or 1px, or 0.5px... or play around).
The alternative (which ends up being similar, but perhaps a bit jumpier), is to set a threshold distance. To say "As soon as it's within 4px of home, snap to the end", or switch to a linear model, rather than continuing the easing.
Say I have a parent div with width 500px. It has 13 child elements that should fill its width.
If I give each child element a width of 500 / 13 = 38.46... pixels, the browser will floor the pixel values, so I end up with 13 elements that take up a total of 38 * 13 = 494 pixels. There will be 6 pixels on the right side of the parent div that are not filled.
Is there an easy way to dither the child element widths so that the remainder (6 pixels) is distributed among some of the child elements, resulting in a total width of 500 pixels?
If I have to do the calculations manually and there's no way to get the browser to manage it, what dithering algorithm might I use in this case?
EDIT: A clarification -- I'm doing these calculations on the client side using JavaScript. Also, the size of the parent div and the number of child divs vary at runtime; the figures above are just an example.
I'd suggest you just do everything with integer math yourself. You can then calculate what the uneven amount is and then decide how you want to distribute it across the elements. My supposition is that the least noticeable way to distribute the extra pixels would be to keep as many like width elements next to each other as possible.
One way of doing that would to calculate how many extra pixels N you have and then just give each N elements starting from the left one extra pixel. If you were worried about things not being centered, you could allocate the first extra pixel to the far left object, the second extra pixel to the far right, the third extra pixel to the 2nd from left, the fourth extra pixel from the 2nd from right, etc... This would have one more boundary between dissimilar width objects, but be more symmetric than the first algorithm.
Here's some code that shows how one could put the extra pixels on the end elements from outside in:
function distributeWidth(len, totalWidth) {
var results = new Array(len);
var coreWidth = Math.floor(totalWidth / len);
var extraWidth = totalWidth - (coreWidth * len);
var w,s;
for (var i = 0; i < len; i++) {
w = coreWidth;
if (extraWidth > 0) {
w++;
extraWidth--;
}
if (i % 2 == 0) {
s = i/2; // even, index from front of array
} else {
s = len - ((i+1)/2); // odd, index from end of array
}
results[s] = w;
}
return(results)
}
And here's a fiddle to see it in action: http://jsfiddle.net/jfriend00/qpFtT/2/