Newsgroup: it.fan.studio-vit
Titolo: Giochi programmati bene ? (segue da cosa all'hardware)

Dato che sono in ritardo apro un altro thjread... e la confusione
aumenta in allegria.
Perozzo... tu mi hai detto che se Unreal, o altri giochi molto esosi,
fossero stati programmati meglio, avrebbero potuto girare su PC meno
potenti.
Io ti posso rispondere che proprio perchč sono programmati meglio hanno
richieste hardware piů esose. 
Il progreammare bene = programmare a piů basso livello e ottimizzando il
codice all'inverosimile č una balla clamorosa, o perlomeno era vero
qualche anno fa, non piů ora con i linguaggi che si evolvono e teorie di
programmazione moderne.

programmazione moderne.
Lo so, tu sei un bravo programmatore cosi' come tutti gli altri ragazzi
della fastware, conosci i tuoi limiti, sai come spremere per bene una
macchina con le linee di codice necessarie.
Tuttavia devi riconoscere che per troppi programmi vengono rilasciate delle
patch onde correggere difetti.
Programmare bene significa riuscire a far fare ad un computer, con poche
righe di codice, o fargli fare cose per le quali sarebbe stata necessario
hardware aggiuntivo (si con tante righe di codice).
 Prendi il C=64: teoricamente la sua polifonia massima era di tre note, ma
con appositi trucchi si riusciva a fargli fare un accordo di tre note piu'
una melodia di due note di polifonia. Per fare una cosa del genere sarebbe
stato necessario comprarsi il soundbuggy, un modulo di espansione sonora.
Amiga ha poi innalzato questa tecnologia permettendo addirittura di
raddoppiare (o quadruplicare) il numero di voci disponibili. E dire che la
casa produttrice diceva che poteva far suonare al massimo quattro voci.
Con lo sviluppo selvaggio dell'hardware il codice non ottimizzato si e'
sparso a macchia d'olio, del resto chi te lo fa fare a perdere tempo per
ottimizzare un programma che gira lento adesso, ma tra 2-3 mesi potra'
contare su hardware decisamente piu' cazzuti?  Prendi le appplicazioni
scritte in VB: un programma che disegna su una schermata "Ciao Gente" occupa
la bellezza di 1500 Kb in Dll e zizac vari, e (forse) 50 K di eseguibile. Lo
stesso programma scritto in Java sta tutto in 980 byte.
Ok sul fatto che non e' possibile ottenere una grafica da sballo senza
scheda 3d, potrei essere d'ccordo, ma solo perche' ci sono migliaia di
schede video in commercio e si dovrebbero studiare programmi ottimizzati per
ciascuna scheda video. Idem per l'audio, il processore, eccetera. A questo
punto meglio demandare parte del lavoro al sistema e fregarsene se poi
rallenta.
Poi si manda a quel paese Fasttour quando non si riesce a fare piu' di 82.
Nella prossima versione metteteci la modalita' trainer con l'undo eh?
--
Memento Audere Semper
Nettuno
159° MASSM
10° C.I.N.G.H.I.A.L.E.
Please remove ziazc.imei to reply

programmazione moderne.
?
Premettendo che io di programmazione ne so poco o zero, mi sembra
comunque strano che un programmatore sia considerato bravo se riesce a
far piantare meglio il suo gioco di un altro!
Flx
------------------------------
Ciucciatevi il calzino
http://www.g-o-l.com/flashback
Ciuccelloni
http://space.tin.it/musica/flaviomu
Bacarospi
http://www.terzomillennio.com/zeta/

 stesso programma scritto in Java sta tutto in 980 byte.
Piů varia roba come la JVM e le classi standard di Java.
 
-- 
Paolo Vece - 
pv...@mclink.it

 far piantare meglio il suo gioco di un altro!
 
Il problema con i giochi di adesso è che non sono i programmi da 20k scritti 
in assembly sul 64 in tre mesi da un programmatore.
Ora ci sono i team di programmazione che lavorano con i team grafici e 
quelli sonori e c'è il marketing che spinge per mettere questo e levare 
quello.
Solo riuscire a far lavorare tre programmatori su una stessa cosa non è che 
sia così semplice: se poi questa cosa è un videogioco che ha dei tempi di 
consegna strettissimi ed un'infinità di variabili da tenere in 
considerazione e le evoluzioni che vengono in mente mentre si testa una 
certa parte non sai più dove vai a finire.
Tenuto conto anche del fatto che pare che ormai la parte sacrificabile del 
tempo di sviluppo sia quella del testing uno si spiega anche perché i giochi 
si piantano e dopo cinque giorni dalla loro uscita esce anche una patch.
Il gioco deve uscire ad una certa data, costi quel che costi. Poi, quando è 
uscito e ci si è rifatti di una parte dei soldi dell'investimento iniziale 
si lavora su basi più tranquille e si sfornano le patch per correggere gli 
errori che diversi tester (paganti) hanno trovato nel frattempo.
Dobbiamo renderci conto che se _Tomb Raider 3_ esce prima di _Half Life_ 
molto probabilmente vende più del secondo (i nomi dei giochi sono a caso).


Vabe' se da .java lo compilo in exe (stand alone) mi aggiunge circa 200k
fissi. Nulla a che vedere col VB.


 far piantare meglio il suo gioco di un altro!
Il problema č che nei programmi moderni di "opera" del programmatore ce
ne č relativamente poca. Soprattutto chi deve gestire il codice
principale (non l'engine grafico) non scrive praticamente nulla, ma fa
dei selvaggi copy&paste da librerie prefabbricate, oppure inserisce dei
moduletti di questo o quel compilatore (che č poi il motivo per cui un
programma C o C++ moderno puň essere compilato solo su questo o quel
compilatore). Ma non č assolutamente tenuto a debuggare o capire il
codice delle funzioni "prefabbricate" che inserisce. Risultato: un debug
impossibile (non sai neanche cosa c'č dentro il tuo programma...),
problemi vari di inter-operabilitŕ fra tutte le 10.000 librerie
utilizzate, che perň non hai il tempo di modificare a dovere, ecc ecc
ecc.
A questo aggiungi che i vari pezzi del programma sono fatti da persone
diverse, che non sempre si capiscono a meraviglia... cosě chi alla fine
prende un editor ascii e riscrive tutto prendendosela comoda, tipo
Carmack, diviene un genietto della tecnologia. Specie se poi č bravo di
per sč ;-)
-- 
==================================================
Cosě disse il monco aruspice
-----------------------------------------------------
      Cyrix Haldir            ICQ UIN Number
 
plc...@iol.it
            1886191
-----------------------------------------------------
 "Il mio nome non c'entra niente con le CPU Cyrix,
     e' un mio personaggio in AD&D ed esiste da prima"
====================================================
 Webmaster di Retroplay- ex TDM
 
http://www.retroplay.com/
**** RETROPLAY E' ARRIVATO! ****

 compilatore).
Allora, rispondo a tutti e due.
Flavio, ottimizzare il codice non significa debuggarlo. Un gioco può
uscire senza bug ma scattoso perchè non ottimizzato. 
Quello che dice cirillo è vero in parte (trovami tutte quelle librerie
per cui riesco a fare un gioco senza scrivere niente, poi ne
riparliamo). E' vero nel senso che il lavoro principale del
programmatore di oggi è quello di creare un progetto fatto bene. Non sta
tanto nell'inventare nuovi e miracolosi algoritmi, o nel far fare una
cosa in 1-2 decimi di secondo più veloce per ciclo.
O meglio, quello lo si fa ma solo dopo: i progetti diventano più
complessi, e c'è necessità di seguire determinati schemi di
programmazione... altrimenti, per dirle bene, va tutto a puttane, e
nessuno si raccapezza più tra codice scritoo, magarri benissimo e
superottimizzato, ma incasinato, non omogeneo e mal strutturato.
La vera sfida nella programmazione di un progetto di grandi dimensioni è
quella di renderlo il più modulare possibile, il più modificabile ed
estendibile possibile. Quella di creare una bella struttura.
Poi c'è sempre tempo per scendere nei bassi livelli del tuo codice ad
ottimizzare varie routine.
Forse il creare programmi così strutturati costringe a cedere un po'
dalla parte della velocità. Questo può essere vero in alcuni casi, ma
non lo è sempre. 
Io non credo che tutti copino delle routine fatte anni fa da altrio
senza capirci... se lo leggesse un programmatore professionista ti
ucciderebbe :). Il fatto è che non ha sempre senso rifare cose che sono
già state fatte da altri. Usare le numerose librerie standard del C++,
evoluazione di un decennio e frutto del lavoro di unìintera comunità di
programmatori non vuol dire essere dei copioni, vuol solo dire non
essere stupidi, dato che solo nell'1% dei casi ti capiterà di dire che
qualcuna di queste librerie non va bene e la riscrivo... solo per
applicazioni molto particolari... ma riscrivere una cosa per un gioco,
con tutti i problemi di bug e mica bug che ci saranno, allora molto
meglio usare librerie solide e standard.

 Nella prossima versione metteteci la modalita' trainer con l'undo eh?
