Retina vs Non Retina?

electricityGames

First of all, I would like to say hello to the gs community, as this is my first post. Basically my question is, is using retina images really worth all of the trouble? the reason I say this is I have a pixel character that i made in photoshop, but all of the body parts(body,head,arm/gun) are different images. on top of this, images such as the arm/gun must have extra transparency so the "center" of the image is offset. with all of this offset in mind, I would like to have my images retina, but is it really worth the trouble?

jamie_c

If you plan on publishing to iOS 7 devices it is required to use retina graphics I believe so you have no choice in that case.

Socks

First of all, I would like to say hello to the gs community, as this is my first post.

:-h

Basically my question is, is using retina images really worth all of the trouble? the reason I say this is I have a pixel character that i made in photoshop, but all of the body parts(body,head,arm/gun) are different images. on top of this, images such as the arm/gun must have extra transparency so the "center" of the image is offset. with all of this offset in mind, I would like to have my images retina, but is it really worth the trouble?

There really is no trouble, GameSalad is actually very very good when it comes to throwing images around an iOS screen (impressively so).

With regard to the 'extra transparency' / 'offset' issue, rather than having the blank areas to accommodate the offset you could constrain elements together . . . the thing is, even if you use your 'extra transparency' method (which is a perfectly valid way of getting the offset you want) you will still have to constrain the various elements to whatever you are using as the master or 'parent' actor (like the 'body'), so you may as well trim off the extra transparency and simply constrain the elements together.

I made a little tool to do just that, take a look at this, it might be useful:

Thread> http://forums.gamesalad.com/discussion/62202/linkmachine


. . .


P.S and like @jamie_c said, you haven't got much of a choice these days.

electricityGames

oh alright. And retina graphics must be divisible by 4 correct? like I could have a 32 by 28 image and it would be retina?

electricityGames

and let me explain a little on the extra transparency. the arm is attached to the gun, and that's the "leading actor" if you will. basically the arm needs to rotate on the center offset. I know I've seen a method for pivoting something not on-center, but it did not apply to the current situation

Socks

oh alright. And retina graphics must be divisible by 4 correct? like I could have a 32 by 28 image and it would be retina?

Retina is a vague term, it's just a branding of 'high-resolution' (which itself is arbitrary).

32 x 28 can be 'Retina' at the same time as 320 x 280 can be non-Retina or low resolution (and 320 x 280 can be 'Retina' at the same time as 32 x 28 can be non-Retina or low resolution), a simple absolute pixel count means nothing, Retina - generally speaking, refers to the ppi when seen on the target device.

Socks

@electricityGames

and let me explain a little on the extra transparency

Your 'extra transparency' method is understood (and commonly used), see my post above referencing the LinkMachine, it does the same job - and might useful as even if you do use the 'extra transparency' method you will still need to constrain everything together.

electricityGames

I already have them constrained. thanks a lot for the help though. also one more quick question, I know this is probably asked a bunch, but must the prototype be unlocked for any sort of constraining of two actors? it makes me uncomfortable having a lot of levels, and knowing that if i find one bug in a constrained actor, I have to fix it on every single non-proto. it's kinda scary

Socks

@electricityGames

also one more quick question, I know this is probably asked a bunch, but must the prototype be unlocked for any sort of constraining of two actors?

Not necessarily, you can make a game level attribute (an attribute that all actors can see) and - using constrains - pass the X and Y information (and anything else you might want to communicate) from the 'parent' actor to the 'child' actors (or the other way around).




"A child actor"



...

electricityGames

haha XD that's great. thanks for all the help, i had tried the global attribute before but it communicated too slow. i'll work it out though.

Socks

@electricityGames

haha XD that's great. thanks for all the help, i had tried the global attribute before but it communicated too slow. i'll work it out though.

A trick for you . . . . .

If the communication between two actors seems overly slow then change their layer order, the layers are scanned in reverse order, that is to say they are scanned from the bottom upwards - in a loop - so bottom to top, then bottom to top again - and so on.

So if actor X is getting information from actor Y (for something like position) and the setup looks something like this . . .

Layer 1
Layer 2
Layer 3
Layer 4
Layer Y
Layer 6
Layer X
Layer 8

. . . then before layer X can get the information it needs from layer Y . . .GameSalad needs to scan through layers 6, Y, 4, 3, 2, 1, 8 . . . only then does it hit layer X and so is able to pass the data it grabbed from layer Y to layer X.

So, let's swap positions . . .

Layer 1
Layer 2
Layer 3
Layer 4
Layer X
Layer 6
Layer Y
Layer 8

. . . now GameSalad only has to scan passed layer 6 before passing the information it grabbed from layer Y to layer X.

Try it, it makes an enormous difference, obviouly the closer the layers are together the better, especially if the layers in-between (if any) are stuffed full of complex rules GS needs to compute.

electricityGames

this is a priceless tip, thanks so much!