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

totebo · September 2015

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 · September 2015

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 · September 2015

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

totebo · September 2015

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 · September 2015

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 · September 2015

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 · September 2015

@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 · September 2015

@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 · September 2015

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

antix · October 2015

Nice

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

totebo · October 2015

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

SinisterSoft · October 2015

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 · October 2015

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 · October 2015

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

hgy29 · October 2015

@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 · October 2015

A great reason to back this kickstarter.

SinisterSoft · October 2015

@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 · October 2015

@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 · October 2015

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

totebo · October 2015

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 · October 2015

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 · October 2015

@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 · October 2015

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 · October 2015

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.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

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

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

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

Comments