chiama il darko :)



ci sono casi e casi
è inutile e fuorviante generalizzare

 ottimizzare varie routine.
Esatto, oggi programmare bene vuol dire riuscire a scrivere moduli 
indipendenti tra loro che vengono in qualche modo "incastrati" da una 
persona addetta a questo.
L'importante č che l'interfaccia per usare questi moduli sia omogenea e che 
il codice sia il piů manutenibile possibile.
Nessuno deve essere indispensabile: č impensabile avere un programma scritto 
in maniera super ottimizzata, sfruttando tutti i trucchi messi a 
disposizione dall'ambiente di sviluppo, ma dove non sia possibile mettere 
mano a meno di riscriverlo tutto. Se la persona che ha scritto quel codice 
se ne va, il capo progetto (o chi per lui) si ritrova con un qualcosa di 
veloce, ma inutilizzabile all'interno della "struttura gioco" ed č costretto 
a far riscrivere quel modulo.
E' necessario fare un lavoro iniziale di progettazione e definizione di 
standard che sacrifica qualcosa in termini di cicli di CPU (che tanto oggi 
vengono sprecati allegramente), ma semplifica lo sviluppo.
Devo essere in grado (paradossalmente) di spostare un programmatore da un 
modulo all'altro senza troppi traumi.


 tempo sprecato ?
