Hey.. il tuo avatar non e' troppo friendly ;)

E sotto c'e' una bio bella corposa.. educativa, pero' ricordo quando scrivesti che solitamente preferisci non dilungarti sul tuo curriculum.. siamo sicuri ? ;)

Anche io di recente ho pensato di mettere su una mia ennesima "vanity page", ma sono un po combattuto.
In passato lo feci (hello, HTML !), ma al giorno d'oggi puo' essere un'arma a doppio taglio. Perche' piu' uno si associa a delle compagnie piu' deve stare attento a quello che scrive.. non tanto per questioni legali ma per questioni di etica.. ovvero' se metto in chiare lettere dove lavoro e poi vaneggio sul blog (cosa non rara), e' possibile che contribuisca negativamente all'immagine della compagnia a cui sono associato.. sia anche solo per un paio di potenziali clienti (i giocatori).

Penso nel tuo caso non sia un problema.. ma a me e' capitato di vergognarmi un po per alcuni colleghi che preferirei non mi rappresentassero pubblicamente.   ..OK, ho divagato 8)

Buon Blog 2010 !

maooooo
Davide

..azzz..  una scusa per pubblicare qualcosa con la benedizione dell'employer puo' essere quella della visibilita' che ne guadagna la compagnia.

Comunque e' importante nutrire la propria individualita'. Personalmente, se vedo che lo sviluppo di un prodotto va bene e ci sono buoni prospetti di una release gloriosa, allora magari metto extra impegno al lavoro.. ma se la barca comincia a fare acqua, meglio dedicare piu' tempo al blog a fare il sapientone o a releasare qualcosa in proprio ...evitando intersezioni con il lavoro.

ole'

..ahh fammi rileggere che mi pompo !

..OK.. fatto 8)

In realta' mi sono reso conto che le cose buone che mi sono successe al livello di carriera sono sempre uscite da un progetto personale o un impegno straordinario in qualcosa in cui ho creduto.. o magari in cui non ci credevo tanto, ma che ho portato avanti comunque..

Da parecchio si parla ormai di multi-core e software rendering, etc.. cosi' un giorno vado dall'ennesimo nuovo capo per chiedergli eventuale supporto per qualcosa a cui ho lavorato in proprio di recente.. un renderer, proprio pensato per many-core, SIMD, network rendering (The Cloudddd !), Reyes pipeline (i micropoligoniii !!! Ma quanto sono piccoli ?!), shader compiler e tutte queste balle.. di cui i vari CEO, CTO e pippiripo', PowerPointano ma che pochi effettivamente implementano (implementare == capire).

..e la risposta che ricevo e a dir poco tiepida. Invece di saltarmi adosso e dirmi: "che ficooo !! famooo, cosamoooo !!", mi ritrovo a dover pitchare come un venditore di macchine usate.
Cose del tipo, "ehh ma poi pesti i piedi a quest'altro che sta facendo una cosa simileee" (si sa, mele == arance), "..ma questi micropoligoni sono vantaggiosi ??", "..ma quante features hai ??".

..si vabbe', buona notte.. se devo perdere tempo a pregare e a dovermi difendere da competizione interna e burocrazia varia e power struggles del piffero, ..non si finisce piu'.

Cosi', in questo ennesimo caso ho continuato per fatti miei ed ora sono sicuro che con il progresso fatto (minimo ma tangibile) posso fare il figaccione in altri lochi.
Con il codice all'aperto, senza contratti o vincoli vari, senza dover perdere un mese su PowerPoint del cacchio a parlare di aria fritta.

E' un loop confermato dal notaio:

- Lavora ad un side project in proprio
- Usa il know-how acquisito per fare il Mastro Lindo al lavoro corrente o per trovarne uno nuovo
- ???
- GOTO 10

ole'

Il problema con quello che si fa al lavoro non e' tanto che piaccia o meno.. nulla e' ideale e bisogna sempre scendere a compromessi, ma con un po di impegno si riesce a fare quello che piace. Il vero problema e' che se poi per qualche ragione un progetto viene cancellato (come spesso succede per i giochi).. si finisce con tanta esperienza ma niente gloria.. e la gloria in questo campo ha anche un valore economico.
Perche' se dedico due anni ad un progetto che si traduce in qualcosa di figo e riconoscibile, il mio valore dimostrato sale.. mentre se passo due anni su un progetto che finisce in un peto, posso mettere sul CV che ho fatto tanta esperienza per 2 anni, ma non fa lo stesso effetto..

Fare qualcosa in proprio a casa invece garantisce che il proprio lavoro non vada in fumo senza mai vedere la luce del giorno.
Chiaramente si e' limitati in quello che si puo' fare da soli (o in un piccolo gruppo).. ma anche un solo programmatore puo' creare tecnologia che puo' tornare utile in futuro.

