Modo discussione | Modo lineare

**_tommo_** · 01-06-2012 12:54

(01-06-2012 8:20)TheCrib ha scritto: Maccheeee ! 8P
iOS usa il chip in little-endian.

Ma... ma... wtf.

nel mio motore ho pure un codice che carica le mesh binarie BE su iOS e LE su x86. Prende un file con dentro int e float encodati BE/LE e li schiaffa direttamente in memoria. E funziona. Lo giuro. L'ho usato Fermosi

Possibile che in qualche modo ho impostato l'endianness in maniera differente? Fermofumo

Questo codice funziona su iOS solo se gli passo un file Big Endian.

Codice:

bool Mesh::load()

{

    //load binary mesh

    char* data;

    Platform::getSingleton()->loadFileContent( data, filePath );

    DEBUG_ASSERT( data );

    char* ptr = data;

    //index size

    setIndexByteSize( *ptr++ );

    //triangle mode

    setTriangleMode( (TriangleMode)*ptr++ );

    //fields

    for( uint i = 0; i < FIELDS_NUMBER; ++i )

    {

        if( *ptr++ )

            setVertexFieldEnabled( (VertexField)i );

    }

    //max and min

    memcpy( &max, ptr, sizeof( Vector ) );

    ptr += sizeof( Vector );

    memcpy( &min, ptr, sizeof( Vector ) );

    ptr += sizeof( Vector );

    //center and dimensions

    center = (max+min)*0.5f;

    dimensions = (max-min);

    //vertex count

    uint vc = *((int*)ptr);

    ptr += sizeof( int );

    //index count

    uint ic = *((int*)ptr);

    ptr += sizeof( int );

    setDynamic( false );

    begin( vc );

    //grab vertex data

    memcpy( vertices, ptr, vc * vertexSize );

    ptr += vc * vertexSize;

    vertexCount = vc;

    //grab index data

    if( ic )

    {

        setIndexCap( ic );

        memcpy( indices, ptr, ic * indexByteSize );

        indexCount = ic;

    }

    //push over to GPU

    return end();

}

come diavolo si spiega?

Gabriele · 01-06-2012 13:26

(01-06-2012 9:25)GeneralMao ha scritto: No, assolutamente, figurati.

Io la penso come te Luca, anche io ho il mio engine (framework) che mi tengo stretto e che ci tengo a portare avanti.

Il mio caso pero' e' un po anomalo perche' faccio questo per divertimento e come dopo lavoro guidato dalla passione.

Penso (credo) che se lo facessi per camparci alla fine unity lo valuterei e gli dedicherei un X ore al giorno per farmici le ossa ed essere in grado quanto prima di releasare.

E cmq non e' che con Unity lo skill non serva no? Non e' che un masterpiece come Syder arcade o come backreef pirates li fai senza uno skillset adeguato

Non so, secondo me il mio essere un evangelista del dark coding alla fine non sta ripagando gli sforzi.

m

imho dipende! Se ne hai le capacità fare un tuo FW va bene, e poi ecco è anche una questione di tempi, se progetti qualcosa da far girare in poco tempo, ti appoggi a unity e compagnia bella, altrimenti se hai tempo fondi e capacità meglio farsi tutto in casa Sisi

.

TheCrib · 01-06-2012 15:24

(01-06-2012 11:45)MannyB ha scritto: Comunque se come esercizio/esperienza vuoi reimplementarti le "tue" STL, male non fa

Male non fa.. ma non e' neanche una passeggiata.. anche solo rifare un vector e' piuttosto tricky in alcuni punti.
Ad esempio nella mia vector si puo' fare vec.push_back( vec.back() ) ..ma ho scoperto che per lo standard e' una cosa che non si puo' fare.
Dettagli che possono far impazzire.. pensavo di aver eun bug ed ho poi scoperto che era come funziona il vettore STL.

Poi ci sono cose come le hash maps.. non ho provato a rifarla e non so se vorrei farlo (^^;)