Infatti oggi non ha più senso: se prima l'Amiga era _fermo_ come macchina e 
l'evoluzione era dovuta al software adesso non è più necessario a meno che 
uno non sia strettamente interessato alla cosa, ma in questo modo mi lego 
mani e piedi ad un certo dispositivo hardware, così succede come con l'Amiga 
o con la Voodoo2 dichiarata compatibile con la precedente, quando poi non 
era così vero.
Oggi il programmatore di applicazioni deve necessariamente lavorare ad _alto 
livello_ ignorando i dettagli implementativi di driver e librerie di 
sistema. 
E' necessario astrarsi e slegarsi da quello che c'è sotto, infatti le 
DirectX, le OpenGL, le varie API esistono per questo: garantire un 
sottostrato comune che consenta di migrare al nuovo hardware (ed al nuovo 
software di sistema) in maniera "indolore".
Che questo poi non sia vero è un altro discorso, ma *teoricamente* dovrebbe 
essere così.


meglio usare librerie solide e standard.
Ma un gioco non e' un'applicazione molto particolare?
Ciao
Tommasone

 meglio usare librerie solide e standard.
Vero, se fossero quelle librerie standard. Ma spesso non lo sono, anzi,
sono "prese a prestito" altrove e ritoccate qua e là...
-- 
==================================================
Così disse il monco aruspice


 stesso programma scritto in Java sta tutto in 980 byte.
