Però occhio: Android 2.2 o inferiore supporta solo i thread managed per lo sviluppo end-user, quelli nativi non andrebbero usati per le applicazioni consumer (è nelle spec) ma solo a fini di sviluppo driver o del software nativo da includere con la distribuzione di un firmware. Questo potrebbe spiegare anche il problema che stai riscontrando sulle API OpenGL ES non implementate. Un processo spawnato nativamente ha dei limiti per aumentare l'efficienza della gestione della memoria.
JNI ha delle funzioni per convertire un thread nativo in thread managed, e su Android funzionano benissimo.
Beh, benissimo, aspettiamo un'attimo. Dipende come lo usi. Se hai una funzione render() che invochi in nativo la differenza non si nota. Entrare ed uscire dal contesto ha un costo piuttosto alto...
Io seguirei le best pratcice che prevedono di wrappare il codice per frame, logica (render(), physics(), ai()) o per componente al fine di evitare al minimo il cambio di contesto e il passaggio di troppi dati da dentro e fuori. Fare pipelining aiuta molto.
Solo Anrdoid 2.3 supporta i thread nativi al 100% delle funzionalità con debug e tutto per lo sviluppo end-user (e non mi pare serva nemmeno il root), perché è la prima piattaforma a supportare i chip multicore anche per lo userspace. Infatti con gli SDK 2.3 fai tutto. Francamente io non ti consiglio di usare il 2.3 in sviluppo se targettate il 2.2 ma nemmeno di usare qualcosa per il 2.2 che non dovrebbe essere usato...
Hai provato a fare un POC tutto basato su Dalvik che faccia quelle cose? Non è detto che vada peggio, visto che devi fare affidamento sul multithreading (e quello managed è molto più reattivo di quello nativo perché l'SO e la CPU non fanno context switching, quindi vai leggero anche sulla cache della CPU).
Quindi non mi consigli di usare il 2.3 se targetto il 2.2. Giusto.
Ma non mi consigli neanche il 2.2, per via del multithread nativo. Giusto anche questo (ma se non va fatto, perche' ci sono i sample? vabbe').
Mi e' sfuggito il consiglio su cosa usare, pero'.
Torno a monte del discorso: non ho nessuno di questi problemi con iOS. Mi piacerebbe - da programmatore - che il mio lavoro consista nel programmare, non nel diventare mongolo dietro a bug della piattaforma/IDE/debugger non collaborativi, e in questo, a mio giudizio, Apple ha fatto un lavoro migliore; viceversa, Android da questo punto di vista e' una delle piattaforme peggiori su cui ho lavorato.
Ti sei risposto da solo e già te l'ho scritto: fai quello che puoi fare, non quello che non puoi fare, forzando il sistema. Esattamente come faresti su iOS, non credo che lì ti metti a smanettare nei meandri dell'SO jailbreakato per arrivare a fare, che ne so, le stesse cose che potevi fare su PS2, no?
Mettiti nei panni di Epic: hanno rilasciato infinity blade su iPad 2 e non ha funzionato un cazzo per settimane abbassando sensibilmente la medi all'app: pensi che hanno portato il vecchio core grafico di iPad su iPad 2 o hanno inziato a capire cosa potevano aggirare, visto che Apple ancora non ha presentato la documentazione ufficiale per garantire la retrocompatibilità sulle nuove GPU e sulla nuova architettura dual core?
Esposto così mi pare piuttosto chiaro che il problema sia "voglio iOS su Android". Non lo avrai mai. Stop. E' un discorso fuori della logica. Se porti un'applicazione da PC a Mac la riscrivi quasi tutta non ti porti windows su PC o il Mac su Windows. Uguale se la porti da una console all'altra.
Non capisco che vuol dire "io sono un programmatore e voglio programmare" e cosa staresti facendo, scusa? Programmare è risolvere problemi, molti dei quali (anzi, quasi tutti) sono a monte del codice. Capito questo avrai risolto gran parte dei tuoi problemi.
Ogni piattaforma ha le sue peculiarità, devi sfruttarle, non abbatterle perché ne vorresti avere altre. Chi ti garantisce che i tuoi "fix" reggano al tempo? Before hacking. Start thinking!
Per essere chiari il mio consiglio è: se devi fare un engine per portare un gioco, la parte core dell'engine riscrivila secondo le specifiche del sistema operativo target. Se l'engine è fatto bene, non avrai problemi a metterci il codice del gioco su senza alcuna o con pochissime modifiche. Avrai molti meno problemi a mantenere le due versioni (che tanto non si evolveranno lo stesso in modi perfettamente paralleli) e non avrai codice dipendente da hack il cui futuro sarà piuttosto dubbio.
L'altra alternativa è pensare ad un software third party che dia queste garanzie. E qui entra in gioco la pianificazione strategica (che non è detto non possa proporre tu, visto che sei l'esperto).
A quel punto dovrai gestirti le discrepanze di OpenGL. Vabbene. Non c'è mai morto nessuno: si tratta di fare una lista della spesa. Il problema è un'altro: ma questa lista della spesa ve l'hanno comunicata? Se non sapete quali sono i dispositivi più importanti per le vostre esigenze commerciali, potreste menare il can per l'aia per settimane e fare un lancio disastroso (per la cronaca: qualcuno mi paga per dare questi consigli scontati, eh!).
Questo per cultura personale:
Mi parli così bene di iOS ma lo sai che la versione che avete usato voi per Master of Alchemy credo fosse la prima con un multithreading quasi reale? (Prima c'era una specie di preemption un po' zoppa se la caricavi troppo). Cosa avresti fatto prima? Perché andare di multithreading su dispositivi single core?
Autore
Topic: Bachi/funzioni non implementate su OpenGL ES per Android? (Letto 3175 volte)