Detto questo.. io stesso continuo con il mio "vector" per ora e i miei smart pointers, finche' non c'e' un compilatore C++11 maturo e sono sicuro che posso affidarmi a quello.

Per l'engine poi, faccio anche del'garbage collection.. per-frame. Quindi, da un lato non ho aura ad implementare roba custom.. dall'altro, devo riconoscere che spesso molte delle ottimizzazioni standard possono essere overkill. Ovvero, piuttosto che fare una push_back() supersmart, magari semplicemente chiamare una bella reserve() prima dell'uso..

Poi ci sono i casi come quelli di STL nei vecchi Visual Studio dove si commettevano dei crimini orribili.. ma si spera che tutte le implementazioni stock siano migliorare rispetto a quella 8)

(01-06-2012 12:18)fatto ha scritto: è il mio piano B da sempre
Lo tengo pronto in caso di fallimento totale della mia vita (informatica)

E' difficile fallire se si punta in alto.
E' piu' probabile che succeda se invece si parte a testa bassa.
I limiti certi sono solo quelli che ti poni 8)

Che senso ha per un programmatore ottenere un risultato col minimo sforzo di programmazione ? Il bello e' tutto li.. e lo sforzo sara' sempre ripagato 8)

(01-06-2012 12:54)_tommo_ ha scritto: come diavolo si spiega?

Non lo so.. non vorrei toglierti un mito.. ma in questo snippet non vedo nessun endian swap.. magari mi sfugge(?)

Endian swap vuol dire semplicemente che i bytes in una "word" (sia 16, 32 o 8*N bits) sono invertiti nell'ordine.

MannyB · 01-06-2012 15:52

(01-06-2012 15:24)TheCrib ha scritto: Male non fa.. ma non e' neanche una passeggiata.. anche solo rifare un vector e' piuttosto tricky in alcuni punti.
Ad esempio nella mia vector si puo' fare vec.push_back( vec.back() ) ..ma ho scoperto che per lo standard e' una cosa che non si puo' fare.
Dettagli che possono far impazzire.. pensavo di aver eun bug ed ho poi scoperto che era come funziona il vettore STL.

Si ma infatti quando dico fatti la tua implementazione ovviamente parlo di implementarsi quello che ti serve (aka l'1% delle funzionalita' di un container STL), che normalmente vuol dire un paio di containers con funzionalita' di base ed ad hoc

Nel caso particolare di sigLuca io andrei di STL senza problemi (soprattutto se e' vero che ora Android le supporta)

Ho citato il code bloat dato che e' uno dei piu' "famosi" problemi di certe implementazioni di STL, soprattutto nei compiler vecchi. Ma dato che si parla di cross platform (aka cross compiler Asd

) non si sa mai in anticipo cosa aspettarsi nel momento che si decide di supportare una nuova piattaforma. Ma ripeto: sto cercando il pelo nell'uovo, questo e' l'ultimo dei problemi

TheCrib · 01-06-2012 15:54

(01-06-2012 13:26)Gabriele ha scritto: imho dipende! Se ne hai le capacità fare un tuo FW va bene, e poi ecco è anche una questione di tempi, se progetti qualcosa da far girare in poco tempo, ti appoggi a unity e compagnia bella, altrimenti se hai tempo fondi e capacità meglio farsi tutto in casa .

Ma il guadagno poi c'e' veramente ? Bisogna imparare tools, linguaggi, API, metodi di sviluppo.. e pagare soldi.. per poter usare un ambiente limitante e generico... nonostante cio' molti dei problemi di sviluppo rimangono comunque.

Magari l'efficienza aumenta verso il prodotto finale.. ma a quali compromessi e quanto tempo si dedica ad imparare ad usare un prodotto piuttosto che affinare le skills da programmatore ?

Per quelli come me, fare giochi e' una scusa per imparare.. del risultato finale mi interessa relativamente poco.. e' una medaglia per una maratona.. bella.. ogni tanto si spolvera, si guarda e si mostra a gli amici.. ma quello che conta e' come ci sono arrivato e cosa faro' dopo... il resto e' marginale.

(01-06-2012 15:52)MannyB ha scritto: Ho citato il code bloat dato che e' uno dei piu' "famosi" problemi di certe implementazioni di STL, soprattutto nei compiler vecchi. Ma dato che si parla di cross platform (aka cross compiler ) non si sa mai in anticipo cosa aspettarsi nel momento che si decide di supportare una nuova piattaforma. Ma ripeto: sto cercando il pelo nell'uovo, questo e' l'ultimo dei problemi

Anche io faccio l'avvocato del diavolo.. sono pur sempre della setta dei game developers, dove per fortuna s'e' mantenuto un certo livello di scetticismo/sanita' 8)

