Hanno molte cose ancora da raccontarci ed oggi ci vogliono spiegare un argomento molto specifico e tecnico: l’ottimizzazione delle texture utilizzando il formato PVR.

Oggi parliamo di Texture con particolare riguardo a qualche ottimizzazione che possiamo fare per i nostri
programmi che usano OpenGLES.

Di base l’Iphone SDK supporta vari formati grafici e come molti di voi sanno di solito viene usato il formato PNG per gestire le texture.

Quello che proponiamo con questo tutorial è l’utilizzo di un formato non molto noto ma che ha molti vantaggi se utilizzato in certi casi.

Il formato in questione è il PVR in particolare PVRTC compression format che devira da PowerVR, analizziamo brevemente vantaggi e svantaggi che si hanno nell’utilizzare tale formato.

I vantaggi ad utilizzare tale formato:
• riduce lo spazio richiesto dalla texture (è un formato compresso)
• minore spazio equivale a minore banda utilizzata e quindi caricamento della texture più veloce
• la decompressione della texture è fatta tramite l’hardware grafico messo a disposizione dall’Iphone / Ipod Touch ergo è più veloce
• caricamento e conversione molto facile da implementare

Mentre gli svantaggi / limiti sono:
• qualità più bassa (parliamo di texture compresse)
• altezza e larghezza della texture devono essere una potenza di 2
• altezza e larghezza della texture devono coincidere

Per quanto riguarda la creazione di texture in formato PVR l’Iphone SDK ha un tool al suo interno che permette di convertire
da formati grafici noti ( PNG, JPG, TIFF e altri ) al formato PVR il tutto tramite riga di comando da un semplice terminale.

Se abbiamo XCode con l’Iphone SDK installato nella cartella di default (/Developer/Platforms/) avremo allora il tool chiamato texturetool direttamente dentro la cartella /Developer/Platforms/Iphone.platform/Developer/usr/bin/.

Texturetool permette di creare 4 varianti del formato PVRTC, in base a queste possiamo quindi trovare un buon compromesso tra compressione e perdita di qualità.

I parametri da passare a texturetool sono molto semplici e li possiamo vedere anche attraverso l’help del programma stesso:
user$ texturetool -h
Usage: texturetool [-hlm] [-e ] [-p
] -o [-f
] input_image
-h Display this help menu.
-l List available encoders, individual encoder options, and file formats.
-m Generate a complete mipmap chain from the input image.
-e Encode texture levels with .
-p
Output a PNG preview of the encoded output to
. Requires -e option.
-o Write processed image to .
-f
Set file
for image.

In particolare come encoder utilizzeremo proprio PVRTC mentre possiamo giocare con il formato scegliendo tra PVR o RAW con le seguenti opzioni aggiuntive:
–channel-weighting-linear
–channel-weighting-perceptual
–bits-per-pixel-2
–bits-per-pixel-4
Di base se lanciamo texturetool senza specificare opzioni avremo il formato –bits-per-pixel-4, –channel-weighting-linear.

Per convertire un ipotetico file prova.png in prova.pvr (con formato a 4bpp (bits per pixel)) scriviamo:
texturetool -e PVRTC -f PVR –channel-weighting-linear –bits-per-pixel-4 -o prova.pvr prova.png

Vediamo dal punto di vista della grandezza quanto conviene:

Ad esempio una texture a 32bpp di dimensioni 256×256 occupa non compressa circa 256kb, se usiamo una compressione a 4bbp avremo
una texture che occupa 32kb più qualcosina per l’header del formato .pvr.

Per il caricamento delle texture dentro la nostra applicazione utilizziamo un’estensione di OPENGLES chiamata glCompressedTexImage2D;
in particolare per chi ha accesso al Developer Connection di Apple è presente una classe PVRTextureLoader che fa già tutto quello che ci serve
per caricare texture compresse in PVR.

Per voi e’ tutto i ragazzi PiXy e BugMaN…e un ringraziamento da Sir. Lodux !

BugMaN: In questo mese, visto il poco tempo a disposizione, abbiamo continuato a sviluppare la parte di gestione dei Menù: in particolare
oltre al lavoro svolto a Febbraio si è cercato di dare un volto ai menù relativi agli obiettivi di ogni singolo livello e ai risultati una
volta che il livello è stato completato.

Ma vediamo con ordine cosa abbiamo realizzato:

Codice:

Scelta del pianeta:

Ora i pianeti attivi danzando allegramente mentre quelli ancora non sbloccati non saranno visualizzabili e quindi selezionabili finché
non si completano tutti i livelli (in tutto 9) del pianeta precedente.

E’ stato cambiato il tasto per tornare al menù principale (ma ancora non ci siamo!!!).

Scelta del livello:

PiXy ha realizzato un nuovo font (versione black e versione white) che utilizzeremo per tutto il gioco.
Ora per la realizzazione di questa schermata (e anche di altre) è stata aggiunta alla classe che gestisce i menù
la possibilità di gestire dei piccoli widgets esterni che hanno anche la possibilità di essere animati.

Se l’utente fa clic (in questo caso touch) su un tassello che compone un livello, sulla destra vengono visualizzati
nome, punteggio e stelle (un modo immediato per sapere come si è finito precedentemente il livello).

Il tasto Play permette di giocare il livello selezionato mentre con Back si torna alla scelta dei pianeti.

Obiettivi:

Una volta scelto un livello apparirà una schermata che riassume gli obiettivi da raggiungere per completarlo:
• In alto avremo nome del livello e stelle (se è già stato completato/giocato)
• Al centro troviamo il numero di palline da colpire (per ogni colore)
• In basso abbiamo invece:
• la direzione da dove escono le palline
• il numero totale di palline
• il tasto play per giocare il livello

Risultati:

In base al raggiungimento degli obiettivi abbiamo 2 schermate differenti.

La prima è “Level completed” che appare in caso di superamento del livello, in questa
schermata sono state realizzate le animazioni delle varie zone ma mancano ancora da inserire
le statistiche e il punteggio in stelle.

La seconda è utilizzata in caso non si raggiunga l’obiettivo… non abbiamo ancora deciso
se visualizzare le statistiche o meno.

BugMaN: Dal solo punto di vista del codice abbiamo:
• Convertito tutti gli sfondi nel formato PVR (ne parleremo nella prossima puntata)
• studiato possibilità per implementare la gestione dell’Audio tramite OpenAL
• iniziato a studiare e valutare l’utilizzo di Facebook Connect

Design:

Bonus (Bubble)

PiXy: Finalmente durante il mese di Marzo abbiamo definito una lista completa dei bonus che saranno presenti all’interno
del gioco. Tutti questi bonus prenderanno il nome di Bubble, in quanto saranno racchiusi tutti all’interno
di una bolla.
Il nome del gioco Bubble Touch, vuole proprio indicare che saranno loro i protagonisti, in quanto renderanno
il gioco divertente e pieno di imprevisti.
Come gia’ accennato nelle puntate precedenti, all’interno del gioco sara’ presente una “Bubble Gallery” dove
potremmo guardare tutte le bolle che abbiamo scoppiato e capire bene quali sono i loro effetti.

Definito il design dei bonus ho subito pensato a fare una prima bozza grafica per ognuno di loro, alcune Bubble
sono venute proprio bene e credo le manterro’ anche nella versione definitiva, altre sono sicuramente da sistemare.

Ecco, in anteprima, un’immagine in cui sono presenti tutti i bonus :

Grafica:
Mappe dei pianeti

PiXy: Durante la fine del mese ho incominciato a lavorare alle mappe dei 5 pianeti, in particolare alle immagini che
saranno poi suddivise in nove parti (una per livello) e che si comporanno quando il giocatore avra’ completato
un intero pianeta.

Musica:

PiXy: Abbiamo pensato di avere una soundtrack musicale differente per ogni pianeta, ho quindi incominciato a comporre
qualcosina. Per realizzare la musica del gioco sto utilizzando MilkyTracker, un’applicazione open source che si rifa’
al buon vecchio FT2 (Fast Tracker 2).
I tracker in genere sono software che fanno da sequencer e servono per comporre musica utilizzando campioni sonori
(ad esempio file .wav) da disporre all’interno di pattern.
Un pattern altro non e’ che un “foglio” di musica, formato da differenti righe che viene suonato sequenzialmente.
Maggiori informazioni su programmi di questo tipo le potete trovare qui: http://en.wikipedia.org/wiki/Tracker

per voi Sir. Lodux !

Box2d è un simulatore di corpi rigidi in 2D sviluppato in C++. E’ molto utile perché permette in poche righe di creare un motore fisico e quindi al posto di crearsi tutte quelle routine per l’animazione degli oggetti lasciamo ad Dott. Isaac Newton di farlo per noi attraverso le regole della Fisica

