Pagine    Articoli    Prodotti    Forum    Cerca  
Nickname

Password


Non sei registrato?
Registrati a GPI qui!

Puoi anche attivare un vecchio utente GPI e chiedere una nuova password.
I Team

Mappa Team
I nostri utenti

Mappa Utenti
  Starling e la multirisoluzione
Pubblicato da Andrea Venturi il 2014-01-02 19:16:52

Uno dei vantaggi dell’utilizzo di Starling é la possibilità di creare un gioco per mobile che possa essere multipiattaforma e multirisoluzione con pochi accorgimenti.

 

Ed ecco che vi scrivo come fare.

 

Avviso: non é la soluzione ottimale, ma é quella più veloce da implementare che richiede poco sforzo e permette di creare una base per molti progetti.

 

L’idea

In pratica quello che serve da implementare é calcolare un aspect ratio di base con il quale creiamo tutto e in proporzione all’ aspect ratio reale del dispositivo scalare/caricare le risorse corrette.

 

Questo metodo comporta uno svantaggio, ovvero i dispositivi con aspect ratio particolarmente distanti da quelle di progetto possano mostrare delle bande nere come riempimento, ma comporta anche un enorme vantaggio, ovvero quello di poter semplificare e velocizzare il processo produttivo.

 

Risoluzioni

In questo articolo prendo ad esempio i device iOS che matematicamente sono più comodi per fare i conti.

 

Partiamo con il minimo modello di iPhone che può gestire questi tipi di giochi, ovvero il modello 3g, questo modello ha una risoluzione di 320x480.

 

Prendiamo questa come risoluzione base, ora consideriamo i modelli successivi come iPhone retina con la sua risoluzione di 640x960, che casualmente é proprio il doppio del suo predecessore, ma con l’avvento dell’iPhone5 le cose cambiano un pochino perché questo ha introdotto una risoluzione particolare che cambia l’aspect ratio (640x1136 ndr), poco male, compariranno delle piccole bande nere.

 

Discorso complementare per quanto riguarda i tablet della famiglia Apple.

 

Quindi da come si può capire facilmente se partiamo dal modello base l’unica cosa che differisce nella risoluzione é un fattore moltiplicativo.

Fattore uguale ad 1 per i modelli vecchi e uguale a 2 per i successivi, per completezza aggiungo fattore uguale a 4 per iPad retina, ma sarebbe meglio trattarlo a parte (vadi osservazioni alla fine).

 

Come procedere

Per prima cosa andiamo a definire una classe dove andiamo a memorizzare le nostre costanti: STAGE_WIDTH, STAGE_HEIGHT e ASPECT_RATIO

 

ovviamente é più comodo progettare e testare con risoluzioni basse, quindi andremo a impostare i dati come se stessimo lavorando con un iPhone 3g.

 

public static const STAGE_WIDTH:int  = 480;
public static const STAGE_HEIGHT:int = 320;
public static const ASPECT_RATIO:Number = STAGE_HEIGHT / STAGE_WIDTH;

A questo punto serve creare una doppia cartella con le texture che ci servono (che siano BitmapFont, texture atlas o immagini), ovviamente nella cartella nominata x1 si devono mettere le risorse come se lavorassimo su un iPhone 3g e nell’altra le stesse risorse con gli stessi nomi ma semplicemente grandi il doppio.

 

A questo punto servono due classi per incorporare le nostre risorse, ovviamente una per le risorse x1 e una classe per le risorse x2.

Ad esempio AssetEmbeds_1x e AssetEmbeds_2x.

 

qui porto l’esempio per caricare la risorsa (immagine) background

 

AssetEmbeds_1x: 

[Embed(source = "../assets/textures/1x/background.jpg")]
public static const Background:Class;

 

AssetEmbeds_2x:

[Embed(source = "../assets/textures/2x/background.jpg")]
public static const Background:Class;

 

Ora serve una classe per gestire il caricamento e l’istanzazione delle risorse, quindi serve una classe Assets tramite la quale andiamo a decidere in base al fattore di scalatura quale risorsa prendere.

 

Prima di tutto serve dichiarare un membro per memorizzare lo scale factor e una collezione per memorizzare le texture caricate..

 

private static var sContentScaleFactor:int = 1;
private static var sTextures:Dictionary = new Dictionary();

 

[nota: per le texture atlas stessa cosa]

 

Poi getter e setter per inizializzare i due membri

 

public static function get contentScaleFactor():Number { return sContentScaleFactor; }
public static function set contentScaleFactor(value:Number):void
{
    for each (var texture:Texture in sTextures)
        texture.dispose();
 
    sTextures = new Dictionary();
    sContentScaleFactor = value < 1.5 ? 1 : 2;
}

A questo punto la funzione per richiedere texture

 

public static function getTexture(name:String):Texture
{
    if (sTextures[name] == undefined)
    {
         var data:Object = create(name);
         
         if (data is Bitmap)
         sTextures[name] = Texture.fromBitmap(data as Bitmap, true, false, sContentScaleFactor);
         else if (data is ByteArray)
         sTextures[name] = Texture.fromAtfData(data as ByteArray, sContentScaleFactor);
    }
           
    return sTextures[name];
}

Quindi se la texture é stata già creata la ritorniamo senza troppi problemi, altrimenti andiamo a chiamare la funzione create(name:String):Object per caricare la bitmap necessaria per creare la texture opportunamente scalata.

 

Il cuore di questa classe risiede appunto nel metodo create che in base allo scale factor va a pescare la risorsa tramite la classe corretta.

 

private static function create(name:String):Object
{
     var textureClass:Class = sContentScaleFactor == 1 ? AssetEmbeds_1x : AssetEmbeds_2x;
     return new textureClass[name];
}

 

in pratica crea una variabile di tipo Class per andare a reperire la risorsa incorporata.

 

A qeusto punto quando abbiamo creato il nostro contesto Starling non dobbiamo far altro che aggiornare tramite setter il membro scale factor e iniziare a richiedere le texture che ci servono.

 

Osservazioni

Come si può capire questo metodo permette di gestire bene più risoluzioni anche dove non siano propriamente esatte le dimensione dato che va ad aggiungere delle barre nere.

 

Questo metodo, con queste impostazioni, da buoni risultati pure per quanto riguarda i device Android, senza andare a gravare troppo sul carico dato dalle risorse, perche’ si dovrebbero creare tre categorie di risorse e incorporarle tutte, andando a creare una gioco molto pesante.

 

Discorso a parte deve essere fatto per iPad Retina display in quanto si sarebbe facilmente inseribile come gestione, come detto prima ha uno fattore moltiplicativo si 4, ma andrebbe a gravare sulle dimensioni della app finale in quanto le risorse essendo molto grandi andrebbero ad essere un vero problema, per questo device consiglio di creare delle classi ad hoc e generare un gioco a se, lo sforzo é minimo ma i vantaggi sono notevoli.

 

 

Tabella di riferimento risoluzioni (rif.)

 

 

Campagne crowfunding

Just One Line
Siamo presenti su

     
Copyright ©2016 - Manifesto - Privacy - Termini di Servizio - Community - Collaboratori - Contattaci