kunos · 01-06-2012 16:05

Insomma... in poche parole:

Ain't about how fast I get there
Ain't about what's waitin' on the other side
It's the climb

Asd

TheCrib · 01-06-2012 16:24

(01-06-2012 16:05)kunos ha scritto: Insomma... in poche parole:

Ain't about how fast I get there
Ain't about what's waitin' on the other side
It's the climb

Il succo e' quello.. anche se chiaramente va interpretato in chiave personale.. altrimenti si puo' andare per eccesso e dire: allora mi faccio il compilatore C++.. senno che gusto c'e', allora mi faccio il mio OS, allora allora.. e dopo 30 anni uno sta li a limarsi il chip 8P

**_tommo_** · 01-06-2012 16:44

(01-06-2012 15:24)TheCrib ha scritto: Non lo so.. non vorrei toglierti un mito.. ma in questo snippet non vedo nessun endian swap.. magari mi sfugge(?)

Endian swap vuol dire semplicemente che i bytes in una "word" (sia 16, 32 o 8*N bits) sono invertiti nell'ordine.

L'endian swap è all'interno del file binario, l'exporter che lo genera fa lo swap prima di scrivere int e float Selo

Dovrò indagare.

sigLuca · 04-06-2012 7:57

Bene,

proseguendo nell'indagine di quale possano essere buoni accorgimenti per lo sviluppo cross-platform, mi trovo per partire con lo sviluppo a dover decidere con quale ambiente/i lavorare.

Quello che mi sembrerebbe un buon punto di partenza sarebbe avere un progetto 'involucro' che possa essere compilato e testato sulle cinque piattaforme di riferimento Win,Mac,Linux,iOS,Android.

Posto che non prescindo dall'utilizzo di una IDE, avete qualche consiglio al riguardo?

Se parto creando un progetto con Visual Studio (Win) ad esempio, posso in qualche modo renderlo compatibile con XCode (Mac,iOS) e/o Eclipse (Linux/Android)?