Caratteristiche del motore fisico:

Collision

• Continuous collision detection.
• Contact callbacks: add, persist, remove.
• Convex polyons and circles.
• Multiple shapes per body
• One-shot contact manifolds
• Incremental sweep-and-prune broadphase
• Efficient pair management
• Fast broadphase AABB queries
• Collision groups and categories

continua…

Physics

• Continuous physics with time of impact island solver.
• Persistent body-joint-contact graph
• Island solution and sleep management
• Contact, friction, and restitution
• Stable stacking with a linear-time solver
• Revolute, prismatic, distance, pulley, gear, and mouse joints
• Joint limits, motors, and friction
• Momentum decoupled position correction
• Fairly accurate reaction forces/impulses

System

• Small block and stack allocators
• Centralized tuning parameters
• Highly portable C++ with no use of STL containers

Testbed

• OpenGL with Freeglut
• Graphical user interface with GLUI
• Easily switch between tests using GUI
• Test framework for easily adding new tests
• Mouse picking and the bomb!
• VC8 project files

In particolare il TestBed ha anche un progetto per Xcode così da poter provare su Macosx
i vari esempi (sono tanti e tutti documentatissimi).

Dicevamo che è scritto in C++, in particolare la maggior parte delle funzioni e dei tipi iniziano con il prefisso b2.

E’ facilmente integrabile in qualunque progetto per Iphone, vediamo brevemente quali sono i passi da compiere per crearsi un progetto che abbia un motore Box2d al suo interno.

1) Scaricarsi il codice sorgente di Box2d da http://sourceforge.net/projects/box2d

Attualmente la versione è la 2.0.1  (13 Aprile 2008)

2) Scompattare il tutto su una cartella

3) Creare o aprirsi un progetto Xcode (magari uno che abbia una vista OpenGLEs)

4) Copiare (anche tramite drag & drop) la cartella Source dentro il nostro progetto Xcode

5) Nella propria view includere l’header di Box2d

#include “Box2D.h”

6) Rinominare il file della view in .mm (per mischiare C++ e objective C)

7) Inizialiare un mondo prima di procedere con l’attivazione della vista OpenGLES

Qualcosa di simile:

Da qualche parte definisco le variabili:

[sourcecode language='c++']
b2AABB worldAABB;
b2World *m_world;
[/sourcecode]

E poi l’init del mondo è :

[sourcecode language='c++']
// inizializzo le coordinate del mondo
worldAABB.lowerBound.Set(-100.0f, -100.0f);
worldAABB.upperBound.Set(100.0f, 100.0f);

// Definisco il vettore di gravità
b2Vec2 gravity(0, -9.81f);

// Do we want to let bodies sleep?
bool doSleep = true;

// Costruisco il mondo
m_world= new b2World(worldAABB, gravity, doSleep);

// Definisco il corpo ground (terreno)
b2BodyDef groundBodyDef;
groundBodyDef.position.Set(0.0f, -15.0f);

// Call the body factory which allocates memory for the ground body
// from a pool and creates the ground box shape (also from a pool).
// The body is also added to the world.
b2Body* groundBody = m_world->CreateBody(&groundBodyDef);

// Define the ground box shape.
b2PolygonDef groundShapeDef;

// The extents are the half-widths of the box.
groundShapeDef.SetAsBox(50.0f, 10.0f);

// Add the ground shape to the ground body.
groundBody->CreateShape(&groundShapeDef);
[/sourcecode]

8 ) Nel main loop (se vogliamo la DrawView della nostra vista OpenGLES) faccio avanzare
la fisica del mondo:

[sourcecode language='c++']
float32 timeStep = 1.0f / 60.0f;
int32 iterations = 10;

// Instruct the world to perform a single step of simulation. It is
// generally best to keep the time step and iterations fixed.
m_world->Step(timeStep, iteration);
[/sourcecode]

(timeStep può essere benissimo animationInterval che usiamo per la view)

9) a questo punto si possono creare oggetti e usando una draw adatta disegnarli per vedere cosa
succede, per esempio se mi creo un cerchio in questo modo:

[sourcecode language='c++']
posX e posY sono la posizione del cerchio
m_body è un oggetto (body) inizializzato così: b2Body *m_body;
m_world è il nostro mondo creato in precedenza
ang è l’angolo di rotazione (in radianti)

