View Full Version : [IMPORTANTISSIMO] Programmare videogames
Volevo sapere se c'è qualkuno che ha mai provato a creare videogiochi. Io ci vorrei provare ma non so da dove cominciare. Non è che mi potete indicare i programmi giusti? Ho sentito dire che 3DMAX è un buon programma. Grazie.
3D studio max è un buon programma...per fare grafica. non c'entra niente col programmare.
mi spiace dirtelo, ma forse hai le idee un po' confuse... :)
cosa vorresti fare esattamente? programmare "gioconi" tipo half life 3 o doom 4? oppure giochini da web? non è semplice dirti da dove cominciare. sicuramente devi saper programmare per iniziare, poi, se vuoi realizzare qualcosa ti serve un grafico (2D o 3D), qualcuno che faccia le musiche, e via discorrendo...
per prima cosa ti consiglierei di imparare un linguaggio di programmazione, scegliere la piattaforma di sviluppo e le tecnologie e poi provare a sviluppare qualche gioco moooolto semplice.
io ad esempio ho iniziato con le directX ed il c++ (che conoscevo già abbastanza bene), ma andrebbe bene anche flash o java o quello che preferisci.
wow... praticamente ho capito il 2% di quello che hai detto :D ... ho le idee confuse!!! :doh: . Allore, intendo programmare giochi 3D anche mooooolto facili. Sono andato su questo sito qui (http://www.gameprog.it/) che si occupa proprio di programmazione di videogames, ma nn c'ho capito niente nemmeno li. Ti faccio qualche esempio: se io voglio creare un personaggio in 3D, che programma devo usare? e se poi lo voglio far muovere, sparare, morire ecc... quale altro programma devo usare?
Non devi usare programmi...devi programmare ;)
Il mdoello lo puoi realizzare anche con 3DS Max, ma poi lo devi caricare ed animare all'interno del programma che realizzi te in un linguaggio di programmazione (Java, C, C+ o altri)...
Non devi usare programmi...devi programmare ;)
Il mdoello lo puoi realizzare anche con 3DS Max, ma poi lo devi caricare ed animare all'interno del programma che realizzi te in un linguaggio di programmazione (Java, C, C+ o altri)...
giusto! hai anticipato quello che volevo scrivere.
come ti dice cionci, devi programmare. impara prima un linguaggio, fai qualche programma e poi prova a creare un gioco. ti assicuro però che per programmare un gioco serve esperienza e bravura...
84seawolf
04-06-2006, 11:48
dipende cosa intendi per videogioco. Se pensi di creare un videogioco tipo Half life o F.e.a.r. levatelo dalla testa. Per fare colossi del genere si investono centinaia di migliaia di dollari e ci lavorano decine di team di sviluppatori.
Se sei decisamente meno ambizioso potresti utilizzare Dark Basic:
http://darkbasic.thegamecreators.com/
(che cmq se si sa usare BENE, permette di realizzare giochini anche 3d di discreto livello): vedi i demo fatti con sto programma.
Quindi per creare un modello uso un programma tipo 3DS Max, e per animarlo quale sarebbe il miglior programma da usare? Se poi mi date un link con un tutorial su come impartire istruzioni a un modello siete grandi :D!
Non serve un programma generico !!! Ma un programma scritto da te in un linguaggio di programmazione :muro:
Non serve un programma generico !!! Ma un programma scritto da te in un linguaggio di programmazione :muro:
dannazione, non sto riuscendo a capire!
mi scuso in anticipo se mi riterrai scortese, ma c e bisogno di chiarezza...ti consiglio di lasciar perdere, cancellare tutto quello che puoi aver immaginato fino ad adesso e incominciare a google.it ---> "linguaggio di programmazione"
se dopo qualche giorno che ti rendi conto di quanto l impresa fosse incredibilmente piu difficile della tua peggior stima, ma, nonostante cio, sei ancora intenzionato almeno a provarci, allora comincia a studiare un linguaggio di programmazione come il c++ per esempio (quasi tutti i giochi si fanno con quello)...detto cio, quando anche avai deciso di sobbarcarti tutto quel lavoro di apprendimento, fai tranquillamente che dimenticarti il 3d (ma anche il 2d) per come minimo un anno di studio...poi comincerai a studiare un po di grafica e un po di 2d, poi un po di nozioni di 3d e poi, forse, potrai arrivare (un annetto e mezzo o anche piu) a programmare un tetris in 3d (gia la vedo dura partendo dal tuo livello)
se poi sei uno che studia duro e la vuoi prendere come un hobby serio magari ti basta meno tempo, altrimenti mi spiace ma l iter è quello...non c e programma che ti salvi, non c e nessun miracolo...i programmi non si usano per fare i giochi...i giochi non si fanno da soli... i giochi difficilissimi da programmare...punto.
eheh si ti capisco, il guaio è che non ho per nulla esagerato :(
mi scuso in anticipo se mi riterrai scortese, ma c e bisogno di chiarezza...ti consiglio di lasciar perdere, cancellare tutto quello che puoi aver immaginato fino ad adesso e incominciare a google.it ---> "linguaggio di programmazione" [...]Quoto. Credo che dnarod sia stato tutt'altro che scortese ... anzi, estremamente chiaro e sopratutto realista. Essere realisti è fondamentale, specialmente nell'informatica.
Ho appena scaricato il compilatore C++ della borland e un tutorial per imparare i fondamenti di C++. Iniziamo :D
Ho appena scaricato il compilatore C++ della borland e un tutorial per imparare i fondamenti di C++. Iniziamo :D
Ok...ci risentiamo fra qualche anno ;)
facciamo cosi,ti racconto la mia storia: universitario di informatica, il mio sogno è sempre stato quello di riuscire un girno a sviluppare un fps come quake2. nonappena sono sbarcato nella mia universita, mi ci sono voluti solo 3 mesi capire quanto fossi fuori strada...ho passato 3 anni a piangermi addosso -[e qui faccio il cut della tiritera della triste storia della mia vita perche l ho gia fatta a fette a tutti]- ; fatto sta che da poco ho cominciato a studiare sul serio, ad occuparmi attivamente del mio "hobby preferito"...dopo 6 mesi (ma io non sono partito da 0 come te!) che mi sbatto a studiare varie materie utili per la programmazione di un gioco, in una settimana (fra pianificazione e realizzazione) ho tirato su un giochino del pong con java in opengl (senza suono, senza artifici, in rettangoli 2d colorati, brutto come la morte) che funziona quasi bene.
c e una morale in questa storiella: se uno non sa giocare a calcio e si improvvisa in una partitella fra amici, puo anche scapparci il puntone che ti fa raggiungere i 5 minuti di gloria perche fai un gol di culo... d altra parte se vuoi programmare il gioco piu semplice che ti viene in mente, ad esempio snake del cellulare, DEVI possedere una SERIE di NOZIONI senza le quali, molto semplicemente, potresti anche amputarti le gambe e fare un rito vudu, ma non programmerai MAI.
imho pero, questo non deve essere preso (come ho fatto io per molto tempo, sbagliando!) come una scusa per mollare li tutto e darsi al golf, quanto piuttosto come una cosa buona (l ho capito da poco): vuoi cucinare un bel giochino? la ricetta deve essere scrupolosamente seguita - gli ingredienti sono specificati minuziosamente - il risultato, a fronte dell esecuzione impeccabile, è garantito ... e meno male che ci sono tutte queste certezze!! non resta che cominciare a focalizzare l attenzione sulla matassa da dipanare, che è grossa, ma sicuramente ha una fine
dunque se hai letto fin qui significa che puoi certamente reggere n porzioni di testo noioso e ridondante...non ti resta che consumarle e imparare!
Ho appena scaricato il compilatore C++ della borland e un tutorial per imparare i fondamenti di C++. Iniziamo :D
Ti sconsiglio C++.
Perchè non usi visual basic o c# con directx? E' di gran lunga più semplice e veloce, e la documentazione è ottima.
Per il resto, "sviluppare videogiochi" è una pratica un pò ampia, perchè racchiude un gran numero di campi (grafica, intelligenza artificiale, ecc...).
Se non hai particolari esigenze, puoi realizzare qualcosa in 2D in un tempo relativamente breve.
Poi se vuoi complicare le cose non si finisce mai. Quando arriverai agli shader te ne accorgerai :)
Ho appena scaricato il compilatore C++ della borland e un tutorial per imparare i fondamenti di C++. Iniziamo :D forse c'è una via più rapida: parti da Java anziché da C++, e se proprio parti da C++ cancella quella porcheria di compilatore e scarica il MinGW; oppure il toolkit della Microsoft ;)
Ti sconsiglio C++.
Perchè non usi visual basic o c# con directx? E' di gran lunga più semplice e veloce, e la documentazione è ottima. quoto al 100%, non avevo letto!! C# con DirectX è probabilmente la via migliore :)
scaricati Visual Studio 2005 Express (è gratis) e parti con un enorme vantaggio rispetto al C++ con... (bleah...) compilatore Borland :Puke:
trallallero
05-06-2006, 09:52
quoto al 100%, non avevo letto!! C# con DirectX è probabilmente la via migliore :)
scaricati Visual Studio 2005 Express (è gratis) e parti con un enorme vantaggio rispetto al C++ con... (bleah...) compilatore Borland :Puke:
non vorrei confondere le idee a DenFox ma io il :Puke: lo metterei per il Visual Studio ...
il mio primo lavoro e' stato insegnare il :Puke: Visual C++ 6.0 (anno 1999) ad un corso regonale. Miiii che schifo!
Non mi ricordo molto, ormai lavoro su linux/unix ma quando creavi un nuovo progetto ti scriveva decine di files e di .h con decine di #include e direttive di ogni tipo :doh:
Il Borland Builder invece ti crea (creava) l'essenziale, il .h con la classe il .cpp con 3 righe.
Forse adesso e' cambiato ? il C# magari la MS e' riuscita a farlo funzionare ? :D
il fatto è che da qualcosa deve iniziare, ma dubito che questo qualcosa sia codare...il mio consiglio, tolto c++, che è "il linguaggio" con cui si sviluppano i giochi (speriamo ancora per poco perche nun me piace manco un po), dovresti cominciare da un libro, senza pensare a mettere le mani alla tastiera...se proprio il c++ non lo amiamo, ti consiglio java oppure c (due approcci completamente diversi alla programmazione), oppure personalmente ti potrei consigliare il .net e il suo favoloso (sempre imho) c#
ma da dove la prendi la prendi, prima anche solo di scrivere "hello world" ti consiglio di prendere un libro di 500 pagine e leggerlo da cima a fondo (al massimo guardarti gli esempi per cominciare a familiarizzare con la sintassi del linguaggio che hai scelto)...dopodiche cominci a farti le prime cacchiate e magari ti fai un giochino di carte in testuale...tieni presente sempre quello che ho detto (che, senza presunzione, ritengo oggettivamente vero): senza una solidissima teoria è inutile anche solo provarci...si perderebbe solo del tempo come ho fatto io e la demoralizzazione è sempre dietro l angolo!
Il C# per fare giochi?
Ma non scherziamo, per favore: è lento più di java.
Molto meglio il C++, più potente, versatile, veloce, portabile, è ha una mole di programmatori e librerie superiori a qualsiasi altro linguaggio.
Solo Java si avvicina al C++ come successo, ma rimane inferiore in molti punti: se è utilizzato quanto il C++ è principalmente a causa della portabilità.
Personalmente mi sto facendo un gioco 2d in C++ e SDL dopo pochi mesi di studio.
E' anche vero che programmare lo sapevo già.
Personalmente, ho studiato Python, Java, C#, e C++ come linguaggi appicativi, e nessuno mi ha soddisfatto tranne quest'ultimo.
Il C++ è davvero il linguaggio più potente in circolazione.
A costo di una maggiore difficoltà iniziale, dà al programmatore possibilità pressochè infinite.
A lui che deve iniziare consiglio prima di imparare le basi della programmazione con Python e poi passare direttamente al C++.
Cosa fai in c++ che in c# non riusciresti a fare? La cosa mi incuriosisce.
Se fossi un pochino dentro al mondo videoludico (basta leggersi un pò le pubblicazioni della industry), ti accorgeresti che c++ non lo vuole usare più nessuno perchè è troppo complesso.
Per un principiante poi, consigliare di partire da c++ mi sembra quasi un comportamento immorale.
Il C# per fare giochi?
Ma non scherziamo, per favore: è lento più di java. vogliamo i numeri
Molto meglio il C++, più potente, se devi fare un device driver serve il C o il C++, ma se devi fare un videogioco basta il C#
versatile, esempio pratico?
veloce, vogliamo i numeri, ah e devono essere riproducibili.
portabile, ROTFL!! :rotfl:
è ha una mole di programmatori e librerie superiori a qualsiasi altro linguaggio. non è vero, il linguaggio più all'avanguardia che io conosca è Java (è affiancato da una comunità di programmatori e da una set di modernissimi strumenti e librerie che sono tra i più vasti che io conosca)
Solo Java si avvicina al C++ come successo, nel senso che si avvicina da davanti
ma rimane inferiore in molti punti: se è utilizzato quanto il C++ è principalmente a causa della portabilità. ah dannazione, su Diamond Crush siamo stati costretti ad usare Java solo perché il C++ non era portabile, e ora come facciamo?
Personalmente mi sto facendo un gioco 2d in C++ e SDL dopo pochi mesi di studio. personalmente io e altre 10 persone ci stiamo facendo un gioco in Java in 2D senza aver studiato un bel cavolo (e sono anche sicuro che il nostro è molto meglio del tuo :Prrr: )
E' anche vero che programmare lo sapevo già.
Personalmente, ho studiato Python, Java, C#, e C++ come linguaggi appicativi, e nessuno mi ha soddisfatto tranne quest'ultimo. probabilmente non sei in grado di scegliere lo strumento migliore per qualcosa.
Il C++ è davvero il linguaggio più potente in circolazione. non ne dubito, ma certe cose non servono veramente mai... a che ti serve l'aritmetica dei puntatori? a che ti servono gli includes quando puoi sostituirli con un sistema di packages? a che ti servono le macro se non ad ingannare sulla sintassi del codice? a che ti serve delete? e potrei continuare per molto...
A costo di una maggiore difficoltà iniziale, dà al programmatore possibilità pressochè infinite. stesso discorso di prima: tutte cose che puoi eliminare a meno che non hai la necessità del controllo totale, e di certo non è il caso di un videogioco (forse ti do una brutta notizia ma probabilmente in futuro anche i device drivers verranno scritti in linguaggi di livello più alto: Microsoft si è avviata verso l'approccio Object Oriented nel campo)
Da quello che ho visto io sicuramente partire da zero a studiare il c++ è un po' ardua, ma non impossibile (dipende dalla persona). Io ho avuto solo delle piccole basi di pascal e poi sono passato al c++ (e dopo java, ecc.) ed ho notato che una volta che sai il c++ gli altri linguaggi li impari relativamente velocemente e facilmente.
Per quanto riguarda il C#, potrei sbagliarmi, ma mi sembra piu una porcheria "inventata" dalla microsoft che altro...
Se fossi un pochino dentro al mondo videoludico (basta leggersi un pò le pubblicazioni della industry), ti accorgeresti che c++ non lo vuole usare più nessuno perchè è troppo complesso. quoto
trallallero
05-06-2006, 12:22
Cosa fai in c++ che in c# non riusciresti a fare? La cosa mi incuriosisce.
Se fossi un pochino dentro al mondo videoludico (basta leggersi un pò le pubblicazioni della industry), ti accorgeresti che c++ non lo vuole usare più nessuno perchè è troppo complesso.
Per un principiante poi, consigliare di partire da c++ mi sembra quasi un comportamento immorale.
tanto ormai siamo OT ...
il c++ non lo vuole usare più nessuno ????
io rimango senza lavoro cosi' !!! :muro:
per me rimane il migliore linguaggio (vengo dal C)
Il C# cosa c'ha di != dal C++ ?
io purtroppo non posso navigare perche' ho internet aziendale con qualche sito aperto (hwupgrade, gmail, trenitalia ...)
Per quanto riguarda il C#, potrei sbagliarmi, ma mi sembra piu una porcheria "inventata" dalla microsoft che altro... potrà anche essere quello il suo feeling, ma del feeling poco importa, stiamo facendo informatica non religione, e contano i risultati. C# è un linguaggio moderno e produttivo, e contiene tutta la potenza della piattaforma .NET
quello che mi incuriosisce di piu è la parte del "c# è piu lento di java"...non vedo come potrebbe...ad ogni modo non gli ho certo consigliato di programmare hl episode 2 in c#, ho semplicemente espresso una preferenza (di stile e di filosofia); infatti il consiglio rimane su java o su c, perche cosi puo rendersi conto dello spartiacque che c e nella programmazione (imperativa/OO)...volendo fare i pignoli poi, sul discorso della lentezza/potenza di un linguaggio si puo sindacare solo su progetti estremamente complessi...un quake in java lo vedo difficile (non impossibile pero), ma qui stiamo parlando di iniziare, e iniziare con c++ puo essere assai ostico e assolutamente non necessario...prendiamo come esempio diamonds: scaricati la demo e prova un po... java + porting opengl + openal ... non mi sembra una tragedia come lentezza, anzi; non ho molta esperienza ma sto cercando di farmela e imho la questione principale del game programming (come del developement in generale) non è il "con cosa" ma il "come" unito al "campo di applicazione".
sulla potenzialita di c++ nessuno ha obiezioni di sorta, quello che si obietta è che, a determinati livelli, si puo usare anche altro, ottenere il medesimo risultato e ottenerlo in maniera piu semplice ed elegante; per chi comincia, semplicita ed eleganza offrono un framework imho essenziale per l apprendimento (o che almeno lo facilita di molto), ma con cio nulla vieta che dopo aver imparato un linguaggio "semplice" (passatemelo) non si possa imparare anche altro...sicuramente pero partire dal c++ è rischioso, perche o uno è mandrake o per metabolizzare gli servono anni, oppure molla li come feci io (e lo dico senza sentirmi uno stupido)
il consiglio di python è altrettanto buono, ma calcola che lui è orientato ai giochi e, anche se java non ti piace, è oggettivamente piu utilizzato di python (al momento) per i games...
il mio consiglio è pero sempre lo stesso: "la sintassi spaventa" qualunque essa sia...se una casa si costruisce dalle fondamenta, bisogna partire dal basso, lo studio della "programmazione" è da preferire allo studio di un linguaggio, almeno all inizio...per capire come gira la quaglia basta un mesetto (variabili, hello world, if else for eccetera), poi si sceglie un linguaggio che fitti il suo look&feel e poi parte a mettere su mattone dopo mattone
ps sry se ho annoiato qualcuno.
tanto ormai siamo OT ...
il c++ non lo vuole usare più nessuno ????
io rimango senza lavoro cosi' !!! :muro: tranquillo, la migrazione è facilissima ;)
per me rimane il migliore linguaggio (vengo dal C) sotto certi punti di vista non lo è più non da anni, da DECENNI
Il C# cosa c'ha di != dal C++ ? più semplice, e nella maggioranza dei casi ti da gli stessi risultati in meno tempo
trallallero
05-06-2006, 12:35
... a che ti serve l'aritmetica dei puntatori?
... a che ti serve delete?
ma te l'immagini videogiochi pesanti, "costosi" come FIFA, HalfLife senza l'aritmetica dei puntatori e senza la delete ??? :confused:
ma te l'immagini videogiochi pesanti, "costosi" come FIFA, HalfLife senza l'aritmetica dei puntatori e senza la delete ??? :confused: certo...
nel senso che si avvicina da davanti
lol!!
cmq non volevo sollevare un vespaio, e ora sono costretto ad argomentare il c# (ora spero di non dire stupidaggini perche non sono molto esperto, lo chiarisco in principio):
-è portabile
-è interpretato ma puo anche essere compilato (e qui il discorso del "Piu lento di java" mostra i suoi limiti)
-sintassi in tutto e per tutto assimilabile a java + c++
-il .net è semplicemente uno degli strumenti piu potenti che abbia mai trovato sulla mia strada; perche? perche si possono utilizzare librerie scritte in qualsiasi linguaggio .net (tipo importo una classe vb in c# e....funziona, punto.), quindi hai potenzialita piu infinite delle infinite (sempre imho)
-il c# vuole "correggere" gli "errori" di java, il fatto di essere interpretato...non che non lo sia (quindi anche lui, come tutti i linguaggi .net, portabile), ma se vuoi lo compili per l architettura che ti interessa ed eccoti servita la velocita esecutiva
-non è la sua filosofia, ma lo puoi sporcare quasi a livello di c (quindi hai tutta la gestione a basso livello che ti pare)
-sebbene personalmente non sia d accordo su questo, è innegabile pero che visual studio roxxi parecchio (come ide)
come vedi, il mio consiglio non era proprio buttato li a caso; quando anche ms stesse sulle balle a un mucchio di gente, bisogna dare a cesare quel che è di cesare, il tutto rigorosamente imho, ed è un imho di un principiante che magari non ne capisce nulla, oppure che quel poco che pensa di aver capito è sbagliato, pero per il momento sono abbastanza convinto di cio che dico, quindi lo dico :)
trallallero
05-06-2006, 12:41
... sotto certi punti di vista non lo è più non da anni, da DECENNI
più semplice, e nella maggioranza dei casi ti da gli stessi risultati in meno tempo
uhm ... ho fatto un colloquio 1 settimana fa con una societa' che fa programmi per trading per banche.
Perche' usano il C++ ??? :mbe:
parole loro: "cerchiamo analista/prog C++ MS per programmi prestanti ... abbiamo anche programmatori Java ma solo per applicazioni web dove non serve la velocita' ..."
l
trallallero
05-06-2006, 12:44
Se usi la programmazione ad oggetti i puntatori puoi anche ficcarteli nel :ciapet:
allora li avverti tu quelli della EA SPORTS perche' mi sa che non se ne sono accorti :rolleyes:
uhm ... ho fatto un colloquio 1 settimana fa con una societa' che fa programmi per trading per banche.
Perche' usano il C++ ??? :mbe: chiedi a fek, sarà molto eloquente
parole loro: "cerchiamo analista/prog C++ MS per programmi prestanti ... abbiamo anche programmatori Java ma solo per applicazioni web dove non serve la velocita' ..." non smetterò mai di dirlo, ma le vere ottimizzazioni che si fanno nei programmi sono quelle della riduzione degli ordini asintotici di complessità degli algoritmi; qualcuno evidentemente non lo sa.
allora li avverti tu quelli della EA SPORTS perche' mi sa che non se ne sono accorti :rolleyes: avoja, se ne saranno già resi conto
trallallero
05-06-2006, 12:53
non smetterò mai di dirlo, ma le vere ottimizzazioni che si fanno nei programmi sono quelle della riduzione degli ordini asintotici di complessità degli algoritmi; qualcuno evidentemente non lo sa.
Scusa se insisto ma allora puoi spiegarmi perche' la Valve, EA Sports, Eidos e compagnia bella fanno i videogiochi in C/C++ ? :confused:
Scusa se insisto ma allora puoi spiegarmi perche' la Valve, EA Sports, Eidos e compagnia bella fanno i videogiochi in C/C++ ? :confused: e tu chiedi a fek, che ci sta dentro fino al collo :D
ma tanto ti assicuro che in breve la situazione cambierà
EDIT: e non parlarmi della Eidos che dal punto di vista tecnico i suoi videogiochi fanno letteralmente c@g@r3... anni fa ho provato quello di Chicken Run, si bloccava su qualsiasi computer sul quale lo facessi andare (ne ho provati 5), e non parliamo di Tomb Raider: non so come sia l'ultimo, ma il fatto che le prime versioni non girassero sui kernel NT era una cosa semplicemente ridicola
EDIT2: be' oddio, quando dico "pime versioni" intendo fino alla 5... :rolleyes:
trallallero
05-06-2006, 13:12
e tu chiedi a fek, che ci sta dentro fino al collo :D
ma tanto ti assicuro che in breve la situazione cambierà
fek ? :confused:
sono nuovo ma mi sembra di aver letto qualche suo post.
FEK !?! se ci sei batti un click :help: :)
in attesa ...
secondo me (e non solo), il non poter accedere direttamente alla memoria, allocarla, deallocarla, spostarla, farci insomma tutto quello che vuoi con istruzioni velocissime come quelle del C, riduce le prestazioni. Devi aspettare che ci pensi il sistema a chiudere cio' che hai aperto e questo non e' bello quando hai aperto taaaante porte ;)
Per esempio: Il mio collega ha fatto una "chattina" in java con tanto di emoticons (su Unix). Fatta molto bene, la usiamo per chattare tra di noi. C'e' un problema pero': quando apri la finestrella degli emoticons il programma crea una mandria di threads (penso uno per ogni emoticon) che rallenta di brutto non il programma .... tutta la "macchina" !!! e non c'e' verso di chiuderli !
Il bello pero' e' che se prendi il codice e lo porti a casa ti funziona anche su MS :fagiano:
scusate se insisto ma credo che si stia continuando a travisare il fulcro della discussione; non si tratta del c++ < || > di qualcos altro, quanto piuttosto di:
-ho un esigenza
-utilizzo il miglior strumento per quell esigenza
-l esigenza è imparare a programmare giochi, quindi si parte da giochini
-il miglior strumento NON è c++
trallallero
05-06-2006, 13:14
EDIT: e non parlarmi della Eidos che dal punto di vista tecnico i suoi videogiochi fanno letteralmente c@g@r3...
e' che non sono un gran videogiocatore ... fino a qualche anno fa giocavo a Pomp Raider e simili poi il lavoro, la figlia ... adesso solo a Fifa 2005 1/2 prima di addormentarmi.
Megli della TV ;) odio la TV :muro:
trallallero
05-06-2006, 13:24
scusate se insisto ma credo che si stia continuando a travisare il fulcro della discussione; non si tratta del c++ < || > di qualcos altro, quanto piuttosto di:
-ho un esigenza
-utilizzo il miglior strumento per quell esigenza
-l esigenza è imparare a programmare giochi, quindi si parte da giochini
-il miglior strumento NON è c++
verissimo :)
stiamo andando troppo OT.
per i giochini son d'accordo che il java - non conosco il Db .... ehm il C# (questa e' sottile :D ) - sia il migliore per la portabilita' e la manualistica online ;)
sul sito sun.java.com ci posso andare :stordita:
fek ? :confused:
sono nuovo ma mi sembra di aver letto qualche suo post. eh be', ne ha più di 7000... :D
in attesa ...
secondo me (e non solo), il non poter accedere direttamente alla memoria, nell'esecuzione finale il programma accede direttissimamente, un solo MOV, come nel C++
allocarla, in Java allochi tutto quello che ti pare... :confused:
deallocarla, in Java gli oggetti si disallocano da soli non appena diventano inutili...
spostarla, a che ti serve? in C++ tu riesci a controllare il modo in cui sposti i blocchi di memoria? senza usare le API del sistema operativo intendo (vabbè che tanto non ci riesci manco con quelle)
farci insomma tutto quello che vuoi con istruzioni velocissime come quelle del C, riduce le prestazioni. non parlarmi delle prestazioni finché non porti i numeri ;)
Devi aspettare che ci pensi il sistema a chiudere cio' che hai aperto e questo non e' bello quando hai aperto taaaante porte ;) e anche se rimangono aperte che ti fanno? tanto mica ricevi, e anche se ricevessi non c'è alcuna possibilità di fare buffer overflow/overrun... ;) non è magnifico?? :D
comunque stai tranquillo che non ti rimane aperto un bel niente
Per esempio: Il mio collega ha fatto una "chattina" in java con tanto di emoticons (su Unix). Fatta molto bene, la usiamo per chattare tra di noi. C'e' un problema pero': quando apri la finestrella degli emoticons il programma crea una mandria di threads (penso uno per ogni emoticon) che rallenta di brutto non il programma .... tutta la "macchina" !!! e non c'e' verso di chiuderli ! è una chat o un worm...? a che gli serve un thread per emoticon...?
è una chat o un worm...? a che gli serve un thread per emoticon...?
infatti...questo rientra nel "come" piu che nel "cosa"...pensa al "come", ti basta andare a sfogliare il progetto diamonds e provare a giocare alla demo (ancora lontana dalla release completa)...quello è un ottimo esempio di come il "come" (modalita di programmazione) possa essere molto piu pesante del "cosa" (linguaggio utilizzato).
trallallero
05-06-2006, 13:47
infatti...questo rientra nel "come" piu che nel "cosa"...pensa al "come", ti basta andare a sfogliare il progetto diamonds e provare a giocare alla demo (ancora lontana dalla release completa)...quello è un ottimo esempio di come il "come" (modalita di programmazione) possa essere molto piu pesante del "cosa" (linguaggio utilizzato).
ok, ma non si puo' sostenere che la scelta del linguaggio non sia importante, soprattutto se ci sono di mezzo le prestazioni. Allora facciamo Quake in VB e togliamo dalle balle 'sto C che e' tanto difficile ;)
in Java gli oggetti si disallocano da soli non appena diventano inutili...
e chi lo decide che sono inutili ? il sistema ? che fa entra nella logica del programma e distrugge la memoria allocata a suo piacimento ? se permetti preferisco essere io a scelgiere se distruggere o no quello che ho creato.
Che poi distrugga tutto alla fine del programma mi sta bene ...
a che ti serve? in C++ tu riesci a controllare il modo in cui sposti i blocchi di memoria? senza usare le API del sistema operativo intendo (vabbè che tanto non ci riesci manco con quelle)
memccpy, memchr, memcmp, memcpy, memmove, memset .... senza queste non avresti le DirectX (C/C++).
No DirectX ? no game ;)
Dirai OpenGL .... ops ... C/C++ ;)
trallallero
05-06-2006, 14:11
è una chat o un worm...? a che gli serve un thread per emoticon...?
ah non lo so :confused: non sono un javista.
Ma visto che tu sei esperto java magari potresti dare un consiglio ;) :help:
l'emoticon e' un oggetto ImageIcon che viene inserito in un JTextPane. Quando poi apri il popup (JMenu) per scegliere l'emoticon e vengono visualizzati tutti gli emo .... brrr ... la macchina rallenta di brutto (CPU 98%), i 3ds (vengono generati automaticamente) aumentano a dismisura e l'unico modo per distruggere i 3ds e' uscire e rientrare.
in caso grazie ;)
memccpy, memchr, memcmp, memcpy, memmove, memset .... senza queste non avresti le DirectX (C/C++).
No DirectX ? no game ;)
Dirai OpenGL .... ops ... C/C++ ;)
ma lol, le directx e le opengl esistono apposta per non doversi rompere il culo a quei livelli!
MSciglio
05-06-2006, 14:48
Se fossi un pochino dentro al mondo videoludico (basta leggersi un pò le pubblicazioni della industry), ti accorgeresti che c++ non lo vuole usare più nessuno perchè è troppo complesso.
Questo dato non mi risulta. Sicuramente c'e' la tendenza a cercare di utilizzare quando possibile C# per i tool ma al momento attuale e' assolutamente fuori discussione un gioco interamente in C#. La situazione potrebbe cambiare nei prossimi anni ma attualmente il C++ e' la sola e unica possibilita' per fare un gioco di un certo livello.
trallallero, scusa ma l evidenza è che ad esempio opengl non c entri molto con c/c++ ....tant e vero che se guardi i ports che ci sono per decine di linguaggi (java compreso, il primo che mi viene in mente è lwjgl che usano in diamonds, ma ce ne sono altri pure per java) te ne rendi conto...
il fatto è che continui non ascoltare cio che ho da dire:
ok, ma non si puo' sostenere che la scelta del linguaggio non sia importante, soprattutto se ci sono di mezzo le prestazioni. Allora facciamo Quake in VB e togliamo dalle balle 'sto C che e' tanto difficile
ritengo, al contrario, che la scelta del linguaggio è assai importante e che, quotando me stesso, il c++ sia la scelta meno indicata per giochini piccoli, che sono il target per qualcuno che deve imparare e non sa nemmeno cosa sia un linguaggio di programmazione...tu insisti nel voler pubblicizzare il c++ come unica soluzione quando la realta dice che non è cosi...la realta è che se parliamo di giochi commerciali allora allo stato attuale dell evoluzione dei linguaggi il c++ rispecchia sostanzialmente (ma non al 100%) cio che sostieni tu, mentre se parliamo di game developement in generale la realta non è quella. ci tengo a precisare che non sono in disaccordo con te: nei giochi "importanti" per il momento c++ is the way; ma le cose cambiano, i linguaggi cambiano, e chi lo sa cosa accadra domani; inoltre nei giochi "meno importanti" gia si puo dire che (esempio) java faccia da padrone: i giochini per i cellulari insegnano; si potrebbe inoltre aprire una parentesi gigantesca sulla "necessita" dei giochi "importanti", quando, nel 2006, c e invece un inversione di tendenza che vuole che i gioconi non implementino novita originali e che, data la stagnazione del settore, ci sia un ritorno al godimento per i "giochini" che magari non hanno un peso commerciale allucinante ma che sono maledettamente divertenti ed immediati (2d su tutti)
mi chiedo: concordiamo o no su questo fatto? cioe che se quel ragazzo deve cominciare da c++, directx (direct3d, directsound, ecc...), 3d math, game design, algoritmi ai, eccetera, non ne viene piu fuori? visto che per sua ammissione non ha mai nemmeno avuto contatti con la programmazione (tanto da confondere un programma con la programmazione), non credi che l approccio piu "soft" sia quello di eliminare, almeno momentaneamente, la gestione di basso livello e concentrarsi sull imparare a programmare? e cosa meglio di java glielo puo insegnare? dopodiche si puo sporcare le mani con tutti i c/c++ che vuole, ma almeno ha qualche base piu semplice da cui partire...inoltre ti ricordo che il java non è poi cosi "semplice", ancora, ti invito a provare diamonds per farti un idea...
ok, ma non si puo' sostenere che la scelta del linguaggio non sia importante, soprattutto se ci sono di mezzo le prestazioni. Allora facciamo Quake in VB e togliamo dalle balle 'sto C che e' tanto difficile ;) dipende, parli di VB 6 o VB.NET?
e chi lo decide che sono inutili ? il sistema ? lo sono per forza di cose: se non hai più riferimenti ad essi è impossibile che tu possa usarli (si chiama garbage collection)
che fa entra nella logica del programma e distrugge la memoria allocata a suo piacimento ? tanto non la potresti più usare...
se permetti preferisco essere io a scelgiere se distruggere o no quello che ho creato. puoi farlo anche con il garbage collector:
lastReference = null;
con questo pseudo-esempio in Java sei tu che decidi di distruggere un certo oggetto; se non eseguissi quella istruzione l'oggetto invece rimarrebbe in vita
memccpy, memchr, memcmp, memcpy, memmove, memset .... così sposti il contenuto del blocco, non il blocco; e memcmp e memset non c'entrano
senza queste non avresti le DirectX (C/C++). perché tiri in ballo proprio quelle adesso...? :mbe:
Dirai OpenGL .... ops ... C/C++ ;) azz, che ironia pungente, sei stato fulminante mi hai proprio distrutto :cry:
trallallero
05-06-2006, 16:03
trallallero, scusa ma l evidenza è che ad esempio opengl non c entri molto con c/c++ ....tant e vero che se guardi i ports che ci sono per decine di linguaggi (java compreso, il primo che mi viene in mente è lwjgl che usano in diamonds, ma ce ne sono altri pure per java) te ne rendi conto...
il fatto è che continui non ascoltare cio che ho da dire:
ritengo, al contrario, che la scelta del linguaggio è assai importante e che, quotando me stesso, il c++ sia la scelta meno indicata per giochini piccoli, che sono il target per qualcuno che deve imparare e non sa nemmeno cosa sia un linguaggio di programmazione...tu insisti nel voler pubblicizzare il c++ come unica soluzione quando la realta dice che non è cosi...la realta è che se parliamo di giochi commerciali allora allo stato attuale dell evoluzione dei linguaggi il c++ rispecchia sostanzialmente (ma non al 100%) cio che sostieni tu, mentre se parliamo di game developement in generale la realta non è quella. ci tengo a precisare che non sono in disaccordo con te: nei giochi "importanti" per il momento c++ is the way; ma le cose cambiano, i linguaggi cambiano, e chi lo sa cosa accadra domani; inoltre nei giochi "meno importanti" gia si puo dire che (esempio) java faccia da padrone: i giochini per i cellulari insegnano; si potrebbe inoltre aprire una parentesi gigantesca sulla "necessita" dei giochi "importanti", quando, nel 2006, c e invece un inversione di tendenza che vuole che i gioconi non implementino novita originali e che, data la stagnazione del settore, ci sia un ritorno al godimento per i "giochini" che magari non hanno un peso commerciale allucinante ma che sono maledettamente divertenti ed immediati (2d su tutti)
mi chiedo: concordiamo o no su questo fatto? cioe che se quel ragazzo deve cominciare da c++, directx (direct3d, directsound, ecc...), 3d math, game design, algoritmi ai, eccetera, non ne viene piu fuori? visto che per sua ammissione non ha mai nemmeno avuto contatti con la programmazione (tanto da confondere un programma con la programmazione), non credi che l approccio piu "soft" sia quello di eliminare, almeno momentaneamente, la gestione di basso livello e concentrarsi sull imparare a programmare? e cosa meglio di java glielo puo insegnare? dopodiche si puo sporcare le mani con tutti i c/c++ che vuole, ma almeno ha qualche base piu semplice da cui partire...inoltre ti ricordo che il java non è poi cosi "semplice", ancora, ti invito a provare diamonds per farti un idea...
si, scusa ma si era aperta una discussione a 2 strade, una sulla via consigliabile al ragazzo che deve iniziare, e li concordo appieno con te, metterlo sui binari della programmazione a basso livello significherebbe farlo impazzire o desistere all'instante, l'altra sul fatto che si possa fare qualsiasi videogioco in java, e li non sono affatto d'accordo.
E , preciso, non sto sostenendo che e' e sempre sara' cosi' ma per adesso il C++ e' insostituibile.
E penso che sara' cosi' fino a quando i processori saranno fatti in questo modo, finche' le periferiche verranno gestite in questo modo. Quando faranno i computers al plasma, alla molecola umana o all'uranio arricchito allora potremo vedere un cambiamento.
Ma visto che tu sei esperto java [...] ma quale esperto ed esperto!! :D
quel poco di Java che so lo so grazie a DC, per il resto il 95% della mia esperienza è nel C e C++: attualmente mi dedico alla programmazione di sistema, sia in user-land che in kernel-land
E , preciso, non sto sostenendo che e' e sempre sara' cosi' ma per adesso il C++ e' insostituibile. lo è, ma non per i videogiochi; nel settore videoludico, come ha spiegato fek in qualche thread passato su questo forum, si tende all'alto livello; Diamond Crush è un ottimo esempio perché è un software estremamente all'avanguardia: logica in Java e accesso a OpenGL tramite librerie third party. come vedi il C è effettivamente insostituibile, ma solo fino allo strato di OpenGL (che noi programmatori del videogioco non abbiamo minimamente toccato): da quello in su si passa a Java, noi del team abbiamo lavorato esclusivamente in Java. più di così è inutile che mi ripeto
E penso che sara' cosi' fino a quando i processori saranno fatti in questo modo, il nostro videogioco non dipende strettamente dal processore, anzi l'abbiamo fatto portabile apposta: fosse stato in C++ dovevamo farne due versioni (almeno)
finche' le periferiche verranno gestite in questo modo. ma che periferiche devi gestire in un videogioco? ci ha già pensato qualcun altro, tu devi solo scrivere la logica secondo la quale le gestisci
Quando faranno i computers al plasma, alla molecola umana o all'uranio arricchito allora potremo vedere un cambiamento. non è così che cambieranno le cose: lo strato di assembly esisterà sempre (assembly Java? nell'anno 4000 forse...), ma tende ad assottigliarsi sempre di più; perché l'essere umano in assembly sbaglia, in Java no!
Mah, mi semrba che la discussione sia diventata piu una "battaglia ideologica" che altro... :p
Java usa solamente gli oggetti, per cui non so quanto questo sia adatto (o istruttivo) per uno che vuole cominciare a programmare (tra l'altro non so neanche quanto sarebbe semplice...). Onestamente non saprei quale linguaggio consigliare per iniziare, ce ne sono tanti, certo è che se uno si impara il C poi non avrà grossi problemi a passare a java/c++/ecc. avendo acquisito un certo metodo...
Poi secondo me ogni linguaggio deve essere usato per quello in cui si comporta meglio: java lo vedo orientato, attualmente, piu al web e al settore mobile, mentre il c++ andrebbe usato per compiti un po' piu "pesanti". Penso di non dire cavolate se ritengo che, ad esempio, un motore grafico tipo quello di doom3 sia semplicemente impensabile (per non dire ridicolo) da sviluppare in java (o in c#, ma su questo non ne sono sicuro :p )....
Mah, mi semrba che la discussione sia diventata piu una "battaglia ideologica" che altro... :p solo per alcuni
Java usa solamente gli oggetti, per cui non so quanto questo sia adatto (o istruttivo) per uno che vuole cominciare a programmare (tra l'altro non so neanche quanto sarebbe semplice...). Onestamente non saprei quale linguaggio consigliare per iniziare, ce ne sono tanti, certo è che se uno si impara il C poi non avrà grossi problemi a passare a java/c++/ecc. avendo acquisito un certo metodo... O-M-G prega solo che non legga fek :D :D :D
Penso di non dire cavolate se ritengo che, ad esempio, un motore grafico tipo quello di doom3 sia semplicemente impensabile (per non dire ridicolo) da sviluppare in java (o in c#, ma su questo non ne sono sicuro :p ).... idem come sopra...
Onestamente non saprei quale linguaggio consigliare per iniziare, ce ne sono tanti, certo è che se uno si impara il C poi non avrà grossi problemi a passare a java/c++/ecc. avendo acquisito un certo metodo...
e si, bisogna scegliere di che morte morire...partire dagli oggetti o dai puntatori? che bel dilemma...alla fine sono difficolta simili anche se all atto pratico sono delle diversita di linguaggio non indifferenti...concordo anche sulla programmazione di un motore grafico in java o c#, al momento non c e nulla del genere che sia al livello di doomIII tanto per dire...pero chissa perche (forse per la mia poca esperienza, ho fiducia nel fatto che il "come" unito al cambio di trend (moda di nuovi linguaggi come java) si possa entro poco tempo arrivare a un traguardo simile...in fondo milioni di anni fa si lavorava solo a bassissimo livello, poi si è passati ad assembly, poi a c, poi a c++...magari si passera a java e via dicendo, cioe "l alto livello" diventera fruibile dai piu poiche l evoluzione dei linguaggi e delle architetture lo permettera (almeno mi sembra logico pensarlo)...
dark lord
05-06-2006, 17:23
per eempio anchio ho incominciato da java...non tanto per sviluppare qualcosa di interessnte con esso, ma per iniziare a capire come funziona la programmazione e imparare i concetti base come metodi, variabili e tuttto il resto...adesso mi sono soffermato sulla programmazione web e ora sto scaricando visual studio!
wingman87
05-06-2006, 19:11
Mi sa che gli state confondendo le idee.. Io x andare controcorrente gli consiglio di provare entrambi i linguaggi (c++ e java), il primo che ti stufa lo scarti. Tanto il difficile è cominciare, poi se ti appassioni il resto viene da sè (tempo permettendo).
O-M-G prega solo che non legga fek :D :D :D
idem come sopra...
sinceramente mi interessa poco se fek (ma poi chi è?) legge o no :p e soprattutto di quello che potrebbe pensare/dire... alla fine siamo qui per imparare e se ho detto cazzate sarebbe opportuno che mi spiegaste perchè, senza tanti giri di parole ;) ;) ;)
tomminno
05-06-2006, 21:13
dipende, parli di VB 6 o VB.NET?
Rimane sempre la sintassi barbara del linguaggio e il modo poco professionale di fare le cose.
Con C# in circolazione VB non ha proprio più senso di esistere.
puoi farlo anche con il garbage collector:
lastReference = null;
con questo pseudo-esempio in Java sei tu che decidi di distruggere un certo oggetto; se non eseguissi quella istruzione l'oggetto invece rimarrebbe in vita
Sei sicuro che la memoria che hai allocato venga rilasciata nel momento che il program counter ha superato quell'istruzione?
Oppure viene deallocata quando il GC si attiva per i cavoli suoi?
Esistono anche librerie per la GC in C/C++ ma sono un controsenso.
Rimane sempre la sintassi barbara del linguaggio
perchè?
e il modo poco professionale di fare le cose.
poco professionale? con che criteri la stabilisci la professionalità?
Con C# in circolazione VB non ha proprio più senso di esistere.
questa è già un'altra storia.
'iao
trallallero
06-06-2006, 07:52
Io ho iniziato col C. Sara' che ho avuto un ottimo insegnante che prima di passare al C ha spiegato in maniera dettagliata come e' fatto e come funziona un PC. Non ho avuto nessun problema a capire i puntatori ... c'e' la RAM con indirizzi di memoria ... il puntatore e' una variabile che contiene un indirizzo, punto. Ovvio che tra il capirli e l'usarli (magari array o matrici di pointers) ne e' passato di tempo, ma, personalmente, non mi sembra che sia un discorso cosi' complicato. Da dire poi che ho iniziato a 28 anni, un corso privato C e VB ... ecco, ho avuto piu' problemi a capire il VB, la logica della MS :doh:
Quindi, concludo, non penso si possa dire "e' giusto iniziare con X linguaggio" ma che dipenda dalla persona. C'e' chi dice: e' mejo er VB, ce pensa tutto lui ... du' righe e fai tutto.
E c'e' chi invece preferisce controllare tutto e dover fare anche le memset e le delete ... :)
Pero' vista la quantita di esempi e manuali online per il java, un pensierino su quest'ultimo, se fossi un novello, lo farei ... si fa sempre in tempo a cambiare livello ;)
trallallero
06-06-2006, 08:05
azz, che ironia pungente, sei stato fulminante mi hai proprio distrutto :cry:
guarda che non e' una sfida personale ;)
Sto solo dicendo che se lo vuoi veloce lo fai in C, tutto qua.
Mi sembra presto pensare di poter affidare alla macchina il compito di gestire al meglio
tutte le operazioni di gestione memoria.
memoria intesa anche come memoria video, memoria audio ...
sempre il solito discorso... :rolleyes: IMHO gli oggetti sono un argomento troppo avanzato per iniziare, ma ognuno è libero di fare come vuole. è inutile dare consigli in questo caso... se uno ha la passione impara il C senza fare troppa fatica, e lo stesso vale per java.. dipende da cosa ti stimola. cioè se vuoi capire come funzionano le cose o se vuoi avere risultati immediati. comunque se uno vuole programmare giochi è difficile che non sappia cosa sia un puntatore... tra l'altro la cosa è anche peggio in java o linguaggi a oggetti perchè i puntatori non li vedi ma ci sono! e in quel caso sono problemi se non sai come funzionano perchè non capisci qual'è il problema del tuo codice che in teoria deve funzionare, ma qualcosa punta a qualcos'altro ecc...
tomminno
06-06-2006, 09:24
perchè?
Intanto l'esigenza di distinguere a livello di codice tra un funzione che ritorna qualcosa da una funzione che non ritorna niente, utilizzo di Set per impostare alcuni tipi di variabili (non basta l'operatore di assegnamento?), Call per chiamare una funzione (non basta invocarla?), se però assegni il valore di ritorno ad una variabile allora Call non serve più, il non utlizzo delle parentesi così che ogni costrutto ha una propria parola chiave di chiusura, variaibli senza scope...
poco professionale? con che criteri la stabilisci la professionalità?
Il fatto che il codice che sottintende a tutto quello che disegni (e in VB se vuoi una cosa devi disegnarla) sia completamente oscurato ti dice niente?
Il VB è un linguaggio nato per chi non ha voglia di studiarsi seriamente la programmazione, che magari di mestiere fa altro, quindi vuole scrivere un programma in fretta e senza troppe conoscenze.
Un pò come se io mi mettessi a disegnare circuiti stampati con il primo programma che trovo in circolazione e pretendessi di essere uno sbrogliatore professionista!
Poi data l'elevata cultura informatica che contraddistingue l'Italia, VB è usatissimo da noi.
Pensa sto mettendo mano ad un programma in VB il cui sviluppo è cominciato nel 1999 (a parte il fatto che è scritto da cani, ma questo è un altro discorso), oggi nel 2006 si parla di riscriverlo da 0 ancora in VB6 :muro: perchè tutti i vari OCX relativi alla cartografia che girano intorno a questo programma, con C# (e .NET in generale) non funzionano correttamente, mentre in C++ non danno nessunissimo problema (dal 1999 C++ non è cambiato molto, VB6 invece non è praticamente più supportato). Siccome al cliente non puoi vendere nuove licenze cartografiche certificate per .NET, allora via a cominciare un nuovo sviluppo in un antiquato VB6 (non sia mai di usare il C++, in azienda si usa VB6!).
Quel era la scelta migliore? VB6 o C++? Solo che la bassa cultura informatica e la voglia di avere un programma subito funzionante alla lunga ha portato a questo. Poi ti farei vedere che schifezza di codice c'è, funzioni di centinaia di righe, variabili globali in quantità, informazioni come latitudine e longitudine conservate in formato stringa :doh: non ultimo un database di riferimento con tabelle senza chiavi primarie e niente foreign keys.
il consiglio di python è altrettanto buono, ma calcola che lui è orientato ai giochi e, anche se java non ti piace, è oggettivamente piu utilizzato di python (al momento) per i games...Ovviamente anche il mio era un consiglio personale, condito da considerazioni personali.
Comunque per iniziare consigliavo Python per la semplicità, non certo per farci videogiochi.
Secondo me anche Java è un pò ostico per cominciare.
vogliamo i numeri Orea i numeri non li ho.
Parlavo per esperienza personale: quando lo provai io, ed era la prima release decente, mi parve più lento di java.
In ogni caso, rimane più lento di C++, concorderai su questo spero.
se devi fare un device driver serve il C o il C++, ma se devi fare un videogioco basta il C# Ma il C++ resta più veloce e imho flessibile.
esempio pratico? Non conosco C# abbastanza per sapere cosa esattamente non può fare.
Puoi dirmelo tu, no?
vogliamo i numeri, ah e devono essere riproducibili. Spero tu non mi venga ora a dire che C# è veloce più di C++, eh.
ROTFL!! Prego?
C++ è il linguaggio compilato più portabile.
Java e C# sono più portabili, è vero.
non è vero, il linguaggio più all'avanguardia che io conosca è Java (è affiancato da una comunità di programmatori e da una set di modernissimi strumenti e librerie che sono tra i più vasti che io conosca)Non esiste un conteggio diretto, ma credo che ad oggi siamo lì.
personalmente io e altre 10 persone ci stiamo facendo un gioco in Java in 2D senza aver studiato un bel cavolo (e sono anche sicuro che il nostro è molto meglio del tuo )Cioè, stai facendo un gioco senza sapere nè Java nè usare le librerie grafiche che usate? :eek:
Scherzi a parte, lo spero per voi, il mio è una cosa fatta per spremere le SDL :p
probabilmente non sei in grado di scegliere lo strumento migliore per qualcosa.Non capisco cosa vuoi dire.
Se intendi che quei linguaggi non li conosco a fondo, hai perfettamente ragione - non per niente rimango un programmatore PHP e C++.
Ho cominciato a studiarli ma non mi sono piaciuti per nulla e li ho mollati.
non ne dubito, ma certe cose non servono veramente mai... a che ti serve l'aritmetica dei puntatori? a che ti servono gli includes quando puoi sostituirli con un sistema di packages? a che ti servono le macro se non ad ingannare sulla sintassi del codice? a che ti serve delete? e potrei continuare per molto... L'aritmetica dei puntatori non è affatto inutile, nei progetti avanzati è una pacchia.
Sono esattamente la stessa cosa, nel senso che svolgono la stessa funzione.
Rimane il fatto che sono utili.
Delete serve a liberare memoria allocata, ovviamente, e ad evitare memory leak.
stesso discorso di prima: tutte cose che puoi eliminare a meno che non hai la necessità del controllo totale, e di certo non è il caso di un videogioco (forse ti do una brutta notizia ma probabilmente in futuro anche i device drivers verranno scritti in linguaggi di livello più alto: Microsoft si è avviata verso l'approccio Object Oriented nel campo)Beh, per un videogioco serio il controllo totale serve, eccome.
Comunque, niente da dire: se non interessa la potenza del C++ nè la sua velocità, Java e C# vanno benissimo.
Io ho solo espresso la mia opinione, non ho certo annunciato verità nascoste :) .
Quel era la scelta migliore? VB6 o C++? Solo che la bassa cultura informatica e la voglia di avere un programma subito funzionante alla lunga ha portato a questo. Poi ti farei vedere che schifezza di codice c'è, funzioni di centinaia di righe, variabili globali in quantità, informazioni come latitudine e longitudine conservate in formato stringa :doh: non ultimo un database di riferimento con tabelle senza chiavi primarie e niente foreign keys.
Da quello che dici, non sembra un problema di vb, ma di competenze generali.
ma te l'immagini videogiochi pesanti, "costosi" come FIFA, HalfLife senza l'aritmetica dei puntatori e senza la delete ??? :confused:
Me l'immagino si'. Ed e' un pensiero meraviglioso :)
Questo dato non mi risulta. Sicuramente c'e' la tendenza a cercare di utilizzare quando possibile C# per i tool ma al momento attuale e' assolutamente fuori discussione un gioco interamente in C#. La situazione potrebbe cambiare nei prossimi anni ma attualmente il C++ e' la sola e unica possibilita' per fare un gioco di un certo livello.
Maurizio, qui ti devo correggere. Ormai (quasi) la maggioranza dei progetti appena partiti o in partenza relegano il C++ quasi al solo engine e parti del game code. C'e' una fortissima tendenza a scrivere la stragrande maggioranza del gamecode in linguaggi come Lua/Python. In futuro la tendenza non puo' che aumentare.
Anche qui scrivendo il gamecode in Lua abbiamo (hanno, perche' io sono ancora relegato al C++ grrr) riscontrato un aumento di produttivita' enorme (nell'ordine del 3/400%). Il codice Lua non appare mai nel profiling.
Sono invece d'accordo nel dire che un gioco interamente in C# e' fuori discussione perche' limiterebbe enormente le possibilita' di porting verso console e la virtual machine .NET offre ancora poco controllo sul garbage collector. .NET 2.0 ha pero' in gran parte risolto il secondo problema, si puo' caricare e ospitare il CLR da un'applicazione nativa avendo il quasi totale controllo del garbage collector e delle policy di allocazione/disallocazione/controllo degl'oggetti managed. Il primo problema e' ancora ovviamente irrisolto :)
E c'e' chi invece preferisce controllare tutto e dover fare anche le memset e le delete ... :)
Ma e' ovvio, i gusti personali sono insostituibili. C'e' chi preferisce piantare un chiodo dandogli le capocciate (e digli che fa male a farlo), oppure spingendo con le dita, e qualcun altro preferisce piantare un chiodo col martello perche' fa prima e con meno fatica. Il risultato e' identico: un chiodo nel muro.
trallallero
06-06-2006, 14:45
Ma e' ovvio, i gusti personali sono insostituibili. C'e' chi preferisce piantare un chiodo dandogli le capocciate (e digli che fa male a farlo), oppure spingendo con le dita, e qualcun altro preferisce piantare un chiodo col martello perche' fa prima e con meno fatica. Il risultato e' identico: un chiodo nel muro.
quindi, se ho capito bene, con questa poetica nonche' sarcastica metafora, stai cercando di convincere qualcuno che:
martello = Java Lua/Python
testa = C/C++
bah :rolleyes: fino a quando non verra' uno che fa videogiochi "pesanti" di professione, a dirmi:
noi, alla Valve, Eidos, Pinco Pallo, facciamo giochi 3D NON in C/C++, non cambiero' idea.
MSciglio
06-06-2006, 14:46
Maurizio, qui ti devo correggere. Ormai (quasi) la maggioranza dei progetti appena partiti o in partenza relegano il C++ quasi al solo engine e parti del game code. C'e' una fortissima tendenza a scrivere la stragrande maggioranza del gamecode in linguaggi come Lua/Python. In futuro la tendenza non puo' che aumentare.
Anche qui scrivendo il gamecode in Lua abbiamo (hanno, perche' io sono ancora relegato al C++ grrr) riscontrato un aumento di produttivita' enorme (nell'ordine del 3/400%). Il codice Lua non appare mai nel profiling.
Sono invece d'accordo nel dire che un gioco interamente in C# e' fuori discussione perche' limiterebbe enormente le possibilita' di porting verso console e la virtual machine .NET offre ancora poco controllo sul garbage collector. .NET 2.0 ha pero' in gran parte risolto il secondo problema, si puo' caricare e ospitare il CLR da un'applicazione nativa avendo il quasi totale controllo del garbage collector e delle policy di allocazione/disallocazione/controllo degl'oggetti managed. Il primo problema e' ancora ovviamente irrisolto :)
Tu stai parlando di linguaggi di scripting interfacciati con l'engine scritto in C++. Quello lo davo per scontato considerando che sono anni che e' ormai la prassi per qualunque gioco di un certo livello.
Io mi riferivo ad un gioco scritto interamente in un linguaggio che non sia C++.
Quando dico che non puoi scrivere un gioco interamente in C# mi riferisco principalmente al calo prestazionale che nell'utilizzo delle DirectX sembrerebbe ammontare a circa il 5% rispetto al C++. Ovviamente il 5% per un gioco 3D e' un'infinita' considerando che entrambi non dormiamo la notte inseguendo i singoli fps :)
Concordo sul fatto che il .NET 2.0 sembra promettere molto bene e sono convinto che il futuro dei videogiochi passera' per la tecnologia .NET.
Come portabilita' non saprei. Mono sembra fare un eccellente lavoro sotto Linux e supporta praticamente tutto il framework.
MSciglio
06-06-2006, 14:47
bah :rolleyes: fino a quando non verra' uno che fa videogiochi "pesanti" di professione, a dirmi:
noi, alla Valve, Eidos, Pinco Pallo, facciamo giochi 3D NON in C/C++, non cambiero' idea.
Non lo vedrai... per ancora un paio di anni :)
tomminno
06-06-2006, 14:47
Da quello che dici, non sembra un problema di vb, ma di competenze generali.
Chi non ha competenze usa VB, chi le ha lo evita.
Il problema è proprio insito nei concetti che stanno alla base del VB.
A parte il mio caso specifico, se anche quel codice fosse stato scritto in maniera decente i problemi di manutenibilità del codice sarebbero rimasti.
Il C/C++ ti dà garanzie di manutenibilità del codice per programmi con una vita utile che supera i 10 anni, Java ancora non ha ancora quell'età (o quasi) e C# non è altrettanto stabile come linguaggio visto che passando dalla versione 2003 alla 2005 di .NET praticamente tutti i programmi che ho visto utilizzano già metodi deprecati. Cosa succederà tra altri 5 anni? Tutto quel codice sarà da buttare?
Il fatto di appoggiarsi ad un framework sottostante ha il difetto che se cambiano le specifiche il tuo codice lo puoi pure buttare e siccome le specifiche .NET le fa Microsoft a suo piacimento nessuno ti garantisce che con una ipotetica versione 3 del framework non ti obblighi a pesanti revisioni (che potrebbero comportare per il cliente l'acquisto di una nuova licenza di qualche software correlato).
Tu stai parlando di linguaggi di scripting interfacciati con l'engine scritto in C++. Quello lo davo per scontato considerando che sono anni che e' ormai la prassi per qualunque gioco di un certo livello.
Io mi riferivo ad un gioco scritto interamente in un linguaggio che non sia C++.
Assolutamente si', un gioco di un certo spessore interamente non in C++ e' impensabile.
Secondo me si tratta di definire quanto C++ c'e' oggi in un gioco, e quanto ce ne sara' in futuro. Malissimo che vada il driver della scheda video conterra' alcune parti in C++/asm :)
Ormai non faccio piu' la distinzione fra linguaggio di scripting e non, per me Lua /Python/C# sono linguaggi a tutti gli effetti, pari dignita' del C++. Si tratta anche qui di capire quale strumento usare nel giusto contesto: rigiro l'affermazione di prima, un gioco di un certo spessore interamente in C++ e' impensabile ormai. Troppo complesso, nessuno vuole piu' spendere nottate alla ricerca di quel double delete o dell'altro memory scribbler. Meglio spendere quelle nottate a guadagnare il 5% di prestazioni oppure ad aggiungere qualche elemento di gameplay, o giocare il gioco e renderlo piu' divertente.
Quando dico che non puoi scrivere un gioco interamente in C# mi riferisco principalmente al calo prestazionale che nell'utilizzo delle DirectX sembrerebbe ammontare a circa il 5% rispetto al C++. Ovviamente il 5% per un gioco 3D e' un'infinita' considerando che entrambi non dormiamo la notte inseguendo i singoli fps :)
Non so, le prestazioni del framework non sono il mio problema. Malissimo che vada posso isolare il codice che mi cala quel 5% di prestazioni e riscriverlo in un paio di serate in C++ (il giusto strumento per questo lavoro). Sono piu' preoccupato del garbage collector non deterministico, che puo' decidere lui per quanto tempo deve girare. Ancora non ho visto un API, neppure nel 2.0, per dire al GC di NON impiegare piu' di un certo tempo per la sua esecuzione. Questo mi preoccupa.
Concordo sul fatto che il .NET 2.0 sembra promettere molto bene e sono convinto che il futuro dei videogiochi passera' per la tecnologia .NET.
Come portabilita' non saprei. Mono sembra fare un eccellente lavoro sotto Linux e supporta praticamente tutto il framework.
In realta' mi riferivo alle console, mi piacerebbe vedere .NET sul 360 ma non sembra ne abbiano intenzione :D
quindi, se ho capito bene, con questa poetica nonche' sarcastica metafora, stai cercando di convincere qualcuno che:
martello = Java Lua/Python
testa = C/C++
In molte situazioni, si', questa e' la metafora.
bah :rolleyes: fino a quando non verra' uno che fa videogiochi "pesanti" di professione, a dirmi:
noi, alla Valve, Eidos, Pinco Pallo, facciamo giochi 3D NON in C/C++, non cambiero' idea.
Noi alla Lionhead facciamo giochi 3D non interamente in C/C++. Ora cambi idea? :)
trallallero
06-06-2006, 14:58
Non lo vedrai... per ancora un paio di anni :)
molti di voi parlano di "fra un po'" ... "tra qualche anno" ...
ma cosa sta per succedere ? io sono un po' fuori dal mondo MS e .NET perche' ormai e' qualche anno che lavoro su Sun ...
io comunque sto parlando di videogiochi INTERAMENTE non fatti in C/C++ ;)
e' ovvio che se fai un qualcosa in C# o vattelapesca che usa le DirectX o OpenGL allora non vale! :sofico:
Togliere completamente il C dalle balle adesso non e' possibile, per me.
Dai che succede tra 2 anni ? :mbe:
molti di voi parlano di "fra un po'" ... "tra qualche anno" ...
ma cosa sta per succedere ? io sono un po' fuori dal mondo MS e .NET perche' ormai e' qualche anno che lavoro su Sun ...
io comunque sto parlando di videogiochi INTERAMENTE non fatti in C/C++ ;)
e' ovvio che se fai un qualcosa in C# o vattelapesca che usa le DirectX o OpenGL allora non vale! :sofico:
Togliere completamente il C dalle balle adesso non e' possibile, per me.
Dai che succede tra 2 anni ? :mbe:
Questo pero e' un ragionamento capzioso :D
Il task scheduler del sistema operativo sara' molto probabilmente per sempre in assembly se e' per questo, come alcune parti dei driver, e non puoi scrivere un gioco che non usi il task scheduler o i driver.
Secondo me il discorso piu' corretto da fare e' questo: quanti programmatori in un team di sviluppo che fa giochi usano il C++ oggi e quanti lo useranno domani? Nel team dove lavoro io adesso, 6 o 7 programmatori scrivono in C++ (me compreso), il resto, circa una ventina, scrivono in Lua/Python/C# a seconda di quello che stanno facendo.
Fra qualche anno vedrai molti team di sviluppo in cui probabilmente non ci sara' un programmatore C++.
trallallero
06-06-2006, 15:03
Noi alla Lionhead facciamo giochi 3D non interamente in C/C++. Ora cambi idea? :)
eh no! non vale ... qualcosa di C usate se ho capito bene ;)
Lionhead ? citami un gioco plz ... non posso navigare liberamente, solo qualche sito.
P.S.: vi serve un prog C++ ? mi son rotto le balle di Sun e ... dell'Italia :)
eh no! non vale ... qualcosa di C usate se ho capito bene ;)
Lionhead ? citami un gioco plz ... non posso navigare liberamente, solo qualche sito.
Fable 2.
P.S.: vi serve un prog C++ ? mi son rotto le balle di Sun e ... dell'Italia :)
Cerchiamo di abbandonare il C++ :p
eh no! non vale ... qualcosa di C usate se ho capito bene ;)
Lionhead ? citami un gioco plz ... non posso navigare liberamente, solo qualche sito.
http://www.lionhead.com/teambw/makingof.html
Di nazionalità italiana ce n'è solo uno in quella pagina ;)
trallallero
06-06-2006, 15:31
Fable 2.
boh ? qui non lo conosce nessuno ...
quindi per adesso non cambio idea :O
Cerchiamo di abbandonare il C++ :p
meglio, diminuisce la concorrenza :p
trallallero
06-06-2006, 15:34
http://www.lionhead.com/teambw/makingof.html
Di nazionalità italiana ce n'è solo uno in quella pagina ;)
non ci posso andare :cry:
Accesso Negato
Utente non autorizzato all'accesso di questo sito.
Questo si verifica nei casi in cui si tenta di accedere ad un sito web bloccato in base alle policy aziendali.
Per ricevere assistenza, contattare l'help desk.
e mi domando ... perche' ci fanno andare (per fortuna) su hwupgrade ??? :confused:
Vediamo se qui ti ci fanno andare: http://www.microsoft.com/presspass/press/2006/apr06/04-06LionheadPR.mspx
trallallero
06-06-2006, 15:39
Vediamo se qui ti ci fanno andare: http://www.microsoft.com/presspass/press/2006/apr06/04-06LionheadPR.mspx
;) grazie :)
Animo, animo ragazzi! State ammosciando la rissa :boxe: ! Mettevi nei panni di chi legge: una noia mortale :coffee: .
Dai, qualcuno butti un bel petardo che rinfocoliamo :D: !
Animo, animo ragazzi! State ammosciando la rissa :boxe: ! Mettevi nei panni di chi legge: una noia mortale :coffee: .
Dai, qualcuno butti un bel petardo che rinfocoliamo :D: !
Anche tu pero', per una volta che non si scatena la lotta nel fango :D
Ma guarda che è un fenomeno antropologico interessantissimo. Mi appare ormai inevitabile che una discussione tra programmatori dai e dai vada a parare sempre nel solito acquitrinio.
C'è una domanda (vale qualsiasi cosa, anche un "il caffè, liscio o macchiato?"), poi qualche messaggio interlocutorio, un po' di gioco di gambe, e PAM!, parte uno col diretto "C è er mejo de tutti", segue un montante di "e Java 'ndo lo metti" a cui non manca mai e dico mai l'uppercut in "nun ve dimenticate de C ppiù ppiù".
Stavolta l'asso di bastoni l'ha calato shynia al 17°, da vecchio volpone, con un "ti sconsiglio C++" che suona sempre come l'invasione della Polonia: da lì in poi è tutti contro tutti :D.
Noi alla Lionhead facciamo giochi 3D non interamente in C/C++. Ora cambi idea? :)Cosa usate?
grande PGI :)
ps. se qualcuno vuole consigliare python è il momento giusto :asd:
Stavolta l'asso di bastoni l'ha calato shynia al 17°, da vecchio volpone, con un "ti sconsiglio C++" che suona sempre come l'invasione della Polonia: da lì in poi è tutti contro tutti :D.
ROTFL!! :D
jappilas
06-06-2006, 17:26
Sei sicuro che la memoria che hai allocato venga rilasciata nel momento che il program counter ha superato quell'istruzione?
Oppure viene deallocata quando il GC si attiva per i cavoli suoi?
Esistono anche librerie per la GC in C/C++ ma sono un controsenso.
io sapevo che nel managed code di .net la memoria viene rilasciata quando un oggetto finisce fuori scope
in Java un thread della VM si occupa del reaping e di eseguire i finalizzatori degli oggetti non piu' referenziati: questo dovrebbe riciclare la memoria in modo trasparente, e al tempo stesso minimizzarne la frammentazione che si potrebbe ottenere se gli oggetti venissero deallocati "subito" - notare che si pone il problema dello scarso determinismo del GC , rendendolo inadatto al real time
librerie per GC per c e c++ in realta' non sono un controsenso, non finche' non si costruiscono dei programmatori immuni dalla famigerata "sindrome del puntatore vagante" :D
Me l'immagino si'. Ed e' un pensiero meraviglioso :)
:D
Anche qui scrivendo il gamecode in Lua abbiamo (hanno, perche' io sono ancora relegato al C++ grrr) riscontrato un aumento di produttivita' enorme (nell'ordine del 3/400%). Il codice Lua non appare mai nel profiling.
questo implica che non e' un bottleneck code path ? :)
ritornando al thread, cioe' alla domanda iniziale, butterei li' una proposta non troppo provocatoria: studiare un po' di java e guardare diamonds :)
io mi sono reso conto di molte cose e ho cambiato la mia prospettiva su molte altre, da quando ho provato a fare qualche task...
Animo, animo ragazzi! State ammosciando la rissa :boxe: ! Mettevi nei panni di chi legge: una noia mortale :coffee: . perché la gente non risponde a tono! ora ci penso io...
Ma guarda che è un fenomeno antropologico interessantissimo. Mi appare ormai inevitabile che una discussione tra programmatori dai e dai vada a parare sempre nel solito acquitrinio.
C'è una domanda (vale qualsiasi cosa, anche un "il caffè, liscio o macchiato?"), poi qualche messaggio interlocutorio, un po' di gioco di gambe, e PAM!, parte uno col diretto "C è er mejo de tutti", segue un montante di "e Java 'ndo lo metti" a cui non manca mai e dico mai l'uppercut in "nun ve dimenticate de C ppiù ppiù".
Stavolta l'asso di bastoni l'ha calato shynia al 17°, da vecchio volpone, con un "ti sconsiglio C++" che suona sempre come l'invasione della Polonia: da lì in poi è tutti contro tutti :D.
:rotfl: :rotfl: :rotfl:
guarda che non e' una sfida personale ;)
Sto solo dicendo che se lo vuoi veloce lo fai in C, tutto qua. e tutto qua un par di palle :D (contento PGI? :p)
I NUMERIIIIII... :muro:
Mi sembra presto pensare di poter affidare alla macchina il compito di gestire al meglio
tutte le operazioni di gestione memoria.
memoria intesa anche come memoria video, memoria audio ... stai facendo un miscuglio insensato... quelle sono ranges di memoria allocate non dinamicamente, un garbage collector per risorse statiche non ha senso
Cosa usate?
Lua
io sapevo che nel managed code di .net la memoria viene rilasciata quando un oggetto finisce fuori scope
No, funziona uguale a Java, ma con un algoritmo Mark&Sweep a tre generazioni bla bla bla che fa il garbage collection...
questo implica che non e' un bottleneck code path ? :)
Esatto :)
E se scrivere gran parte del game code in Lua non e' un collo di bottiglia, che motivo resta per scriverlo in C++ con tutti i problemi e i cali di produttivita' che si porta dietro?
Edit: continuo a ridere sguaiatamente in ufficio pensando all'invasione della Polonia e fra poco mi accompagnano alla porta :rotfl:
In ogni caso, rimane più lento di C++, concorderai su questo spero. no; ma neanche sul contrario: concordo con i fatti, con i numeri
Ma il C++ resta più veloce e imho flessibile. metti imho anche a veloce, e aggiungi che il C++ ha tanti svantaggi rispetto ai linguaggi di alto livello
Non conosco C# abbastanza per sapere cosa esattamente non può fare.
Puoi dirmelo tu, no? no, io sono un esperto di C (neanche tanto di C++)
Spero tu non mi venga ora a dire che C# è veloce più di C++, eh. io dico quello che dicono i numeri (essì, ho rotto co sti numeri, lo ben so, e a rompere continuerò)
Prego?
C++ è il linguaggio compilato più portabile.
Java e C# sono più portabili, è vero. appunto...
Cioè, stai facendo un gioco senza sapere nè Java nè usare le librerie grafiche che usate? :eek: quando abbiamo iniziato conoscevo poco di Java (giusto la sintassi) e non sapevo dell'esistenza di LWJGL; molti componenti del team sono partiti esattamente così, e il gioco sta venendo benissimo
Non capisco cosa vuoi dire. se ti ritrovassi a dover scegliere lo strumento più adatto per svolgere un lavoro in certe situazioni sceglieresti quello errato
Se intendi che quei linguaggi non li conosco a fondo, hai perfettamente ragione - non per niente rimango un programmatore PHP e C++.
Ho cominciato a studiarli ma non mi sono piaciuti per nulla e li ho mollati. "piaciuti"? e se te vai a gusti... a me piace mangiare quintali di cioccolata, ma non è che sia esattamente la gioia del mio fegato, perciò non lo faccio
L'aritmetica dei puntatori non è affatto inutile, nei progetti avanzati è una pacchia. in quali "progetti avanzati" hai lavorato in C++, e in quali situazioni ti sei ritrovato a godere di una tecnica così anti-intuitiva? ti dico subito che il "progetto avanzato" era un progetto italiano allora non serve neanche che mi rispondi
Sono esattamente la stessa cosa, nel senso che svolgono la stessa funzione.
Rimane il fatto che sono utili. che? cosa? mi sono perso una quotatura, non seguo più...
Delete serve a liberare memoria allocata, ovviamente, e ad evitare memory leak. ma a che ti serve quando potrebbe farlo un garbage collector senza possibilità di sbagliare (al contrario di come fai tu)?
Beh, per un videogioco serio il controllo totale serve, eccome. in un videogioco serio hai l'estrema necessità di usare stub di assembly, di manipolare puntatori, di deallocare manualmente, di... oh, ma che mi ripeto a fare, l'ho già scritto 1000 volte -.-'
leggete i miei post precedenti in questo thread, è inutile che mi ripeto (d'ora in poi rispondo così)
io comunque sto parlando di videogiochi INTERAMENTE non fatti in C/C++ ;) te l'hanno detto: tra qualche anno sarà così
e' ovvio che se fai un qualcosa in C# o vattelapesca che usa le DirectX o OpenGL allora non vale! :sofico: perché?
Togliere completamente il C dalle balle adesso non e' possibile, per me. Diamond Crush non è in C, è interamente in Java; immaginati Diamond Crush solo che molto più complesso, proiezioni tridimensionali, modelli fatti con qualche software di grafica 3D come 3D Studio Max, eccetera eccetera. è possibilissimo, chi lo vieta... in Java, in C#, chi lo vieta...
Ma guarda che è un fenomeno antropologico interessantissimo. Mi appare ormai inevitabile che una discussione tra programmatori dai e dai vada a parare sempre nel solito acquitrinio.
C'è una domanda (vale qualsiasi cosa, anche un "il caffè, liscio o macchiato?"), poi qualche messaggio interlocutorio, un po' di gioco di gambe, e PAM!, parte uno col diretto "C è er mejo de tutti", segue un montante di "e Java 'ndo lo metti" a cui non manca mai e dico mai l'uppercut in "nun ve dimenticate de C ppiù ppiù".
Stavolta l'asso di bastoni l'ha calato shynia al 17°, da vecchio volpone, con un "ti sconsiglio C++" che suona sempre come l'invasione della Polonia: da lì in poi è tutti contro tutti :D.
Ahahaha mi hai fatto sdraiare!!! Però non mi toccate la Polonia eh che ce l'ho nel cuore!!!
Comunque butto un asso di bastoni pure io, secondo me iniziare col Python potrebbe essere un bel jolly.
Perchè dite che non si possono fare giochi con Python? Non è assolutamente vero:
http://www.amazon.com/gp/product/1592000770/103-0749577-9264632?v=glance&n=283155
Il consiglio di uno che ha iniziato a programmare per fare videgiochi è: "Io inizierei da un linguaggio ad alto livello".
io lo sapevo :D il python viene sempre dopo la lotta java/.NET versus C++
ciao a tutti ho letto solo ora sto topic e mi piacerebbe cominciare a cimentarmi un pò anche a me nella programmazione con speranze di sbarcare nel mondo della videoludica, ma non ho conoscenze di nessun linguiaggio tranne pascal che lo studio da un anno a scuola. premesso che mi ha sempre attirato il c++ ho letto in queste pagine che a quanto pare non è il più consigliato e sta per passare di moda. volevo sapere se secondo voi faccio bene alla luce di questo topic a buttarmi sul python (o forse c# ma sono insicuro). io avevo intenzione di imparicchiarmi lu python, poi su alcune premesse sulla programmazione videoludica mi dicevano di imparare il c++ e qui mi dite di no :P asd e a questo punto sono confuso anche io. dato che so che ci vorranno come minimo tutte le vacanze estive per imparare un pò un linguaggio non voglio imparare qualcosa per poi sapere che tra 3 anni non sarà più usato :rolleyes: ...
inoltre volevo sapere secondo voi quale linguaggio è più compatibile con opengl.
*din din din*
fuori i secondi :D
jappilas
06-06-2006, 20:19
Il task scheduler del sistema operativo sara' molto probabilmente per sempre in assembly se e' per questo, come alcune parti dei driver, e non puoi scrivere un gioco che non usi il task scheduler o i driver.
non è detto :)
poco tempo fa leggevo giusto un white paper sul sito dell' università di Dresda ( "makers of" L4 ), il quale parlava giusto dell' impatto che ha la riscrittura di un kernel in c++
e si è visto che riprogettare e scrivere un kernel ( il loro sistema è tra l' altro un microkernel puro con il VM paging / caching/ persistency subsystem esterno, quindi quando parlano di "kernel" intendono proprio lo scheduler di processi e tread ) avente prestazioni pari alla versione precedente in assembly e' fattibile e conveniente
ciao a tutti ho letto solo ora sto topic e mi piacerebbe cominciare a cimentarmi un pò anche a me nella programmazione con speranze di sbarcare nel mondo della videoludica, ma non ho conoscenze di nessun linguiaggio tranne pascal che lo studio da un anno a scuola. premesso che mi ha sempre attirato il c++ ho letto in queste pagine che a quanto pare non è il più consigliato e sta per passare di moda. volevo sapere se secondo voi faccio bene alla luce di questo topic a buttarmi sul python (o forse c# ma sono insicuro). io avevo intenzione di imparicchiarmi lu python, poi su alcune premesse sulla programmazione videoludica mi dicevano di imparare il c++ e qui mi dite di no :P asd e a questo punto sono confuso anche io. dato che so che ci vorranno come minimo tutte le vacanze estive per imparare un pò un linguaggio non voglio imparare qualcosa per poi sapere che tra 3 anni non sarà più usato :rolleyes: ...
inoltre volevo sapere secondo voi quale linguaggio è più compatibile con opengl.
ah! ma allora c'è ancora gente che impara pascal :) bravo bravo... secondo me da una buona preparazione. se vuoi rimanere con la sintassi pascal-like vai con il delphi che non ti sbagli (cosa che io non ho fatto). opengl che io sappia è compatibile allo stesso modo con i vari linguaggi... io le ho usate con C++ e con java. ottima scelta anche per opengl (parlo a livello didattico, niente flame (questa volta :D )).
ciao a tutti ho letto solo ora sto topic e mi piacerebbe cominciare a cimentarmi un pò anche a me nella programmazione con speranze di sbarcare nel mondo della videoludica, ma non ho conoscenze di nessun linguiaggio tranne pascal che lo studio da un anno a scuola. premesso che mi ha sempre attirato il c++ ho letto in queste pagine che a quanto pare non è il più consigliato e sta per passare di moda. no, hai frainteso: il discorso è sottilmente diverso, in informatica non c'è il concetto di moda; il C++ si usa ancora, ma solo dove serve. nel settore videoludico serve sempre di meno, ma ci sono altre tipologie di software dove è ancora ampiamente utilizzato assieme al C (leggi: system programming).
volevo sapere se secondo voi faccio bene alla luce di questo topic a buttarmi sul python (o forse c# ma sono insicuro). quella del linguaggio d cui iniziare è una discussione veramente senza fine, se ne sono tenute parecchie istanze senza mai secondo me che una delle parti in discussione mostrasse le sue ragioni in maniera assolutamente incontestabile; che dire, inizia dal linguaggio che ti pare, anche il C++ se vuoi; tanto se ti piace veramente programmare, di sicuro continuerai e ne imparerai altri.
il linguaggio per fare tutto comunque non esiste e mai esisterà, ogni cosa ha il suo motivo di esistere in questo settore; ecco perché un buon programmatore deve sapere più d'un linguaggio di programmazione, perché se ne conosce uno solo vuol dire che sa fare solo una cosa
io avevo intenzione di imparicchiarmi lu python, poi su alcune premesse sulla programmazione videoludica mi dicevano di imparare il c++ e qui mi dite di no :P asd oddio, sinceramente penso che una buona base culturale di C++ per un programmatore videoludico non faccia assolutamente male, ma sappi che è un linguaggio che devi usare il meno possibile: è un settore in cui causa solo guai (e la doppia delete, e i dangling pointers, e i processori che si inchiodano nelle catene di if... :D), anzi a dirla tutta non è neanche l'unico settore: il C++ serve per programmare a basso livello, non ad alto livello.
e a questo punto sono confuso anche io. dato che so che ci vorranno come minimo tutte le vacanze estive per imparare un pò un linguaggio non voglio imparare qualcosa per poi sapere che tra 3 anni non sarà più usato :rolleyes: ... no, ok, ma mettiti in testa che se vuoi essere un bravo programmatore devi avere una mente aperta e dinamica: è una scienza in continua evoluzione e tra tutte le scienze è quella che si evolve più rapidamente, non giungerai mai ad un punto di arrivo, chi si ferma rimane indietro: ogni mese qua esce una novità, quello che impari adesso tra 10 anni ti farà ridere per la sua obsolscenza :)
pensa ai programmatori di 10 anni fa, che hanno imparato a programmare a 16 bit... di loro, quelli che si sono fermati ora non sanno più programmare :)
inoltre volevo sapere secondo voi quale linguaggio è più compatibile con opengl. OpenGL è spesso implementato in C, ma vi puoi accedere da numerosi altri linguaggi che a seconda delle situazioni si rivelano spesso molto più adatti agli scopi di un programmatore che usa OpenGL :D
non è quello il ragionamento che devi fare ("quale strumento si adatta meglio a quell'altro"), gli strumenti non si devono adattare tra di loro, si devono adattare tutti assieme a te :D
trallallero
07-06-2006, 07:25
e tutto qua un par di palle :D (contento PGI? :p)
I NUMERIIIIII... :muro:
'azz ... per fortuna alle 17:00 in punto me ne vado ....
e non vado certo a casa a connettermi ad internet ;)
ma come fanno certi personaggi a scrivere dalle 7:00 alle 24:00 ??? oddio, mejo che guardare la TV, in effetti :rolleyes:
stai facendo un miscuglio insensato... quelle sono ranges di memoria allocate non dinamicamente, un garbage collector per risorse statiche non ha senso
o non mi sono spiegato o continui a non capire :muro: (tanto per scaldare un po' l'ambiente :p )
sai come funzicano le DirectX ? puoi anche fare un gioco in java, basic o cobol ma se poi usi 'ste benedette dairectics per il video, suono etc, stai usando "indirettamente" il C/C++. Quindi, vorrei vedere le prestazioni di ipotetiche DirectX fatte in Java e/o C# con 'sta benedetta "garbage collector" ... secondo me a FIFA giocheresti solo al replay :rotfl:
PS: per far contento PGI ... :fuck:
trallallero
07-06-2006, 07:28
non è detto :)
... il quale parlava giusto dell' impatto che ha la riscrittura di un kernel in c++ ...
ma dai, un kernel iun C++ ??? :rotfl:
ma non lo sanno che ormai i kernels si fanno in Java ??? :O
dato che so che ci vorranno come minimo tutte le vacanze estive per imparare un pò un linguaggio non voglio imparare qualcosa per poi sapere che tra 3 anni non sarà più usato :rolleyes: ...
Nessun linguaggio è inutile...ogni linguaggio ha suoi campi di applicazione, quelli del C++ probabilmente si stanno riducendo in favore di Java, ma si stanno anche ampliando alle spese del C...
Insomma, sei già avanti con il C++ ? Continua e dopo Java te lo impari in 1 mese...
Nessun linguaggio è inutile...ogni linguaggio ha suoi campi di applicazione, quelli del C++ probabilmente si stanno riducendo in favore di Java, ma si stanno anche ampliando alle spese del C...
Insomma, sei già avanti con il C++ ? Continua e dopo Java te lo impari in 1 mese...
Quoto
Le guerre di linguaggi sono inutili, l'importante è avere una base solida, il linguaggio è solo un modo di esprimerla.
Una volta che si impara a programmare ad oggetti per usare c++ o java bsta cambiare la sintassi, i concetti grosso modo sono quelli.
io insisto: una discussione quasi interamente di aria fritta, il tutto perche ho tirato fuori un c# in prima pagina... c' e un compito da eseguire, uno strumento da scegliere; si valutano le esigenze, si sceglie lo strumento...un linguaggio serve per x, l altro serve per y...sinceramente questa "guerra di linguaggi" non la vedo proprio...
invece il mio parere personale è che iniziare da c++ possa risultare scoraggiante (ma io ho iniziato da java, quindi probabilmente sono di parte); certo è che per un giochino per imparare trovo mille volte piu isi java/python/c#...
invece il mio parere personale è che iniziare da c++ possa risultare scoraggiante
Dipende con che spirito si apprende il C++...se si vuole essere subito produttivi si sceglie un altro linguaggio... Ti assicuro che passare da C++ a Java è banale...mentre passare da Java a C++ non è la stessa cosa... In defintiva sono convinto per imparare entrambi il tempo perso sia lo stesso, da qualsiasi linguaggio si cominci...
giusto cionci, modifico; perche parliamo sempre in termini pessimistici, come se "imparare" fosse una fatica da ridurre il piu possibile...in effetti per il 90% della popolazione è cosi, essendo cresciuti nell american style del tutto e subito si è persa la soddisfazione del processo del "divenire" (e io sono stato dentro quel calderone) e delle soddisfazioni che puo dare qualsiasi campo a qualsiasi livello...per alcuni pero effettivamente non fa molta differenza iniziare da c++ piuttosto che da qualsiasi altra cosa, perche l attenzione è shiftata sul fine da raggiungere piuttosto che sul risultato da ottenere; se si parte dal presupposto "voglio programmare un videogioco" convinti che l iter dell apprendimento funzioni come una capsula hopla all interno del cervello, anche imparare html diventa complesso; e detta cosi puo sembrare banale, in realta basta guardare cosa succede (come trend) nelle scuole o nelle universita per rendersi conto che una porzione sempre piu considerevole di aspiranti master nel loro presunto campo mancano di un abilita fondamentale (parlo per esperienza personale e diretta): la basilare capacita di autovalutazione e di problem solving, la quale non si impara su una guida, ma si masterizza con l esperienza accumulata (il discorso che per la matematica bisogna fare esercizi su esercizi).
ti porto un esempio concretissimo: nella mia universita (informatica torino) ogni anno i prof fanno una riunione sull insegnamento della programmazione per fare una statistica; da me funziona che al primo anno c e prog 1 e 2 in java e laboratorio di linguaggi in c...da anni ci si interroga su cosa sia meglio fare al primo anno, per non impattare troppo sugli studenti; ci sono proposte di solo java e c al secondo anno, o viceversa, o gente che propone c++ solo imperativo al primo anno per poi introdurre un approccio OO dal secondo in avanti (e altre proposte tipo smalltalk o linguaggi piu accademici)...uno sforzo encomiabile, ma imho quasi del tutto inutile e fine a se stesso, dal momento che la difficolta non sta nel linguaggio in se, quanto nella volonta che il singolo ha di impararlo (e anche un po nella perizia che ci mette chi te lo spiega); e quando si tratta di avere a che fare con 200 pischelli che derivano dalle situazioni piu eterogenee possibili, con backgrounds non standardizzabili, imho l unica cosa che si puo fare e puntare sulla qualita dell insegnamento e sperare che ci sia una percentuale di "inetti" (come mi chiamavo) sempre minore col tempo...
...dopo anni spesi a non capire cosa mancasse ho realizzato che per vederlo non serviva cercare troppo lontano (professore che spiega male, crisi esistenziale, mancanza di fregna), semplicemente dovevo guardare in basso per rendermi conto che non poggiavo su alcuna base (nozionistica, di voglia,di allenamento mentale); una volta capita la direzione in cui lavorare, se c e anche la voglia, nulla assume piu i connotati di "maaaaa che mazza nel culo, è troppo hard&huge da studiare", quanto piuttosto "il c++, bene, ha una struttura, ci sono delle cose da sgrossare, finalizzo, imposto dei paletti, nel giro di x tempo avro imparato dy di questo linguaggio..."
ecco il perche della diatriba sul linguaggio piu giusto per iniziare. implicitamente si pensa al fatto del rendersi operativi nel minor tempo possibile, quando impiegando lo stesso tempo che si impiega a scegliere per studiare, probabilmente si sta gia avvicinando il primo giochino testuale; mentre chi non ha problemi (ripeto, una minoranza nella quale non sono mai stato incluso, ma che spero di stare per raggiungere) sa gia da subito (perche è allenato) ad affrontare un problema non nella misura in cui potrebbe diventare ostico un domani, ma, diciamo, con un approccio di tipo divide et impera :)
vogliamo parlare di giochi? bene, ho letto in sto periodo un paio di libri della serie "beginning....game programming", quello di c++, quello di c#, quello di opengl e sto proseguendo con quelli di directx...il tutto è finalizzato a diamonds in effetti (per riuscire, prima che lo finiate, a fare almeno un task lol) e piu vado avanti, piu mi rendo conto che ho le idee chiare; bello il c++, bello il c, bello il c#, belle le dx, bello tutto, ma se devo essere sincero mi attira particolarmente l accoppiata java+opengl o c#+d3d e di idee ne ho molte, mi mancano proprio solo gli input necessari a realizzare cio che ho in testa!! quindi do un altro consiglio a denfox ---> parti, parti piu in fretta possibile e da un punto qualsiasi (java, c++, python, boh)...i consigli che ti sono stati dati sono tutti validi ed hanno a sostegno le rispettive argomentazioni inequivocabili, ti puoi fidare...nulla ti vieta poi di andare su diamonds a curiosare...è UN approccio, non so se il migliore, ma sicuramente è concreto, produttivo, formativo e didattico quanto basta; se la tua motivazione superera il pigro scetticismo generazionale, nel giro di pochi mesi (perche prima, come ho detto, non è materialmente possibile) ti sarai levato parecchie soddisfazioni.
ps. o io ci provo ad essere stringato, non me ne vogliate :P
o non mi sono spiegato o continui a non capire :muro: (tanto per scaldare un po' l'ambiente :p )
sai come funzicano le DirectX ? puoi anche fare un gioco in java, basic o cobol ma se poi usi 'ste benedette dairectics per il video, suono etc, stai usando "indirettamente" il C/C++. Quindi, vorrei vedere le prestazioni di ipotetiche DirectX fatte in Java e/o C# con 'sta benedetta "garbage collector" ... secondo me a FIFA giocheresti solo al replay :rotfl:
Qui sei tu che continui a non capire che stai facendo un discorso capzioso ;)
Secondo il tuo ragionamento tutti i programmi di questo mondo sono scritto in assembly, perche' ad un certo punto della loro esecuzione ci saranno chiamate che ad un certo punto finiranno in codice del sistema operativo scritto in assembly. Ovviamente e' una posizione abbastanza assurda.
Quello che conta e' quanto codice che il team di sviluppo scrivere per un gioco e' scritto in C++ e quanto e' scritto in Java.
Se io uso D3D Managed, che si appoggiano a D3D native, e scrivo il codice del gioco in C#, [b]sto scrivendo tutto il codice del gioco in C#. Non conta che alla fine il mio codice chiamera' qualcosa scritto in C++, io l'ho scritto tutto in C#. Esistono gia' una manciata di giochi rilasciati scritti in C# (sebbene come dice giustamente Maurizio non e' qualcosa da consigliare al momento).
Fifa poi e' proprio un tipo di gioco che non avrebbe alcun problema ad essere scritto interamente in C# (fatto salvo il problema della portabilita'): pochi oggetti a schermo, poche texture, un working set abbastanza ridotto (a parte le animazioni da gestire che sarebbero un buon numero): si potrebbe scrivere il render loop praticamente senza mai allocare un singolo oggetto, ovvero, virtualmente niente garbage collector.
il tutto è finalizzato a diamonds in effetti (per riuscire, prima che lo finiate, a fare almeno un task lol)
E tu stai leggendo quella manciata di roba per fare un task di Diamonds dove probabilmente basta saper fare un ciclo for e magari neppure quello?
Ti stai perdendo la lezione piu' importante nella programmazione: pragmatismo e produttivita'. Se vai da un'azienda e gli dici che prima di diventare produttivo e scrivere codice devi studiare tre mesi, ti mandano subito a casa.
BountyKiller
07-06-2006, 12:16
ho dato un'occhiata al codice sorgente di Half life 2........e posso dirvi che:
è scritto in C++
col Visual Studio 6.0...anche se la compilazione è a blocchi e viene fatta con dei file batch e con degli script credo scritti in Perl
fa ampissimo uso di puntatori e template
usa strutture dati miste STL e proprietarie Valve
le librerie di classi sono essenzialmente fatte da Valve, gran parte delle classi (almeno così desumo dai commenti) sono state derivate da quelle usate per il primo half life e per Counterstrike.......ovviamente ci sono le classi delle directX 8 e 9.
morale della storia; buttati sul C++.....magari inizialmente solo procedurale, quando hai imparato bene a usarlo proceduralmente buttati sulla programmazione a oggetti e non ci sarà niente al mondo che non riuscirai a fare con questo linguaggio.
buono studio. :)
ho dato un'occhiata al codice sorgente di Half life 2........e posso dirvi che:
è scritto in C++
col Visual Studio 6.0...anche se la compilazione è a blocchi e viene fatta con dei file batch e con degli script credo scritti in Perl
fa ampissimo uso di puntatori e template
usa strutture dati miste STL e proprietarie Valve
le librerie di classi sono essenzialmente fatte da Valve, gran parte delle classi (almeno così desumo dai commenti) sono state derivate da quelle usate per il primo half life e per Counterstrike.......ovviamente ci sono le classi delle directX 8 e 9.
Half Life 2 ha ritardato di due anni, ed e' durato almeno 5 anni di sviluppo. E ci sara' un perche'. Non e' proprio un fulgido esempio di Ingegneria del Software votato alla produttivita' :)
Non avvicinatevi neppure al C++ da principianti. Tanto meno procedurale, per poi disimparare e ricominciare daccapo.
PS. Possedere i sorgenti di HL2 e' illegale.
'azz ... per fortuna alle 17:00 in punto me ne vado ....
e non vado certo a casa a connettermi ad internet ;)
ma come fanno certi personaggi a scrivere dalle 7:00 alle 24:00 ??? oddio, mejo che guardare la TV, in effetti :rolleyes: ma che stai a di, ieri ho scritto solo nel pomeriggio e alla sera... :mbe:
in questi giorni cmq sto parecchio al PC perché studio per gli esami e di tanto in tanto vengo qui a cazzeggiare :p
o non mi sono spiegato o continui a non capire :muro: (tanto per scaldare un po' l'ambiente :p )
sai come funzicano le DirectX ? sicuramente meglio di te ciccio
puoi anche fare un gioco in java, basic o cobol ma se poi usi 'ste benedette dairectics per il video, suono etc, stai usando "indirettamente" il C/C++. no, non stai usando una ceppa: tu usi solo i linguaggi ad alto livello; è questo quello che tutti qui intendono dire, nella programmazione videoludica il C++ scomparirà del tutto (nel senso che esisteranno team totalmente privi di programmatori di basso livello), anche se il C++ continuerà ad essere usato per molto in settori totalmente diversi (system programming, e aridaje)
Quindi, vorrei vedere le prestazioni di ipotetiche DirectX fatte in Java e/o C# devi prima aspettare che Microsoft fornisca framework per programmare drivers in linguaggi ad alto livello, cosa che, se tu ne sapessi qualcosa in merito, non ti sembrerebbe tanto improbabile (anche se in un futuro ancora molto lontano). intanto sono già passati dal C89 al C++ :p
E allora parlo!.
Partite con un linguaggio che offra gli strumenti necessari per adottare una prospettiva orientata agli oggetti e usatelo secondo tale prospettiva.
C'è una convenienza logica (non parlo di superiorità disattendendo il mio stesso invito a dar fuoco alle polveri :D) nella prospettiva orientata agli oggetti che forse a qualcuno sfugge. Con un motto potremmo dire che in un'ottica OO la rappresentazione del problema è la sua soluzione a differenza di altre prospettive in cui la soluzione richiede un passaggio in più, comunemente detto pianificazione.
Tento di dirlo nel modo più chiaro possibile.
Calcolatori e umani rappresentano i fenomeni in modo diverso. Per un calcolatore il mondo è fatto di operazioni su valori immagazzinati in registri di memoria (prospettiva procedurale o imperativa) mentre per gli esseri umani si ritiene che il mondo sia fatto di identità (ambiguamente definite oggetti a mio avvviso) e relazioni tra queste identità.
Un linguaggio che non metta a disposizione gli strumenti per dichiarare identità e relazioni tra identità richiede inevitabilmente (ma proprio non se ne può fare a meno) che lo sfortunato di turno traduca il fenomeno osservato da un punto di vista umano in fenomeno osservato da un punto di vista diverso.
In C, questo punto di vista o è lo stesso del calcolatore (essendo C un linguaggio che supporta una prospettiva procedurale) o è diverso da quello del calcolatore e diverso da quello umano (essendo C un linguaggio che supporta anche la prospettiva funzionale).
In C++ (che farà anche schifo ma è sempre meglio di LUA :D) non è necessario che il problema sia tradotto dalla prospettiva umana ad una prospettiva procedurale o altra intermedia.
Dunque se accettiamo due premesse:
1. la soluzione di un problema è un procedimento composto di rappresentazione (studio umano del fenomeno), pianificazione (passaggio dalla rappresentazione umana a un che di eseguibile), esecuzione e controllo
2. i fenomeni sono compresi dall'uomo come insiemi di identità e di relazioni tra queste identità
allora qualsiasi linguaggio che supporti la dichiarazione e definizione di identità e relazioni tra identità è necessariamente più "economico" di un linguaggio che non offra questi strumenti perchè la pianificazione è ridotta alla mera stesura in codice della rappresentazione umana del fenomeno mentre qualsiasi altro "tipo" di linguaggio richiederebbe inevitabilmente almeno un passaggio in più cioè la traduzione dalla prospettiva umana ad un'altra prospettiva.
Notate bene che non sembra possibile osservare direttamente un fenomeno secondo una prospettiva diversa da quella umana (per un essere umano). La frase "da un certo punto di vista" propriamente intesa significa "traducendo il punto di vista umano ad un altro punto di vista"
Probabilmente dovremmo cercare di spiegare la ragione per cui qualcuno discuta ancora dell'idoneità dell'orientamento agli oggetti ad essere primo argomento di studio per un programmatore. Cosa piuttosto facile se si abbia avuto l'ardire di leggere il malloppo che ho scritto.
Supponiamo ad esempio che qualcuno abbia la bizzarra idea che il succo dell'orientamento agli oggetti non stia nel consentire una traduzione immediata della rappresentazione umana dei fenomeni ma, così per caso, nel polimorfismo oppure nell'ereditarietà.
Supponiamo che nell'insegnare la prospettiva orientata agli oggetti non si parta dal punto di vista umano alla rappresentazione dei fenomeni ma si inizi con la modularità o il data hiding.
A me pare irrevocabile in dubbio che il povero disgraziato che subisse queste lezioni non potrebbe che chiedersi alla fine della storia quale fantomatico vantaggio potrebbe avere dall'usare anzichè variabili e operazioni oggetti e metodi avendo ricevuto la qual strana idea che sarebbe più economico tradurre il suo punto di vista in punto di vista orientato a non si sa cosa per poi farne un programma anzichè tradurre il suo punto di vista in prospettiva procedurale.
E questo vorrei farlo notare chiaramente.
La prospettiva procedurale, quella di un certo C, per intenderci, ha una logica molto facile da comprendere: siccome il computer capisce valori in memoria e operazioni su quei valori noi dobbiamo rappresentargli i fenomeni in forma di valori in memoria e operazioni su quei valori.
Ma altrettando elemetanre è la prospettiva orientata agli oggetti, quella di un certo Java o di un certo C++: siccome in quanto uomo io non rappresento i fenomeni come valori e operazioni su valori scrivo quello che ho pensato e lascio che sia il compilatore ad operare sia la traduzione di prospettiva che la traduzione di simboli.
Quando sentite parlare di "rivoluzione dell'orientamento agli oggetti" è questo che si dovrebbe intendere.
Data hiding, polimorfismo ed ereditarietà sono elementi di una prospettiva che non ha nulla a che spartire con quella umana. Predicarne l'essenzialità è quasi criminale :D.
trallallero
07-06-2006, 13:39
ma come fanno certi personaggi a scrivere dalle 7:00 alle 24:00 ??? oddio, mejo che guardare la TV, in effetti
ma che stai a di, ieri ho scritto solo nel pomeriggio e alla sera... :mbe:
ehm ... non vorrei offenderti facendoti notare che "certi personaggi" potrebbe anche NON riguardarti ;)
egocentrico ? :p
in effetti ogni tanto bazzico su "Attualita, storia, etc ..." e pensavo piu' ai personaggi di quel forum ...
scrivono con una frequenza da capogiro :eek:
sai come funzicano le DirectX ?
sicuramente meglio di te ciccio
non ci vuol molto, io le ho solo studicchiate per fare un giochetto con una palla che rimbalza, ingoiata da botole che si aprono/chiudono e qualche suono/musichetta
... in C++ (Borlan Builder, mitico)
ma ammetto che per una stronzatina del genere sarebbe bastato un C# ... ma anche un C bemolle :rotfl:
ma per me era una scusa per studiare C++
no, non stai usando una ceppa: tu usi solo i linguaggi ad alto livello ...
:blah: :blah: :blah: si si, hai ragione tu :ave:
beh, peccato, mi piaceva il C++, mi manchera :cry:
povero dumaron :rolleyes: ... stara' pensando:
"ma diventero' cosi' anch'io ? :muro: "
beh, io ho da lavorare ... in C++ :p
PGI, tutto molto interessante...
Mi permetto di aggiungere anche che sarebbe opportuno, secondo me, insegnare la programmazione ad oggetti prima a parole ed in modo completamente indipendente da un linguaggio di programmazione... Questo sarebbe l'ideale per dare agli studenti una visione OO dei problemi...
Poi successivamente dargli in mano uno strumento...cioè un linguaggio...
Adesso danno subito in mano lo strumento e spiegano come funziona...con il risultato che gli studenti programmano in modo procedurale anche in Java (questo te lo assicuro, l'ho visto di persona)...
Quindi ricapitolando...lo strumento secondo me non è importante (a meno che non si impari per raggiungere un determinato fine), ma è importante una visione OO dei problemi...senza la quale continueremmo a fare fatica a programmare OO...
'o cionci, e come darti torto! Tant'è che mi capitò tempo fa di accennare in pvt con (Amaronn'? Aragon? ragazzi io già non mi ricordo i nomi, figuratevi i nick :D) al fatto che nel marasma generale quasi sembra che l'orientamento agli oggetti non sia qualcosa un precedente logico dei vari linguaggi OO ma una collezione delle proprietà comuni a questi linguaggi.
Razionalmente assurdo ma c'è una tentazione in questo senso.
ma è importante una visione OO dei problemi...senza la quale continueremmo a fare fatica a programmare OO...
Per mettere un pò di carne al fuoco, aggiungerei questo: :Prrr:
"For those who have wondered: I don't think object-oriented programming is a structuring paradigm that meets my standards of elegance."
"Object-oriented programming is an exceptionally bad idea which could only have originated in California."
E.W. Dijkstra
Per mettere un pò di carne al fuoco, aggiungerei questo: :Prrr:
"For those who have wondered: I don't think object-oriented programming is a structuring paradigm that meets my standards of elegance."
"Object-oriented programming is an exceptionally bad idea which could only have originated in California."
E.W. Dijkstra
sarebbe da vedere anche quando è stata fatta quella dichiarazione ;)
sarebbe da vedere anche quando è stata fatta quella dichiarazione ;)
Al premio Turing del 1972 a quanto sembra...un po' di acqua ne è passata sotto i ponti :D
Al premio Turing del 1972 a quanto sembra...un po' di acqua ne è passata sotto i ponti :D
in effetti con gli strumenti disponibili oggi(refactoring(automatico), pattern, ide grafici, etc), e tutto un altro andare
Il premio Turing lo danno per meriti informatici, non perchè si sia incapaci di dire stupidaggini :D.
Credo che sopra per "eleganza" si riferisse al SUO concetto di eleganza: http://it.wikipedia.org/wiki/Edsger_Dijkstra
Comunque è stato uno dei grandi...
La giustificazione ad ogni costo non rende onore alla grandezza. Artistotele scrisse che il sistema politico ideale è una dittatura di saggi mantenuti da un popolo in ignorante schiavitù.
E' stato un colosso del pensiero umano, ha detto una stronzata, fine.
Allo stesso modo, non è che le parole di Dijkstra trasformino magicamente l'acqua in vino.
Io per aver inventato Algol gli avrei dato 5 anni senza condizionale :D
PGI, di Aristotele ne potevi citare anche di peggiori, per esempio che l'intelligenza risiede nel cuore e che il cervello serve solo a raffreddare il sangue... :rotfl:
ehm... o era Archimede...? :stordita: :doh:
vabbè, io so gnurant :rolleyes:
jappilas
07-06-2006, 16:00
Io per aver inventato Algol gli avrei dato 5 anni senza condizionale :D
no aspetta... prima che lo mettano dentro, ho bisogno che mi spieghi lui il suo metodo per l' ottimizzazione dinamica, mi serve per l' esame di Ricerca Operativa :stordita:
jappilas
07-06-2006, 16:07
ma dai, un kernel iun C++ ??? :rotfl:
ma non lo sanno che ormai i kernels si fanno in Java ??? :O
in realtà se ridefinisci new e delete tramite codice che gestisce la memoria direttamente, non mi pare che manchi molto per appoggiare la progettazione delle strutture dati di un kernel ( microkernel poi ... nemmeno chissà cosa) ;)
In C++ (che farà anche schifo ma è sempre meglio di LUA :D)
Meglio per fare che cosa? :)
Una vanga e' meglio di un martello. Ha senso quest'affermazione senza specificare per fare che cosa?
Guarda come abboccano oggi :D, basta buttare la lenza e plof, ti trovi il pescione attaccato all'amo!
Era una facezia (sottolineata dalla faccina che ride): non so assolutamente niente di LUA.
jappilas
07-06-2006, 17:58
Era una facezia (sottolineata dalla faccina che ride): non so assolutamente niente di LUA.
http://www.lua.org/about.html :)
Hey, si prende tutto alla lettera qui, eh? :D
So dell'esistenza di LUA, l'ho provato (innata curiosità) ma per come la vedo io tentare confronti è una cosa che richiede una conoscenza ed un'esperienza più "intime" di quelle che ho con questo strumento.
(come minimo mi arriva un link alla pagina "Confronto C++ vs. LUA" :D).
Guarda come abboccano oggi :D, basta buttare la lenza e plof, ti trovi il pescione attaccato all'amo!
Era una facezia (sottolineata dalla faccina che ride): non so assolutamente niente di LUA.
E io ho usato la tua facezia per ricordare qualcosa che spesso e volentieri in informatica si dimentica: e' una collezione di strumenti :)
(come minimo mi arriva un link alla pagina "Confronto C++ vs. LUA" :D).
http://mail.python.org/pipermail/python-list/2004-January/202920.html
:D:D:D:D
tomminno
07-06-2006, 21:25
http://mail.python.org/pipermail/python-list/2004-January/202920.html
:D:D:D:D
Tratto dal link:
I ported Lua
(www.lua.org) using the perfectly serviceable C compiler
Tratto da http://www.lua.org/faq.html
Lua is implemented in pure ANSI C, and compiles unmodified in all known platforms
Gira e rigira sempre lì si finisce :D
Ah e chi lo ha mai detto che Java è il linguaggio più portabile?
trallallero
08-06-2006, 12:29
Originariamente inviato da trallallero
ma dai, un kernel iun C++ ???
ma non lo sanno che ormai i kernels si fanno in Java ???
in realtà se ridefinisci new e delete tramite codice che gestisce la memoria direttamente, non mi pare che manchi molto per appoggiare la progettazione delle strutture dati di un kernel ( microkernel poi ... nemmeno chissà cosa) ;)
eccome no! guarda che arrivi tardi, ci sono gia' le classi
JKernel e JSo
figo il metodo public JSo CreateSO()
lo chiami e ... puff! ti crea e restituisce un S.O. ... ad oggetti, ovviamente :D
http://java.sun.com/j2se/1.5.0/docs/api/JKernel :sofico:
eccome no! guarda che arrivi tardi, ci sono gia' le classi
JKernel e JSo
No, arrivi tardi tu :)
http://is5.cs.man.ac.uk/apt/projects/jamaica/os.php
La CPU esegue bytecode e il kernel e' scritto in...? Java.
Further investigation is under way into implementing a complete bootstrap and runtime kernel in Java targetted for Jamaica and other hardware platforms.
trallallero
08-06-2006, 12:50
No, arrivi tardi tu :)
http://is5.cs.man.ac.uk/apt/projects/jamaica/os.php
La CPU esegue bytecode e il kernel e' scritto in...? Java.
Further investigation is under way into implementing a complete bootstrap and runtime kernel in Java targetted for Jamaica and other hardware platforms.
:muro: un kernel in java no! :muro: io scherzavo :eek:
vabbe' ma in Jamaica con tutta l'erba che si fumano potrebbero farlo anche in Cobol :Prrr:
e comunque sul sito non ci posso andare quindi ... non ci credo :O
io saro anche l ultimo dei cani a programmare, ma mi chiedo: "che c e di male se l evoluzione tende ad astrarre e a lavorare a piu alto livello?" la storia dei linguaggi di programmazione e la loro evoluzione si comporta molto come l evoluzione di un cervello umano (ci sono studi che considerano l evoluzione tecnologica come logica conseguenza di quella cerebrale, e io sono quasi fermamente convinto che cio accada per il semplice fatto che la visione antropocentrica dell uomo tende a far modellare delle soluzioni che siano piu vicine al suo modo di pensare)...ripeto, se dagli spinotti intercambiabili si è passati ad assembler ci sara un motivo; se da assembler si è passati a c ci sara un motivo; se da imperativo si sta passando ad oggetti ce ne sara un altro...imho l evoluzione non è una mutua esclusione e non è detto che debba per forza uccidere cio che c era prima; quel che è certo secondo me è che piu passera il tempo e piu si potra scrivere ad alto livello qualcosa di assolutamente valido, lo vedo chiaramente...poi forse non ho capito nulla della vita, ma è la mia idea, e tra l altro per come la vedo il mondo è sempre andato cosi...morale: se non ci fidassimo della lavatrice potremmo sempre lavare i panni a mano, ma oramai penso sia assodato che la lavatrice (alto livello) sia meglio...
trallallero
08-06-2006, 13:08
io saro anche l ultimo dei cani a programmare, ma mi chiedo: "che c e di male se l evoluzione tende ad astrarre e a lavorare a piu alto livello?" la storia dei linguaggi di programmazione e la loro evoluzione si comporta molto come l evoluzione di un cervello umano (ci sono studi che considerano l evoluzione tecnologica come logica conseguenza di quella cerebrale, e io sono quasi fermamente convinto che cio accada per il semplice fatto che la visione antropocentrica dell uomo tende a far modellare delle soluzioni che siano piu vicine al suo modo di pensare)...ripeto, se dagli spinotti intercambiabili si è passati ad assembler ci sara un motivo; se da assembler si è passati a c ci sara un motivo; se da imperativo si sta passando ad oggetti ce ne sara un altro...imho l evoluzione non è una mutua esclusione e non è detto che debba per forza uccidere cio che c era prima; quel che è certo secondo me è che piu passera il tempo e piu si potra scrivere ad alto livello qualcosa di assolutamente valido, lo vedo chiaramente...poi forse non ho capito nulla della vita, ma è la mia idea, e tra l altro per come la vedo il mondo è sempre andato cosi...morale: se non ci fidassimo della lavatrice potremmo sempre lavare i panni a mano, ma oramai penso sia assodato che la lavatrice (alto livello) sia meglio...
io non son un C ... ista convinto, non voglio fare solgan del tipo "C e' meglio" o scemenze del genere. Di solio scherzo :D
Ma qui stiamo parlando di creare del codice macchina con un linguaggio che crea del byte code che dovra' essere interpretato :eek:
Se ci si riesce ben venga, ma non riesco a capire come sia possibile :confused:
Hanno fatto un processore apposta ? il kernel carica una vm ?
Il Java NON puo' scendere di livello come ad esempio il C col quale
scrivi anche in assempler: asm { ...}
Mi manca almeno un anello alla catena ...
Prendo il tuo esempio, immagina una pubblicita che ti dice:
da oggi la nuova lavatrice Pippo! non devi piu' mettere il sapone! se lo crea lei!
a me verrebbe un dubbio :eek:
e magari: da domani non servira' neanche l'acqua, la crea!
:eek:
esattamente, sicuramente prima o poi (ma per il tuo esempio si parla di moltissimi anni) troveranno il modo di sintetizzare qualsiasi cosa partendo da un mucchietto di carbonio, non è difficile da immaginare...cio di cui ho parlato pero è molto piu terra terra; non esiste solo java e il suo bytecode ad alto livello, anzi il java e uno dei linguaggi "piu nuovi", a sua volta frutto di una concezione fra le piu "nuove" per quanto riguarda la programmazione; per me non è affatto difficile ipotizzare un futuro (o evoluzione di un presente) linguaggio ad alto livello (magari anche piu di un java o di un c++) che, grazie alla ricerca, sia in grado di svolgere le stesse funzioni ma in maniera molto piu facile da capire e produrre per il nostro cervello...alla fine si tratta solo di quello: rendere human-like una cosa che è tutto fuorche quello e farlo per passi successivi...è quello che è sempre accaduto e che accade tutt ora, altrimenti staremmo ancora giocando col pong invece che con motori fotorealistici che simulano comportamenti sempre piu vicini a quella realta che NOI umani percepiamo...l idea del semplificare qualcosa aggiungendo un substrato che fitti le nostre esigenze è secondo me validissima, tant è vero che il mondo si muove in quella direzione (automazione, miniaturizzazione, multifunzionalita,...); quindi per quale motivo non dovrebbe essere cosi anche per uno strumento qualsiasi utilizzato per una delle tante attivita umane (il software nel nostro caso)? a riprova della mia ipotesi ci sono persone qui, che sono sicuramente piu dentro la materia di me (ci lavorano), che manifestano le stesse opinioni che io esprimo in maniera intuitiva (quindi generale, perche non posseggo gli strumenti per esporle in maniera tecnica) e che linkano parole di personaggi autorevoli che dicono le stesse cose...
quindi non dico che il basso livello non ha senso di esistere, dico solo che piu passera il tempo e piu sono convinto che si escogiteranno sistemi per lavorare piu ad alto livello ottimizzando la gestione delle stratificazioni inferiori (un po come l esempio che hai fatto scherzosamente del metodo getOs che restituisce un os gia fatto); sul fatto che questo sia impossibile attualmente concordo pienamente con te, ma solo perche non siamo ancora al livello evolutivo giusto; cio pero non significa che la "direzione in cui lavorare e in cui stanno lavorando tutti" non sia quella
Ma i linguaggi non scendono da nessuna parte. Qui qualcuno dovrebbe iniziare a dare un'occhiata al patterson-hennessy.
Se in Smalltalk creo un oggetto che si chiama "MachineAdd" e gli do due metodi, add: R1 with: R2 che fa una somma di due registri e toMachineCode: binaryStream che scrive in un flusso i bit
1000110010100000
ditemi cosa mi impedisce di usare Smalltalk per fare un sistema operativo, driver annessi e connessi, senza scrivere una parola di assembly.
Perchè non si fa? Per me è semplicissimo. Hanno investito ottantanni e stramiliardi nell'approccio procedurale e perdiana non cambieranno strada finchè non abbiano spremuto ogni goccia di soldo possibile e immaginabile in quella tecnologia. Guardate l'architettura dei processori, abbiamo lo x86 che fa schifo e piuttosto che mollarla facciamo i processori che traducono internamente i CISC in RISC.
trallallero
08-06-2006, 14:25
esattamente, sicuramente prima o poi (ma per il tuo esempio si parla di moltissimi anni) troveranno il modo di sintetizzare qualsiasi cosa partendo da un mucchietto di carbonio, non è difficile da immaginare...cio di cui ho parlato pero è molto piu terra terra; non esiste solo java e il suo bytecode ad alto livello, anzi il java e uno dei linguaggi "piu nuovi", a sua volta frutto di una concezione fra le piu "nuove" per quanto riguarda la programmazione; per me non è affatto difficile ipotizzare un futuro (o evoluzione di un presente) linguaggio ad alto livello (magari anche piu di un java o di un c++) che, grazie alla ricerca, sia in grado di svolgere le stesse funzioni ma in maniera molto piu facile da capire e produrre per il nostro cervello...alla fine si tratta solo di quello: rendere human-like una cosa che è tutto fuorche quello e farlo per passi successivi...è quello che è sempre accaduto e che accade tutt ora, altrimenti staremmo ancora giocando col pong invece che con motori fotorealistici che simulano comportamenti sempre piu vicini a quella realta che NOI umani percepiamo...l idea del semplificare qualcosa aggiungendo un substrato che fitti le nostre esigenze è secondo me validissima, tant è vero che il mondo si muove in quella direzione (automazione, miniaturizzazione, multifunzionalita,...); quindi per quale motivo non dovrebbe essere cosi anche per uno strumento qualsiasi utilizzato per una delle tante attivita umane (il software nel nostro caso)? a riprova della mia ipotesi ci sono persone qui, che sono sicuramente piu dentro la materia di me (ci lavorano), che manifestano le stesse opinioni che io esprimo in maniera intuitiva (quindi generale, perche non posseggo gli strumenti per esporle in maniera tecnica) e che linkano parole di personaggi autorevoli che dicono le stesse cose...
quindi non dico che il basso livello non ha senso di esistere, dico solo che piu passera il tempo e piu sono convinto che si escogiteranno sistemi per lavorare piu ad alto livello ottimizzando la gestione delle stratificazioni inferiori (un po come l esempio che hai fatto scherzosamente del metodo getOs che restituisce un os gia fatto); sul fatto che questo sia impossibile attualmente concordo pienamente con te, ma solo perche non siamo ancora al livello evolutivo giusto; cio pero non significa che la "direzione in cui lavorare e in cui stanno lavorando tutti" non sia quella
io non metto limiti a niente. Cioe', a niente ma che soddisfi il mio senso del "bello".
Se mi dici: un giorno avremo le lavatrici che ci vengono a prendere al lavoro avrei qualche
dubbio ma son sicuro che si potra' viaggiare nel tempo :ops: :)
Questo per dire che son d'accordo su quello che hai scritto ed e' la storia ad insegnarcelo:
programmatori di codice macchina quanti ne esisteranno ancora ? Assembly forse ancora ancora
ma ormai c'e' il C se proprio vuoi sporcarti le mani.
Ma il problema e' un'altro: una lavatrice la capisco, l'ho anche smontata, anzi e' piuttosto semplice come meccanismo. Riesce a simulare, in meglio, il lavaggio a mano grazie ai suoi componenti, circuito integrato (o come si chiama) etc. Un kernel in java non mi va giu' :confused:
e' presto, troppo presto per una cosa del genere, per me, quindi se c'e' qualcuno che sa come e' stato fatto, per favore lo spieghi ... grazie
Puoi rifare una memcpy in C, come ha fatto qualcuno in questo forum, per divertirti o imparare e magari riesci anche a farla piu' permormante di quella standard (ma dubito) perche' il C ti permette di scendere a livello macchina. In Java no! I processori, fino ad adesso, hanno bisogno di un eseguibile, codice macchina per partire quindi non riesco a capire come si sia riusciti (se e' vero) a fare 'sto cacchio di kernel con un linguaggio interpretato.
trallallero
08-06-2006, 14:30
Ma i linguaggi non scendono da nessuna parte. Qui qualcuno dovrebbe iniziare a dare un'occhiata al patterson-hennessy.
Se in Smalltalk creo un oggetto che si chiama "MachineAdd" e gli do due metodi, add: R1 with: R2 che fa una somma di due registri e toMachineCode: binaryStream che scrive in un flusso i bit
1000110010100000
ditemi cosa mi impedisce di usare Smalltalk per fare un sistema operativo, driver annessi e connessi, senza scrivere una parola di assembly.
Perchè non si fa? Per me è semplicissimo. Hanno investito ottantanni e stramiliardi nell'approccio procedurale e perdiana non cambieranno strada finchè non abbiano spremuto ogni goccia di soldo possibile e immaginabile in quella tecnologia. Guardate l'architettura dei processori, abbiamo lo x86 che fa schifo e piuttosto che mollarla facciamo i processori che traducono internamente i CISC in RISC.
e' quello che avevo scritto qualche post fa:
quando cambieranno tecnologia e faranno i processori alla molecola di nutella o all'uranio arricchito toglieremo il C dalle balle .... :cry:
[...] quindi non riesco a capire come si sia riusciti (se e' vero) a fare 'sto cacchio di kernel con un linguaggio interpretato. evidentemente non è interpretato, ma qualche pezzo sarà stato compilato in maniera nativa; dal un programma Java nulla vieta che si possa produrre un exe o un eseguibile ELF, e magari pure un binario puro (che è quello che vuole la macchina all'avvio)
un programma Java nulla vieta che si possa produrre un exe o un eseguibile ELF, e magari pure un binario puro (che è quello che vuole la macchina all'avvio)
In teoria questa cosa la puoi fare senza il supporto Sun, con GCJ...il compilatore Java GNU...
io credo che si intende l'esecuzione di bytecode (o almeno parte di esso) via hardware... è una ca#*@ata?
Xalexalex
08-06-2006, 20:17
Scusate se mi intrometto. Solo per fare i complimenti a tutti per la mole di cose che sapete. Sto imparando più da questa discussione che in 16 anni di vita...
Solo due cosucce:
1) Esiste un manuale di LUA (cartaceo è meglio, inglese è perfetto).
2)Tanto per animare la discussione, io uso Whitespace.
:sofico: :asd:
Comunque se non lo sapevate ancora il linguaggio grafico g di labview è il migliore di tutti!!!! :D
e io che so un pò di programmazione strutturata e quella orientata agli oggetti cosa dovrei fare ora?
e io che so un pò di programmazione strutturata e quella orientata agli oggetti cosa dovrei fare ora? scegliere una strada ed intraprenderla: scegli cosa ti piace fare e studia quali sono gli strumenti più adatti nel tuo settore a livello di linguaggi di programmazione
e io che so un pò di programmazione strutturata e quella orientata agli oggetti cosa dovrei fare ora?
Studiare un pò di programmazione funzionale, così sai un pò di tutto :)
Ti consiglio haskell. Buon viaggio!
Ma qui stiamo parlando di creare del codice macchina con un linguaggio che crea del byte code che dovra' essere interpretato :eek:
Il bytecode (o il CLI in .NET) non viene interpretato :)
Al momento della prima esecuzione di un metodo, il Just In Time compiler lo traduce al volo in codice macchina e questo viene eseguito dalla CPU per la quale non c'e' differenza se quel codice macchina arriva da un bytecode tradotto al volo oppure da un codice C pre-compilato. Dalla seconda esecuzione in poi del metodo, la traduzione non avviene piu'. Sia in Java sia in .NET si puo' precompilare tutto una volta in codice macchina: a quel punto e' del tutto indistinguibile. In .NET puoi fare aritmetica dei puntatori e scrivere ovunque in memoria, ma non solo non e' consigliato, in quel caso l'assembly diventa "non puro" e l'utente puo' decidere di non eseguirlo se non ha certificati.
E' curioso notare come esistono situazioni in cui, attenzione, il codice intermedio in bytecode o CLI e' eseguito piu' velocemente rispetto a codice precompilato!
Guarda questo esempio:
for (int i = 0; i < numero_molto_alto; ++i)
{
if (CalcolaQualcosa() > 0) // 1
{
// esegui molto codice // 2
}
else
{
// esegui poco codice // 3
}
}
Ora immagina che CalcolaQualcosa ritorni nella maggior parte dei casi un valore minore di 0, cosi' la seconda parte del branch viene eseguita spessissimo, il primo branch molto raramente.
Un compilatore C produce codice assembly nello stesso ordine in cui e' scritto il codice, prima il primo branch poi il secondo.
L'esecuzione assomiglia a qualcosa del tipo:
- Entra nel ciclo
- esegui 1, test fallisce
- esegui 3... ma... c'e' molto codice in mezzo... CACHE MISS! Carica la pagina in cui c'e' il codice di 3, esegui
- Ritorna all'inizio del ciclo
Hai un cache miss garantito quasi ad ogni ciclo :)
Il compilatore C non puo' fare assunzioni sul valore ritornato da CalcolaQualcosa() cosi' non puo' scambiare gli if, lo devi fare tu a mano (se te ne accorgi).
Un compilatore JIT puo' farlo invece, perche' conosce quante volte e' preso il branch 1 e quante il branch 2 e puo' girare e impacchettare il codice a suo piacimento durante l'esecuzione: gli basta ricompilare il metodo con il test invertito e i due branch invertiti. Risultato: quel codice in Java/.NET e' piu' veloce che se scritto in C date le premesse :)
A completare il discorso, esistono compilatori C++ che possono fare una cosa simile: si compila l'eseguibile, lo si lancia con ingressi piu' o meno comuni, si raccolgono le statistiche, si ricompila il codice con questi dati in ingresso. Il risultato e' molto simile, se non per il fatto che un JIT puo' riorganizzare quel codice anche se gli input cambiano e non sono comuni durante l'esecuzione. Un compilatore C++ non puo': una volta compilato e fatto il deploy, il codice macchina non cambia piu'.
e' quello che avevo scritto qualche post fa:
quando cambieranno tecnologia e faranno i processori alla molecola di nutella o all'uranio arricchito toglieremo il C dalle balle .... :cry:
Il C o meglio il C++ o l'assembly non lo toglierai probabilmente mai dalle balle. Qualche riga di codice in assembly sara' sempre e comunque scritta. Non e' questo il punto, nessuno sano di mente vuole eliminare i linguaggi a basso livello perche' hanno il loro scopo e il loro utilizzo.
Il discorso non e' qui, il discorso e' quanto codice oggi si scrive in C++ e quanto in linguaggi ad alto livello? Quanto ieri e quanto domani? Spannometricamente, dieci anni fa probabilmente il 90% del codice si scriveva in C/C++, oggi probabilmente solo il 20/30%, domani probabilmente solo l'1%. Il codice restante si scrive con strumenti piu' ad alto livello, piu' produttivi e migliori per quegl'ambiti. Se devo scrivere un inner loop in un task scheduler che deve manipolare direttamente la CPU, oppure del codice di un driver che deve direttamente la GPU, molto probabilmente lo scrivero' in assembly o in C/C++.
trallallero
09-06-2006, 11:32
Non quoto niente perche hai (fek) scritto troppo :)
vedo che sei preparatissimo sull'argomento, io ho solo una forte conoscenza del C/C++, molto intuito e parecchia logica. Ho studiato solo ad un corso privato di 6 mesi, salvandomi tra l'altro dalla fame perche' era un periodo di boom (1998/1999) :eek:
Ma ho fatto i miei bei progettini ;)
So che esistono tools per i programmi scritti in C/C++ che fanno analisi sulle prestazioni, sulle chiamate alle funzioni per riuscire a velocizzare al massimo l'eseguibile (io non li ho mai usati perche' non mi servono :sofico: ) e fino a qui ci siamo, ti seguo. Ma stento a credere che ci sia un qualcosa che lo faccia al meglio in automatico :eek:
Impressionante!
E comunque se mi dici che il programma fatto in java viene convertito in eseguibile allora cambia tutto ;)
PS: cos'e' il CACHE MISS ? :confused:
PS: cos'e' il CACHE MISS ? :confused:
Anche il codice da eseguire e' conservato in memoria da qualche parte e dev'essere prelevato dalla memoria per poter eseguito dalla CPU.
Banalizzando molto, una CPU lavora con un modello di questo tipo:
1) fetch istruzione dalla memoria
2) decodifica istruzione dalla memoria
3) esegui istruzione
Come sicuramente sai, prelevare dati dalla memoria e' un'operazione lenta, allora le CPU fanno il prefetch di un blocco di memoria sapendo che molto probabilmente in futuro eseguiranno un'istruzione conservata vicino all'istruzione correntemente in esecuzione. In questo modo la CPU molto spesso preleva l'istruzione da una memoria molto veloce al suo interno perche' e' stato fatto il prefetch prima e non deve aspettare. Se c'e' un salto (e il salto non e' stato previsto), la CPU deve scartare tutto e andare in memoria centrale ad aspettare la nuova istruzione da eseguire (questo e' un cache miss).
Complica il tutto per CPU superscalari a esecuzione dinamica ed hai un quadro vago di come funziona una CPU :)
In realta' nel mio piccolo esempio di prima le CPU moderne sono in grado di accorgersi che c'e' un salto in corso e prevedere dove andare a pescare la prossima istruzione e farne prima il prefetch evitando il cache miss.
Quello infatti e' un esempio semplificato, puoi complicarlo fino al punto da mandare in crisi l'unita' di branch prediction della CPU e ritrovarti con il codice Java che va 10 volte piu' veloce di quello C in quella particolare situazione.
trallallero
09-06-2006, 12:06
:eek: un pozzo di scienza! :)
vedi perché ti dicevo sempre di chiedere a lui? perché se le cose te le dice lui ci credi; io invece il "pezzo di carta" che ancora devo prendere all'università per ora non ce l'ho, e i miei 8 anni di esperienza non ufficializzati non valgono una ceppa.
Ma non e' vero 71104, i tuoi anni di esperienza valgono eccome. Qui non ho scritto nulla di piu' di cio' che si puo' imparare anche solo leggiucchiando qua e la. Non bisognerebbe credere a nulla in base a chi la scrive, ma solo in base ai contenuti.
trallallero
09-06-2006, 13:03
vedi perché ti dicevo sempre di chiedere a lui? perché se le cose te le dice lui ci credi; io invece il "pezzo di carta" che ancora devo prendere all'università per ora non ce l'ho, e i miei 8 anni di esperienza non ufficializzati non valgono una ceppa.
dai non fare il permaloso :D
Sei tu che dal primo messaggio hai sempre messo in ballo il parere del fek, adesso ti lamenti se gli do ragione ? :Prrr:
E poi e' da un po' che ne "parliamo" e all'inizio gli ho detto "non ti credo" ... poi ha argomentato con dati incontestabili (da me almeno) e voila' ... che faccio ? comincio a cercargli errori di congiuntivo, a criticargli la firma o ad offenderlo come fanno certe persone quando si trovano ... :mc:
Ne sa piu' di me (sicuramente anche tu ma lui spiega meglio :D ) quindi "ascolto" :)
E' l'unico modo per vivere la vita ogni giorno in maniera un po' diversa, imparando, e l'umilta' e' un ingrediente indispensabile ;)
PS: I tuoi 8 anni di esperienza non ufficializzati, se li hai assimilati, vissuti e capiti, valgono tantissimo per te ... non una ceppa ;)
jappilas
10-06-2006, 21:41
i miei 8 anni di esperienza non ufficializzati non valgono una ceppa.
non è vero :)
l' esperienza in certi ambiti è tutto, e può contare più dell' ufficializzazione in se' stessa
pensa solo a questo... ne hai N volte più di me quanto a sviluppo di componenti di sistema ;)
Bene...arrivo come al solito in ritardo.
L'unica cosa che penso di aver capito è che per diventare un game-developer devo:
- imparare il C++ per poter dire so come funzia, senza morirci sopra.
- approfondire in modo approfondito( :D ) C#, .NET, CLI e CLR
- imparare Lua, Phyton e Ruby
Manca niente??
Inoltre mi chiedo: tu fek che lavori con shaders e grafica e devi ottimizzare anche il pelo, vedi la possibilità di non programmare più in C++, ma, che ne so, in C#?? E, secondo la tua opinione, quanto ci vorrà??
jappilas
19-06-2006, 13:20
Bene...arrivo come al solito in ritardo.
L'unica cosa che penso di aver capito è che per diventare un game-developer devo:
...
fek sicuramente risponderà in altro modo, ma la mia impressione è che ancora dipenda dalla SW house:
ad esempio su ArenaNet (makers of GuildWars) trovi
Game Programmer Positions
Some of the skills we seek in our programming staff include the following:
* Extremely fluent in C/C++
* Fanatical about writing optimized, scalable code
* Experience working on a team
* Ability to develop clean abstractions and interfaces
* Proven ability to finish projects
* Strong math skills
* A passion for games
* An ability to work with all types of development staff
Graphics Programmer
Requirements:
* Highly motivated, self starter, creative thinker
* Expertise in current graphics algorithms, data structures, hardware and mathematics
* Reliably able to create good quality, performance-minded code
* Experienced with shader programming
* Knowledge of the Windows programming API
Plusses:
* Previous commercial games development experience
* Ability to work with artists and designers
* Experienced with 3dsMax or Maya
Game Server & Network Programmer Positions
Some of the skills we seek in our programming staff include the following:
* Experience with Client/Server architecture
* Extensive experience with TCP, sockets, and WinSock
* Extensive experience with multithreading
* Ability to engineer robust solutions to hard problems
* Extremely fluent in C/C++
* Fanatical about writing optimized, scalable code
* Experience working on a team
* Ability to develop clean abstractions and interfaces
* Proven ability to finish projects
* Strong math skills
* A passion for games
* An ability to work with all types of development staff
* Three years of professional programming experience (not necessarily in the game industry)
ecc ecc :D
Inoltre mi chiedo: tu fek che lavori con shaders e grafica e devi ottimizzare anche il pelo, vedi la possibilità di non programmare più in C++, ma, che ne so, in C#?
Una bella domanda... pure io mi sono chiesto la stessa cosa: principalmente anche perché nelle dx10 verrà incorporato il supporto al framework 2.0... che guarda caso serve per C# (almeno credo sia indispensabile o no?!).
E' vero anche che le stesse dx10 sono in C++ ma secondo me come aveva detto fek qualche post fa se adesso in una sw house sono in 6-7 programmer C++ in futuro ce ne saranno 1-2 o nessuno perché si riuscirà a gestire il tutto con un linguaggio più alto... C# appunto.
Morale della favola credo che una base di C++ sia necessaria ma che il futuro sarà verso linguaggi tipo C#...
Futuregames
19-06-2006, 22:46
Posso intromettermi senza che mi scanniate? :D
Io vi posto la mia opinione poi vedete voi..
Premetto che conosco Assembly 8086, PHP, SQL, C/C++, VB6, C# un po e Java
-NESSUN LINGUAGGIO E' IL MIGLIORE: questa frase la ritengo importante. Il miglior linguaggio si determina in base al software finale che dobbiamo fare..
-Le societa richiedono un linguaggio obsoleto? Problemi loro voi dovete cercare di proporre soluzioni alternative... Io abito vicino ad una software house che programma in cobol e fortran... Pazzi? no antichi ma se producono lo stesso risultato nello stesso tempo di chi programma in C# sono bravi (o il programmatore di C# è monco)
Prestazioni linguaggi:
-C# vs Java? Se trovo la pag di bench ve la mando cmq C# è più veloce in piu della meta di tests fatti contro Java
-C# vs C++? C++ piu veloce in quasi tutti i tests ma di poco
-Java vs C++: C++ piu veloce
-Assembly vs Qualsiasi altro linguaggio: Assembly vince al 100%
-Ora come ora io dico che il C++ sia un linguaggio quasi perfetto ma piu si facilita la programmazione (OOP ecc) + ne vanno a scapito le prestazioni. Volete prestazioni e nn volete rivali? Assembly... impazzite pure ma avrete un risultato prima o poi. Il fatto principale è preferite programmare in modo efficente per la cpu che utilizzerà il programma o preferite programmare agilmente e con velocita per creare un prodotto finale migliore e senza bugs?
-Ora vi posto il succo: la maggior parte delle librerie che utilizzate con C# sono costruite in c++ il che dimostra che C# utilizza comunque codice compilato via c++ e quindi è veloce quasi quanto quest'ultimo. Il fatto è che rende la programmazione + facile e ad "Alto livello". Il futuro della programmazione è utilizzare + linguaggi per lo stesso scopo: ora come ora si tende ad utilizzare il C#+LUA (linguaggio di scripting) in modo da avere un prodotto finale di qualita ma anche estendibile e riprogrammabile in un certo senso... Quindi non fermatevi alla scelta del linguaggio di programmazione troppo!
Ricordate che non dovete assolutamente "tifare" per un linguaggio di programmazione perchè questo vi porterà fuori strada rispetto al contesto generale :)
Futuregames
19-06-2006, 22:47
scusate ultima cosa: un videogioco non si programma da soli... ci vuole un team che si specializzi in un tema (esempio creazione modelli ecc)
Inoltre consiglio di partire da un motore gia fatto e non dalle DirectX o OpenGL... :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.