(2017-06-29, 20:56)Travis Cobbs Wrote:(2017-06-29, 20:40)Jaco van der Molen Wrote: I don't understand this. If I scale 4000x1200 pixels tot 80x24 LDU it is a perfect fit. Not?
You're forcing the app to load a 4000x1200 texture, which then must be loaded into the graphics hardware, even though only a small fraction of that is actually used. So in a typical scenario, this image would require over 24MB of graphics memory in a situation where most of it is wasted space.
Textures often get loaded using a technique called MIP-mapping, which loads multiple progressively smaller versions of the same image. All the MIP-map levels add up to roughly 133% as much memory as the main texture alone would require. 4000 x 1200 x (4 bytes per pixel) x 1.33 = 25,536,000 bytes. Cropped, the image is 1768x879. The same calculation from above yields 8,267,663 bytes, which is just under 1/3 as many. So, since it uses less than 1/3 the memory, but produces identical end results, it's worth it to go that route when creating an official part.
Ok this is too technical for me
What would be the ideal dimensions for the PNG?
Would 1768x879 be it for a 1x4 brick to have a good enough resolution, a good fit and good result?
I am aiming to create some standard parts that are typically patterned like the 1x1, 1x2, 1x3, 1x4 ,1x6 bricks etc.
And tiles 1x1 (square or round), 1x2, 2x2, 1x3, 1x4, 2x4 etc.
And thus create some template PNG files of the correct dimension so we can easily create new patterns.
The minifig torso is a good candidate too to create some standard as are panels.
Jaco van der Molen
lpub.binarybricks.nl
lpub.binarybricks.nl