..non tutti hanno il tempo o la voglia di intraprendere questo percorso, ma per me ha sempre funzionato, e praticamente ogni cosa a cui ho lavorato individualmente, si e' rivelata utile se non vitale.
Tanto e' che il mio primo impiego serio nel game dev e' stato in America nel 95.. al tempo mandai una demo 3D come dimostrativo (RTMZ).. e dubito che senza di quella mi avrebbero mai considerato.

E poi c'e' anche la soddisfazione personale di sentirsi dire "ahh tu sei quello di RTMZ/ PSEmu/ kazrace/ quel frattale sulla PSX/ TokyoClubbers (?!)/ etc"..  ..tutte cose che nel loro piccolo danno tanta soddisfazione considerando quello che costano.. e che talvolta sono anche di ispirazione al prossimo.
E personalmente forse preferisco qualcuno che apprezza un mio renderer, piuttosto che un gamer che pensa che sia bello solo perche' lavoro per la compagnia di FF.

In sintesi, non dico di andare indie.. e avendo lavorato per compagnie piccole.. sono molto contento di lavorare per una compagnia grossa e famosa che mi manda al Siggraph, al GDC e che mi da accesso ad hardware superfigo..  ma personalmente credo sia anche importante mantenere una certa indipendenza se si vuole avere maggior controllo sul proprio futuro.

ole'

Interessante ! Hai qualcosa di provabile, screenshots o info su web ? 8)

Mettere il frame rate in prima posizione e' una fregatura per l'evoluzione.
Il real-time in realta' e' solo possibile grazie al lavoro che si fa offline in fase di building.. ma nel game dev tende ad esserci questo grande divario tra run-time e build.. il run-time medio e' relativamente banale perche' c'e' poco controllo del sistema a basso livello.

Personalmente i vari OpenGL e DX mi hanno scocciato.. perche' sono sempre altri (compagnie, hardware makers) a decidere come evolvono... e continua ad esserci un bel divario fra off-line e real-time: diversa pipeline, diverse primitive, diverso lighting e materiali, diverso shader system. Tutto questo, per compagnie che fanno sia prerendered che real-time, e' un gran spreco.

Capire l'off-line un po meglio, avere il controllo totale del rendering, permette di decidere cosa e' o potra' diventare real-time, e cosa relegare alla fase di build.
Se poi uno ha bisogno del doppio dei cores per renderare alla stessa velocita' dell'hw moderno.. non e' una cosa cosi' negativa se lo fa con una pipeline piu' efficiente che non richiede ogni volta di creare e sistemi specifici per il real-time che non c'entrano niente con l'off-line.

L'importante per me ora e' mirare alla scalabilita'. Quindi quando scrivo qualcosa non mi chiedo quanto sia veloce ma piu' che altro quanto potra' migliorare il giorno in cui la CPU avra' piu' cores o vector instructions con SIMD piu' largo.
E poi al guadagno riguardo ai tempi di sviluppo.

ummummm

Sommo adesso ti dico una curiosita' che forse non hai mai saputo ma a quel tempo quando bazzicavo con assembly e super inner loop per il phong shading con la div ad un 1 ciclo ero stato molto colpito da RTMZ, tanto da mettermi li' con un mio amico demo-scener Giuliano Cioffi (un genio) ad ottimizzare il nostro engine per demo ad andare 2 volte piu' veloce del tuo RTMZ.
Infatti, te lo sarai perso perche' sarai stato in America, ma aveva fatto scalpore quando in demo.ita di fidonet avevo pubblicato i benchmark in cui proudamente sostenevo di averti battuto in ogni feature (Boh forse il Caturano avra' ancora qualche archivio di fidonet da qualche parte di Lelio)

Vedi, non sai mai chi ti ritrovi 10 anni dopo

btw: ok il mio era piu' veloce ma il tuo disegnava meglio, ma io questo mica l' ho detto a nessuno.
(Findo ad adesso )

Stiamo andando OT 

Eh la paginetta non la faccio proprio per la pressione... già sto seguendo l'uni e il mio gioco ed è un disastro

Cmq il problema con CUDA è che è molto diverso dai processori normali, volte in meglio volte in peggio: per esempio la "SIMDificazione" è un non-problema perchè l'hardware è SIMT; invece che fare 1 thread che fa float4*float4, si fanno 4 threads che fanno float*float
Il downside sta nel fatto che i bucket e le atomic operations in genere sono il disastro: fermare un thread serializza l'intera wave, cioè 32 threads in blocco... per cui la semplice operazione di "chiedere" in quale bucket risiede un thread porta alla devastazione delle performances... paradossalmente è più performante eseguire un thread per triangolo alla cieca.
Anche qua aspettavo Fermi come la manna

Cmq ok meglio smettere di deragliare il topic di Alberto, magari se ne apre un'altro?