Scaling pixels; @1, @2, @3 and beyond

totebo

Hi guys,

The ever-growing export options in Gideros lead to extra time spent making bitmaps work everywhere. How do you deal with this?

I would appreciate all thoughts regarding scaling, from pixel perfect, to scaled up retro bitmaps, to pixels drawn with code.

Cheers,

Niclas

antix

I'm slowly getting my code base up to scratch and haven't even started addressing this issue. Currently I'm having fun (not really) with scaling my app and having nasty visible lines (mostly horizontal) appear everywhere because the scaling in Gideros doesn't really work that well.

I'm keen to learn what others are doing

SinisterSoft

The scaling works fine for me. Do you mean scaling tilemaps?

totebo

I mean catering for all resolutions and still retaining crisp bitmaps.

There is quite a range now with all export options and a very fragmented iOS and Android world. The resolutions vary from 640x960 on the iPhone 4 to 2048x2732 on the iPad Pro. And everything in between!

My aim is to support all resolutions to make sure everyone can play my games and that they look decent on all devices. A few concrete options to make this happen come to mind:

a) Create bitmaps to cater for the largest resolution, then scale them down for lower res devices. This means the lower resolution devices will look worst.

b) Create bitmaps at 100% to cater for all devices and let the background "bleed" when needed. This is a lot of effort and adds a lot of extra weight to the app. But the bitmaps are always perfect.

c) Draw all graphics with code. Hard core!

I was curious to see what approach people take on this, if any of the above, or something else.

simwhi

We have used a combination of coded graphics and images designed for specific resolutions. It's a lot of work, but I think it's well worth it in the long term.

We're using coded graphics for dialogue boxes and other basic menu buttons etc. We've built classes to make this process a lot easier.

Recently, I created a 9 patch function for building dialogues with rounded corners. Scaling the straight edges and centre images works well.

ar2rsawseen

I think new vector path stuff would address it, as you would be able to create SVG files like in inkscape or Illustrator and use it on any resolution

totebo

@simwhi, that sound like a good workflow. Any chance of sharing the 9 slice code? How do you separate the resolutions? Is there a "standard" way of determining which resolution to use? Or do you do what I would do, which is measure the actual pixels and inches the screen size is and then trial and error until it works on all my test devices?

@ar2rsawseen, that would be amazing. I love to work with vector graphics. It would save a lot of time, and download time!

SinisterSoft

@totebo Here is a 9 slice routine...

function Gui:image9(m,ib,i,w,h,left,right,top,bottom,fh,fv) local tx,ty,tw,th=i:getRegion() local w3,h3=tw/3,th/3 local l,r,t,b=left or w3,right or w3,top or h3,bottom or h3 local tx2,tx3=tx+l,tx+tw-r local ty2,ty3=ty+t,ty+th-b local tx4,ty4=tx+tw,ty+th if fh then tx,tx2,tx3,tx4=tx4,tx3,tx2,tx l,r=r,l end if vh then ty,ty2,ty3,ty4=ty4,ty3,ty2,ty t,b=b,t end local x2,x3=l,w-r local y2,y3=t,h-b m:setVertexArray(0,0,x2,0,x2,y2,0,y2, x2,0,x3,0,x3,y2,x2,y2, x3,0,w,0,w,y2,x3,y2, 0,y2,x2,y2,x2,y3,0,y3, x2,y2,x3,y2,x3,y3,x2,y3, x3,y2,w,y2,w,y3,x3,y3, 0,y3,x2,y3,x2,h,0,h, x2,y3,x3,y3,x3,h,x2,h, x3,y3,w,y3,w,h,x3,h) m:setIndexArray(1,2,3,1,3,4, 5,6,7,5,7,8, 9,10,11,9,11,12, 13,14,15,13,15,16, 17,18,19,17,19,20, 21,22,23,21,23,24, 25,26,27,25,27,28, 29,30,31,29,31,32, 33,34,35,33,35,36) m:setTextureCoordinateArray(tx,ty,tx2,ty,tx2,ty2,tx,ty2, tx2,ty,tx3,ty,tx3,ty2,tx2,ty2, tx3,ty,tx4,ty,tx4,ty2,tx3,ty2, tx,ty2,tx2,ty2,tx2,ty3,tx,ty3, tx2,ty2,tx3,ty2,tx3,ty3,tx2,ty3, tx3,ty2,tx4,ty2,tx4,ty3,tx3,ty3, tx,ty3,tx2,ty3,tx2,ty4,tx,ty4, tx2,ty3,tx3,ty3,tx3,ty4,tx2,ty4, tx3,ty3,tx4,ty3,tx4,ty4,tx3,ty4) m:setTexture(ib) return l,r,t,b end

with m...

local m=Mesh.new()

Used in a Lua GUI lib I'm making in my spare time...

simwhi

@SinisterSoft Nice. It looks a lot more comprehensive than mine. What are the parameters?

antix

Nice

Don't use shapes if you can help it, they are terribly slow when using huge amounts of them

totebo

@SinisterSoft, looks impressive! How do I use this thing?

SinisterSoft

I'll try remember, I was on a roll when I wrote it.

m = a mesh
ib = image base of a texture pack
i = the image within a texture pack (getTextureRegion("ninepatch.png"))
left, right, top, bottom = the edges or null, if null then it's equally split into 9 sections
fh, fv = flip horizontal and vertical

SinisterSoft

It's all part of the gui thing I'm making. If you all want I'll release it as things progress, it's very early days though and things could change a lot within it and how it's used.

totebo

Thanks, nice! Hey, why not chucking it on Github and iterate?

hgy29

@antix, Yes shapes are awfully slow and TTFonts also since they use the same codepath.
I'll be working on a faster implementation of shapes/vector graphics as part of HTML5 kickstarter, including SVG support.

SinisterSoft

A great reason to back this kickstarter.

SinisterSoft

@totebo I would if I could get used to github. It drives me mad.

I'll add some sample 'widgets' and demos then put it in with the Gideros github.

totebo

@SinisterSoft cool, look forward!

@hgy29 that's an awesome feature to put in. Probably worth explaining the speed and weight improvements as selling points.

antix

@hgy29 - great news. I'm experiencing all manner of strange behavior with shapes at the moment, they totally need an overhaul

totebo

I'm experimenting with spritesheets at @0.5x, @1x, @2x and @3x as set in the document properties:


I have added these spritesheets to the Project library:


This code always picks the @1x spritesheet:

local texturePack = TexturePack.new("spritesheet.txt", "spritesheet.png", true)

How do I get Gideros to automatically pick the correct spritesheet and text file? Is there a way to check which @nx is currently used?

totebo

Gotcha: In properties, the "Scale Mode" has to be "Pixel Perfect".

A whole new way of thinking, pixels instead of percentage. I like it.

keszegh

@totebo, i don't think it needs to be pixel perfect, that would beat the aim of the whole automation. look here, maybe it helps:
http://docs.giderosmobile.com/automatic_image_resolution.html

Tom2012

Hi Totebo, whats the resolution / which device are you testing on?

EDIT - I don't think it will work with no scale set in the box. You have to choose a scale method for Gideros to pick the right sprite sheet. Anything but the top two choices, the 'no scale' ones, should work. The rest of the code and the sprite sheets names look fine.

Pixel perfect will still use the correct @2x / @3x sprite sheet. It just means that it won't be stretched in any way. Rather than being stretched to fit, more of your scene can be viewed around the edges. This has pluses and minuses.

totebo

That makes sense guys. I like pixel perfect, as long as you understand the "bleed" that happens it feels like a great option to have the bitmaps crisp and clean.