Studio E Sviluppo Di Un Progetto Per La Portabilitá Multipiattaforma Di Un
Total Page:16
File Type:pdf, Size:1020Kb
STUDIOESVILUPPODIUNPROGETTOPERLA PORTABILITÁMULTIPIATTAFORMADIUN SISTEMAPERLAVISUALIZZAZIONEDIAMBIENTI VIRTUALITRIDIMENSIONALIINTERATTIVI ilario sanseverino Giugno 2014 Ilario Sanseverino: Studio e sviluppo di un progetto per la portabili- tá multipiattaforma di un sistema per la visualizzazione di ambienti virtuali tridimensionali interattivi, © Giugno 2014 ABSTRACT Object of this thesis is to investigate the existing solutions avail- able for cross-platforming, analysing in particular the specific case study of the conversion of a large project, related to a com- plex multimedia application native to the Microsoft (MS) Win- dows environment, into a multi-platform project, discussing the problems encountered and the solutions adopted. SOMMARIO Lo scopo di questa tesi è di investigare le soluzioni esistenti per la portabilità multipiattaforma, in particolare analizzando lo specifico caso di studio della conversione di un grande proget- to, relativo ad una complessa applicazione multimediale nativa per l’ambiente MS Windows, in un progetto multipiattaforma, discutendo dei problemi incontrati e delle soluzioni adottate. iii INDICE 1 introduzione1 2 stato dell’arte5 2.1 Macchine Virtuali 5 2.1.1 ScummVM 7 2.1.2 Mupen64+ 8 2.2 Linguaggi interpretati 8 2.2.1 Java 10 2.2.2 Web apps 11 2.3 Sorgenti ad hoc 12 2.4 Portabilità per libreria 14 2.4.1 Cocos2d 15 2.4.2 Unity 16 2.4.3 Marmalade 18 2.5 Wine 20 2.6 Considerazioni 21 3 architettura 24 3.1 Struttura originale 25 3.1.1 Parser 26 3.1.2 Engine 31 3.1.3 Procedural 35 3.1.4 VR 36 3.1.5 Avatar 37 3.1.6 Multimedia 38 3.1.7 Audio 39 3.2 Librerie utilizzate 39 3.2.1 Boost 40 3.2.2 SDL 41 3.2.3 FFmpeg 43 3.2.4 LibFFI 44 3.2.5 Libarchive 46 3.3 Modifiche apportate 46 3.3.1 Message passing 48 3.3.2 Embedded Resources 49 3.3.3 Video 51 4 implementazione 54 4.1 Building... 54 4.1.1 Piccoli bug insidiosi 56 4.2 Restyling 59 4.2.1 Networking 59 iv indice v 4.2.2 Audio 61 4.2.3 Device di input 62 4.2.4 Console 65 4.2.5 DLL esterne 65 4.2.6 Video Library 68 4.2.7 Shared Memory 80 4.3 File Embedder 82 5 conclusioni 85 5.1 Obiettivi raggiunti 85 5.2 Confronti 86 5.2.1 Capacità del sistema 86 5.2.2 Lego Editor 88 5.2.3 Novità 93 5.2.4 Retrocompatibilità 94 5.2.5 Oculus VR 96 5.3 Sviluppi futuri 99 i appendice 104 bibliografia 106 ELENCODELLEFIGURE Figura 1 Mappa dei branch di Cocos2d 15 Figura 2 Configurazioni specifiche in Unity 17 Figura 3 Marmalade c++ stack 18 Figura 4 Marmalade workflow 19 Figura 5 Marmalade Juice stack 20 Figura 6 Architettura di Wine 22 Figura 7 CVmMemManager e derivate 27 Figura 8 Infrastruttura per le classi s3d 29 Figura 9 Virtual Machine 30 Figura 10 Extract and Execute 31 Figura 11 Diagramma di sequenza dell’engine 32 Figura 12 Oggetti multimediali 33 Figura 13 Download ed estrazione 34 Figura 14 Schermate di xvr 35 Figura 15 ProceduralLib 36 Figura 16 AvatarLib 38 Figura 17 Interazione con la libreria multimediale 39 Figura 18 Architettura per la OnTimer 47 Figura 19 Message queue 48 Figura 20 Supporto all’internazionalizzazione 50 Figura 21 Video Library 52 Figura 22 Video riprodotto con la nuova libreria 79 Figura 23 Tentativo di riproduzione col player ori- ginale 79 Figura 24 “Riproduzione” di video con wine 80 Figura 25 Test sul numero di poligoni in azione 86 Figura 26 Esecuzione con 2000 oggetti 89 Figura 27 Esecuzione con 6000 oggetti 90 Figura 28 Una semplice costruzione ottenuta con l’editor 90 Figura 29 Logo 3d 91 Figura 30 Confronto 91 Figura 31 Esempi di output tramite console 94 Figura 32 Livorno Virtuale 96 Figura 33 Ambiente tridimensionale vasto e detta- gliato 97 Figura 34 Esempi di uso di shader GLSL 98 vi Figura 35 Script per Oculus, prima e dopo lo shad- ing 100 Figura 36 Interazione tramite Oculus Rift 101 ELENCODELLETABELLE Tabella 1 Branch di Cocos2d e caratteristiche 16 Tabella 2 Alcune metriche relative al progetto 26 Tabella 3 Piattaforme supportate da LibFFI 45 Tabella 4 Confronto sul framerate 92 Tabella 5 Comportamento della rete 93 Tabella 6 Righe di codice degli shader 95 ELENCODEILISTATI Listato 1 Inclusione delle funzioni OpenGL 57 Listato 2 Header per le funzioni di rete 60 Listato 3 WSA Setup 61 Listato 4 Close socket and WSA cleanup 61 Listato 5 Caricamento di file Wav in OpenAL 63 Listato 6 CVmJoystick: vecchio costruttore 64 Listato 7 CVmJoystick: nuovo costruttore 64 Listato 8 CVmJoystick: vecchia query 64 Listato 9 CVmJoystick: nuova query 64 Listato 10 Gestione della tastiera 66 Listato 11 CVmExternDLL: vecchia invocazione 67 Listato 12 CVmExternDLL: nuova invocazione 68 Listato 13 costruttore copia di VFrame 69 Listato 14 Operatori di confronto 70 Listato 15 Iteratore inverso in enqueue 70 Listato 16 Iteratore inverso in shiftTime 70 Listato 17 Query con coda vuota 71 Listato 18 Dati per FFmpeg 72 Listato 19 Dati per VThread 72 Listato 20 Decodifica di un frame video 74 vii Listato 21 Decodifica di un frame audio 75 Listato 22 Calcolo del Presentation TimeStamp (PTS) 76 Listato 23 Pausa 76 Listato 24 Binary file embedder 83 Listato 25 Test sul numero di poligoni supportati 87 ACRONIMI API Application Programming Interface EAX Environmental Audio eXtensions EFX Effects eXtensions FFI Foreign Function Interface GCC GNU Compiler Collection GLSL GL Shading Language GLUT OpenGL Utility Toolkit GPL GNU General Public License GTK+ GIMP ToolKit HMD Head Mounted Display IDE Integrated Development Environment JIT Just In Time LGPL GNU Lesser General Public License LOD Level Of Detail MCI Multimedia Control Interface MinGW Minimal GNU for Windows MS Microsoft MSDNAA Microsoft Developer Network Academic Alliance MSVC Microsoft Visual C++ viii acronimi ix MSVS Microsoft Visual Studio POD Plain Old Data PPC PowerPC PTS Presentation TimeStamp RCOD Red Cross Of Death SCUMM Script Creation Utility for Maniac Mansion SDK Software Development Kit SDL Simple DirectMedia Layer SVN Subversion VM Virtual Machine Wine Wine Is Not an Emulator WSA Windows Socket API XVR eXtreme Virtual Reality 1 INTRODUZIONE Per cross-platforming si intende comunemente la capacità di un software di poter essere eseguito su due o più configurazioni diverse di hardware/sistema operativo, come ad esempio un gioco che funziona sia su PC che su console, o un programma in grado di girare su MS Windows, GNU/Linux e Mac OSX senza differenze di comportamento eccessivamente marcate. Agli albori dell’home computing gli sviluppatori non aveva- no a che fare con una grande varietà di sistemi. I primi mi- crocomputer, come l’Apple II o il Commodore PET, avevano un hardware ben definito e scarse possibilità di modifica. Inol- tre erano oggetti difficili da reperire e parecchio costosi, quin- di chi possedeva un calcolatore si concentrava sullo sviluppo per quella macchina specifica, cercando di sfruttare al meglio le componenti a disposizione. Con la sempre maggiore diffusione dell’elettronica di consu- mo la situazione ha cominciato a cambiare: le prestazioni dei componenti tecnologici sono migliorate incredibilmente, i prez- zi dell’hardware sono scesi, sul mercato sono approdati i PC assemblati; inoltre la produzione di software è diventata un af- fare molto redditizio, provocando un cambiamento sostanzia- le dell’approccio produttivo, passando dall’appassionato che programma “artigianalmente” nel suo garage alle aziende che producono per vendere al maggior numero di utenti possibile. Pertanto è diventato imprescindibile avere layer d’astrazione sull’hardware e standard d’interoperabilità. Negli anni ’90 MS Windows ha fatto indiscussamente da pa- drone sul mercato PC consumer; le esigenze di programma- zione multipiattaforma erano per lo più limitate all’ambiente videoludico, in cui distribuire un gioco sia su PC che sulle va- rie console disponibili poteva essere un affare remunerativo. Al giorno d’oggi invece la situazione è molto più complicata: con l’avvento degli smartphone gli utenti non sono più tanto dispo- sti a tollerare che i loro programmi preferiti siano legati ad un sistema operativo particolare, si aspettano di poter passare da telefono a tablet a PC in maniera rapida ed efficace. Inoltre è più probabile che siano i software ad essere acquistati in base alla disponibilità per il proprio dispositivo che non il viceversa 1 introduzione 2 (come invece accade per le console, in cui esiste il concetto di killer app, il software talmente desiderato da spingere le vendite dell’hardware). Il mobile computing non ha solo portato una grande diffusio- ne di sistemi operativi non Microsoft tra gli utenti, ma anche nuovi paradigmi di utilizzo ed interazione basati su sensori e dispositivi, quali il GPS, i sensori inerziali o gli schermi multi- touch, fino ad allora indisponibili o non utilizzati. La program- mazione multipiattaforma comporta, dunque, tutta una serie di problemi, tecnici (quali caratteristiche sono riconosciute dal compilatore? Quali librerie posso dare per scontate e quali inve- ce devo fornire insieme al programma? Quali feature non sup- portate possono essere sostituite, quali escluse e quali invece devono essere considerate vitali?) e d’interfaccia (in quale mo- do posso efficacemente tradurre una complessa combinazione di tasti per joystick in gesture e accelerazioni?). In compenso il cross-platforming presenta anche molti van- taggi. In primo luogo la disponibilità per sistemi differenti con- sente all’utente di utilizzare i programmi che desidera in un unico ambiente, senza la necessità di multi-boot o macchine vir- tuali dedicate. Inoltre si aggiunge un layer d’astrazione anche sul software, e come affermò una volta David J. Wheeler “all problems in computer science can be solved by another level of indirection” [10].