Pensavo anche alla possibilità di usare una IDE cross-platform (Eclipse? CodeBlocks?) in modo che il progetto fosse unico per ogni piattaforma. Il mio timore in tal senso riguarda tutta la trafila di signature/certificati necessari per il deploy su iOS (per il quale sembra obbligatorio l'uso di XCode). Cosa ne pensate?

Grazie!

TheCrib · 04-06-2012 8:30

(ripeto un po' di cose (^^;))

Io sono partito con progetto VS e progetto Xcode.
Ora ho CMake (per creare il progetto VS) e sempre progetto piano in Xcode.. perche' appunto Xcode ha bisogno delle sue storielle con signature e quant'altro e cercare di generare un proj del genere via CMake sarebbe una impresa epica e molto dolorosa.

Per Android abbiamo una build con SCons.. che tutto sommato fa il suo dovere.

Di base vai con la piattaforma che preferisci.
Per me e' Visual Studio 2008 + Visual Assist X + ViEmu + AutoHotKey (per mappare CTRL+SHIFT+h/j/k/l in modo da avere Vi cursor movement fuori da ViEmu ..per selezionare la lista autocomplete, etc).

La cosa fondamentale per quanto mi riguarda e Visual Assist X ..senza il refactoring e la search semantica, secondo me e' troppo doloroso lavorare in C++.

Comunque l'idea di base e' che come prima piattaforma scegli quella che rappresenta l'ambiente ideale per te per sviluppare.

Ultima nota riguardo agli shell scripts.. ho rimpiazzato tutto con Python scripts.. sono piu' flessibili e si possono rendere multipiattaforma.
Esempio di script che chiama un mio tool per convertire dei .png in un formato custom, chiamando comando tipo dlsconv pack -q 90 <file in> <file out>:

Codice:

#!/usr/bin/env python

import os, shutil, glob 

#=======================================================

srcPattern = "data_src_terr/terr*disp*.png"

# assigns and converts to system path (needs \ in Windows..)

exePath = os.path.normpath( "databuild/bin/dlsconv" )

for f in glob.glob( srcPattern ): 

    baseName = os.path.basename( f )

    name, ext = os.path.splitext( baseName )

    cmd = exePath + " pack -q 90";

    cmd += " " + f;

    cmd += " " + os.path.join( " data_src", name + ".dls");

    print cmd

    os.system( cmd )

sigLuca · 25-06-2012 22:45

(04-06-2012 8:30)TheCrib ha scritto: (ripeto un po' di cose (^^;))

Io sono partito con progetto VS e progetto Xcode.
Ora ho CMake (per creare il progetto VS) e sempre progetto piano in Xcode.. perche' appunto Xcode ha bisogno delle sue storielle con signature e quant'altro e cercare di generare un proj del genere via CMake sarebbe una impresa epica e molto dolorosa.

Fammi capire meglio.

Tu hai creato due progetti, uno VS ed uno Xcode.

Entrambi i progetti condividevano gli stessi sorgenti e headers giusto? Magari in un repository comune?

Perché se questa soluzione funzionava, poi hai optato per CMake?

Facendo alcune ricerche ho trovato un sacco di tools che potrei usare, ma la confusione che ho in testa aumenta: GMake, IMake (o lmake), CMake, scons...

Altra cosa: usi CVS o qualcosa del genere per il codice?

Grazie ancora.

encelo · 25-06-2012 23:25

(25-06-2012 22:45)sigLuca ha scritto: Facendo alcune ricerche ho trovato un sacco di tools che potrei usare, ma la confusione che ho in testa aumenta: GMake, IMake (o lmake), CMake, scons...

Per avere un quadro più completo aggiungi anche waf, Premake e magari pure jam. Ahsisi

(25-06-2012 22:45)sigLuca ha scritto: Altra cosa: usi CVS o qualcosa del genere per il codice?

TheCrib · 26-06-2012 8:00

(25-06-2012 22:45)sigLuca ha scritto: Tu hai creato due progetti, uno VS ed uno Xcode.

Entrambi i progetti condividevano gli stessi sorgenti e headers giusto? Magari in un repository comune?

Perché se questa soluzione funzionava, poi hai optato per CMake?

Ho scelto CMake un po' con il sogno segreto di poter avere la build per tutte le piattaforme basata su quello. Purtroppo con iOS sembra un po' troppo difficile liberarsi da Xcode, per cui il sogno e' rimasto tale.

Per Android e OS X, invece il mio partner ha usato SCons (fatto tutto lui, non mi lamento 8). Quindi possiamo generare degli eseguibili OS X con la build SCons, senza Xcode ! Per iOS non ci abbiamo provato, ma sicuramente sarebbe una cosa piu' dolorosa e forse insostenibile nel tempo.

L'unico problema e' che SCons non credo generi progetti e soluzioni per VS.. e quindi continuo ad usare CMake per PC, il quale appunto permette di dire "prendi tutti i sorgenti in src e gli include in include e fammici il progetto", oppure gli si puo' dire di creare un makefile, nel caso uno non voglia usare neanche VS !

Se uno punta pero' solo a VS e iOS.. allora l'utilita' pratica viene meno, perche' tutto sommato il progetto Xcode comunque va sempre costruito a mano e fare lo stesso per VS non e' la fine del mondo.

Citazione:Altra cosa: usi CVS o qualcosa del genere per il codice?

Usavo svn.. ma poi siamo passati a hg + svn. Ovvero c'e' un repository hg per i sorgenti ed uno svn per gli assets. Il repo hg e' configurato per gestire il repo svn come un sotto-repository e quindi lavorano in sincronia (blog post sulla cosa).

E' una cosa abbastanza complessa e che ti sconsiglio.. e non lo avrei fatto da me senza l'aiuto del mio solito partner, che in queste cose ci sguazza bene.

Riguardo alle alternative:

- CVS: antico, arcaico, da dimenticare

- SVN: sucessore di CVS, fa il suo dovere, ma non e' ideale per chi fa molto branching e merging

- GIT (video): ideale per chi fa branching e merging, al giorno d'oggi ormai anche user friendly (e' un version control distributed.. ovvero funziona tranquillamente in locale, senza bisogno di un server)

- HG (Mercurial): molto simile a GIT come architettura, forse meno performante

- Perforce: non-free ma e' lo standard nel gamedev professionale ed oltre (si usa anche internamente in Google)

Noi usiamo hg + svn perche' volevamo a flessibilita' di hg.. ovvero la capacita' di lavorare con branches (senza i casini di svn).. ma allo stesso tempo, avendo parecchi dati binari, hg da solo non bastava.

La ragione e' che hg/git, essendo distribuiti, mantengono tutta la storia di tutti i files in locale. La cosa va bene per i files di testo tipo sorgenti.. ma se uno ha una PNG di 10 MB, modifica un pixel, risalva e committa.. quel file non essendo "diffabile" fa crescere il repository di altri 10 MB, per sempre, per tutti.

In pratica, rispetto a cvs/svn/Perforce, con git/hg ognuno ha tutti i dati che sono nel server.. ed infatti ognuno potrebbe essere un server a se stante.
Idea potente.. ma in pratica dolorosa con i files binari 8)

Perforce invece ha di bello che si comporta bene con i binari (tiene la storia solo sul server, come cvs/svn) e funziona bene con branches & merges. Ultimamente la licenza free e' migliorata di molto, ma comunque richiede sempre un server fai-da-te.. mentre per il resto dei version control ci sono soluzioni online piu' o meno free ..vedere github (io uso Assembla).

Un altro problema di Perforce e' che e' molto server-centrico.. e' pensato per essere sempre online. La versione recente migliora un po' le cose, aggiungendo una modalita' off-line ..ma e' comunque una cosa aggiunta dopo..

Quindi in pratica.. ti consiglio il buon vecchio svn (magari con un bel client visuale tipo TortoiseSVN o SourceTree) se hai abbastanza dati di grafica (come immagino avrai), altrimenti git e' interessante.. ma richiede il suo tempo ed e' forse piu' troppo una moda/religione.
Altrimenti hg, se vuoi la struttura tipo git, ma hai bisogno di estensioni tipo la gestione di subrepositories come facciamo noi (e se ti piace bestemmiare 8).

dany_dev · 26-06-2012 8:04

qui ci sono diverse soluzioni per gestire file binari con git
http://stackoverflow.com/questions/54053...s-with-git

per Mac, il miglior client per svn è Cornerstone, mentre il migliore client per git è SourceTree

TheCrib · 26-06-2012 8:16

(26-06-2012 8:04)dany_dev ha scritto: qui ci sono diverse soluzioni per gestire file binari con git
http://stackoverflow.com/questions/54053...s-with-git

Se ne parla molto, ma non vedo ancora una chiara soluzione con git.
La questione del submodule e' interessante, ma si tratta di nuovo di subrepos in git, non svn.

Senza contare che tutte queste cose aggiungono "moving parts".. il nostro hg+svn in teoria funziona bene.. in pratica, alle volte "sbrocca" 8)

La soluzione migliore secondo me rimane Perforce.. e spero che si decideranno a creare una versione cloud che non sia solo per trial.

Modo discussione \| Modo lineare Sviluppare un gioco multipiattaforma: risorse e consigli
Autore	Messaggio