// Define the dynamic body. We set its position and call the body
b2BodyDef bodyDef;

bodyDef.position.Set(posX, posY);
bodyDef.angle = ang; // the body’s angle in radians.
//bodyDef.linearDamping = 0.0f;
//bodyDef.angularDamping = 0.01f;
//bodyDef.isBullet = false;
bodyDef.angularDamping = 0.02f;

m_body = m_world->CreateBody(&bodyDef);

// Define box shape for our dynamic body.
b2CircleDef circleDef;

// Set the box density to be non-zero, so it will be dynamic.
circleDef.density = 1.0f;

// Override the default friction.
circleDef.friction = 0.3f;

// Add the shape to the body.
m_body->CreateShape(&circleDef);

// Now tell the dynamic body to compute it’s mass properties base
// on its shape.
m_body->SetMassFromShapes();
[/sourcecode]

Se vedete il codice al body va associato uno shape che sarà poi la forma che permette di controllarne la fisica, le collisioni e molto altro.
Se poi vogliamo disegnare questo oggetto procediamo in opengles a disegnare uno Sprite (c’e’ l’esempio dell’SDK che puo’ tornare utile) con la posizione corretta che prendiamo in questo modo:

[sourcecode language='c++']
// Vettore posizione del body:

b2Vec2 position = m_body->GetPosition();

// X sarà position.x e Y sarà position.y

// Angolo di rotazione del body

float32 angle = m_body->GetAngle();
[/sourcecode]

Una volta presi questi parametri il disegno dell’oggetto è semplicemente tuto codice openGLES:

[sourcecode language='c++']
glPushMatrix();

glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, spriteTexture);

if(m_isBlend) {
// Set a blending function to use
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
// Enable blending
glEnable(GL_BLEND);
}

glTranslatef(position.x, position.y, 0.0f);
glRotatef(angle*(180/b2_pi), 0.0, 0.0, 1.0f);

glVertexPointer(2, GL_FLOAT, 0, m_vertices);
glEnableClientState(GL_VERTEX_ARRAY);

// va tolto il colore se è textured!!! SI MA LO FACCIO SU SETTEXTURE
glColor4f(m_color_r, m_color_g, m_color_b, 1.0);

glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

if(m_isBlend) {
glDisable(GL_BLEND);
}

if(m_isTextured) {
glDisable(GL_TEXTURE_2D);
}

glPopMatrix();
[/sourcecode]

Per voi BugMan e un caloroso ringraziamento da Sir. Lodux !

Durante il mese di Febbraio il gioco non ha subito grosse evoluzioni dal punto di vista del gameplay.
Questo perchè abbiamo preferito concentrarci sui menu, sulla pulizia e il refactoring (mettere a fattor comune classi e metodi) del codice. Inoltre abbiamo cercato di rendere il codice sorgente molto piu’ corto, leggibile e semplice da usare. Tutti gli sforzi fatti sicuramente andranno ad incidere positivamente anche per i mesi successivi e per i prossimi giochi (se ce ne saranno) che potranno riutilizzare il codice scritto per Bubble Touch.
Ma vediamo nel dettaglio cosa e’ stato fatto questo mese:

•    Menu del gioco

Finalmente abbiamo completato il design del menu principale, e dei sottomenu utili per accedere e poter giocare ad un livello. L’idea e’ quella di rendere i menu facilmente intuibili ed utilizzabili, senza troppe spiegazioni e perdite di tempo.
Personalmente crediamo che un gioco per iPhone deve essere semplice e facile da usare, fin dal suo primo utilizzo: i primi 3/4 minuti di gioco devono impressionare chi gioca, e devono puntare quindi tutto su semplicita’ e giocabilita’.
Questo e’ ancora piu’ importante per Bubble Touch, che puo’ essere giocato anche per 2/3 minuti alla volta.

•    Bottone Play

Una volta cliccato sul bottone Play appare la schermata di selezione del pianeta:

Molto semplicemente i pianeti selezionabili appaiono nel loro “splendore” danzando, mentre per i pianeti non ancora sbloccati vedremo un’ombra.  Ogni pianeta è composto da 9 livelli che si sbloccheranno in ordine cronologico man mano che per ogni livello si raggiunge l’obiettivo prefissato.
Dopo aver scelto il pianeta (all’inizio del gioco sarà possibile solo giocare sul Blue Planet)  si accede alla selezione del livello:

Come gia’ descritto nel design, il livello e’ rappresentato con una mappa divisa in 9 singoli pezzi. I pezzi completati mostrano una parte di disegno che si andra’ a formare interamente quando il pianeta sara’ totalmente completato, mentre se un livello è disponibile ma non ancora “superato” il pezzo di mappa apparirà oscurato.
Selezionando un livello (con un clic – touch) sulla destra appariranno delle statistiche.
In particolare vedremo il numero del livello (Livello 1-1 nell’esempio in figura), un  bottone Play per poter giocare e se il livello è stato superato il punteggio massimo ottenuto.
La grafica di questa sezione e’ ancora in via di sviluppo, si possono notare le stelline che abbiamo deciso di utilizzare per sapere se il punteggio raggiunto è buono o meno.
Il box in grigio che vedete in figura rappresenta lo spazio dedicato al bottone Play che ancora non è stato disegnato graficamente.

•    Pagina dei risultati

Stiamo ancora lavorando sulla pagina dei risultati che apparira’ quando il giocatore ha terminato un livello.
Uno screenshot ancora in fase di costruzione che puo’ dare un’idea di come saranno presentati i risultati è il seguente:

In particolare in alto troveremo il risultato (livello completato o meno) mentre nel riquadro ora vuoto avremo le statistiche di bolle colpite divise per colori. Lo spazio dedicato alle stelle ci darà un valore visivo del punteggio che invece apparirà nella zona in basso subito dopo la scritta “Score:”.  Infine il pulsante “Map” farà tornare il giocare alla schermata di selezione del livello.

•    Supporto Texture PVR e Texture Atlas

Durante la fase di pulizia del codice ne abbiamo approfittato per migliorare la gestione delle texture atlas ed inserire il supporto per le texture PVR .
Probabilmente abbandoneremo il formato .png in favore del formato PVR in modo da occupare meno spazio su disco e migliorare le perfomance.
Inoltre abbiamo concluso l’implementazione del Texture Manager inserendo la possibilità di usare i Texture Atlas per ottimizzare il numero di immagini da gestire.

PiXy & BugMaN / PixMapBrothers per iPhone and Go….

un ringraziamento da sir. Lodux !

LINGUAGGIO DI PROGRAMMAZIONE:

Molto semplicemente, se si conosce gia’ qualcosa di C / C ++ conviene utilizzare direttamente questo linguaggio ed impararsi i costrutti e i fondamenti di Objective-C.
Objective-C deve essere necessariamente utilizzato per poter comunicare direttamente con le API del dispositivo e gestire il suo HW (ad esempio per poter creare una view che contiene una finestra OpenGL ES, oppure per poter gestire il touch (o il multitouch), l’accellerometro, … ).

Se non si conosce nessun linguaggio tanto vale imparare l’objective-c da 0.

Quali sono i vantaggi e gli svantaggi di una scelta (C/C++) piuttosto che l’altra (Objective-C) ?

Principalmente la portabilita’. Se scrivo un codice C++, utilizzando le librerie standard il gioco che scrivero’ sara’ molto facile da portare su altre piattaforme (anche su PC stesso) senza troppe modifiche. Per quanto riguarda i dispositivi mobili, windows CE (o mobile), il vecchio Symbian, o anche le stesse Qt (ora passate a Nokia) utilizzano estensivamente e in maniera completa il C++. Android di Google e’ l’unico sistema di API che attualemente utilizza Java e per cui il porting richiede la riscrittura di buona parte di codice.

Conoscendo solo l’Objective-C, per poter fare il porting (trasferire cioe’ l’applicazione da un dispositivo ad un altro) probabilmente ci sara’ molto piu’ lavoro da fare.

Ma non e’ che scrivere in Objective-C porta vantaggi nelle performance dell’applicazione ?

Assolutamente No. Il compilatore GCC e’ in grado di compilare allo stesso modo (ed anche in modo promiscuo) cocice C/C++ ed Objective-C. Molti sviluppatori non hanno trovato nessun calo dal punto di vista delle performance.

E’ possibile “mischiare” codice C++ ed Objective-C ?

Si ! Ed e’ quello che attualmente facciamo noi nel nostro gioco, se si conoscono e si utilizzano entrambi i linguaggi si puo’ prendere il meglio dall’uno e dall’altro e farli convivere tranquillamente.
Ad esempio il codice del nostro gioco che legge i livelli (che sono semplicemente file XML) utilizza il parser presente in Cocoa (la NSXMLParser ) fornendo metodi e comunicando con oggetti C++.