Quello si chiama "Marketing MS"



Chi vuole generalizzare alzi la mano!


Io conosco un coglionello, ma generale proprio no
KRAPP
gray...@tin.it
Comprate tutti Don Giovanni: il meraviglioso in musica.
a.k.a.
Proconsole Marcus Krapp
ambasciatore Bajoriano su Deep Space Tango
Iscrivetevi a Federazione Unita, il GDR di Star Trek
STAR TREK: PBEM
http://gilda.it/startrek
Fed. Unita: Alliance
http://members.tripod.com/~Fresh_/Federazione_Unita1.html

 sono "prese a prestito" altrove e ritoccate qua e là...
Sai cosa ? mi sembra che tu abbia un po' troppe certezze sull'argomento.
Quali esperienze dirette hai per poter sostenere tutto ciò ?
Bada... sono d'accordo anche io sul fatto che molto codice sia
copiato... il fatto è che non trovo che ciò sia sbagliato come concetto,
anzi probabilmente è il modo giusto.


Sarà l'età ma.... ?????????????????????????????????????





programmazione moderne.
prob. è vero, resta il fatto che a me Trespasser gira uno schifo,
mentre Half-Life fà solo un po' di fatica, che è diverso cmq dal fare
schifo. E 'sto Trespasser non mi sembra poi l'ottava meraviglia.
                      babalot  
                     --> ;) <-- 
 


Si Toma č proprio l'etą.


schifo. E 'sto Trespasser non mi sembra poi l'ottava meraviglia.
Ma quale ottava meraviglia, a giudicare dalla demo fa proprio schifo, a
prescindere da quale computer lo faccia girare.
Ciao,
Francesco Lauricella


Visto che sono vecchio, allora spiega al matusa. :P


Io sono l'uomo cattivo più buono del mondo, quindi non ti spiego niente,
così impari a fare le pernacchie PPRRR


prescindere da quale computer lo faccia girare.
bo... l'idea però è interessante
--
-S+E
mon...@mindless.com
[ perché tanto odio? ]


Non si trattano così gli anziani.


Quasi quasi mi commuovi, sigh.



Commuoviti e spiega.


Mi sono dimenticato cosa ho scritto.



Idem


cum patatibus



gnoccas gnoccantis?


Nutella bona est.



Nihil ad superbam.


Nullum iam non capire, semper quattruom il latinum.



Non omnibus datum est habere nasum.


Deus ex machina, crasch fecit



Veni, vidi et crashai


Pirata, piratai et crackai
KRAPP
gray...@tin.it
"La corda tesa amò l'arco, e la tempesta la schiuma"
a.k.a.
Console Marcus Krapp
ambasciatore Bajoriano su Deep Space Tango
Iscrivetevi a Federazione Unita, il GDR di Star Trek



Quod est quod unum est pro laboribus tantis.


Quoque tu Toma, homo mortus uccidit



pulcherrimo. :)


Non ricordo cosa vuol dir, mi sembra "bellissimo". Che ti sei innamorato di
me? Spiacente, gią impegnato.
KRAPP  
gray...@tin.it
"La corda tesa amņ l'arco, e la tempesta la schiuma"
Federazione Unita, il GDR via mail di Star Trek
http://members.tripod.com/~Fresh_/Federazione_Unita1.html

 pulcherrimo. :)
Mamma corri guarda... ci sono i matti.


Ma quando mai?


Dove, caro?


line 3 too long?
KRAPP  
gray...@tin.it
"La corda tesa amò l'arco, e la tempesta la schiuma"



Boh.