CONCLUSIONI:

Questi i nostri consigli:

Se si conosce gia’ il C++ incominciare ad imparare, quando serve e necessario, Objective-C (le basi sono comunque obbligatorie).

Se si hanno necessita’ e si pensa in futuro di riscrivere il codice per altri dispositivi pensare al C++ come linguaggio “primario”.

Se non si conosce nessun linguaggio e si vuole sviluppare solo per iPod /iPhone (ed al massimo Mac) imparare da 0 e per bene Objective-C.

OpenGL ES:

Se si vuole fare un gioco (sia 2D che 3D) penso la cosa migliore sia imparare ed utilizzare OpenGL ES.
OpenGL ES e’ un API (Application Programming Interface) di basso livello dedicata alla grafica tridimensionale e non solo.
E’ vero che per sviluppare una semplice applicazione 2D probabilmente anche le librerie messe a disposizione da Cocoa (nell’SDK di iPhone) potrebbero essere sufficienti, credo sia comunque meglio imparare OpenGL ES in quanto permette poi di poter sviluppare anche applicazioni 3D e sopratutto (cosa piu’ importante) comunicano a basso livello direttamente con il sottosistema grafico (scheda grafica + GPU).

Ci sono alcuni semplici esempi di utilizzo, basilare di OpenGL ES per una semplice applicazione 2D o 3D che possono essere “studiati”.

FISICA (physics engine):

Un buon gioco ha oramai anche un buon motore fisico alle spalle per gestire collisioni, interazioni tra oggetti, gravita’ , frizione, etc. etc.
Su iPhone vengono attualmente utilizzate due librerie:

* Box2D (nel prossimo articolo)
* Chipmunk (molto piu’ semplice e snella)

LIBRERIE AD ALTO LIVELLO:

Se volete utilizzare delle librerie (o motori grafici) di alto livello per sviluppare (evitando di dover imparare i concetti di basso livello) potete provare benissimo
Cocos2D (per il 2D) (che e’ scritta in Objective-C) o altre librerie gia’ esistenti per il 3D (simili).

AUDIO:

Per l’audio conviene utilizzare le librerie e le API messe a disposizione da Apple nell’SDK.
Ecco… per voi PiXy…! e un grazie da iPhone and Go.

PiXy e BugMaN hanno stilato un documento di nove pagine (fin’ora) molto dettagliato su quello che deve essere il concetto, la struttura, le sezioni, insomma tutto il necessario per argomentare tutti i punti che formeranno il gioco.

Si comincia con una descrizione tecnica, come l’orientamento del gioco, le opzioni di multiplayer o singleplayer, e le librerie da utilizzare BOX2d, OpenGLES; si passerà poi alla descrizione del gioco, come funzionerà, lo scopo, ecc; in seguito si troveranno le sezioni menu che comporranno il gioco e le loro specifiche.

Il documento che potrete facilmente scaricare da questo link e’ molto completo e ben fatto. PiXy e BugMaN nella loro avventura discutono, con domande aperte, su quelle che sono le soluzioni migliori da adottare per la realizzazione di Bubble Touch.

Ognuno di noi e’ libero di partecipare ponendo domande o semplicemente commentando ciò che sente nella speranza di dare un campo di prova molto importante prima della sua realizzazione completa finale !.

Per voi Sir. Lodux !

Ha inizio l’avventura, PiXy e BugMan ci racconteranno la loro esperienza, ci diranno come e’ nata la loro passione dei video games dai tempi del famoso C64 e dei giochi come Bubble Bobble, si racconteranno delle loro esperienze professionali e la loro sinergia come fratelli per realizzare i loro sogni comuni.

Impareremo !… Impareremo !… Bubble Touch e’ il loro videogame, si basa sulla fisica dei corpi 2D e la simulazioni di essi attraverso componenti disegnati appositamente per la loro realizzazione Box2d; PiXy e BugMaN ci insegneranno e mostreranno articolo dopo articolo, il codice necessario a realizzare queste splendide simulazioni in videogame.

Spero che tutti seguiranno insieme a me questo contributo e possano commentare ed aiutare PiXy e BugMaN in questa loro avventura!..

Sir. Lodux !