Miglior linguaggio per giochi?

[MissaW_RaZ_98]

Qual'è attualmente il miglior linguaggio di programmazione per creare giochi(sia 2d che 3d)?

Grazie :)

[PGI-Bis]

Uno qualsiasi. Tra .NET e Java ci sono più API per creare giochi di quante se ne possano desiderare e le due piattaforme supportano praticamente ogni linguaggio noto e ignoto.

Il problema sono gli assets: modelli, suoni, immagini... è lì che investi la maggior parte del tempo.

[=KaTaKliSm4=]

Uno qualsiasi. Tra .NET e Java ci sono più API per creare giochi di quante se ne possano desiderare e le due piattaforme supportano praticamente ogni linguaggio noto e ignoto.

Il problema sono gli assets: modelli, suoni, immagini... è lì che investi la maggior parte del tempo.

Se parliamo del "MIGLIOR" linguaggio, il leader indiscusso è il c++, a seguito c# abbinato al framework XNA.

Java non è tra la lista dei migliori linguaggi per giochi 3d (poi dipende pur sempre dal gioco in questione, un conto è snake, un conto è battlefield).

Quoto in toto il discorso sugli assets, se non hai una squadra di grafici in gamba la vedo dura, molto dura.

:)

[ingframin]

Java non è tra la lista dei migliori linguaggi per giochi 3d

Come giustamente ci insegna Minecraft :doh:

Il problema non e' il linguaggio il problema e' il programmatore.
Fare un gioco e' dannatamente difficile, farlo divertente lo e' ancora di piu'.

Quindi, se vuoi fare giochi, parti da questo bel thread
http://www.indievault.it/forum/showthread.php?tid=4305

Poi impara un linguaggio qualunque e comincia a codare.
Quando hai qualcosa di funzionante poi pensi all'ottimizzazione.

Tieni presente che Metin2 ad esempio o Cabal sono scritti in python.
Magicka che ha fatto tanto successo e' scritto in C#
Minecraft che pure ha tanto successo e' fatto in java
Tutti i giochi per iphone sono fatti in objective c o c++
Quasi tutti i giochi per pc sono scritti in una combinazione di C++ e Lua o un altro linguaggio di scripting per programmare il gameplay.
Unity usa C#

Quindi...
L'importante non e' il linguaggio ma il team che sviluppa il gioco ;)

[MissaW_RaZ_98]

capisco...quindi la decisione è più soggettiva che oggettiva...

Comunque,se io decidessi di scegliere il c/c++,quale libreria è la migliore,o semmai la più utilizzata? :cool:

Allegro,openGl,etc?

[ingframin]

parti da qui:
http://lazyfoo.net/SDL_tutorials/index.php

[Tommo]

Protip: stai partendo dal lato sbagliato.

Per fare un gioco devi chiederti prima che gioco vuoi fare, e su quali piattaforme (windows, mac, linux, iphone, android, WP7, XBLIG, Flash, www, etc).
Quando sai questo puoi iniziare a scegliere il tool migliore allo scopo tra le decine disponibili, che vanno da UE3.5 a Game Maker al tuo motore scritto a mano in C, a seconda delle tue disponibilità e capacità.

Il linguaggio è una scelta obbligata in questo modo, si tratta semplicemente di imparare quello che usa il tuo tool preferito :D

OT: Java non è usato affatto nei videogiochi proprio per una questione di tools - non c'è nessun motore grafico per Java, e usare Java significa doversi scrivere un motore OpenGL da 0 insieme a tutti i tools.
Cosa che è stata fatta per Minecraft infatti... ma Minecraft è un gioco del tutto atipico che non avrebbe guadagnato nulla dall'usare un tool esistente tipo Unity o UE3.
Senza contare che una roba scritta in PC-Java gira SOLO su PC, quindi niente mobile (no, nemmeno android) o consoles... brutta faccenda per un dev.
E in più, Java è OpenGL only (mi pare)... ma su windows appena inizi a usare gli shader OpenGL è meglio evitarla alla grande... e questo taglia fuori Java anche dagli AAA per PC.

Riassumendo, le prestazioni di Java sono più che sufficienti al 99% dei giochi, ad oggi, ma è un ecosistema meno adatto ai giochi rispetto a tanti altri.

[MissaW_RaZ_98]

inanzitutto,grazie per le risposte immediate.

Inizio subito col fare un'altra domandina,a cosa servono e cosa sono di preciso i tool?(comunque la piattaforma che voglio usare è windows)

p.s: scusate l'ignoranza :P

[banryu79]

OT: Java non è usato affatto nei videogiochi proprio per una questione di tools - non c'è nessun motore grafico per Java, e usare Java significa doversi scrivere un motore OpenGL da 0 insieme a tutti i tools.

JMonkey Engine (http://jmonkeyengine.com/) (tanto per prenderne uno conosciuto) non è un motore grafico (tra le altre cose)?


E in più, Java è OpenGL only (mi pare)...

Java3D su Windows può girare su Direct3D invece che su OpenGL...

[pabloski]

Comunque è fondamentale avere ben chiaro quali sono le specifiche del gioco che si vuole fare.

In base a quelle si può decidere se java può essere una scelta o meno, se c# va o non va, se bisogna "fare sul serio" e buttarsi su c++.

Stesso discorso per i vari tool, motori grafici e librerie grafiche. Se vuoi realizzare un gioco multipiattaforma directx non lo puoi ovviamente usare. Se fai un gioco solo windows, allora directx può essere una scelta. Se deve girare sugli smartphone, allora opengl es è la tua api di riferimento.

Ma non è detto che devi partire da un livello così basso. Potresti, ad esempio, usare ogre e allora il problema opengl/directx nemmeno si porrebbe.

Il punto è che è tutto molto dipendente da quello che si vuole fare.

Se lo scopo è didattico, allora c++ e directx o opengl. Più a basso livello di così non puoi scendere e imparerai tante cose.

[MissaW_RaZ_98]

Comunque è fondamentale avere ben chiaro quali sono le specifiche del gioco che si vuole fare.

In base a quelle si può decidere se java può essere una scelta o meno, se c# va o non va, se bisogna "fare sul serio" e buttarsi su c++.

Stesso discorso per i vari tool, motori grafici e librerie grafiche. Se vuoi realizzare un gioco multipiattaforma directx non lo puoi ovviamente usare. Se fai un gioco solo windows, allora directx può essere una scelta. Se deve girare sugli smartphone, allora opengl es è la tua api di riferimento.

Ma non è detto che devi partire da un livello così basso. Potresti, ad esempio, usare ogre e allora il problema opengl/directx nemmeno si porrebbe.

Il punto è che è tutto molto dipendente da quello che si vuole fare.

Se lo scopo è didattico, allora c++ e directx o opengl. Più a basso livello di così non puoi scendere e imparerai tante cose.
capisco...ma cosa intendi con basso/alto livello?:what:

[PGI-Bis]

Una delle prime cose che insegnano a legge è la differenza tra fatti e atti. I fatti sono accadimenti naturali, gli atti sono eventi generati dall'intervento umano.
Tra gli esempi di fatti se ne danno generalmente quattro.
Fulmine, pioggia, imbrunire, i motori 3D Java che girano su Android.
Dei tre motori di gioco java più noti (Ardor3D, BonzaiEngine, JMonkeyEngine) ben tre funzionano su android.
Ecco, di fronte ad una casistica del genere io mi domando dove uno possa aver preso l'affermazione "quindi niente mobile (no, nemmeno android)", con un "nemmeno" che suona come un pugno battuto sul tavolo.
Tre su tre. Non due, che uno dice "vabbè, ha beccato l'altro". No.

Ribadisco poi: scegli la lingua che preferesci. Anzi: usa Blender e Python (Komodo come editor, è l'unico passabile che ho trovato). L'accoppiata si presta molto bene a creare almeno un rapido prototipo (sebbene Blender in sè sia in grado di generare ambienti visivamente molto più che prototipali) perchè, nonostante una documentazione orrenda, fonde molto bene l'aspetto logico-digitante con quello grafico.

[=KaTaKliSm4=]

Come giustamente ci insegna Minecraft :doh:


Ma perchè in questo forum, gli utenti tendono a cambiare le carte in tavola?E sopratutto perchè si fa sempre della facile ironia sui post altrui?Sono uno sviluppatore professionista, ne saprò pur qualcosa....

Io NON HO DETTO che in java non si puo programmare un gioco 3D, ma bensi ho detto che "NON E' IL MIGLIOR LINGUAGGIO PER FARLO ED E' BANALMENTE SURCLASSATO DA C++ e da C#(XNA, solo per windows ovviamente)"

L'utente ha chiesto qual'è il "MIGLIOR linguaggio" e senza dubbio alcuno bisogna consigliare C++, ora vediamo se qualcuno ha il coraggio di dire che lo sviluppo gaming è preferibile farlo in Java piuttosto che c++....!Perchè la Valve non ha sviluppato Battlefield in Java?Perchè il 99% delle software house che sviluppano giochi, li sviluppano in c++?Ci sarà un motivo no?

[pabloski]

capisco...ma cosa intendi con basso/alto livello?:what:

quando parlo di basso livello mi riferisco a tutto ciò che implica un maggior lavoro per il programmatore e un'interazione più diretta con l'hardware

alto livello è ovviamente il viceversa

ad esempio se volessi seguire il consiglio di usare python e blender, staresti operando ad un livello molto alto....tutto sarebbe più semplice, avresti molti strumenti preconfezionati e ovviamente i relativi pro e contro

se invece fai un gioco con c++ e opengl/directx, allora stai lavorando al livello più basso umanamente ammissibile per lo sviluppo di giochi....hai più potere, più libertà, più possibilità di ottimizzare, ma fai più lavoro e il tutto è molto più complicato da gestire

ad esempio usare c++ e ogre è già ad un livello più alto del precedente....usare c#/java e un motore grafico è ad un livello ancora più alto

comunque sia è importante valutare il target/piattaforma del tuo gioco, cioè dove vuoi che giri e quali limitazioni in termini di performance, flessibilità, ecc... puoi accettare

un gioco multipiattaforma ha necessità differenti rispetto ad un gioco solo windows o solo macos o solo android

tutto dipende da te e da cosa vuoi ottenere, ovvero vuoi realizzare un gioco senza troppe pretese, un titolo tripla A, vuoi imparare quanto più possibile, ecc....

un gioco discreto si può fare, come suggerisce pgi-bis, con python e blender....fai un bel gioco ( guarda i video su youtube ), lo fai rapidamente, con sforzo minimo e impari pure qualcosa

poi puoi scendere più giù, fin dove t'aggrada

[Tommo]

JMonkey Engine (http://jmonkeyengine.com/) (tanto per prenderne uno conosciuto) non è un motore grafico (tra le altre cose)?

Beh?
Non ho detto che non ci sono, ho detto che ce ne sono pochi e quasi sicuramente inferiori ai motori più famosi, sia come features, sia come supporto della community...
che jMonkeyEngine sia veramente poco usato è un dato di fatto, poi certo chiunque è libero di usarlo se ritiene che sia adatto ai suoi scopi!


Java3D su Windows può girare su Direct3D invece che su OpenGL...

No dai, non si può usare Java3D per un videogioco nel 2012 :asd:

Una delle prime cose che insegnano a legge è la differenza tra fatti e atti. I fatti sono accadimenti naturali, gli atti sono eventi generati dall'intervento umano.
Tra gli esempi di fatti se ne danno generalmente quattro.
Fulmine, pioggia, imbrunire, i motori 3D Java che girano su Android.
Dei tre motori di gioco java più noti (Ardor3D, BonzaiEngine, JMonkeyEngine) ben tre funzionano su android.
Ecco, di fronte ad una casistica del genere io mi domando dove uno possa aver preso l'affermazione "quindi niente mobile (no, nemmeno android)", con un "nemmeno" che suona come un pugno battuto sul tavolo.
Tre su tre. Non due, che uno dice "vabbè, ha beccato l'altro". No.

Questa non la sapevo, ho sempre pensato che il Java di windows fosse di una razza molto differente da quello Android, dato che la maggior parte della libreria cambia... buono :D

[PGI-Bis]

Ci sarà un motivo no?

Questo è sinceramente un grande mistero dell'informatica. Io penso che sia una questione di costi, nel senso che le software house che si occupano di giochi hanno un base di codice C++ così ampia e consolidata che il passaggio ad una tecnologia diversa (non necessariamente Java, francamente a C++ sarebbe preferibile qualsiasi cosa) costerebbe troppo. E' un po' come certi sistemi gestionali di magazzino scritti in cobol tremila anni fa che sono così estesi e così legati alle metodologie dell'impresa che li usa che cambiarli non è materialmente conveniente.

[pabloski]

Però mi sovviene un dubbio. Si parla di linguaggi? Ma in quanto a know-how come stai messo?

[=KaTaKliSm4=]

Questo è sinceramente un grande mistero dell'informatica. Io penso che sia una questione di costi, nel senso che le software house che si occupano di giochi hanno un base di codice C++ così ampia e consolidata che il passaggio ad una tecnologia diversa (non necessariamente Java, francamente a C++ sarebbe preferibile qualsiasi cosa) costerebbe troppo. E' un po' come certi sistemi gestionali di magazzino scritti in cobol tremila anni fa che sono così estesi e così legati alle metodologie dell'impresa che li usa che cambiarli non è materialmente conveniente.

Finalmente un utente che controbatte senza fare dell'ironia...! :)

Beh che a favore di C++ ci sia un vasto know-how da parte degli addetti ai lavori è palese, come è palese anche che Java e C++ sono nettamente differenti a livello prestazionale.

P.S tengo a precisare che il know-how è ASSOLUTAMENTE una discriminante a favore di c++!

[MissaW_RaZ_98]

Però mi sovviene un dubbio. Si parla di linguaggi? Ma in quanto a know-how come stai messo?
a chi ti riferisci?

[pabloski]

a chi ti riferisci?

mi riferivo al tuo background

il punto è che la scelta di un linguaggio diventa quasi ovvia avendo già un background solido ( si sa cosa si vuole e quindi dove andarlo a prendere )

il punto è che pure il discorso del "miglior linguaggio" è molto relativo

nessun gioco di un certo spessore sfrutta un solo linguaggio o è costruito su un singolo linguaggio

[ingframin]

Ma perchè in questo forum, gli utenti tendono a cambiare le carte in tavola?E sopratutto perchè si fa sempre della facile ironia sui post altrui?Sono uno sviluppatore professionista, ne saprò pur qualcosa....

Io NON HO DETTO che in java non si puo programmare un gioco 3D, ma bensi ho detto che "NON E' IL MIGLIOR LINGUAGGIO PER FARLO ED E' BANALMENTE SURCLASSATO DA C++ e da C#(XNA, solo per windows ovviamente)"

L'utente ha chiesto qual'è il "MIGLIOR linguaggio" e senza dubbio alcuno bisogna consigliare C++, ora vediamo se qualcuno ha il coraggio di dire che lo sviluppo gaming è preferibile farlo in Java piuttosto che c++....!Perchè la Valve non ha sviluppato Battlefield in Java?Perchè il 99% delle software house che sviluppano giochi, li sviluppano in c++?Ci sarà un motivo no?

Secondo te a chi parte per voler fare un videogioco a conoscenza quasi zero e il primo problema che si pone invece del gamplay è "qual è il miglior linguaggio per fare videogiochi" può cambiare qualcosa usare Java o C++?
Se poi guardi il tutorial che ho suggerito è quello di Lazy foo su SDL usato in C++.
So bene che per varie necessità il mondo dell'industria videoludica usa C++, ma non è una legge e non credo esista un "linguaggio migliore" in assoluto per i videogames. Notch ha sfornato diversi quattrini con minecraft, quelli di gameforge 3D incassano tranquillamente con giochi in Python e così via, questo voleva essere il senso del mio intervento. Gli assolutismi non portano mai niente di buono.

E comunque tutto è riportato nel thread di Indievault che ho linkato nel mio intervento di prima in cui è spiegato abbastanza bene come partire.

[banryu79]

Perchè la Valve non ha sviluppato Battlefield in Java?Perchè il 99% delle software house che sviluppano giochi, li sviluppano in c++?Ci sarà un motivo no?

Questo è sinceramente un grande mistero dell'informatica. Io penso che sia una questione di costi, nel senso che le software house che si occupano di giochi hanno un base di codice C++ così ampia e consolidata che il passaggio ad una tecnologia diversa (non necessariamente Java, francamente a C++ sarebbe preferibile qualsiasi cosa) costerebbe troppo.
Ha senso.
Un'altra ragione che mi viene in mente è il problema della frammentanzione della RAM e la conseguente neccessità di dover gestire allocazione/deallocazione della memoria in maniera chirurgica.
Nei miei ricordi mi pare lo disse fek proprio in questo forum (da qualche parte).
Vista l'esperienza specifica del tizio, tenderei a fidarmi.

[cdimauro]

Ricordi bene, era quello il motivo principale.

[PGI-Bis]

E' un motivo che mi lascia perplesso perché la gestione della memoria della jvm di Sun è un grosso punto di vantaggio rispetto ai linguaggi non gestiti, non solo perchè libera da un peso superfluo il programmatore ma anche per una mera questione di forza bruta:

http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html

Ed esiste una chirurgia della memoria Java che, ovviamente, funziona in modo diverso e si basa sulla combinazione di parametri del garbage collector e codice - che consiste nel far generare al codice una quantità di "spazzatura" per frame compatibile con le dimensioni della young generation.

Insomma, io sulla questione "memoria" ci andrei coi piedi di piombo.

[pabloski]

C'è anche da dire che i problemi legati alla memoria e al garbage collector sono parzialmente risolti dalla tecnologia hardware.

Non avere la possibilità di deallocare "chirurgicamente" la memoria può portare ad occupare più ram? E quindi? Oggi si viaggia sui 4-8 GB dei pc domestici e oltre.

L'altro problema è il garbage collector che entra in funzione quando la cpu è già troppo impegnata di suo. Ma anche qui i sistemi multicore alleviano enormemente il problema.

Un gioco java multithreaded non vedo perchè dovrebbe soffrire pesantemente queste limitazioni.

Discorso a parte va fatto per i sistemi embedded chiaramente, ma ancora per poco vista la velocità di evoluzione dell'hardware in questo settore.

Il C++ dà vantaggi prestazionali e non ci piove, ma a che prezzo? E il prezzo è giustificabile? A volte si, altre volte no.

[PGI-Bis]

Bisogna comunque considerare il fattore console: si può (o poteva) installare java sulla PS3 ma sulle XBox che io sappia non ci sono stati neanche tentativi.

[pabloski]

Bisogna comunque considerare il fattore console: si può (o poteva) installare java sulla PS3 ma sulle XBox che io sappia non ci sono stati neanche tentativi.

Purtroppo il prezzo della chiusura lo paghiamo un pò tutti.

Per fortuna i gamer si stanno risvegliando e leggo molte critiche portate alle console. Chiramente va stretta la mancata espandibilità, ma soprattutto le politiche commerciali volte a blindare le libertà più essenziali ( come comprare e vendere giochi usati ).

Spero che crollino sotto il peso della loro arroganza.

[banryu79]

Ed esiste una chirurgia della memoria Java che, ovviamente, funziona in modo diverso e si basa sulla combinazione di parametri del garbage collector e codice - che consiste nel far generare al codice una quantità di "spazzatura" per frame compatibile con le dimensioni della young generation.

Ecco, non ricordo bene, bisognerebbe ritrovare il post in cui fek spiegava la faccenda, perchè per la gestione della memoria (prevenire la frammentazione) c'era anche un requisito relativo ad un fatto di timing da rispettare per frame.
E il tutto implicava (mi pare) la neccessità di poter indirizzare direttamente la memoria. Qualcosa così (si lo so che sono molto vago, ma parlo di cose che non conosco, ergo :D).

[cdimauro]

E' un motivo che mi lascia perplesso perché la gestione della memoria della jvm di Sun è un grosso punto di vantaggio rispetto ai linguaggi non gestiti, non solo perchè libera da un peso superfluo il programmatore ma anche per una mera questione di forza bruta:

http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html

Ed esiste una chirurgia della memoria Java che, ovviamente, funziona in modo diverso e si basa sulla combinazione di parametri del garbage collector e codice - che consiste nel far generare al codice una quantità di "spazzatura" per frame compatibile con le dimensioni della young generation.

Insomma, io sulla questione "memoria" ci andrei coi piedi di piombo.
http://www.hwupgrade.it/forum/showpost.php?p=20453765&postcount=330
http://www.hwupgrade.it/forum/showpost.php?p=20472261&postcount=336
C'è anche da dire che i problemi legati alla memoria e al garbage collector sono parzialmente risolti dalla tecnologia hardware.
Questa mi è nuova. Potresti essere più chiaro, cortesemente? Grazie.
Non avere la possibilità di deallocare "chirurgicamente" la memoria può portare ad occupare più ram? E quindi? Oggi si viaggia sui 4-8 GB dei pc domestici e oltre.
Non è quello il problema. Vedi sopra.
L'altro problema è il garbage collector che entra in funzione quando la cpu è già troppo impegnata di suo. Ma anche qui i sistemi multicore alleviano enormemente il problema.
Invece continua a essere un problema, proprio perché non è un'operazione prevedibile, mentre su C++ sì.
Un gioco java multithreaded non vedo perchè dovrebbe soffrire pesantemente queste limitazioni.
Non è una questione di multithreading sì/no, altrimenti (sulla carta) si potrebbe utilizzare qualunque linguaggio che usi il multithread.
Discorso a parte va fatto per i sistemi embedded chiaramente, ma ancora per poco vista la velocità di evoluzione dell'hardware in questo settore.
Cioè?
Il C++ dà vantaggi prestazionali e non ci piove, ma a che prezzo? E il prezzo è giustificabile? A volte si, altre volte no.
Ogni scelta è frutto di compromessi.

Non penso che i programmatori di giochi "di spessore" siano così masochisti da continuare a usare il C++ quando ci sono linguaggi ben più comodi.
Bisogna comunque considerare il fattore console: si può (o poteva) installare java sulla PS3 ma sulle XBox che io sappia non ci sono stati neanche tentativi.
E' un problema degli sviluppatori. Se vuoi, puoi portare la JVM su XBox (anche la prima, per la quale c'è persino Python disponibile :cool:).
Purtroppo il prezzo della chiusura lo paghiamo un pò tutti.
Da quando la PS3 e la Wii sono console "aperte"?

Per caso riesci a farci girare codice non firmato SENZA alcuna modifica?
Per fortuna i gamer si stanno risvegliando e leggo molte critiche portate alle console. Chiramente va stretta la mancata espandibilità, ma soprattutto le politiche commerciali volte a blindare le libertà più essenziali ( come comprare e vendere giochi usati ).

Spero che crollino sotto il peso della loro arroganza.
Dipende tutto dagli utenti, perché il futuro è rappresentato da piattaforme "trusted" anche su PC.

Le console sono un assaggio di quello che vedremo in futuro in termini di tecnologie liberamente utilizzabili per proteggere le proprietà intellettuali di chi ne detiene i diritti.

Ma su questo sono anni che ne discutiamo, in questo forum e in altri posti. ;)
Ecco, non ricordo bene, bisognerebbe ritrovare il post in cui fek spiegava la faccenda, perchè per la gestione della memoria (prevenire la frammentazione) c'era anche un requisito relativo ad un fatto di timing da rispettare per frame.
E il tutto implicava (mi pare) la neccessità di poter indirizzare direttamente la memoria. Qualcosa così (si lo so che sono molto vago, ma parlo di cose che non conosco, ergo :D).
Vedi sopra. ;)

[pabloski]

Questa mi è nuova. Potresti essere più chiaro, cortesemente? Grazie.
Non è quello il problema. Vedi sopra.


ma infatti mi riferivo proprio a quello

la latenza è un fattore che incide sul limite di tempo massimo per svolgere un'operazione

se l'hardware è sufficientemente potente, tale limite verrà rispettato sempre...puoi far girare il garbage collector su un core, mentre il gioco gira sugli altri e allora è come avere un gioco scritto in c++ dal punto di vista delle latenze

è il motivo per cui un banale gioco 2d lo fai in java e nessuno si accorge dei limiti legati alla presenza di un garbage collector


Da quando la PS3 e la Wii sono console "aperte"?


??? io ho detto che sono piattaforme chiuse, mica aperte



Dipende tutto dagli utenti, perché il futuro è rappresentato da piattaforme "trusted" anche su PC.


vedremo

di certo piattaforme castra-rusted non sono tanto tollerate dall'utenza

sony ha accennato alla possibilità di bloccare i giochi usati e si è già giocata il futuro della ps4 e la faccia, oltre ai profitti e ad un bel mucchio di impiegati....ms sembra volerla seguire e probabilmente rimarrà solo wii


Le console sono un assaggio di quello che vedremo in futuro in termini di tecnologie liberamente utilizzabili per proteggere le proprietà intellettuali di chi ne detiene i diritti.

mah, a me sembrano solo un modo per vendere hardware obsoleto a prezzi folli

se vogliono difendere solo i diritti di chi i giochi li fa, devono pure essere pronti a perdere quote di mercato

del resto c'è pure il diritto di un pinco pallino di vendere la copia di un videogioco regolarmente acquistato, di prestarlo ad un amico, ecc....

queste derive fasciste del proteggere tutto e a tutti i costi mi fanno solo ridere

[cdimauro]

ma infatti mi riferivo proprio a quello

la latenza è un fattore che incide sul limite di tempo massimo per svolgere un'operazione

se l'hardware è sufficientemente potente, tale limite verrà rispettato sempre...puoi far girare il garbage collector su un core, mentre il gioco gira sugli altri e allora è come avere un gioco scritto in c++ dal punto di vista delle latenze

è il motivo per cui un banale gioco 2d lo fai in java e nessuno si accorge dei limiti legati alla presenza di un garbage collector
Appunto: un banale gioco. Prendine uno AAA, stracarico di effetti speciali (perché la gente pretende sempre di più), e vedrai che non c'è hardware "sufficientemente potente" che basti già normalmente. Figuriamoci se dovesse mettere nel conto il GC che si attiva chissà quando e non si sa nemmeno quando finisce.

??? io ho detto che sono piattaforme chiuse, mica aperte
OK, era un discorso generale. Mi sembrava avessi fatto distinzione fra le varie console.
vedremo

di certo piattaforme castra-rusted non sono tanto tollerate dall'utenza

sony ha accennato alla possibilità di bloccare i giochi usati e si è già giocata il futuro della ps4 e la faccia, oltre ai profitti e ad un bel mucchio di impiegati....ms sembra volerla seguire e probabilmente rimarrà solo wii
Qual è il problema? Lascia che Sony e Microsoft si suicidino, se pensi che sarà quella la loro fine. :D
mah, a me sembrano solo un modo per vendere hardware obsoleto a prezzi folli
Che c'entra questo?
se vogliono difendere solo i diritti di chi i giochi li fa, devono pure essere pronti a perdere quote di mercato
Lascia che le perdano. Non è ancora meglio per te, che odi tanto le multinazionali brutte e cattive? :O
del resto c'è pure il diritto di un pinco pallino di vendere la copia di un videogioco regolarmente acquistato, di prestarlo ad un amico, ecc....
Cosa non ti è chiaro del fatto che questo diritto ce l'hai SE il produttore te l'ha concesso?
queste derive fasciste del proteggere tutto e a tutti i costi mi fanno solo ridere
Da quando la tutela delle proprietà intellettuali viene configurata come "deriva fascista"?

Posso permettermi di affermare, invece, che la deriva attuale è quella degli scrocconi che vogliono giocare / fruire di contenuti senza pagare i legittimi proprietari?

Immagino che tu propenda di più per la tutela di questi ultimi e non dei primi...

[Tommo]

lol e alla fine è finita a una battaglia sul fatto che Java è veloce come gli altri linguaggi :asd:

Da (recentemente) addetto ai lavori vi assicuro che questo NON IMPORTA A NESSUNO.
Anche perchè le prestazioni pure sono un aspetto che interessa solamente di un tipo di videogiochi (AAA) che compongono una minoranza molto piccola del mercato del lavoro, oggi.
La quasi totalità dei giochi indie, casual, o comunque non AAA ormai gira con una frazione delle risorse di un computer.
Per fare un esempio, il gioco su cui sto lavorando ora (http://playcobalt.com/) è totalmente scritto in Lua, ed è pure complesso per essere un indie game :D

Non a caso HTML5, Flash, Unity, e XNA usano tutti linguaggi e VM che sono più lenti che Java (C# per xbox è lentissimo).
Ma il linguaggio si sceglie sulla base delle possibilità che dà il suo ecosistema, e soprattutto sulla base dei COSTI.
Se Java mi fa spendere più di C#, Java è accannato.
E no, il fatto che jMonkeyEngine sia gratis NON rende Java più economico. Il costo da affrontare per "trainare" uno sviluppatore su una tecnologia sconosciuta e magari non del tutto adatta al progetto è spesso maggiore dei 1500 euri che vuole Unity per la versione pro.

Per cui: il garbage collector è perfettamente compatibile col gaming, e esistono tecniche tipo pooling etc che lo rendono sostenibile anche per giochi decisamente "pesanti" (sebbene a quel punto stai gestendo la memoria a mano esattamente come in C, ma quello è un'altro discorso :D )...
ma la scelta di un tool o di un linguaggio è economica e poco influenzata dalle ragioni tecniche, e sicuramente non è influenzata da quanto il linguaggio è "elegante" :asd:

@pabloski: per cortesia.
Risponderò solo alle boiate più grandi per brevità:


puoi far girare il garbage collector su un core, mentre il gioco gira sugli altri


bella idea! chissà perchè non ci aveva pensato nessuno. Forse perchè così invece che sprecare qualche ms ogni tot sprechi una frazione fissa della potenza della macchina che può arrivare fino al 50% su un dual core :asd:
Inoltre dimostri di essere ignorante su come funziona il multithreading e un garbage collector in generale: mentre il GC gira, deve per forza di cose acquisire i mutex delle regioni di memoria che va a toccare, altrimenti se leggesse/cancellasse oggetti su cui sta operando un'altro thread il programma crasherebbe molto rapidamente :D
Un pò di multithreading si può usare in un GC, ma un momento di pausa nel thread che sta "pulendo" è obbligatorio, e questo significa che un GC, per costruzione, causa lag imprevedibile. C'è poco da fare.


sony ha accennato alla possibilità di bloccare i giochi usati e si è già giocata il futuro della ps4


http://i.qkme.me/3ovqpf.jpg

[pabloski]

Appunto: un banale gioco. Prendine uno AAA, stracarico di effetti speciali (perché la gente pretende sempre di più), e vedrai che non c'è hardware "sufficientemente potente" che basti già normalmente. Figuriamoci se dovesse mettere nel conto il GC che si attiva chissà quando e non si sa nemmeno quando finisce.


mica tanto banale....ci sono giochi discreti che rientrano nella categoria di quelli realizzabili tramite java e soci

come ho detto più sopra, ci sono situazioni in cui è possibile farlo e altre in cui non è proprio possibile, ma sta al progettista valutare

però escludere a priori linguaggi diversi dal c++ è sbagliato

il punto fondamentale è che le latenze di cui parlava fek sono strettamente legate a quanto il gioco richiede in termini di potenza bruta e quanta è in grado di fornirne l'hardware

man mano che il carico di lavoro verrà sempre più spostato verso le gpu, diventerà sempre meno necessario usare il c++

spesso leggo cose tipo "java non è adatto ad applicazioni real-time" o applicazioni che fanno uso intensivo della cpu...questo è parzialmente errato e ci sono vari articoli su developerworks e la stessa sun, in passato, ha cercato di spiegare come loro hanno mitigato il problema e come e cosa fare per rendere java adatto a tali scopi


Cosa non ti è chiaro del fatto che questo diritto ce l'hai SE il produttore te l'ha concesso?

pure lo ius prime noctis era stabilito per legge, ciò non toglie che fosse una porcata

così come lo sono le assurde pretese delle multinazionali del software


Da quando la tutela delle proprietà intellettuali viene configurata come "deriva fascista"?

ma guarda che nel ventennio c'erano tanti leggi, poi definite fasciste, che erano totalmente regolari

tu confondi diritto e giustizia, due cose che quasi mai vanno a braccetto


Posso permettermi di affermare, invece, che la deriva attuale è quella degli scrocconi che vogliono giocare / fruire di contenuti senza pagare i legittimi proprietari?

ci sono scrocconi, ma c'è pure chi paga e vorrebbe garantiti i propri diritti


Immagino che tu propenda di più per la tutela di questi ultimi e non dei primi...

no, io propendo per l'equità

non passa giorno senza dover leggere assurdità fasciste come il controllo 24 ore sue di internet, lo spionaggio delle major, le lettere estorsive di Peppermint e soci, le sempre più restrittive eula, ecc...

per fortuna i giudici ancora ragionano http://punto-informatico.it/3498695/PI/News/usa-violare-policy-non-reato.aspx

almeno siamo sicuri di non vederci appioppare un ergastolo solo perchè abbiamo violato un'eula

io sono un vero liberista, loro no

[pabloski]

lol e alla fine è finita a una battaglia sul fatto che Java è veloce come gli altri linguaggi :asd:

no no, facevo solo notare che i problemi imposti da un certo modello di gestione della memoria possono essere minimizzati


Da (recentemente) addetto ai lavori vi assicuro che questo NON IMPORTA A NESSUNO.
Anche perchè le prestazioni pure sono un aspetto che interessa solamente di un tipo di videogiochi (AAA) che compongono una minoranza molto piccola del mercato del lavoro, oggi


quindi sei d'accordo con me che java non è da escludere a priori? e mi riferisco ovviamente a tutti i linguaggi/vm che si trovano nelle stesse condizioni


La quasi totalità dei giochi indie, casual, o comunque non AAA ormai gira con una frazione delle risorse di un computer.


motivo per cui le latenze non sono un problema


Ma il linguaggio si sceglie sulla base delle possibilità che dà il suo ecosistema, e soprattutto sulla base dei COSTI.
Se Java mi fa spendere più di C#, Java è accannato.


occhio però, io non parlavo specificamente di java, ma di tutti i linguaggi che non sono c++


decisamente "pesanti" (sebbene a quel punto stai gestendo la memoria a mano esattamente come in C, ma quello è un'altro discorso :D )...


a quel punto ne vale la pena? direi di no, meglio usare c++, che ha un'ecosistema migliore per lo sviluppo di videogames



Risponderò solo alle boiate più grandi per brevità:


da come hai risposto non mi sembra di aver detto boiate


bella idea! chissà perchè non ci aveva pensato nessuno. Forse perchè così invece che sprecare qualche ms ogni tot sprechi una frazione fissa della potenza della macchina che può arrivare fino al 50% su un dual core :asd:


affermazione molto forzata....


Inoltre dimostri di essere ignorante su come funziona il multithreading e un garbage collector in generale: mentre il GC gira, deve per forza di cose acquisire i mutex delle regioni di memoria che va a toccare, altrimenti se leggesse/cancellasse oggetti su cui sta operando un'altro thread il programma crasherebbe molto rapidamente :D


il che non implica assolutamente l'impossibilità di ridurre le latenze sfruttando le maggiori risorse offerte dall'hardware


Un pò di multithreading si può usare in un GC, ma un momento di pausa nel thread che sta "pulendo" è obbligatorio, e questo significa che un GC, per costruzione, causa lag imprevedibile. C'è poco da fare.


lo so, ma la differenza sta nel prezzo dell'imprevedibilità

prendo lo stesso gioco, lo faccio girare su hardware via via più dotato di risorse di calcolo e misuro il risultato

l'hardware più dotato avrà ridotto le latenze e abbassato l'incidenza di eventi imprevedibili

se così non fosse, la tua affermazione circa la possibilità di usare sistemi gc per sviluppare giochi non si reggerebbe in piedi

la questione è sembra la stessa, ovvero quante risorse richiede il gioco....superata una certa soglia, diventa impossibile realizzarlo tramite sistemi di gestione automatica della memoria senza che si presentino lag randomici e problemi vari

p.s. per capirci meglio


ma un momento di pausa nel thread che sta "pulendo" è obbligatorio, e questo significa che un GC, per costruzione, causa lag imprevedibile

il punto è quanto dura quella pausa e che incidenza ha tale pausa sulla percezione del gioco da parte dell'utente....è questo il motivo per cui un indie lo fai in lua senza problemi e un tripla A no....questione di rapporto potenza hardware/potenza richiesta dal gioco

il concetto di realtime non è assoluto, ma è relativo alla capacità del sistema di calcolo di rispondere in tempi accettabili al mondo esterno....per cui un lag, per quanto imprevedibile, può essere insignificante o meno a secondo del rapporto in questione

[PGI-Bis]

Non concordo con i necro-post citati. Il riassunto delle ragioni è che il gc è deterministico (non capita quando gli pare, ci si potrebbe regolare un orologio) e se ne può tenere matematicamente conto anche in presenza di un sistema estensibile - con gli opportuni interventi in codice, esattamente come occorre scrivere un certo C++ per non mandare tutto in vacca.

[Tommo]

quindi sei d'accordo con me che java non è da escludere a priori? e mi riferisco ovviamente a tutti i linguaggi/vm che si trovano nelle stesse condizioni

Beh, sono d'accordo che Java non può essere escluso per motivi tecnici...
Esistono casi in cui Java è il linguaggio più conveniente, e lì non c'è nessun problema ad usarlo.
Ad esempio io lo uso per tutti i tool del mio motore, dato che sono pc-only e lo conosco già.
C++ mi avrebbe obbligato a rebuildare per ogni OS (e comunque richiede uno sforzo superiore).

Però, rimane che Java è una pessima scelta per fare giochi, per bazzecole come la non-portabilità totale su consoles e IOS (vedi minecraft che è stato riscritto da zero per xbox, android e iphone, con costi piuttosto importanti - fosse stato C++ sarebbe stato molto più facile) e la mancanza di tool affermati e una community di sviluppatori di un certo livello.

@PGI-Bis: il GC sarà pure deterministico, ma non è sincronizzato con la logica dei thread che va a interrompere. Per cui dal "punto di vista" del thread interrotto, il blocco capita in un punto casuale della sua esecuzione, e quindi è essenzialmente casuale.
C'è un modo per chiamare il GC a mano quando c'è tempo?

[PGI-Bis]

Vedi, la prospettiva che adotti è quella di un linguaggio unmanaged.

Suona come un indovinello ma è giusto dire che non puoi chiamare il gc a mano sebbene tu possa stabilire a mano quando interverrà.

Considera il serial collector (il JRE ha cinque diversi tipi di gc quindi il discorso non è generalizzabile) e prendiamo solo la tenured gen per semplicità.
Il serial collector esegue una pulizia completa della tenured gen esattamente quando questa è piena.
La dimensione della tenured gen è controllabile.
Se sai quando monnezza infili in quella regione per ogni ciclo del tuo motore di gioco sei anche in grado di predire con esattezza il momento in cui il gc interviene. E' una questione di mere divisioni.

Non è il garbage collector sia un programma che parte quando vuole lui, fa quello che gli pare... no: ha tempi e modi certi e misurabili e, soprattutto, che dipendono dal codice che scrivi tu.

L'effetto è lo stesso della gestione manuale della memoria C++. Cambia il modo in cui lo ottieni.

[Tommo]

Bon, non lo sapevo.
Rimane sempre il problema che idealmente in un gioco tutti i frame dovrebbero essere quanto più omogenei come sequenza di eventi che vengono eseguiti, e avere un GC che viene lanciato un frame si e 33 no non è un granchè, per quanto sia controllato.

Certo, puoi accoppiare questo tipo di GC a un pooling che elimina le allocazioni a runtime, e poi puoi fare il "clean" quando il gioco cambia "stato", ovvero carica qualcosa.

Però in qualche modo questo dimostra come quando si hanno determinati requisiti il GC è più un impiccio che altro, e poter gestire la memoria a mano è una gran cosa :D
Che poi, personalmente non l'ho mai trovato difficile. Basta usare l'OOP come si deve e ricordarsi di chiamare delete :D

[PGI-Bis]

Qui l'unica cosa che conta è che quando avrò finito il mio FPS coi Mech dovrò tenere i giocatori lontani a bastonate!

Ho quasi finito il modello della parte sotto del primo mech. Quando ho fatto anche gli altri novantanove passo al terreno del primo livello... ci vediamo quando ci vediamo.

[Tommo]

Ma tu invece trovare un artist no eh :D

[PGI-Bis]

Il problema non è l'artist, è l'artist aggratists che manca. Altrimenti avrei già assunto questo:

http://vimeo.com/25352771

[Tommo]

Il problema non è l'artist, è l'artist aggratists che manca. Altrimenti avrei già assunto questo:

http://vimeo.com/25352771

Non ci piove che trovare l'artist aggratis è difficile, ma ci sono parecchi modi... non ultimo frequentare una community di sviluppatori (http://www.indievault.it/forum/) :read: /shamelessspam
Quello che conta è non cercare gente per fare il "tuo" gioco, e dimostrare che l'idea e la programmazione sono cazzute :D

[cdimauro]

mica tanto banale....ci sono giochi discreti che rientrano nella categoria di quelli realizzabili tramite java e soci

come ho detto più sopra, ci sono situazioni in cui è possibile farlo e altre in cui non è proprio possibile, ma sta al progettista valutare

però escludere a priori linguaggi diversi dal c++ è sbagliato
Nel contesto specifico di cui si parlava, il C++ è il linguaggio giusto da utilizzare per le motivazioni che sono state portate.

Infatti fek ha lavorato a giochi AAA. E io, non a caso, ho citato giochi AAA.

E' chiaro che se rilassiamo i requisiti, rientriamo nel discorso che ha fatto Tommo prima e che non fa una piega.
il punto fondamentale è che le latenze di cui parlava fek sono strettamente legate a quanto il gioco richiede in termini di potenza bruta e quanta è in grado di fornirne l'hardware

man mano che il carico di lavoro verrà sempre più spostato verso le gpu, diventerà sempre meno necessario usare il c++
Falso per diverse ragioni:
- le CPU continueranno a essere spremute come un limone perché per diverse tipologie di codice non c'è GPU con tanti core che tenga;
- anche le CPU stanno integrando sempre funzionalità che in precedenza erano appannaggio delle GPU (molti core, e unità SIMD massicciamente parallele);
- anche le GPU si programmano in C++ (vedi CUDA) se si vogliono ottenere certi risultati;
- la latenza è un fattore che è destinato a rimanere.
spesso leggo cose tipo "java non è adatto ad applicazioni real-time" o applicazioni che fanno uso intensivo della cpu...questo è parzialmente errato e ci sono vari articoli su developerworks e la stessa sun, in passato, ha cercato di spiegare come loro hanno mitigato il problema e come e cosa fare per rendere java adatto a tali scopi
Non è adatto per quanto già detto.
pure lo ius prime noctis era stabilito per legge, ciò non toglie che fosse una porcata
Senza dubbio.
così come lo sono le assurde pretese delle multinazionali del software
Qui, logica alla mano, hai fatto il passo più lungo della gamba, perché le due cose non c'entrano niente l'una con l'altra.

Il tuo discorso è viziato dal preconcetto che le multinazionali abbiano delle pretese che tu classifichi aprioristicamente come assurde, quando questa è una presa di posizione individuale e opinabilissima.
ma guarda che nel ventennio c'erano tanti leggi, poi definite fasciste, che erano totalmente regolari
Senza dubbio, ma vedi sopra.
tu confondi diritto e giustizia, due cose che quasi mai vanno a braccetto
No, tu confondi. Punto.

Stai generalizzando su un discorso assolutamente soggettivo, appioppando bollini rossi a chi ti sta antipatico.
ci sono scrocconi, ma c'è pure chi paga e vorrebbe garantiti i propri diritti
Quali? E, soprattutto, sono realmente loro diritti? A che titolo li possono pretendere su prodotti che NON hanno commercializzato loro?
no, io propendo per l'equità
Brutta parola di questi tempi.

L'equità la si ottiene esercitando la libertà di scelta che ha un consumatore. Ne parlo alla fine.
non passa giorno senza dover leggere assurdità fasciste come il controllo 24 ore sue di internet, lo spionaggio delle major, le lettere estorsive di Peppermint e soci,
Vero.
le sempre più restrittive eula, ecc...
Qui, invece, vale quanto scritto sopra: se non ti piace, non compri. Libertà di scelta del consumatore.
per fortuna i giudici ancora ragionano http://punto-informatico.it/3498695/PI/News/usa-violare-policy-non-reato.aspx

almeno siamo sicuri di non vederci appioppare un ergastolo solo perchè abbiamo violato un'eula
Preferisco non aprire quel link. Mi secca leggere PI.
io sono un vero liberista, loro no
Se lo fossi veramente, e mi ricollego a quanto detto prima, dovresti lasciare che sia il mercato ad autoregolarsi, lasciando libertà alle aziende di proporre i LORO prodotti alle LORO condizioni, e ai consumatori di scegliere se acquistarli o meno.

Poiché i primi non possono vivere senza i soldi dei secondi, e questi sono interessati ai prodotti dei primi, la situazione del mercato è destinata ad equilibrarsi.

La condizione è, ovviamente, che le parti siano consapevoli del potere che hanno nelle loro mani. Cosa, purtroppo, tutt'altro che scontata, specialmente per i secondi.
Vedi, la prospettiva che adotti è quella di un linguaggio unmanaged.

Suona come un indovinello ma è giusto dire che non puoi chiamare il gc a mano sebbene tu possa stabilire a mano quando interverrà.

Considera il serial collector (il JRE ha cinque diversi tipi di gc quindi il discorso non è generalizzabile) e prendiamo solo la tenured gen per semplicità.
Il serial collector esegue una pulizia completa della tenured gen esattamente quando questa è piena.
La dimensione della tenured gen è controllabile.
Se sai quando monnezza infili in quella regione per ogni ciclo del tuo motore di gioco sei anche in grado di predire con esattezza il momento in cui il gc interviene. E' una questione di mere divisioni.

Non è il garbage collector sia un programma che parte quando vuole lui, fa quello che gli pare... no: ha tempi e modi certi e misurabili e, soprattutto, che dipendono dal codice che scrivi tu.

L'effetto è lo stesso della gestione manuale della memoria C++. Cambia il modo in cui lo ottieni.
Anche dopo la tua descrizione, rimane il problema dell'indeterminabilità dell'esecuzione del GC.

Il tuo modello funziona nella misura in cui è possibile prevedere in maniera precisa quanti elementi vanno a finire nel GC, e la capienza di quest'ultimo.

Supponendo nota la capienza, non è comunque noto il numero di oggetti che andrà a finirvi.

Il motivo è semplice: un gioco non genera esattamente lo stesso ammontare di oggetti per ogni frame elaborato.

Ma anche se ciò fosse possibile, il GC non si attiverebbe esattamente nello stesso momento per ogni frame, ma in momenti diversi, magari in momenti in cui NON si vorrebbe che si attivasse.

Pertanto Java non è assolutamente paragonabile a C++.

Lo sarebbe nella misura in cui permettesse di impostare la capienza del GC E di abilitare, disabilitare, far eseguire un run/cleanup degli oggetti fino a quel momento collezionati (magari agendo anche sulle diverse generazioni degli oggetti).

A queste condizioni, visto che comunque è possibile stabilire un tetto massimo per il numero di oggetti istanziabili dal gioco per ogni frame, sarebbe possibile impostare una capienza opportuna per il GC, e decidere anche quando fargli eseguire il cleanup, divenendo perfettamente prevedibile allo scopo.

Ma non funziona così. Per cui... amen! Java != C++.

[pabloski]

Un interessante articolo di amd per chiarire un pò di dubbi http://developer.amd.com/documentation/articles/pages/4EasyWaystodoJavaGarbageCollectionTuning.aspx

Continuiamo a parlare di indeterminatezza, latenze, ecc... senza minimamente curarci del carico di lavoro che il gioco da sviluppare richiede all'hardware.

Faccio notare, solo a titolo di cronaca, che java e .net micro framework sono usati in ambito embedded realtime. Penso che questo dato, da solo, possa chiudere la diatriba.

Ripeto, se non so quanto "mi costa" il gioco, allora non posso dire se è meglio java, c++, c#, lua, javascript o che altro.

[cdimauro]

Un interessante articolo di amd per chiarire un pò di dubbi http://developer.amd.com/documentation/articles/pages/4EasyWaystodoJavaGarbageCollectionTuning.aspx
Io mi chiedo se i link che passi prima li leggi oppure no:

Since the compaction can happen at an unpredictable time, your application requirements might not be met.
Continuiamo a parlare di indeterminatezza, latenze, ecc... senza minimamente curarci del carico di lavoro che il gioco da sviluppare richiede all'hardware.
Perché è un discorso che non c'entra nulla con quello di cui si sta discutendo.
Faccio notare, solo a titolo di cronaca, che java e .net micro framework sono usati in ambito embedded realtime. Penso che questo dato, da solo, possa chiudere la diatriba.
Sempre per la cronaca, se non rispettano i requisiti che ho espresso prima, la diatriba continua a rimanere aperta.
Ripeto, se non so quanto "mi costa" il gioco, allora non posso dire se è meglio java, c++, c#, lua, javascript o che altro.
Il costo lo si stabilisce, perché:
1) un gioco è tarato in base a requisiti minimi e massimi;
2) a runtime è possibile eseguire dei test di carico su CPU e GPU per gli scenari peggiori, e tarare l'engine di conseguenza.

Viceversa, il costo di un GC non è determinabile e/o non si può sapere quando si attiverà, ed è il motivo per cui non si sposa con la tipologia di giochi di cui abbiamo parlato finora.

E' chiaro adesso?

[=KaTaKliSm4=]

Io mi chiedo se i link che passi prima li leggi oppure no:

Since the compaction can happen at an unpredictable time, your application requirements might not be met.


Evidentemente non leggono :)

Il discorso è che C++ oltre ad avere una piena libertà nella gestione della memoria (che è piu un bene che un male), è nettamente piu performante di qualsiasi altro linguaggio OOP e questo, è un dato di fatto constatabile perfino in un banalissimo ciclo che incrementa una altrettanto banale variabile, figuriamoci quando bisogna gestire modelli 3D complessi, effetti particolari e complesse elaborazioni per la simulazione della fisica.

Il confronto con minecraft non regge assolutamente, il gioco, tecnicamente parlando, non ha bisogno di grossi requisiti, a differenza di un gioco AAA.

Sembra uno scontro tra tifosi di calcio e non un dibattito tra professionisti/interessati.

P.S riguardo la portabilità : C++, OpenGl e framework QT, niente di piu "portabile", il fatto che Java sia "portabile" anche su piattaforme mobile è uno specchietto per allodole, un motore grafico che ha bisogno di determinati requisiti non può, per forza di cose, girare su dispositivi mobile e questo è un dato di fatto imprescindibile, ma, anche se lo fosse non sarebbe comunque possibile un porting senza la riscrittura parziale del codice.

Tanto per la cronaca : sviluppo la maggior parte dei miei software in C# e spesso mi avvalgo di componenti grafici di 3e parti (vedi DevExpress), vi posso garantire che in un software di media complessità che usa pesantemente elementi grafici e reflection, il calo di prestazioni si sente.

Poi ovvio, in base al progetto si è disponibili ad avere un leggero calo di prestazioni in cambio di altissima produttività, ma l'alta produttività non fa di un linguaggio il "MIGLIOR LINGUAGGIO" in senso assoluto, bensi fa di un linguaggio il "MIGLIOR LINGUAGGIO in QUEL contesto".

[PGI-Bis]

Che Java sia diverso da C++ nessuno sano di mente lo revocherebbe in dubbio ma il punto era, più generalmente, sulla possibilità di ottenere un risultato determinato in termini di tempi da una piattaforma "garbage collected".

A queste condizioni, visto che comunque è possibile stabilire un tetto massimo per il numero di oggetti istanziabili dal gioco per ogni frame, sarebbe possibile impostare una capienza opportuna per il GC, e decidere anche quando fargli eseguire il cleanup, divenendo perfettamente prevedibile allo scopo.

E questo è perfettamente possibile. Lo fa in effetti Brackeen in Developing Games in Java (un vecchio libro per la verità): determina la quantità di spazzatura generata per frame e poi modifica la dimensione della young generation in modo tale da ottenere un intervento del gc a cadenze regolari. Perchè la condizione che attiva il gc (be', uno, quello più semplice e prevedibile) è determinata. Cioè sono tutte determinate ma quella del serial collector è "quando la regione da ripulire non può più essere riempita". E' questo che rende determinabile il momento in cui interviene la raccolta. E' anche il limite, nel senso che io posso fare la previsione se la quantità di spazzatura è costante a prescindere dal numero di oggetti gestiti, il che richiede una qualche forma di pooling "totale".

Che non si usa. Se guardiamo i motori Java esistenti il pooling è sempre limitato alle strutture di base per il calcolo delle trasformazioni (vettori, quaternioni e matrici). Per buone ragioni, in verità in un gioco non è carichi dinamicamente granchè, più che altro trasformi cose che hai già ficcato in memoria durante l'inizializzazione. E la maggior parte delle allocazioni che restano sono "young", una fetta di memoria il cui uso è praticamente gratuito dal punto di vista della garbage collection.

E l'articolo citato giustamente premette:

"One issue to consider with the concurrent collector is that"

[PGI-Bis]

C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
Object p = new Point(i, i);
x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.

[PGI-Bis]

Sui garbage collector del JRE:

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

Qui ci sono tutti (quelli vecchi, che io sappia ne hanno aggiunto almeno un altro). Quello di cui parla l'articolo di AMD è verso la metà. Quello che "raccoglie quando trabocca" è il primo.

[ingframin]

Apro un leggero OT, ho trovato questo sito pieno di benchmark fatto molto bene:
http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php?calc=chart&ifc=on&gcc=on&gpp=on&java=on&ghc=on&csharp=on&sbcl=on

:sofico:

[nico159]

A meno che non utilizzi la JVM commerciale Azul, parlare di un GC pauseless è fantascienza :)

La JVM di Oracle con 3GB di heap ti fa un stop the world di 4 secondi

Ah ovviamente Windows non è supportato da Azul Zing

[PGI-Bis]

Apro un leggero OT, ho trovato questo sito pieno di benchmark fatto molto bene:
http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php?calc=chart&ifc=on&gcc=on&gpp=on&java=on&ghc=on&csharp=on&sbcl=on

:sofico:

Sono tutti benchmark di calcolo, non sulla gestione dinamica della memoria

[PGI-Bis]

A meno che non utilizzi la JVM commerciale Azul, parlare di un GC pauseless è fantascienza :)

La JVM di Oracle con 3GB di heap ti fa un stop the world di 4 secondi

Ah ovviamente Windows non è supportato da Azul Zing

Azul in verità usa un truccone: anzichè far fare una grossa pausa al GC ne fanno fare tante piccole al kernel - tutti i riferimenti nella loro jvm sono protetti da delle barriere in lettura che hanno implementato direttamente nel kernel linux (o una roba del genere). Poi sarà anche un meccanismo migliore, per carità, ma quando dicono che è "pauseless" secondo me raccontano la storia del mago.

[nico159]

C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
Object p = new Point(i, i);
x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.
Uhum? Sto dando uno sguardo e tutti i principali compilatori convertono secondo alcune basi metodi virtual a chiamate dirette
http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx
Virtual Call Speculation – If a virtual call, or other call through a function pointer, frequently targets a certain function, a profile-guided optimization can insert a conditionally-executed direct call to the frequently-targeted function, and the direct call can be inlined.

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
-fdevirtualize
Attempt to convert calls to virtual functions to direct calls. This is done both within a procedure and interprocedurally as part of indirect inlining (-findirect-inlining) and interprocedural constant propagation (-fipa-cp). Enabled at levels -O2, -O3, -Os.

http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/copts/ccpp_options/option_opt-class-analysis.htm
This option determines whether C++ class hierarchy information is used to analyze and resolve C++ virtual function calls at compile time. The option is turned on by default with the -ipo compiler option, enabling improved C++ optimization. If a C++ application contains non-standard C++ constructs, such as pointer down-casting, it may result in different behaviors.

[Tommo]

C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
Object p = new Point(i, i);
x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.

Veramente, ho fatto qualche test e da quello che ho visto le virtual in C++ sono più veloci di una chiamata a metodo normale di Java, mentre il 90% delle chiamate a metodo normali diventano inline e pesano esattamente 0, o al più una misera CALL assembly.
Senza contare che quando il tipo dato è conosciuto a runtime i compilatori moderni inseriscono un "non-virtual-thunk", che sarebbe una chiamata diretta inline alla sottoclasse in questione.

Mentre invece a quanto so in Java ogni metodo è "virtuale", tant'è che non sono stati previsti gli operatori *apposta* per rendere scomodo ai programmatori spammare chiamate a funzione.
Ora la situazione potrà essere pure migliorata, ma dubito seriamente che le chiamate a funzione di Java possano competere con C++.

L'unica cosa di java che è più veloce è la creazione di oggetti sull'heap: in quel codice ce ne sono due a loop (Point e String) e la cosa si sente. Prova a mettere le allocazioni fuori dal ciclo (o anche sullo stack) e vedi chi vince :D

[cdimauro]

Che Java sia diverso da C++ nessuno sano di mente lo revocherebbe in dubbio ma il punto era, più generalmente, sulla possibilità di ottenere un risultato determinato in termini di tempi da una piattaforma "garbage collected".
Ed è per quello che l'ho scritto. Poi è lapalissiano che siano diversi, no? :D
E questo è perfettamente possibile. Lo fa in effetti Brackeen in Developing Games in Java (un vecchio libro per la verità): determina la quantità di spazzatura generata per frame e poi modifica la dimensione della young generation in modo tale da ottenere un intervento del gc a cadenze regolari.
Come fa a modificarne le dimensioni? Da quel che ho visto, puoi modificare alcuni parametri da command line, prima di lanciare la VM, ma non a runtime.

Supponendo di conoscere a priori la dimensione dello spazio che il GC ha riservato alla young generation, l'unico modo che mi viene in mente per far scattare la pulizia è di riempirlo per il numero di oggetti che mancano. Se, fino ad allora, ne ha contanti m che sono finiti nel GC, e la capacità di questo è n (maggiore di m), ne crea altri n - m e li fa finire subito nel GC.
Perchè la condizione che attiva il gc (be', uno, quello più semplice e prevedibile) è determinata. Cioè sono tutte determinate ma quella del serial collector è "quando la regione da ripulire non può più essere riempita". E' questo che rende determinabile il momento in cui interviene la raccolta. E' anche il limite, nel senso che io posso fare la previsione se la quantità di spazzatura è costante a prescindere dal numero di oggetti gestiti, il che richiede una qualche forma di pooling "totale".

Che non si usa. Se guardiamo i motori Java esistenti il pooling è sempre limitato alle strutture di base per il calcolo delle trasformazioni (vettori, quaternioni e matrici). Per buone ragioni, in verità in un gioco non è carichi dinamicamente granchè, più che altro trasformi cose che hai già ficcato in memoria durante l'inizializzazione. E la maggior parte delle allocazioni che restano sono "young", una fetta di memoria il cui uso è praticamente gratuito dal punto di vista della garbage collection.

E l'articolo citato giustamente premette:

"One issue to consider with the concurrent collector is that"
Nemmeno a queste condizioni puoi ottenere lo stesso funzionamento del C++.

A parte il casino di dover eseguire il tracking di ogni singolo oggetto (de)allocato per farti i conti alla fine, il problema principale è che stai supponendo che TUTTI gli oggetti allocati finiscano poi nella young generation, e vengano poi deallocati "forzando la mano" del GC.

Questo non è vero, perché in un frame un gioco non alloca soltanto oggetti che poi "butta via" alla fine. Non è assolutamente così. Lo è per moltissimi oggetti, ma non per tutti.

Ciò significa che ci saranno oggetti che andranno a finire nella young generation e altri nella tenured, e prima o poi il GC verrà attivato anche per questi.

Ma, soprattutto, non è possibile eliminare la frammentazione dell'heap di cui parlava fek nei suoi messaggi, che in Java prima o poi farebbe scattare un'operazione di pulizia generale per ricompattare lo spazio, e anche qui in maniera non deterministica.

Pensaci bene. Se la situazione fosse così semplice come l'hai dipinta finora, in C++ nemmeno servirebbe sbattersi la testa sulla meticolosa scelta di come e dove allocare i diversi tipi di oggetti generati durante un frame. Basterebbe sfruttare un solo allocatore, sfruttando proprio lo stack, e alla fine del frame non ti servirebbe nemmeno fare opera di deallocazione: rimetti a posto lo stack e hai finito, ottenendo peraltro prestazioni impareggiabili (NON deallochi nulla :D).
C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
Object p = new Point(i, i);
x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.
Prima di tutto non è vero che la OOP è fatta tutta di chiamate virtuali: questo è un modello sbagliato perché in Java il buon Gosling ha fatto la minchiatona colossale di decidere che tutti i metodi debbano essere virtuali.
Un metodo dovrebbe essere virtuale quando lo decide il programmatore, quindi in maniera selettiva, quando serve (un'occhiata al Turbo Pascal 5.5 della Borland non avrebbe guastato).
Sia chiaro che pure in Python di default tutti i metodi sono virtuali. Ma è un linguaggio dinamico, ed è nato per fare cose "zozze" (agli occhi di un programmatore abituato a linguaggi staticamente tipati :D).

Ciò detto, l'esempio che hai fornito tu in C++ lo si fa letteralmente volare costruendo un de/allocatore statico (nemmeno su stack: troppa grazia :asd:) che:
- restituisce la stessa area di memoria alla prima chiamata (per Point);
- restituisce la stessa area di memoria alla seconda chiamata (conversione a stringa);
- non fa nulla nella deallocazione (di Point e della stringa).

E Java ci farebbe una figura, diciamo, barbina. :D

Fermo restando che se voglio giocare "più pulito", posso realizzare un de/allocatore più efficiente per la gestione dell'heap.

Perché non si può configurare come "sporca" la soluzione che ho proposto? Perché sto semplicemente sfruttando gli strumenti che C++ mi mette a disposizione per risolvere quel particolare problema. Esattamente come lo sviluppatore di giochi userà più de/allocatori a seconda del tipo di oggetti che sta creando e di come ha bisogno di distruggerli. ;)
Sui garbage collector del JRE:

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

Qui ci sono tutti (quelli vecchi, che io sappia ne hanno aggiunto almeno un altro). Quello di cui parla l'articolo di AMD è verso la metà. Quello che "raccoglie quando trabocca" è il primo.
Ho un perso un mare di tempo a smazzarmelo, ma non c'è proprio nulla che possa risolvere le problematiche che abbiamo affrontato finora. Maremma maiala. :(

@=KaTaKliSm4=: in linea generale concordo. Idem per gli ultimi messaggi. :)

[ingframin]

Sono tutti benchmark di calcolo, non sulla gestione dinamica della memoria

Si lo so, l'ho detto che era un piccolo OT, volevo solo segnalare un sito fatto bene in qualche modo legato alla discussione.

[PGI-Bis]

Supponendo di conoscere a priori la dimensione dello spazio che il GC ha riservato alla young generation, l'unico modo che mi viene in mente per far scattare la pulizia è di riempirlo per il numero di oggetti che mancano. Se, fino ad allora, ne ha contanti m che sono finiti nel GC, e la capacità di questo è n (maggiore di m), ne crea altri n - m e li fa finire subito nel GC.

Questo.

La dimensione delle fette di memoria usate dal GC devi tenerla fissa se vuoi sapere quanto interverrà.

E' la stessa cosa che fai in C++, nel senso di decidere quanto tempo dedicare alla deallocazione nel ciclo di gioco.

Con il collector "seriale" sai che il GC pulisce la young generation quando si riempie. Puoi stabilire quanto è grande la young con XX:NewSize/NewMaxSize. Se la young è grande 100 e il tuo ciclo genera monnezza per 100 ad ogni frame ottieni una pulizia per frame. Se la pulizia impiega 10 millisecondi ecco che spendi 10 millisecondi per frame nella gestione della memoria.

Per quanto riguarda la tenured e la sua frammentazione, certamente farla pulire nel ciclo di gioco ti affonda il framerate. MA, c'è una ma grosso come una casa: non è che stiamo parlando di meccanica quantistica, toh l'oggetto adesso è nella young, adesso è nella tenured e domani chissà.

Cioè qua sembra che i garbage collector siano esseri dotati di vita propria, largamente indeterminati nel loro comportamento...

Se io scrivo un programma maratoneta, io posso anche dire il gc interverrà quando vuole lui, spero ci metta poco e via.

Ma se scrivo un centometrista non posso più usare quella semplificazione: devo andare a vedere come effettivamente funziona.

Io posso scrivere il programma in modo tale che la tenured venga ripulita solo quando passo da un livello ad un altro, posso scriverlo in modo tale che, avendone a disposizione abbastanza, non si verifichi mai una pulizia. E' chiaro che non posso sperare nell'intervento divino.

Gli oggetti che finiranno nella tenured saranno solo quelli che sopravviveranno ad N passaggi del GC nella young, con N determinato dalle impostazioni di esecuzione della JVM.

Non facciamo passare l'idea - che è già passata - che un garbage collector renda tutto facile: è facile se i requisiti del programma sono facili.

Prima di tutto non è vero che la OOP è fatta tutta di chiamate virtuali: questo è un modello sbagliato perché in Java il buon Gosling ha fatto la minchiatona colossale di decidere che tutti i metodi debbano essere virtuali.

Fu per la verità Alan Kay a deciderlo e ci ha pure vinto un Turing (non credo intitolato a "la minchionata colossale"). La programmazione orientata agli oggetti è intimamente vincolata al collegamento dinamico per il semplice fatto che la decisione sull'operazione da eseguire in presenza di un certa richiesta "nominale" (c->faiQuesto) spetta al ricevente che è variabile e quindi non puoi fissarlo a priori. C++ fa l'esatto contrario: tutti i metodi sono collegati staticamente a meno che non diversamente stabilito. E' un'innegabile fotografia: c'è la programmazione orientata agli oggetti, c'è C++ e nella foto si vede C++ che tira un cazzotto nell'occhio della OOP.

Non è che lo faccia perchè gli piace: lo fa per ragioni di performance.

Perché non si può configurare come "sporca" la soluzione che ho proposto? Perché sto semplicemente sfruttando gli strumenti che C++ mi mette a disposizione per risolvere quel particolare problema. Esattamente come lo sviluppatore di giochi userà più de/allocatori a seconda del tipo di oggetti che sta creando e di come ha bisogno di distruggerli

Allo stesso modo il programmatore Java scriverà il codice in modo che il comportamento del GC sia predicibile.

Per quanto riguarda il benchmark la soluzione più semplice sarebbe prendere direttamente il codice (C) dell'allocatore usato dalla JVM per gli oggetti locali - che se non ricordo male è fatto in C e non in C++ perchè alloca sullo stack della funzione o una roba del genere e C++ non lo permette.

[=KaTaKliSm4=]

Si lo so, l'ho detto che era un piccolo OT, volevo solo segnalare un sito fatto bene in qualche modo legato alla discussione.

Non è assolutamente OT, anzi, da quei benchmark si vede chiaramente che c++ è il linguaggio OOP con le migliori prestazioni in senso assoluto.

Sarebbe stato interessante comparare anche C# su runtime .net e non Mono...

[pabloski]

Sarebbe stato interessante comparare anche C# su runtime .net e non Mono...

non lo trovo adesso, ma c'era un post su un blog che confrontava java, c# .net/mono e c++ su linux e windows

su windows .net è più performante di mono, ma mono su linux è più performante di .net su windows

inutile dire che c++ era più performante degli altri e con mia sopresa ( perchè ho sentito dire diversamente da altri ) che gcc è quasi in pari con icc ( icc risultava max il 10% più veloce di gcc ) e molto più performante di vc++

[marco.r]

C++ non è ASSOLUTAMENTE il linguaggio OOP più performante. Anzi, è uno dei peggiori in assoluto.

Perchè l'OOP è fatta tutta di invocazioni di metodi virtuali, gerarchie profonde e allocazioni dinamiche.

Tu prova a fare un ciclo in cui invochi un metodo virtuale che causa l'allocazione e deallocazione di memoria dinamica in C++ e vedi subito.

E non parlo di un paio di volte più lento di Java: parliamo di centinaia di volte più lento. Ma veramente. Tu traduci questo in C++:

int x = 0;
for(int i = 0; i < 10000000; i++) {
Object p = new Point(i, i);
x += p.toString().length();
}
System.out.println(x);

e ti cadono le braccia per terra. Se vuoi fare 1+1, va benissimo. Ma se vuoi un minimo di dinamicità lascialo perdere in partenza.
Nei microbenchmark java vince quanto vuoi, ma all'atto pratico in generale le applicazioni Java sono piu' lente. Intanto perche' per quanto Java come linguaggio possa essere veloce, Java come piattaforma e' piuttosto una ciofeca (performance-wise). D'altra parte e' il prezzo da pagare per avere un'api decisamente piu' fruibile di quelle tipicamente disponibili in C++.
Inoltre, visto che di solito i punti veramente critici per le performance sono pochi, in C++ hai maggiori strumenti per ottimizzarli.
Il codice sopra potresti ad esempio cambiarlo un po' per renderlo a costo zero in termini di heap.


Per tornare al discorso del GC, e' vero che uno puo' adattarne l'uso per diminuire le latenze introdotte (cosa che tra l'altro non e' neanche sempre necessaria per un gioco, vedi la quintalata di giochi flash che trovi su internet...), ma questo va al di la' delle competenze standard del tipico programmatore Java ( C# etc.) ed e' un tipo di attivita' che si avvicina alla gestione manuale della memoria in un linguaggio come C++. Tra star li' a calcolare quanto devo ridimensionare una generazione del GC perche' entri in azione quando voglio e una semplice arena di memoria gestita dalla creazione/cancellazione di un singolo oggetto non vedo grandi differenze di complessita'...

[tecno789]

interessante...mi iscrivo al thread! :)

[marco.r]

Sono tutti benchmark di calcolo, non sulla gestione dinamica della memoria

Si potrebbe provare con qualcosa che vada a toccare molto piu' spesso la memoria. Ad esempio qualcosa tipo creare un albero di ricerca (BR, avl, quel che si vuole) con qualche milionata di oggetti e poi fare una dose massiccia di rimozioni e inserzioni. Dovrebbe dare una idea.

[clockover]

interessante...mi iscrivo al thread! :)

É un po che speravo di poter leggere una discussione del genere ;) posso fare solo da spettatore :D

[MissaW_RaZ_98]

É un po che speravo di poter leggere una discussione del genere ;) posso fare solo da spettatore :D
siete i benvenuti :D

[tecno789]

É un po che speravo di poter leggere una discussione del genere ;) posso fare solo da spettatore :D

eh purtroppo anche io :(

[MissaW_RaZ_98]

eh purtroppo anche io :(
bhè,io neanche mi aspettavo che la mia domanda fosse così "ricca" di risposte :stordita:

Siete grandi raga! :)

[pabloski]

bhè,io neanche mi aspettavo che la mia domanda fosse così "ricca" di risposte :stordita:


la cosa importante credo che sia: "sei riuscito ad avere una risposta accettabile alla tua domanda?"

[LMCH]

D'altra parte e' il prezzo da pagare per avere un'api decisamente piu' fruibile di quelle tipicamente disponibili in C++.

Dipende da cosa si intende per "tipicamente disponibili".

Il vero problema di C++ è che "si adatta troppo bene alle varie esigenze"
e non avendo un azienda dietro interessata a spingere delle librerie standard "complete" di solito si usa "C++ e qualcosaltro".
Bisogna quindi fare lo sforzo in più di fare più attenzione a cosa ci si appoggia in termini di librerie.

[cdimauro]

Questo.

La dimensione delle fette di memoria usate dal GC devi tenerla fissa se vuoi sapere quanto interverrà.
Intanto è da vedere come ciò sia possibile. A quanto pare NON da codice...
E' la stessa cosa che fai in C++, nel senso di decidere quanto tempo dedicare alla deallocazione nel ciclo di gioco.
In C++ posso avere de/allocatori multipli per decidere finemente cosa fare con ogni tipo di oggetto.

In Java posso al più scegliere un tipo di GC, e nemmeno da codice, visto che stiamo parlando di un parametro della virtual machine e non del compilatore.

La differenza fra le due cose è sostanziale.
Con il collector "seriale" sai che il GC pulisce la young generation quando si riempie. Puoi stabilire quanto è grande la young con XX:NewSize/NewMaxSize. Se la young è grande 100 e il tuo ciclo genera monnezza per 100 ad ogni frame ottieni una pulizia per frame. Se la pulizia impiega 10 millisecondi ecco che spendi 10 millisecondi per frame nella gestione della memoria.
Questo potrebbe andare bene se tutti gli oggetti fossero young. Ne parlo meglio dopo.

Comunque in C++ posso anche allocare memoria sullo stack o in maniera statica, e togliere di mezzo i tempi di deallocazione nei casi in cui riconosco che si possa fare. Questo in Java non si può fare.

Parliamo in ogni caso di caratteristiche standard del linguaggio. Niente alchimie con settaggi vari della virtual machine.
Per quanto riguarda la tenured e la sua frammentazione, certamente farla pulire nel ciclo di gioco ti affonda il framerate. MA, c'è una ma grosso come una casa: non è che stiamo parlando di meccanica quantistica, toh l'oggetto adesso è nella young, adesso è nella tenured e domani chissà.

Cioè qua sembra che i garbage collector siano esseri dotati di vita propria, largamente indeterminati nel loro comportamento...

Se io scrivo un programma maratoneta, io posso anche dire il gc interverrà quando vuole lui, spero ci metta poco e via.

Ma se scrivo un centometrista non posso più usare quella semplificazione: devo andare a vedere come effettivamente funziona.

Io posso scrivere il programma in modo tale che la tenured venga ripulita solo quando passo da un livello ad un altro, posso scriverlo in modo tale che, avendone a disposizione abbastanza, non si verifichi mai una pulizia. E' chiaro che non posso sperare nell'intervento divino.

Gli oggetti che finiranno nella tenured saranno solo quelli che sopravviveranno ad N passaggi del GC nella young, con N determinato dalle impostazioni di esecuzione della JVM.
La fai troppo facile. In un gioco servono anche delle informazioni di stato che variano nel tempo (inter-frame) e la cui de/allocazione non è facilmente prevedibile a priori.

Per essere chiari, potresti applicare lo stesso principio su esposto per gli oggetti young, ma significherebbe controllare in un preciso punto del codice (dove ti fa comodo) lo stato del GC, e riempirlo arbitrariamente di oggetti da deallocare in modo farne scattare la pulizia se ti accorgi che lo spazio rimasto potrebbe non essere sufficiente fino alla fine del frame.

La classica cura che funziona, ma ammazza il malato, insomma.

Come ricordava fek, in 10ms bisogna renderizzare un terzo del frame, non perdere tempo a fare da balia al GC...
Non facciamo passare l'idea - che è già passata - che un garbage collector renda tutto facile: è facile se i requisiti del programma sono facili.
In questo caso stai andando a toccare la virtual machine, e non il linguaggio, per cercare di mimare quello che in altri linguaggi (e solo il linguaggio) si fa in maniera semplice, naturale, ed efficiente.

Il martello puoi anche usarlo per intonacare una parete, ma un fracasso lo fa LEGGERMENTE meglio...
Fu per la verità Alan Kay a deciderlo e ci ha pure vinto un Turing (non credo intitolato a "la minchionata colossale").
Non mi risulta che Alan Key abbia inventato la programmazione a oggetti, ma potrei anche sbagliarmi...
La programmazione orientata agli oggetti è intimamente vincolata al collegamento dinamico per il semplice fatto che la decisione sull'operazione da eseguire in presenza di un certa richiesta "nominale" (c->faiQuesto) spetta al ricevente che è variabile e quindi non puoi fissarlo a priori. C++ fa l'esatto contrario: tutti i metodi sono collegati staticamente a meno che non diversamente stabilito. E' un'innegabile fotografia: c'è la programmazione orientata agli oggetti, c'è C++ e nella foto si vede C++ che tira un cazzotto nell'occhio della OOP.

Non è che lo faccia perchè gli piace: lo fa per ragioni di performance.
Basta non confondere la OOP con quello che non lo è.

Per la OOP è necessario il collegamento dinamico, ma ciò non vuol dire che in un linguaggio che supporti la OOP tutto debba essere collegato dinamicamente. Non c'è bisogno di un premio Turing per capirlo.

Un oggetto non deve necessariamente avere tutti i membri polimorfici. Il polimorfismo si applica dove t'interessa modellare il comportamento di un oggetto. Non a membri che possono benissimo essere non dinamici.

In Java è possibile definire membri non dinamici per una classe? Se la risposta è sì, permane l'affermazione di cui sopra: Gosling fece la minchiatona colossale, perché avrebbe dovuto utilizzarli di default, e lasciare al programmatore il compito di definire quelli per cui serve il collegamento dinamico.
Allo stesso modo il programmatore Java scriverà il codice in modo che il comportamento del GC sia predicibile.
Non è certo la stessa cosa, visto che parliamo di mettere le mani ai dettagli della virtual machine. Qualcosa che va al di fuori del mero linguaggio.
Per quanto riguarda il benchmark la soluzione più semplice sarebbe prendere direttamente il codice (C) dell'allocatore usato dalla JVM per gli oggetti locali - che se non ricordo male è fatto in C e non in C++ perchè alloca sullo stack della funzione o una roba del genere e C++ non lo permette.
Gli oggetti che definisci all'interno della funzione e che vengono utilizzati soltanto in quello scope finiscono nello stack, e vengono automaticamente distrutti all'uscita della funzione.

Nessuno m'impedisce di definire un vettore di byte nello stack, e costruirmi un de/allocatore in C++ che lo usi per particolari mie esigenze.

Lo si fa, appunto, nei giochi, quando sai che dovrai allocare al più n oggetti di un certo tipo, che dovranno essere distrutti alla fine dei calcoli, e t'interessa che allocazione e deallocazione siano operazioni velocissime. E hai pure il pregio di non frammentare la memoria...

E' una cosa che in Java non puoi fare. Sic et simpliciter.

E' un esempio dell'enorme flessibilità che il C++ ti mette a disposizione. Difatti il codice hai postato alla fine ha sortito l'effetto opposto, perché non ha fatto che rafforzare quanto già detto. ;)
non lo trovo adesso, ma c'era un post su un blog che confrontava java, c# .net/mono e c++ su linux e windows

su windows .net è più performante di mono, ma mono su linux è più performante di .net su windows
Se trovi il link postalo, perché sarebbe interessante vedere in quali scenari avviene ciò.
inutile dire che c++ era più performante degli altri e con mia sopresa ( perchè ho sentito dire diversamente da altri ) che gcc è quasi in pari con icc ( icc risultava max il 10% più veloce di gcc ) e molto più performante di vc++
Questo già non mi risulta:
http://www.phoronix.com/scan.php?page=article&item=gcc_45_benchmarks&num=1
http://www.g-truc.net/post-0372.html#menu
http://software.intel.com/en-us/articles/intel-composer-xe/#details

Da notare l'ultimo, che è il più recente, e che sfrutta la nota batteria di test SPEC, che è abbastanza corposa ed eterogenea in termini delle varie (tante) tipologie di codice utilizzate.

[ingframin]

Apprezzo sempre queste discussioni, si imparano un sacco di cose... :D
Solo che mentre qui si discute di C++ vs Java rimane il problema di fare giochi.
Anche se ora mi prendo una sputazza in un occhio ritengo che prima di pensare ad ottimizzare il gioco al bit bisognerebbe pensare al gameplay e al tipo di grafica. Fatto ciò si parte, si fa un prototipo funzionante e poi, se il prototipo non va sufficientemente rapido o bisogna aggiungere cose e limare i tempi, si passa all'ottimizzazione.
Ecco perché in una delle mie prime risposte avevo scritto "usa il linguaggio che preferisci".

Non esiste il miglior linguaggio per fare i giochi, questa è la risposta alla domanda originale del thread.

Che C++ vada più veloce di Java è cosa nota (sempre che il programmatore sia all'altezza, altrimenti...), che per fare un gioco serva necessariamente di spremere la macchina all'osso direi proprio di no.
Anche perché, il singolo sviluppatore, difficilmente ti programmerà un AAA, è più facile che ti tiri fuori un Angry Birds ;)

Però continuatela la discussione Java vs C++ che sto imparando più cose qui che nel corso di POO dell'università :D

[cdimauro]

Di un gioco si può benissimo realizzare un modello/prototipo, e si può tranquillamente fare a meno del C++ per questo. Anzi, meglio linguaggi di gran lunga più produttivi. ;)

Riflettendo ancora sulla discussione, il tracking di qualunque cosa in Java non è affatto semplice. Se per una classe che ho scritto ho assoluta cognizione e controllo, lo stesso non si potrebbe dire per le altre, ad esempio quelle del framework.

Se devo convertire un oggetto in stringa, sono sicuro che verrà istanziato esattamente un oggetto? Non si sa. E se in alcuni casi, invece, vengono istanziati n oggetti, in altri casi m, in altri p, ecc.? E magari quel codice non è sotto il mio controllo (leggi: non posso sfruttare il sistema di tracking che ho messo in piedi)?

Dovrei conoscere i dettagli del framework in maniera maniacale, e ciò non mi salverebbe comunque da casi complicati.

Questo non significa che il C++ non sia del tutto esente dalla problematica, ma nel momento in cui posso definire arbitrariamente gli allocatori, vuol dire che posso comunque reindirizzare le allocazioni e le deallocazioni come e dove voglio, e quindi tenere sotto controllo qualunque aspetto del lifetime degli oggetti, probabilmente anche senza conosce alcunché degli internal del framework.

Alla luce di ciò affermare che il GC sia assolutamente prevedibile risulta ampiamente discutibile.

[marco.r]

Che C++ vada più veloce di Java è cosa nota (sempre che il programmatore sia all'altezza, altrimenti...), che per fare un gioco serva necessariamente di spremere la macchina all'osso direi proprio di no.

Ah chiaro, anzi queste discussioni sono principalmente disquisizioni tecniche ("seghe mentali" :D) valide per categorie particolari di programmi, quelli che coinvolgono una qualche simulazione in tempo reale (RTS, FPS...).
In un'avventura grafica (alla Monkey Island), o meglilo ancora uno strategico a turni la cosa conta molto meno. Li' anche se devi aspettare diversi secondi perche' finisca il turno il computer piu' di tanto non ti lamenti.

[pabloski]

Questo già non mi risulta:
http://www.phoronix.com/scan.php?page=article&item=gcc_45_benchmarks&num=1
http://www.g-truc.net/post-0372.html#menu
http://software.intel.com/en-us/articles/intel-composer-xe/#details


onestamente sono 3 link che non dicono niente

il primo confronta 3 versioni di gcc e quindi non lo confronta con icc e vc++

il secondo non dice su che os fa i benchmark....quello che ho visto dal benchmark di cui parlavo è che su windows vincono vc++ e .net, su linux ( con gli stessi benchmark ) gcc e mono impiegano meno tempo di vc++ e .net rispettivamente ( su windows )

magari la differenza dipende dal sistema operativo :D

il terzo link mi pare onestamente un bel pò di marketing.....comunque in moltissimi benchmark, icc arriva ad un 10% di performance in più rispetto a gcc, ma è il massimo che riesce ad ottenere....in media siamo sul 3-5%

trovai pure questo all'epoca http://attractivechaos.github.com/plb/ dove si vede che tra gcc e icc passa ben poca differenza

[MissaW_RaZ_98]

la cosa importante credo che sia: "sei riuscito ad avere una risposta accettabile alla tua domanda?"
si,troppe anche :D

[pabloski]

si,troppe anche :D

l'importante è aver trovato almeno una risposta....troppe però possono creare confusione e riportare al punto di partenza, cioè "che diavolo di linguaggio devo usare?" :D

ma penso che ormai sia chiaro che il linguaggio è l'ultimo dei problemi in questo caso

e c++ ha l'enorme vantaggio di avere tonnellate di codice già pronto

[marco.r]

Questo già non mi risulta:
http://www.phoronix.com/scan.php?page=article&item=gcc_45_benchmarks&num=1
http://www.g-truc.net/post-0372.html#menu
http://software.intel.com/en-us/articles/intel-composer-xe/#details

Da notare l'ultimo, che è il più recente, e che sfrutta la nota batteria di test SPEC, che è abbastanza corposa ed eterogenea in termini delle varie (tante) tipologie di codice utilizzate.

In realta' l'ultimo dice che ICC genera codice tra il 9% e il 12% piu' performante di gcc sotto linux (in determinati test), mentre sotto windows genera codice tra il 21% e il 42% piu' performante di VS2010, quindi e' in linea con quanto diceva pabloski.

[marco.r]

Dipende da cosa si intende per "tipicamente disponibili".

Il vero problema di C++ è che "si adatta troppo bene alle varie esigenze"
e non avendo un azienda dietro interessata a spingere delle librerie standard "complete" di solito si usa "C++ e qualcosaltro".
Bisogna quindi fare lo sforzo in più di fare più attenzione a cosa ci si appoggia in termini di librerie.

Intendo quelle di maggiore diffusione, che facciano parte della libreria standard piuttosto che di librerie terze di maggior diffusione (boost etc.).
Prendi l'I/O ad esempio; in C++ fondamentalmente le due alternative principali sono l'api C classica oppure gli stream. In entrambi i casi se voglio implementare un classe che faccia un qualche filtro (boh, mettiamo una codifica RLE) devo fare molto piu' lavoro che non in Java.

[cdimauro]

onestamente sono 3 link che non dicono niente

il primo confronta 3 versioni di gcc e quindi non lo confronta con icc e vc++
Ho sbagliato a incollare il link. Ecco qui (http://keyj.emphy.de/compiler-benchmark/) quello giusto.
il secondo non dice su che os fa i benchmark....
Al 99,9999999 (periodico) % sarà Windows.
quello che ho visto dal benchmark di cui parlavo è che su windows vincono vc++ e .net, su linux ( con gli stessi benchmark ) gcc e mono impiegano meno tempo di vc++ e .net rispettivamente ( su windows )

magari la differenza dipende dal sistema operativo :D
Il s.o. è invariante: è lo stesso per tutti i compilatori.
il terzo link mi pare onestamente un bel pò di marketing.....comunque in moltissimi benchmark, icc arriva ad un 10% di performance in più rispetto a gcc, ma è il massimo che riesce ad ottenere....in media siamo sul 3-5%
SPEC è un benchmark famosissimo, con centinaia di test e tantissime tipologie di codice.

Se a te non piace per i risultati, beh, non possiamo farci niente.
trovai pure questo all'epoca http://attractivechaos.github.com/plb/ dove si vede che tra gcc e icc passa ben poca differenza
Visto anche questo. Sono pochi, quasi tutti che sfruttano l'ALU, e soltanto in uno è ipotizzabile che vengano sfruttate SSE & compagnia.
In realta' l'ultimo dice che ICC genera codice tra il 9% e il 12% piu' performante di gcc sotto linux (in determinati test), mentre sotto windows genera codice tra il 21% e il 42% piu' performante di VS2010, quindi e' in linea con quanto diceva pabloski.
A lui non stanno bene comunque anche se dipingono una situazione simile a quella che ha citato, semplicemente perché li ho riportati io. :rolleyes:

Comunque sono singolari i benchmark su Windows, perché su questa piattaforma ho visto che generalmente ICC >> VS >> GCC. Le differenze sono abbastanza marcate.

[tecno789]

si,troppe anche :D

ora ti aspetta solo lo studio, matto e disperatissimo :)

[LMCH]

Intendo quelle di maggiore diffusione, che facciano parte della libreria standard piuttosto che di librerie terze di maggior diffusione (boost etc.).

Infatti è li il problema, "librerie standard" mica significa "uniche librerie da utilizzare".
Se una libreria si adatta meglio alle mie esigenze ed è pure multipiattaforma francamente non vedo il motivo per cui uno non dovrebbe usarla.

Il vero problema è che spesso molti conoscono il C++ durante un corso di base in cui si usano al massimo le librerie standard e poi lo confrontano con Java o C# con relative IDE "standard di fatto" e "librerie più o meno standard" molto più polpose.

In altre parole fanno confusione tra linguaggio ed ecosistema di sviluppo software e magari fanno pure l'errore di non cercare oltre quello che gli viene fornito "di serie".

[banryu79]

@MissaW_RaZ_98
Pagine di post (interessantissimi, per carità) ma finalmente ci siamo arrivati:

...ma penso che ormai sia chiaro che il linguaggio è l'ultimo dei problemi in questo caso

e c++ ha l'enorme vantaggio di avere tonnellate di codice già pronto

Proprio per questa ragione forse (forse eh) è più conveniente partire con un linguaggio che non richieda almeno un paio d'anni di pratica costante per imaparare ad utilizzarlo, non dico bene, ma almeno senza farsi troppo male.

A questo punto, tanto per continuare a citare 'sto fek:
http://www.appuntidigitali.it/2506/quale-linguaggio-per-imparare-a-programmare/

[=KaTaKliSm4=]

@MissaW_RaZ_98
Proprio per questa ragione forse (forse eh) è più conveniente partire con un linguaggio che non richieda almeno un paio d'anni di pratica costante per imaparare ad utilizzarlo, non dico bene, ma almeno senza farsi troppo male.


Ma perché si cade costantemente in questi luoghi comuni?Teoricamente ci impieghi più tempo ad utilizzare per bene c# e tutto il corredo .net che C++, in quanto il framework .net e mostruosamente enorme e solo con tempo e dedizione riesci a crearti una mappa mentale grazie al quale puoi sviluppare senza andare a sfogliare ogni 2x3 MSDN.

E poi il topic è molto chiaro : "Qual'è il miglior linguaggio per lo sviluppo di videogame?", per prestazioni,ecosistema e libertà nella gestione della memoria vince C++, e la cosa difficilmente si può discutere.

Inoltre, tendo a precisare una cosa che mi sta "particolarmente a cuore" : inculcare ai novelli programmatori che C++ è il male e C#/Java/Python/etc siano il bene è sbagliato quanto ridicolo, mi spiego meglio :

- C#, VB.Net e tutto l'ambaradam sono stati scritti in C++, con il tempo alcune parti del compilatore sono state riscritte in C#;

- La VM Oracle è interamente scritta in C++,

- Python è scritto in C (Probabilmente anche C++ ma potrei sbagliarmi),

C# e Java in particolare hanno una sintassi C++ like, quindi mi chiedo, perché non portare i novellini a studiarsi un po di sano C++???Perché non far capire alla gente cosa c'è sotto un GC?E' imbarazzante vedere "programmatori" persi difronte all'inesistenza del tipo String (tanto per dire una banalità) o stupefatti di fronte alla deallocazione "manuale" delle risorse o peggio ancora intontiti dalla sola definizione di "puntatore", c'è gente che continua a chiedere perché passando una property ad un metodo e modificando i campi dal metodo stesso le modifiche vengano apportate anche alla property passata come argomento (:( vi giuro che capita spessissimo).

Quindi, se qualcuno dovesse incominciare, incominciasse con il C++ per poi passare a linguaggi più produttivi....non ve ne pentirete assolutamente.

[banryu79]

Ma perché si cade costantemente in questi luoghi comuni?Teoricamente ci impieghi più tempo ad utilizzare per bene c# e tutto il corredo .net che C++, in quanto il framework .net e mostruosamente enorme e solo con tempo e dedizione riesci a crearti una mappa mentale grazie al quale puoi sviluppare senza andare a sfogliare ogni 2x3 MSDN.

Guarda, per me il luogo comune è proprio il contrario. Comunque.
Ho anche linkato il post di fek proprio per mettere la cosa in prospettiva.
Poi forse son io che non ho capito la domanda dell'utente: io ho capito che lui è prima di tutto interessato a capire quale è il "miglior" linguaggio per programmare videogiochi per se stesso, non per i professionisti dell'industry.
Il mio post qui sopra è basato su questa premessa.
Se la tua critica alla mia opinione resta per te valida tenuto conto di questa stessa premessa, allora, nel mio piccolo, non concordo; altrimenti parliamo di due cose diverse.


Quindi, se qualcuno dovesse incominciare, incominciasse con il C++ per poi passare a linguaggi più produttivi....non ve ne pentirete assolutamente.
Guarda, io iniziai con C, passai poi a C++, approdai a Java, con il quale, per le mie esigenze quotidiane, mi son trovato sempre bene.
Ho studiacchiato anche altro, ma mai in modo approfondito.
Non ho una preparazione accademica, ho molte lacune, ho imparato da autodidatta e non posso certo definirmi un programmatore nel senso proprio del termine: smanettone al massimo.
Nonostante abbia quindi relativamente poche conoscenze, mi sento lo stesso in grado di poter non consigliare il precorso che ho fatto. Questo in generale.

[=KaTaKliSm4=]

Guarda, per me il luogo comune è proprio il contrario. Comunque.
Ho anche linkato il post di fek proprio per mettere la cosa in prospettiva.


Con tutto il rispetto per fek, ma la sua opinione vale come tutte le altre opinioni, è una semplice e soggettiva dichiarazione come tante altre, basta leggere i commenti e noterai che un'altissima percentuale di utenti non è d'accordo con lui...


Poi forse son io che non ho capito la domanda dell'utente: io ho capito che lui è prima di tutto interessato a capire quale è il "miglior" linguaggio per programmare videogiochi per se stesso, non per i professionisti dell'industry.
Il mio post qui sopra è basato su questa premessa.
Se la tua critica alla mia opinione resta per te valida tenuto conto di questa stessa premessa, allora, nel mio piccolo, non concordo; altrimenti parliamo di due cose diverse.


Cit. 1° post :

"Qual'è attualmente il miglior linguaggio di programmazione per creare giochi(sia 2d che 3d)?

Grazie"

Si parla del "miglior" linguaggio in senso assoluto, e non del miglior linguaggio basato sul suo know-how.


Guarda, io iniziai con C, passai poi a C++, approdai a Java, con il quale, per le mie esigenze quotidiane, mi son trovato sempre bene.
Ho studiacchiato anche altro, ma mai in modo approfondito.
Non ho una preparazione accademica, ho molte lacune, ho imparato da autodidatta e non posso certo definirmi un programmatore nel senso proprio del termine: smanettone al massimo.
Nonostante abbia quindi relativamente poche conoscenze, mi sento lo stesso in grado di poter non consigliare il precorso che ho fatto. Questo in generale.

Fammi capire : ai bambini si insegna prima ad utilizzare la calcolatrice, o si insegna a fare le divisioni a manina?Presumo la 2°...e allora per quale motivo a scopi didattici e non, uno dovrebbe evitare "l'oscuro" C++???E' un po come dire : non fate le divisioni con carta e penna, tanto c'è la calcolatrice che le fa per voi!Datemi una motivazione logica ma sopratutto VALIDA del perché non si dovrebbe consigliare c++!Il fatto che sia + "complicato" di java e simili è solamente una scusa utilizzata da gente svogliata e parecchio chiusa mentalmente.

Anch'io non utilizzo C++ nella mia quotidianità lavorativa in quanto se lo utilizzassi avrei un calo di produttività indicibile ma ciò non implica che C++ sia un linguaggio da evitare.

Ti faccio un'esempio : sviluppo di un software di teleassistenza in .net, il seguente listato fa parte di un metodo che cattura una bitmap del cursore a schermo :


...
...
int stride = imgData.Stride;
IntPtr scan0 = imgData.Scan0;
unsafe
{
byte* pByte = (byte*)(void*)scan0;
for (int h = 0; h < height; h++)
{
for (int w = 0; w < width; w++)
{
int offset = h * stride + w * numBytesPerPixel + 3;
if (*(pByte + offset) == 0)
{
*(pByte + offset) = 60;
}
}
}
}
img.UnlockBits(imgData);
...
...

Se non hai conoscenze sui puntatori (in generale) questo blocco non riesci neanche a leggerlo a voce alta...figuriamoci a capirlo, quindi di che stiamo parlando?Di formare sviluppatori mediocri che saranno un peso in un team e non un vantaggio?Se questo è quello che volete fate pure!

P.S La mia non è assolutamente una critica, in un forum c'è dibattito e io espongo semplicemente le mie idee :)

[banryu79]

@=KaTaKliSm4=
Guarda, sarà l'autore del thread a stabilire cosa gli interessa.
Se ho capito male ho capito male, però ho esplicitato le premesse ai consigli che do, e le ragioni (rinvio al post di fek).

Che una opinione sia soggettiva siam tutti d'accordo credo (altrimenti l'opinione non sarebbe più tale); e penso siamo d'accordo anche sul fatto che se oltre ad esprimere un'opinione uno riporta anche la o le ragioni che la supportano è pure meglio.

Ripeto: io ho espresso la mia opinione sulla base della mia esperienza (e in quanto tale, limitatissima, non ho nessun motivo per nasconderlo) e ho riportato almeno anche un altro riferimento (il post di fek) a me esterno nel quale trovo opinioni e ragioni che le supportano che trovo affini alle mie. Non tutte, ma la maggioranza sì.

Il fatto che fek sia fek non ne fa un dio in terra, ovviamente, ma ti faccio notare che l'autore del thread, con ogni probabilità, non sa chi è fek e cosa ha fatto, quindi quando va a leggere il contenuto di quel link può giudicare le opinioni la espresse al netto del "peso" dei nomi di chi le esprime.

Proprio per la mancanza di esperienza diretta in materia, l'utente del thread farà comunque fatica, a capire in quale "ecosistema tecnologico" (linguaggio piattaforma framework ecc..) collocarsi anche dopo aver sentito le nostre opinioni, e ci credo: come fai a scegliere gli strumenti giusti per il tuo lavoro, quando non sai ancora di preciso qual'è?

A questo punto uno non può far altro che considerazioni generiche e dare consigli di massima.

Stabilito che per una certa tipologia di videogiochi sia quasi da tutti ritenuto neccessario, o più adatto l'utilizzo di C++ come linguaggio (tra l'altro nella discussione è emerso che C++ lo è per certe problematiche precise del motore grafico, e un videogioco è fatto anche di altro) vogliamo dirgli anche che non esiste solo quello, e che dire videogioco è dire tutto e niente?

In ogni caso, citandoti:

Il fatto che sia + "complicato" di java e simili è solamente una scusa utilizzata da gente svogliata e parecchio chiusa mentalmente.

Non è molto carino dire una cosa del genere.
Se non altro io ho sempre detto che riporto la mia esperienza, e nel dare la mia opinione non ho mai offeso quelli (come ad esempio te) che la pensano diversamente.

[pabloski]

fek ha ragione su un punto fondamentale e cioè il fatto che i linguaggi sono strumenti e nulla più

lui non esclude c++, c, assembly o che altro a priori, ma contestualizza la scelta di un linguaggio

esempio banale...viene da me un tizio che mi dice che vuole imparare a programmare, nel senso di capire la logica non nel senso di capire la macchina

cosa gli posso consigliare oggi? sicuramente gli consiglierò python o un linguaggio simile

se però il tipo viene da me e mi dice che vuole apprendere i segreti che stanno dietro la macchina, io gli consiglierò ( oltre ad un serio studio dell'architettura dei calcolatori ) assembly o c

imho è questo il problema che sta dietro la domanda iniziale di questo thread, cioè la relatività del termine "miglior linguaggio per i giochi"

se in informatica esistessero cose migliori in generale, avremmo quadrato il cerchio e non avremmo le os war, le browser war, le language war, microkernel contro monolitici, erlang contro google go ( no, questa per fortuna non c'è :D )

[cdimauro]

Visto che non esiste un linguaggio "migliore" (in assoluto) allo scopo, direi che possiamo anche chiudere il thread. ;)

[shinya]

se in informatica esistessero cose migliori in generale, avremmo quadrato il cerchio e non avremmo le os war, le browser war, le language war, microkernel contro monolitici, erlang contro google go ( no, questa per fortuna non c'è :D )
Secondo me è l'esatto contrario: abbiamo le foo vs bar-wars perché qualcuno pensa che foo sia migliore di bar. Non esiste il "in generale". La persone discutono proprio perché pensano "in generale". E questo a dispetto di prove e controprove della superiorità o meno di una tecnologia in un particolare contesto: l'ottusità fa parte della natura umana ed è una forma di difesa da parte di agenti esterni. Non sono molte le persone che volontariamente si mettono "out of the comfort zone" per vedere le cose da altri punti di vista.

[=KaTaKliSm4=]

In ogni caso, citandoti:

"Il fatto che sia + "complicato" di java e simili è solamente una scusa utilizzata da gente svogliata e parecchio chiusa mentalmente."

Non è molto carino dire una cosa del genere.
Se non altro io ho sempre detto che riporto la mia esperienza, e nel dare la mia opinione non ho mai offeso quelli (come ad esempio te) che la pensano diversamente.

Guarda che non è mica un'offesa la mia!Ti dico per esperienza, che se metti sul piatto vari linguaggi, il C++ viene scartato a priori perchè "complicato e troppo tecnico", ribadisco che se viene escluso per questo è solo perchè si è svogliati e chiusi mentalmente (sul profilo professionale). NON mi sembra di aver offeso ne tè ne tanto meno altre persone.

Non era riferito a chi non sviluppa in C++ ma chi non lo studia e non lo prende in considerazione perchè "gli hanno detto che il C++ è il lato oscuro dello sviluppo software", sono queste le cose che onestamente mi fanno ridere...poi, se ci vuoi vedere un'offesa, sei libero di farlo...

E' un po come quando incontri gente che si definisce webmaster/webdesigner/sviluppatore web, e fanno i siti in joomla senza neanche sapere cos'è php o asp.net...la differenza è proprio questa : uno senza conoscenze e/o voglia e/o bravura ti fa il sito in joomla, uno bravo che ha voglia e conoscenze ti fa un CMS, e fidati che di gente poco preparata c'è né fin troppa...sono realista, non sono cattivo.

Comunque sia non hai risposto alla mia domanda con tanto di riferimento ad un piccolo listato C#....

[=KaTaKliSm4=]

Secondo me è l'esatto contrario: abbiamo le foo vs bar-wars perché qualcuno pensa che foo sia migliore di bar. Non esiste il "in generale". La persone discutono proprio perché pensano "in generale". E questo a dispetto di prove e controprove della superiorità o meno di una tecnologia in un particolare contesto: l'ottusità fa parte della natura umana ed è una forma di difesa da parte di agenti esterni. Non sono molte le persone che volontariamente si mettono "out of the comfort zone" per vedere le cose da altri punti di vista.

Le cose sono oggettive se non fortemente contestualizzate....un conto è chiedere quale sia l'auto più veloce del mondo, un conto è chiedere quale sia l'auto piu veloce del mondo sotto i 20.000 euro...

Qual'è il linguaggio migliore del mondo?Assembler...qual'è il migliore per i gestionali su windows?C#/Java...per i videogame?C++...qui la contestualizzazione gioca un ruolo fondamentale...

(Scusate la banalità degli esempi :))

[cdimauro]

Il linguaggio migliore è quello macchina. :cool:

Comunque, cosa ne pensi di uno che conosce il C++, ma lo ritiene ugualmente "complicato e troppo tecnico"? Questo in generale. Poi a seconda del contesto, la stessa persona potrebbe benissimo consigliarlo (ad esempio per sviluppare giochi AAA).

[banryu79]

Comunque sia non hai risposto alla mia domanda con tanto di riferimento ad un piccolo listato C#...

Questa è la domanda, suppongo:

Se non hai conoscenze sui puntatori (in generale) questo blocco non riesci neanche a leggerlo a voce alta...figuriamoci a capirlo, quindi di che stiamo parlando?

Non occorreva un esempio per dimostrare l'ovvio, che nessuno ha messo in dubbio: cioè che se non conosci i puntatori non puoi capirne la loro semantica, l'aritmetica, e farne uso.

Però è altrettanto ovvio che si possono scrivere programmi senza fare uso dei puntatori nudi e crudi e della relativa aritmetica. Che sia più "sicuro" e più "facile" fare a meno di questa funzionalità, penso sia pacifico.
Che si possa farne sempre a meno, banalmente no.
E quando tocca usarli li si usa, punto.

Quindi, te la rigiro: nel contesto della dicussione che stavamo facendo, di che stai parlando?

Secondo te, dato un'ammontare di tempo X (con X arbitrariamente scelto dall'autore del thread ma ragionevolmente non troppo grande) a disposizione per cominciare a programmare un videogioco (che sicuramente non sarà nè tripla ne doppia ma neanche singola A), per l'autore del thread in questione è più proficuo fare a pugni con i segmentation fault, dangling pointers, double delete e altre piacevolezze varie a cui dare la caccia per ore col debugger o "avere il culo parato" da uno strumento che sotto il tappeto gestisca per lui questi aspetti in modo che il tempo invece lo "perda" dietro ad altri aspetti forse più di suo interesse?

Non so, magari studiando Python e usando la libreria PyGame, ad esempio.

Per poi magari affrontare il boccone più grosso quando avrà la bocca più grande e i denti più robusti?

[=KaTaKliSm4=]

Questa è la domanda, suppongo:

Non occorreva un esempio per dimostrare l'ovvio, che nessuno ha messo in dubbio: cioè che se non conosci i puntatori non puoi capirne la loro semantica, l'aritmetica, e farne uso.

Però è altrettanto ovvio che si possono scrivere programmi senza fare uso dei puntatori nudi e crudi e della relativa aritmetica. Che sia più "sicuro" e più "facile" fare a meno di questa funzionalità, penso sia pacifico.
Che si possa farne sempre a meno, banalmente no.
E quando tocca usarli li si usa, punto.


Perfetto e fin qua siamo d'accordo, il punto è questo : uno sviluppatore che non ha la minima conoscenza dei puntatori come fa a risolvere un problema che ne obbliga l'uso?Semplice, non può, anzi a dir la verità se prendi sottomano questi argomenti DOPO aver fatto parecchia esperienza con linguaggi un po piu di alto livello la cosa diventerà ancora più complicata dal mio punto di vista.


Quindi, te la rigiro: nel contesto della dicussione che stavamo facendo, di che stai parlando?

Secondo te, dato un'ammontare di tempo X (con X arbitrariamente scelto dall'autore del thread ma ragionevolmente non troppo grande) a disposizione per cominciare a programmare un videogioco (che sicuramente non sarà nè tripla ne doppia ma neanche singola A), per l'autore del thread in questione è più proficuo fare a pugni con i segmentation fault, dangling pointers, double delete e altre piacevolezze varie a cui dare la caccia per ore col debugger o "avere il culo parato" da uno strumento che sotto il tappeto gestisca per lui questi aspetti in modo che il tempo invece lo "perda" dietro ad altri aspetti forse più di suo interesse?

Per poi magari affrontare il boccone più grosso quando avrà la bocca più grande e i denti più robusti?

Puoi usare il linguaggio che ti pare, anche LUA....ma il topic non è questo, la domanda è "Qual'è il miglior linguaggio per lo sviluppo di videogames" e per prestazioni ed ecosistema vince nettamente C++.

Se la domanda fosse stata quella che mi hai appena sottoposto io avrei consigliato C#(XNA) e/o Java con uno dei tanti engine esistenti...:)


Il linguaggio migliore è quello macchina.


Comunque, cosa ne pensi di uno che conosce il C++, ma lo ritiene ugualmente "complicato e troppo tecnico"? Questo in generale. Poi a seconda del contesto, la stessa persona potrebbe benissimo consigliarlo (ad esempio per sviluppare giochi AAA).


Certo, questo è lecito, io in primis ammetto che C++ è "complicato" rispetto ad altri linguaggi OOP, infatti per aumentare l'efficienza/produttività ed avere prodotti di medio/alto livello utilizzo C# .net4 WPF e WCF.

Riprendo l'esempio dell'auto (che calza a pennello) :

- L'auto piu veloce del mondo?
- La bugatti
- Eh..ma costa millemilamilioni di euro...
- Ciò non toglie che è la più veloce.

- Il linguaggio OOP più performante e con maggiore know-how degli addetti al mondo?
- C++
- Eh....ma ci sono i pointers, non esiste un GC, devi impazzire con il debugger...
- Ciò non toglie che sia il linguaggio OOP più prestante ad oggi.

Penso che siamo tutti d'accordo su questo....

[banryu79]

Perfetto e fin qua siamo d'accordo, il punto è questo : uno sviluppatore che non ha la minima conoscenza dei puntatori come fa a risolvere un problema che ne obbliga l'uso?Semplice, non può, anzi a dir la verità se prendi sottomano questi argomenti DOPO aver fatto parecchia esperienza con linguaggi un po piu di alto livello la cosa diventerà ancora più complicata dal mio punto di vista.

Bene, e questo è il succo: dal mio punto di vista no, ergo vale quanto detto prima: non concordiamo.


Puoi usare il linguaggio che ti pare, anche LUA....ma il topic non è questo, la domanda è "Qual'è il miglior linguaggio per lo sviluppo di videogames" e per prestazioni ed ecosistema vince nettamente C++.

E daje: senza stabilire un criterio preciso, non si può fare nessuna valutazione.

Secondo te, un tizio che posta nella sezione di programmazione di un forum, che ti chiede quale è il linguaggio migliore per programmare videogiochi e che fa presente di essere agli inizi con la programmazione stressa, potenzialemte che tipo di interesse potrà mai avere? Scrivere il titolo AAA dell'anno prossimo?


Il linguaggio migliore è quello macchina.

L'essere migliori o peggiori è sempre rispetto a qualcosa, ad un criterio di valutazione: niente criterio == valutazione impossibile.

[cdimauro]

Credo che si riferisse alla capacità che ha un linguaggio di poter essere utilizzato per risolvere qualunque problema.

@=KaTaKliSm4=: ma a uno che deve iniziare a guidare non consiglierei mai di cominciare con la Bugatti... ;)

[shinya]

@=KaTaKliSm4=: ma a uno che deve iniziare a guidare non consiglierei mai di cominciare con la Bugatti... ;)
Magari avessi cominciato a guidare con la Bugatti! Sai quanta figa!

ps. la metafora sta cominciando a sfuggire di mano...

[banryu79]

* edit

[=KaTaKliSm4=]

@ banryu79 :

"Il linguaggio migliore è quello macchina." faceva parte del quote di cdimauro...

IO : Perfetto e fin qua siamo d'accordo, il punto è questo : uno sviluppatore che non ha la minima conoscenza dei puntatori come fa a risolvere un problema che ne obbliga l'uso?Semplice, non può, anzi a dir la verità se prendi sottomano questi argomenti DOPO aver fatto parecchia esperienza con linguaggi un po piu di alto livello la cosa diventerà ancora più complicata dal mio punto di vista.

TU : Bene, e questo è il succo: dal mio punto di vista no, ergo vale quanto detto prima: non concordiamo.

Hai dato il tuo "punto di vista" ma non hai risposto alla domanda :

"uno sviluppatore che non ha la minima conoscenza dei puntatori come fa a risolvere un problema che ne obbliga l'uso?" P.S per "non avere la minima conoscenza" intendo proprio non sapere, che sono, dove sono, chi sono, e a cosa servono...


Tu : "E daje: senza stabilire un criterio preciso, non si può fare nessuna valutazione."

Io il criterio c'è lo vedo eccome, esiste il criterio inteso come termini assoluti dove ogni variabile comune entra in gioco per dettare chi di 2 o piu entità è migliore delle altre :

Sviluppo di S.O : C++ Si, Java No
Sviluppo su piattaforme su cui la VM non è presente : C++ si, Java No
Sviluppo di giochi AAA : C++ si, Java No
Sviluppo di gestionali : C++ si , Java si
Sviluppo di giochi AA/A/nulla : C++ si, Java si
Sviluppo di sistemi di videoconferenza : C++ si, Java si
Sviluppo di applicazioni XYZ : C++ si, Java si (compromessi sulle prestazioni a parte...)

Quindi visto questo dettagliatissimo (:D) elenco di macro tipologie di software deduco che in senso assoluto C++ sia migliore di Java perchè con C++ si possono fare cose che con java non si possono fare.

P.S puoi restringere la cosa anche ai soli videogiochi, il risultato non cambia.

Poi ribadisco (sperando che tu non ripeta la questione del contesto :D ) che se il gioco da scrivere è il Tris, lo si può fare anche in LUA.

@cdimauro

Verissimo, non la consiglierei mai, ciò non toglie che sia comunque la macchina più veloce del mondo....sbaglio? :)

Anche se qui il paragone dell'auto non regge : se non hai esperienza, con la Bugatti ti schianti e muori, se non sai programmare e incominci da C++ tutti gli altri linguaggi ti sembreranno più semplici ed apprezzerai seriamente i vari framework...

P.S Ad uno che incomincia a programmare non consiglio neanche di "buttarsi" sui videogame, ma su altro...

Poi ragazzi...sappiamo perfettamente che ognuno dice la sua e smuoversi è piuttosto difficile però quando una cosa è oggettiva è oggettiva...

;) Una cosa è certa, spero che nessun novello sviluppatore entri in questo thread e incominci a leggere...gli togliamo la voglia di accendere il pc :D

[banryu79]

Hai dato il tuo "punto di vista" ma non hai risposto alla domanda :

"uno sviluppatore che non ha la minima conoscenza dei puntatori come fa a risolvere un problema che ne obbliga l'uso?" P.S per "non avere la minima conoscenza" intendo proprio non sapere, che sono, dove sono, chi sono, e a cosa servono...
Non può.
Ma mi sembra sufficientemente chiara la mia posizione: se il problema che devi risolvere non richiede neccessariamente l'uso dei puntatori, ne fai a meno.
E visto che si scrivono giochi in linguaggi dove non c'è l'aritmentica dei puntatori, beh, per realizzare quei giochi non è neccessario conoscere l'aritmentica dei puntatori.

E per favore, non farmi più domande retoriche per poi sollecitarmi alla risposta: se son retoriche mi secca perdere del tempo a scrivere l'ovvio, ovvio no? :)

[Mettiu_]

Mi iscrivo al post e nel frattempo esprimo anche un concetto. Secondo me uno dei "problemi" di queste discussioni è che molti rispondono come se fossero nella posizione di dover dare la risposta accademicamente e "teoricamente" più giusta come se a farla sia un capo aziendale o un professore mentre qui chi parla è un novello aspirante. Forse anche le domande andrebbero contestualizzate... Questo per dire che lo sappiamo tutti che con C o C++ o assembly ottieni il meglio delle prestazioni perchè ti allochi la memoria manualmente, la deallochi quando decidi tu, non hai la VM di sotto che spesso non è facile prevedere, ecc ecc... Tuttavia, dire ad un ragazzo che vuole cominciare a progettare qualche giochino (inizialmente stupido): "vatti a studiare i puntatori, la gestione della memoria, fatti un deallocatore, usa gli smart pointer, vatti a studiare l'architettura del DMA così ottimizzi la gestione del bus di sistema, calcolati la trasfomata di Fourier del treno di impulsi che attraversano il cavo Ethernet così massimizzi l'efficenza di trasmissione" è quantomeno scoraggiante per il novello perchè questo prima di vedere un pixel colorato sul suo schermo diventerà vecchio sopra quintali di teoria. Secondo me è meglio indicargli degli strumenti che lo immergano da subito nell'ambito delle cose un pò più "tangibili" e di più alto livello. In questo modo magari tra qualche tempo nascerà spontaneamente la volontà di indagare i meccanismi di più basso livello, realmente utili per fare prodotti di qualità dall'eccellente in sù.
Sarebbe bello sapere, visto che non programmo giochi (e tra l'altro non in C++), quanto tempo impiega un novello per cominciare a muovere in maniera sensata "un pixel" in un linguaggio piuttosto che nell'altro... Con C++ dubito riesco a farlo in tempi tali da non fargli passare la voglia :D

[ingframin]

Puoi usare il linguaggio che ti pare, anche LUA....ma il topic non è questo, la domanda è "Qual'è il miglior linguaggio per lo sviluppo di videogames" e per prestazioni ed ecosistema vince nettamente C++.



E qui casca l'asino...
Un team di sviluppo che deve fare un gioco massiccio, magari 3D, sicuramente trarra' grande vantaggio dal C++, ma non e' una regola assoluta.
Lo sviluppatore solitario di videogame si demotiva facilmente, se non riesce a raggiungere un minimo di risultato in un tempo umano si demotiva (o termina il budget) e rischia di abbandonare il progetto.
Non esiste un linguaggio migliore in assoluto per i videogame perche' in base al gioco che fai usi il linguaggio piu' appropriato.
Molti titoli AAA tra l'altro hanno l'engine scritto in C++ e il gameplay scriptato in Lua e similari.
Un'ultima cosa:
prestazioni ed ecosistema != gioco divertente

La cosa piu' importante in assoluto da curare in un gioco e' il gameplay. Un gioco che non diverte non e' un gioco.
A seconda dei requisiti del gameplay si sceglie il linguaggio.
Se per un clone di tetris va benissimo flash, per un simulatore di guida probabilmente si mischieranno C++ e Assembler (?).
Per un piccolo RPG "fatto in casa" ti assicuro che Python e Pygame vanno benissimo perche' provando con C ed SDL ottieni lo stesso risultato (anche in termini di frame rate) sbattendoti il triplo. Ne vale la pena?

[Tommo]

Ripeto ai partecipanti alla discussione che il linguaggio è ininfluente, e tra gli addetti ai lavori è d'uso individuare il "nabbo" chiedendo opinioni tipo queste (semmai qualcuno voglia farsi assumere) :D
Nel fare giochi, quello che conta è avere presente che cosa significa realizzare veramente un gioco da 0, dall'inizio alla pubblicazione.
L'unico modo per imparare a fare un gioco è pubblicarne un 2 o 3!

Mentre al contrario, il risultato tipico di uno studio partito da C++ e sentiti dire vaghi e generici tipo quelli di =KaTaKliSm4= (senza offesa) è un motore di gioco che non risolve alcun problema in particolare e non è adatto a supportare un gioco completo... se capita accompagnato da una tech demo in programmer art.
Posso dirlo per esperienza perchè riguardando il primo motore che ho scritto in C++, mi sono reso conto di come fosse una CAGATA PAZZESCA (cit.) del tutto sbagliata e inadatta a supportare un qualsiasi gioco reale... che avrei potuto scrivere con un decimo dello sforzo semplicemente sapendo qual'è la direzione da prendere.
Fare un gioco è un'altro discorso, che è meglio affrontare per primo partendo da un linguaggio più semplice.
Per approfondire ed aumentare le proprie capacità c'è sempre tempo, quando si hanno abbastanza strumenti per capire che cosa si sta facendo :D

Per cui anche se uso a tempo pieno C++ per lavoro, e sapere C++ a menadito è il modo migliore per avere un incarico di una qualsiasi importanza, mi sento di sconsigliare in assoluto C++ per iniziare.
E' un linguaggio eccessivamente complesso, potente e di basso livello. Tutte caratteristiche molto utili se si è in possesso dell'esperienza che serve a fare le scelte giuste, ma controproducenti se questo know how non si ha... rischiando di risolvere le scelte di design con un coin flip o a seconda di quello che si trova su internet... oppure di non accorgersi nemmeno che una scelta c'era.

PS: assembler non lo usa più nessuno nemmeno nelle sezioni critiche. Non ne ho visto mai in nessuna lib, nemmeno quelle più di sistema. Basta co sto mito dell'assembler per favore.

[Tommo]

In breve: all'OP consiglio ActionScript3 (http://en.wikipedia.org/wiki/Actionscript) (il linguaggio del Flash player) con un framework tipo Flixel (http://en.wikipedia.org/wiki/Flixel) o FlashPunk (http://flashpunk.net/).
E' semplice, ma allo stesso tempo è una versione "in scala" di quello che serve a fare un gioco nativo (2D) dalla A alla Z.
E comunque pubblicare un gioco su internet è una bella soddisfazione e può anche essere remunerativo (http://www.flashgamelicense.com/) :D

[marco.r]

Secondo me è l'esatto contrario: abbiamo le foo vs bar-wars perché qualcuno pensa che foo sia migliore di bar. Non esiste il "in generale". La persone discutono proprio perché pensano "in generale". E questo a dispetto di prove e controprove della superiorità o meno di una tecnologia in un particolare contesto: l'ottusità fa parte della natura umana ed è una forma di difesa da parte di agenti esterni. Non sono molte le persone che volontariamente si mettono "out of the comfort zone" per vedere le cose da altri punti di vista.
E' una variante del bikeshedding; ognuno ha una opinione emotiva dell'argomento perche' poco suffragata da fatti. Di conseguenza meno si conosce l'argomento e piu' si resta attaccati alle proprie convinzioni.

In ogni caso resto convinto che consigliare C++ solo perche' usato dai titoli AAA sia sbagliato. Ci sono fiori di persone che campano usando flash, anzi alcuni dei giochi piu' giocati al mondo sono proprio in flash.
Tornando all'esempio dell'auto, sono poche le persone che campano guidando una bugatti per lavoro; molte di piu' quelle che lo fanno guidando un camion.

[tecno789]

non vorrei essere deludente e far cadere i sogni di qualcuno ma per progettare un videogame comunque ci dev'essere dietro un team di sviluppo, non è possibile farselo da soli! Tra l'altro state sconsigliando di studiare il C, ma se ci pensate bene i giochi "pionieri" per esempio degli sparattutto, esempio quake ( scusate se lo metto in ballo) è scritto interamente in questo linguaggio e sinceramente a me diverte ancora ora :)

[Tommo]

non vorrei essere deludente e far cadere i sogni di qualcuno ma per progettare un videogame comunque ci dev'essere dietro un team di sviluppo, non è possibile farselo da soli!

Già, perchè dovresti essere deludente considerato che non (http://www.minecraft.net/) è (http://2dboy.com/games.php) vero (http://braid-game.com/) :asd:

Tra l'altro state sconsigliando di studiare il C, ma se ci pensate bene i giochi "pionieri" per esempio degli sparattutto, esempio quake ( scusate se lo metto in ballo) è scritto interamente in questo linguaggio e sinceramente a me diverte ancora ora

Difatti quanto diverte quake dipende dal fatto che è fatto in C.
Usiamo tutti uno strumento degli anni 80, così saremo tutti un pò john carmack :asd:
Il fatto che scrivere quake all'epoca era un'impresa titanica, e che oggi si tira su una cosa 100 volte meglio in 2 giorni non ti dice niente vero, sulla produttività di C puro? :asd:

[tecno789]

Già, perchè dovresti essere deludente considerato che non (http://www.minecraft.net/) è (http://2dboy.com/games.php) vero (http://braid-game.com/) :asd:



intendevo di giochi seri in 3d....



Difatti quanto diverte quake dipende dal fatto che è fatto in C.
Usiamo tutti uno strumento degli anni 80, così saremo tutti un pò john carmack :asd:

beh si ahahah :) anche tu hai ragione

[=KaTaKliSm4=]

Ripeto ai partecipanti alla discussione che il linguaggio è ininfluente, e tra gli addetti ai lavori è d'uso individuare il "nabbo" chiedendo opinioni tipo queste (semmai qualcuno voglia farsi assumere) :D


Probabilmente nella tua azienda, dove ho svolto i colloqui richiedono specificatamente determinati linguaggi e se non li conosci sei fuori a priori, a volte sono necessarie conoscenze specifiche di alcuni framework (Ex : QT).

Ti sto parlando di colloqui fatti in alcune multinazionali da >20.000 dipendenti e non al fruttivendolo sotto casa.


Nel fare giochi, quello che conta è avere presente che cosa significa realizzare veramente un gioco da 0, dall'inizio alla pubblicazione.
L'unico modo per imparare a fare un gioco è pubblicarne un 2 o 3!


Certo, basta avere le idee chiare, poi tutto viene da se...il codice si scrive da solo e i modelli 3D si animano come in un film della Walt Disney.

Questo trucchetto lo utilizzo anch'io nelle mie piattaforme gestionali in grado di gestire magazzini, tracking della merce e quant'altro...basta pensare al risultato più intensamente possibile e basta aver scritto 2/3 software prima...


Mentre al contrario, il risultato tipico di uno studio partito da C++ e sentiti dire vaghi e generici tipo quelli di =KaTaKliSm4= (senza offesa) è un motore di gioco che non risolve alcun problema in particolare e non è adatto a supportare un gioco completo... se capita accompagnato da una tech demo in programmer art.
Posso dirlo per esperienza perchè riguardando il primo motore che ho scritto in C++, mi sono reso conto di come fosse una CAGATA PAZZESCA (cit.) del tutto sbagliata e inadatta a supportare un qualsiasi gioco reale...


Sbagliato, io ho incominciato con l'eccezionale VB6 (sono ironico sull'aggettivo) ed è proprio per questo che mi sento di consigliare la strada inversa.

P.S, i miei commenti sono sicuramente opinabili, discutibili, errati...ma non venirmi a dire che sono stati vaghi o generici perchè ho postato listati non riproducibili senza determinate conoscenze e si è discusso sulla base di benchmark CHIARI ed INEQUIVOCABILI, cosi come per il discorso del GC.

Mi dispiace dirtelo, ma, se il tuo primo engine in C++ è uscito una CAGATA PAZZESCA (cit.) è per colpa delle tue conoscenze del linguaggio in QUEL momento, di sicuro non era colpa di C++, :rolleyes: finiamola di dare la colpa a dei meri strumenti....ed incominciamo a prenderci le nostre responsabilita....

L'engine è uscito una cagata...E' COLPA DI C++!!!!Maddai! :muro:


che avrei potuto scrivere con un decimo dello sforzo semplicemente sapendo qual'è la direzione da prendere.
Fare un gioco è un'altro discorso, che è meglio affrontare per primo partendo da un linguaggio più semplice.
Per approfondire ed aumentare le proprie capacità c'è sempre tempo, quando si hanno abbastanza strumenti per capire che cosa si sta facendo :D


Avresti potuto scriverlo con un decimo dello sforzo semplicemente perchè l'engine non richiedendo particolari prestazioni potevi scriverlo in qualsiasi altro linguaggio...un AAA in python personalmente non l'ho mai visto.


Per cui anche se uso a tempo pieno C++ per lavoro, e sapere C++ a menadito è il modo migliore per avere un incarico di una qualsiasi importanza, mi sento di sconsigliare in assoluto C++ per iniziare.


:muro: tipica frase da sviluppatore "duro" : è un lavoro sporco...qualcuno deve farlo perchè è richiesto...ma TU, tu non farlo...

Ma che ragionamenti sono????Se TU hai avuto difficoltà con l'apprendimento di C++ non significa che "anch'io" dovrò averle...ma dove sta scritto?La curva di apprendimento è totalmente soggettiva, e non mi venite a dire il contrario perchè senno mi auto convinco del fatto che si posta tanto per postare, sono passato da VB6 a C# in una, e dico una settimana studiano 10 ore al giorno, idem con patate per il C...sono un genio?Assolutamente no, mi sono semplicemente applicato sfruttando più che potevo le mie capacità.


E' un linguaggio eccessivamente complesso, potente e di basso livello. Tutte caratteristiche molto utili se si è in possesso dell'esperienza che serve a fare le scelte giuste, ma controproducenti se questo know how non si ha... rischiando di risolvere le scelte di design con un coin flip o a seconda di quello che si trova su internet... oppure di non accorgersi nemmeno che una scelta c'era.


E beh...certo, è risaputo che C++ sia di basso livello....

C++ è un linguaggio relativamente complesso rispetto ad altri, potente e di alto livello.

I design pattern spero che tutti sappiano cosa siano...e spero che tutti sappiano che possono essere utilizzati con qualsiasi linguaggio di programmazione...ma non eravate voi a dire che i linguaggi sono solo strumenti ? :muro:


PS: assembler non lo usa più nessuno nemmeno nelle sezioni critiche. Non ne ho visto mai in nessuna lib, nemmeno quelle più di sistema. Basta co sto mito dell'assembler per favore.

No assembler non lo usa piu nessuno, i PLC si programmano in LUA ora...ah!Anche il kernel linux...non sono sorgenti assembler, quei file sono messi li per fare arredamento.

Scusate il tono sarcastico, ma sta discussione sta diventando RIDICOLA.E che diamine per due puntatori e un de/allocazione manuale della memoria tutto sto baccano....manco vi avessero chiesto di ricostruire le torri gemelle con una benda agli occhi....

[Tommo]

Probabilmente nella tua azienda, dove ho svolto i colloqui richiedono specificatamente determinati linguaggi e se non li conosci sei fuori a priori, a volte sono necessarie conoscenze specifiche di alcuni framework (Ex : QT).

Ti sto parlando di colloqui fatti in alcune multinazionali da >20.000 dipendenti e non al fruttivendolo sotto casa.


Stiamo parlando di videogiochi mi pare... dove non ci sono team da 20.000 dipendenti, massimo massimo qualche centinaio.
E comunque, non so dove hai pescato la diatriba sull'azienda dato che stavo parlando di un genericissimo "fare un gioco".
Cioè, intendevo che per fare un gioco, la scelta di un linguaggio è ininfluente se questo rispetta i requisiti del gioco.
Mi sembra abbastanza regolare, senza scomodare aziende da 20000 dipendenti.

(come se il numero di dipendenti riflettesse la skill degli stessi - anzi, la botte piccola ha il vino buono. Ma cambiamo discorso va :D )


Certo, basta avere le idee chiare, poi tutto viene da se...il codice si scrive da solo e i modelli 3D si animano come in un film della Walt Disney.

Questo trucchetto lo utilizzo anch'io nelle mie piattaforme gestionali in grado di gestire magazzini, tracking della merce e quant'altro...basta pensare al risultato più intensamente possibile e basta aver scritto 2/3 software prima...


Che c'entra? Stiamo parlando della programmazione. Il punto di tentare di finire un gioco prima è PROPRIO rendersi conto di quanto la difficoltà del realizzare un gioco ruota intorno all'integrare l'idea di gioco col codice e con l'art.
Programmando e basta non si capisce qual'è il problema, specie se vieni da un mondo di software "aridi" (ie. non multimediali) tipo le famose piattaforme gestionali.
Non sono io a dirlo, l'unico modo per imparare a fare giochi, capire cosa funziona e cosa no e come farli efficientemente è farne UNA CIFRA.
Chiunque sostenga dell'altro mente :read:

Linko un'ottimo articolo di Derek Yu (no, non fa AAA, ma "giochini" tipo acquaria e spelunky :asd: ) al riguardo: Finishing a Game (http://makegames.tumblr.com/post/1136623767/finishing-a-game)


Sbagliato, io ho incominciato con l'eccezionale VB6 (sono ironico sull'aggettivo) ed è proprio per questo che mi sento di consigliare la strada inversa.

P.S, i miei commenti sono sicuramente opinabili, discutibili, errati...ma non venirmi a dire che sono stati vaghi o generici perchè ho postato listati non riproducibili senza determinate conoscenze e si è discusso sulla base di benchmark CHIARI ed INEQUIVOCABILI, cosi come per il discorso del GC.

Mi dispiace dirtelo, ma, se il tuo primo engine in C++ è uscito una CAGATA PAZZESCA (cit.) è per colpa delle tue conoscenze del linguaggio in QUEL momento, di sicuro non era colpa di C++, :rolleyes: finiamola di dare la colpa a dei meri strumenti....ed incominciamo a prenderci le nostre responsabilita....

L'engine è uscito una cagata...E' COLPA DI C++!!!!Maddai! :muro:

Continui a confondere le conoscenze in game development con la conoscenza del linguaggio... al dilà della qualità del motore, che da un punto di vista architetturale era alta (motore grafico, fisico e sonoro di prima scelta, component-based-objects, scripting etc) il problema era proprio che non sapevo cosa serviva per fare un gioco...
e quindi tutto era troppo generico, troppo complesso da usare perchè tutto faceva tutto e niente.
Un problema che è completamente estraneo al C++.

Il C++ però aggrava questo problema perchè non ti limita/aiuta come fa Flash, ma anzi ti richiede di smanacciare la memoria, scegliere librerie etc... e da "newcomer" mi sono perso in questo... anche perchè costruire un engine è un mondo sicuramente affascinante.
Per cui mi sentivo di dare questo avviso all'autore del topic.
La tua opinione informata invece qual'è, che non esiste questo rischio e io sono stupido? :asd:


Avresti potuto scriverlo con un decimo dello sforzo semplicemente perchè l'engine non richiedendo particolari prestazioni potevi scriverlo in qualsiasi altro linguaggio...un AAA in python personalmente non l'ho mai visto.


Si.
Il che dimostra la mia tesi che per iniziare (leggasi fare GIOCHI PICCOLI) il C++ non va bene.
Ho scritto "per iniziare" tipo duemila volte e ancora la meni con gli AAA, ma chi li ha chiamati, io rispondevo all'OP :asd:


:muro: tipica frase da sviluppatore "duro" : è un lavoro sporco...qualcuno deve farlo perchè è richiesto...ma TU, tu non farlo...

Ma che ragionamenti sono????Se TU hai avuto difficoltà con l'apprendimento di C++ non significa che "anch'io" dovrò averle...ma dove sta scritto?La curva di apprendimento è totalmente soggettiva, e non mi venite a dire il contrario perchè senno mi auto convinco del fatto che si posta tanto per postare, sono passato da VB6 a C# in una, e dico una settimana studiano 10 ore al giorno, idem con patate per il C...sono un genio?Assolutamente no, mi sono semplicemente applicato sfruttando più che potevo le mie capacità.


Ma chi ha detto che per me il C++ è stato difficile :asd:
E che tu sia un genio non l'ho mai pensato tranquillo :D
Ma poi tu sto C++ lo sai o no? perchè se no ho appena sprecato un post.


E beh...certo, è risaputo che C++ sia di basso livello....

C++ è un linguaggio relativamente complesso rispetto ad altri, potente e di alto livello.

I design pattern spero che tutti sappiano cosa siano...e spero che tutti sappiano che possono essere utilizzati con qualsiasi linguaggio di programmazione...ma non eravate voi a dire che i linguaggi sono solo strumenti ? :muro:


C++ è un linguaggio che richiede conoscenze di basso livello. Punto.
Design pattern o no, devi sapere che cos'è uno stack, un'heap, devi linkare librerie, devi quantomeno intuire cos'è una compile unit, la differenza tra dichiarazione e definizione, devi allocare e deallocare la memoria a mano, senza contare che non offre alcun supporto out of the box per operazioni grafiche.
Io questo lo chiamo di basso livello... se invece pensi si possa usare come una specie di Java compilato ignorando tutto ciò... buon per te :D
E si, la più grande forza di C++ è che espone sia il "basso livello" che "l'alto livello", ma appunto, gestirli entrambi come si deve non è affatto banale come lo fai sembrare.
Esistono strumenti più delicati di altri, per rimanere nella metafora.


No assembler non lo usa piu nessuno, i PLC si programmano in LUA ora...ah!Anche il kernel linux...non sono sorgenti assembler, quei file sono messi li per fare arredamento.

Scusate il tono sarcastico, ma sta discussione sta diventando RIDICOLA.E che diamine per due puntatori e un de/allocazione manuale della memoria tutto sto baccano....manco vi avessero chiesto di ricostruire le torri gemelle con una benda agli occhi....

Figo, quindi tu conosci giochi che girano su PLC, o sono integrati nel kernel linux :asd:
Stavo sempre parlando di giochi, grazie per avermi ricordato che c'è ancora roba vecchissima che lo usa :asd:

[banryu79]

Linko un'ottimo articolo di Derek Yu (no, non fa AAA, ma "giochini" tipo acquaria e spelunky :asd: ) al riguardo: Finishing a Game (http://makegames.tumblr.com/post/1136623767/finishing-a-game)

Grazie, molto interessante è istruttivo.
Il punto 10 mi ha sorpreso molto, non me l'aspettavo :asd:

[=KaTaKliSm4=]

Stiamo parlando di videogiochi mi pare... dove non ci sono team da 20.000 dipendenti, massimo massimo qualche centinaio.
E comunque, non so dove hai pescato la diatriba sull'azienda dato che stavo parlando di un genericissimo "fare un gioco".
Cioè, intendevo che per fare un gioco, la scelta di un linguaggio è ininfluente se questo rispetta i requisiti del gioco.
Mi sembra abbastanza regolare, senza scomodare aziende da 20000 dipendenti.

(come se il numero di dipendenti riflettesse la skill degli stessi - anzi, la botte piccola ha il vino buono. Ma cambiamo discorso va :D )


"e tra gli addetti ai lavori è d'uso individuare il "nabbo" chiedendo opinioni tipo queste (semmai qualcuno voglia farsi assumere)"

Ecco dove ho pescato la diatriba dell'azienda...per te avere un parere piu o meno soggettivo su una questione tecnica e da "nabbi".

Infatti è risaputo che se vuoi lavorare in una software house che produce videogame, puoi anche essere totalmente estraneo al linguaggio utilizzato.

Se entri in un team, la scelta del linguaggio è obbligatoria, altro che non influisce...


Che c'entra? Stiamo parlando della programmazione. Il punto di tentare di finire un gioco prima è PROPRIO rendersi conto di quanto la difficoltà del realizzare un gioco ruota intorno all'integrare l'idea di gioco col codice e con l'art.
Programmando e basta non si capisce qual'è il problema, specie se vieni da un mondo di software "aridi" (ie. non multimediali) tipo le famose piattaforme gestionali.
Non sono io a dirlo, l'unico modo per imparare a fare giochi, capire cosa funziona e cosa no e come farli efficientemente è farne UNA CIFRA.
Chiunque sostenga dell'altro mente :read:


Tipico ragionamento di chi non conosce assolutamente lo sviluppo software enterprise, le applicazioni si PROGETTANO, proprio come i giochi...se ne studia la grafica e l'interazione utente..proprio come i giochi!(Incredibile vero?:rolleyes:) E tu immagina che addirittura, la difficoltà di una piattaforma enterprise è proprio quella di "rendersi conto di quanto la difficoltà del realizzare un software ruota intorno all'integrare l'idea, i processi produttivi, le richieste, col codice..." (Cit.)

Da come parli sembra che l'esperienza conti solamente in ambito di game development..."Non sono io a dirlo, l'unico modo per imparare a fare giochi, capire cosa funziona e cosa no e come farli efficientemente è farne UNA CIFRA.", guarda che anche un fabbro impara il mestiere lavorando, cosi come il cameriere e uno sviluppatore software tuttofare.


Continui a confondere le conoscenze in game development con la conoscenza del linguaggio... al dilà della qualità del motore, che da un punto di vista architetturale era alta (motore grafico, fisico e sonoro di prima scelta, component-based-objects, scripting etc) il problema era proprio che non sapevo cosa serviva per fare un gioco...
e quindi tutto era troppo generico, troppo complesso da usare perchè tutto faceva tutto e niente.
Un problema che è completamente estraneo al C++.


Io non confondo assolutamente nulla, sei tu che cerchi di portare il game development su un livello superiore ad altri...lo sviluppo di videogame è tale e quale allo sviluppo di qualsiasi altro software, l'unica differenza è che ogni tipologia di sviluppo ha difficoltà diverse. Nello sviluppo di videogiochi, avere un ottimo motore grafico ti risolve il 40/50% dei problemi, la restante parte non so quanto possa centrare con lo sviluppo...penso sia piu una questione grafica e multimediale.


Il C++ però aggrava questo problema perchè non ti limita/aiuta come fa Flash, ma anzi ti richiede di smanacciare la memoria, scegliere librerie etc... e da "newcomer" mi sono perso in questo... anche perchè costruire un engine è un mondo sicuramente affascinante.


Mi fai capire dove ho detto esplicitamente che C++ sia piu semplice di altri linguaggi?Chi ha affermato sta cosa?Io no...ho semplicemente detto che C++ ti lascia libero di effettuare le piu disparate operazioni, ed essendo nativo ha delle prestazioni nettamente maggiori di altri linguaggi, PUNTO. Rischi il memory leak ed altre cazzatine che questo benedetto linguaggio può portare, ma basta stare attenti e fare del buon e sano TEST, ovvio è che i tempi di sviluppano si allungano, ma è banale...


Per cui mi sentivo di dare questo avviso all'autore del topic.
La tua opinione informata invece qual'è, che non esiste questo rischio e io sono stupido? :asd:


Complimenti per la girata di frittata, perché dici che ti ho dato dello stupido?Dove lo hai letto?Io ho IPOTIZZATO, visto la TUA stessa frase "E' USCITO UNA CAGATA" che non avessi abbastanza conoscenze in GENERALE (C++ e game development) per sviluppare un motore grafico degno di tale nome...ti ho dato dello stupido?NO, quindi fammi il favore di non mettermi parole in bocca che non ho detto e non ho neanche mai pensato...tra l'altro ribadisco il concetto : hai parlato di questa "tua esperienza personale" dando la colpa a C++ e ti ripeto che potevi farlo anche in java, se la tua esperienza e/o conoscenze non fossero state abbastanza avresti comunque fatto "UNA CAGATA DI MOTORE" (Cit. precisiamo, non vorrei che qualcuno mi dica che sto offendendo l'operato altrui...)



Si.
Il che dimostra la mia tesi che per iniziare (leggasi fare GIOCHI PICCOLI) il C++ non va bene.
Ho scritto "per iniziare" tipo duemila volte e ancora la meni con gli AAA, ma chi li ha chiamati, io rispondevo all'OP :asd:


No sbagliato, siete VOI che ve la menate con sto "per iniziare", il topic è incominciato con tutt'altro obbiettivo, ovvero in maniera generale, qual'è il miglior linguaggio per lo sviluppo di videogiochi?Che poi il know-how dell'utente sia basso non me ne frega nulla, ha fatto una domanda, io ho dato una risposta, poi SUCCESSIVAMENTE si è parlato del livello dell'utente in questione, ma il thread era già bello che "andato".Comunque per avvalorare la mia tesi ANCHE TU sviluppi giochi in C++, quindi, di che stiamo parlando?


Ma chi ha detto che per me il C++ è stato difficile :asd:
E che tu sia un genio non l'ho mai pensato tranquillo :D
Ma poi tu sto C++ lo sai o no? perchè se no ho appena sprecato un post.


Evita di offendere perché io non ti ho offeso, non ti conosco, non so chi sei...potresti essere Torvalds o il fruttivendolo sotto casa, pertanto evita le battutine mirate....

Sono un progettista e uno sviluppatore, lo conosco C++ tranquillo, lavoro con altro ma nel mio bagaglio c'è un po di tutto, se avessi letto un po di post te ne saresti accorto da solo...ma vabbè, leggere è un optional nei forum...


C++ è un linguaggio che richiede conoscenze di basso livello. Punto.
Design pattern o no, devi sapere che cos'è uno stack, un'heap, devi linkare librerie, devi quantomeno intuire cos'è una compile unit, la differenza tra dichiarazione e definizione, devi allocare e deallocare la memoria a mano, senza contare che non offre alcun supporto out of the box per operazioni grafiche.


Sei fantastico....infatti un programmatore SERIO .net NON SA ASSOLUTAMENTE cosa sia lo stack, l'heap il code segment non sa cosè lo scope, non sa cose un puntatore, non conosce la differenza tra managed ed unmanaged...non capisco il perchè di questi luoghi comuni : un programmatore è un programmatore, ed un programmatore DEVE avere determinate conoscenze...non sei d'accordo?


Io questo lo chiamo di basso livello... se invece pensi si possa usare come una specie di Java compilato ignorando tutto ciò... buon per te :D
E si, la più grande forza di C++ è che espone sia il "basso livello" che "l'alto livello", ma appunto, gestirli entrambi come si deve non è affatto banale come lo fai sembrare.
Esistono strumenti più delicati di altri, per rimanere nella metafora.


:confused: C++ di basso livello?Ma sei veramente convinto che C++ sia un linguaggio di basso livello in senso assoluto?????:confused: :confused: poi, prima dici che è di basso livello, poi ammetti che espone entrambe le facce...

Il C++ è un linguaggio di alto livello che in determinati ambiti può diventare un linguaggio di basso livello per effettuare determinate operazioni. Già il fatto che sia OO dice tutto. La visione comune è proprio quella di attribuire al C++ lo status di linguaggio intermedio.

P.S se vuoi, puoi darmi una DEFINIZIONE di alto e basso livello?


Figo, quindi tu conosci giochi che girano su PLC, o sono integrati nel kernel linux :asd:
Stavo sempre parlando di giochi, grazie per avermi ricordato che c'è ancora roba vecchissima che lo usa :asd:

Altra girata di frittata : "PS: assembler non lo usa più nessuno nemmeno nelle sezioni critiche. Non ne ho visto mai in nessuna lib, nemmeno quelle più di sistema. Basta co sto mito dell'assembler per favore."

Ho semplicemente risposto a questa tua errata affermazione, l'assembler se pur in maniera ridotta viene utilizzato ancora in determinati ambiti, anche nelle lib di sistema.

Io non capisco perché nei forum, uno cerca dibattito e trova solo flame e sarcasmo...abbiamo la possibilità di scambiare idee e opinioni e ogni tanto di imparare qualcosa di utile...invece sembra una lotta a chi "crede" di saperne di più sulla base di un confronto senza regole....

[banryu79]

Io non capisco perché nei forum, uno cerca dibattito e trova solo flame e sarcasmo...abbiamo la possibilità di scambiare idee e opinioni e ogni tanto di imparare qualcosa di utile...invece sembra una lotta a chi "crede" di saperne di più sulla base di un confronto senza regole...

Sposo in pieno il concetto, ma tu dove ti collocheresti?
Per te noi (mi includo e assieme a me metto Tommo) stiamo "lottando per imporre il nostro concetto scavalcando il tuo" e facendo "flame"?
A me personalmente pare che sia tu, che io che Tommo che chiunque altro sia interventuto nella discussione fin'ora abbia portato la sua opinione personale, sulla questione.

Se poi chi ha un'opinione diversa dalla tua è automaticamente dalla parte del torto, dice cazzate e "crede" di saperne... beh, fai te.

[=KaTaKliSm4=]

Sposo in pieno il concetto, ma tu dove ti collocheresti?
Per te noi (mi includo e assieme a me metto Tommo) stiamo "lottando per imporre il nostro concetto scavalcando il tuo" e facendo "flame"?
A me personalmente pare che sia tu, che io che Tommo che chiunque altro sia interventuto nella discussione fin'ora abbia portato la sua opinione personale, sulla questione.

Se poi chi ha un'opinione diversa dalla tua è automaticamente dalla parte del torto, dice cazzate e "crede" di saperne... beh, fai te.

Questo sta succedendo per un banalissimo motivo : io continuo a parlare in termini assoluti, e voi in termini di contesto, è ovvio quanto banale che le nostre opinioni non convergeranno MAI.

Però permettimi di dire che : uno non può dare del "nabbo" solo perché esprime opinioni su un linguaggio (siamo in un forum sulla programmazione o su un forum di casalinghe?), uno non può dire che C++ è un linguaggio di basso livello per l'esistenza di puntatori e per la gestione della memoria, uno non può dire che è SBAGLIATO A PRIORI incominciare con C++ perché c'è una curva di apprendimento più bassa di altri linguaggi e perché ci sono concetti un po più tecnici (comunque presenti in altri linguaggi), basti pensare che il fenomeno di memory leak (in maniera ridotta) è presente anche in linguaggi gestiti, ed è ridicolo vedere sviluppatori .net in preda "al panico" perché non riescono a capire il perché di un aumento smisurato di memoria e magari hanno semplicemente richiamato delle funzioni non gestite in cui sono presenti oggetti che devono essere distrutti.

Alla fine, i concetti della OOP sono quelli, la sintassi dei linguaggi è quasi sempre c++ like...quindi seriamente non capisco questa sorta di "vade retro"...

P.S io non ho mai detto che l'unico linguaggio valido sia C++, perche RIPETO che io per lavoro NON sviluppo in C++!!!!Non so più come ve lo devo dire....

Vi faccio un esempio : è da poco arrivato in ufficio un nuovo ragazzo che sto formando, prima di farlo passare a .net gli ho fatto studiare un po di C per un paio di mesi. Premetto che il ragazzo NON era un programmatore e non aveva MAI programmato prima d'ora. Oggi a distanza di 2 mesi e mezzo riesce a scrivere piccoli applicativi in C e applicativi medio complessi in c#.

Non è stato traumatizzato...e come lui tanti altri. Quindi, perchè questo luogo comune di far diffidare la gente dallo studiare C/C++?

Non pensate che studiano C++ si possa apprezzare meglio un linguaggio "meno complesso" e farne un uso sicuramente migliore?Dite la vostra...

[Tommo]

-cut-

Senti sei sicuramente abilissimo e sai il fatto tuo, ma credo non risponderò perchè sono troppo occupato a rilasciare un gioco su Steam :asd:
Chiamami quando con la tua abilità farai altrettanto, conto di non aspettare molto :D

PS: parlano in termini assoluti solo i preti e gli ignoranti. Non vedo croci quindi il cerchio si restringe, figliolo (semicit) :asd:

[=KaTaKliSm4=]

Senti sei sicuramente abilissimo e sai il fatto tuo, ma credo non risponderò perchè sono troppo occupato a rilasciare il mio gioco su Steam :asd:
Chiamami quando con la tua abilità farai altrettanto, conto di non aspettare molto :D

PS: parlano in termini assoluti solo i preti e gli ignoranti. Non vedo croci quindi il cerchio si restringe, figliolo (semicit) :asd:

Ho capito perfettamente che tipo sei, non hai alcuna argomentazione e continui ad offendermi, caschi male, malissimo.

La cit. potevi evitartela e dare dell'ignorante a persone che non si conoscono non è molto intelligente ne tanto meno da persone educate.

Magari dicci il titolo del gioco, 7.99€ te li regalo....:rolleyes:

P.S puoi rilasciare tutti i giochi che vuoi, ma questo, continua a non significare assolutamente NULLA.

P.S2 Meriteresti una segnalazione per questo commento a dir poco superlativo....

[banryu79]

Non è stato traumatizzato...e come lui tanti altri. Quindi, perchè questo luogo comune di far diffidare la gente dallo studiare C/C++?

Non ho obiezioni di sorta; io stesso ho studiato C e C++, all'epoca.
E devo dire che personalmente il C mi piace(va).

Non è che stiam qui a dire: non studiateli mai, sono brutti e cattivi.
Almeno a me non pare di averlo detto; io dico: sei bianco come un telo? Non sai un cippa di programmazione, design, problem solving, logica cazzi & mazzi? Bene, per addentrarti in questo mondo, comincia con un linguaggio ad alto livello di astrazione.

Per la tua esperienza tu ritieni valido il contrario e non sei d'accordo con questa opinione? Bene, pace, non casca il modo, vediamo le cose in modi diversi.

Io ripeto, secondo me l'OP avrà vita più facile (relativamente parlando, eh) a scegliersi un linguaggio tipo Python, una libreria tipo PyGame, insomma, strumenti ad alto livello di astrazione, e spendere il suo tempo nel rompersi la testa a tirar fuori idee originali, tradurle in un un buon gameplay, e a implementarlo (con tutto ciò che questo comporta)

E per fare questo non gli occorre sapere della memoria, dei puntatori, delle stringhe in C++ e altro "dettagliume". Semplicemente: non è produttivo, si rompe le balle prima, ci metto la mano sul fuoco.

[Tommo]

P.S puoi rilasciare tutti i giochi che vuoi, ma questo, continua a non significare assolutamente NULLA.

Quindi, per tel'opinione di uno che ha rilasciato un paio di giochi sull'argomento "fare videogiochi" ha lo stesso peso di uno che sviluppa database e non c'ha manco mai provato?

Per l'ultima volta, accetta che hai una visione limitata del problema e che non puoi dare i migliori consigli a chi inizia perchè tu stesso non sai quasi niente... non è un'offesa, nessuno nasce imparato, stranamente.
E' normale e sano, non mi sognerei mai di rispondere con tuo stesso tono in una discussione, che sia "miglior linguaggio per gestionali" o "migliori ferri per l'uncinetto".

Poi, non sono il massimo guru dell'argomento, tutt'altro... ci sono infinite persone che ne sanno più di me, ma almeno io lo riconosco :asd:

[=KaTaKliSm4=]

Quindi, per tel'opinione di uno che ha rilasciato un paio di giochi sull'argomento "fare videogiochi" ha lo stesso peso di uno che sviluppa database e non c'ha manco mai provato?

Per l'ultima volta, accetta che hai una visione limitata del problema e che non puoi dare i migliori consigli a chi inizia perchè tu stesso non sai quasi niente... non è un'offesa, nessuno nasce imparato, stranamente.
E' normale e sano, non mi sognerei mai di rispondere con tuo stesso tono in una discussione, che sia "miglior linguaggio per gestionali" o "migliori ferri per l'uncinetto".

E si, questo modo di fare mi spinge a essere acido :asd:

Questa situazione è ridicola :D , dai facciamo cosi, sono ignorante e limitato...e tu invece sei il number one dei number one...contento?

La cosa ridicola è vedere quanto ti senti onnipotente...

Mi sono un po scocciato ;) ti lascio ai tuoi rilasci, io vado a sviluppare "database"...

Oltre all'onnipotenza intravedo un accenno di onniscienza, io NON HO MAI provato e/o lavorato a progetti del genere...mmmm, ok...

P.S parli di aziende di game development, di "addetti" al lavoro, di esperienza...ma, lavori in qualche software house?

[=KaTaKliSm4=]

Non ho obiezioni di sorta; io stesso ho studiato C e C++, all'epoca.
E devo dire che personalmente il C mi piace(va).

Non è che stiam qui a dire: non studiateli mai, sono brutti e cattivi.
Almeno a me non pare di averlo detto; io dico: sei bianco come un telo? Non sai un cippa di programmazione, design, problem solving, logica cazzi & mazzi? Bene, per addentrarti in questo mondo, comincia con un linguaggio ad alto livello di astrazione.

Per la tua esperienza tu ritieni valido il contrario e non sei d'accordo con questa opinione? Bene, pace, non casca il modo, vediamo le cose in modi diversi.

Io ripeto, secondo me l'OP avrà vita più facile (relativamente parlando, eh) a scegliersi un linguaggio tipo Python, una libreria tipo PyGame, insomma, strumenti ad alto livello di astrazione, e spendere il suo tempo nel rompersi la testa a tirar fuori idee originali, tradurle in un un buon gameplay, e a implementarlo (con tutto ciò che questo comporta)

E per fare questo non gli occorre sapere della memoria, dei puntatori, delle stringhe in C++ e altro "dettagliume". Semplicemente: non è produttivo, si rompe le balle prima, ci metto la mano sul fuoco.

Perfetto ci troviamo perfettamente d'accordo su questo punto...in realtà stiamo dicendo esattamente le stesse cose...;)

Solamente che io propendo comunque a consigliare C++ altri no...ma queste sono "mere" opinioni personali.

[banryu79]

Perfetto ci troviamo perfettamente d'accordo su questo punto...in realtà stiamo dicendo esattamente le stesse cose...;)

Solamente che io propendo comunque a consigliare C++ altri no...ma queste sono "mere" opinioni personali.
Ah, meno male, che sollievo: cominciavo a temere di avere seri problemi nell'esprimermi (il che comunque non mi avrebbe stupito più di tanto) :D

[cdimauro]

In ogni caso resto convinto che consigliare C++ solo perche' usato dai titoli AAA sia sbagliato. Ci sono fiori di persone che campano usando flash, anzi alcuni dei giochi piu' giocati al mondo sono proprio in flash.
Tornando all'esempio dell'auto, sono poche le persone che campano guidando una bugatti per lavoro; molte di piu' quelle che lo fanno guidando un camion.
D'accordissimo.
non vorrei essere deludente e far cadere i sogni di qualcuno ma per progettare un videogame comunque ci dev'essere dietro un team di sviluppo, non è possibile farselo da soli!
Dipende dal tipo di gioco.

Non siamo più ai tempi di Geoff "una software house in una sola persona" Crammond, ma realizzare da soli giochi di complessità comparabile è anche più facile oggi rispetto ad allora.
Tra l'altro state sconsigliando di studiare il C, ma se ci pensate bene i giochi "pionieri" per esempio degli sparattutto, esempio quake ( scusate se lo metto in ballo) è scritto interamente in questo linguaggio e sinceramente a me diverte ancora ora :)
Ai miei tempi i giochi (AAA) li ho sviluppati interamente in assembly, inclusi tutti i tool che servivano.

Prima ancora, si lavorava (e ho lavorato) spesso in linguaggio macchina, perché non c'erano nemmeno assemblatori.

OGGI non consiglierei a nessuno di ripetere la stessa esperienza.
Avresti potuto scriverlo con un decimo dello sforzo semplicemente perchè l'engine non richiedendo particolari prestazioni potevi scriverlo in qualsiasi altro linguaggio...un AAA in python personalmente non l'ho mai visto.
Mai dire mai. :p
E beh...certo, è risaputo che C++ sia di basso livello....

C++ è un linguaggio relativamente complesso rispetto ad altri, potente e di alto livello.
Ma offre anche costrutti di basso livello, come il C.
I design pattern spero che tutti sappiano cosa siano...e spero che tutti sappiano che possono essere utilizzati con qualsiasi linguaggio di programmazione...ma non eravate voi a dire che i linguaggi sono solo strumenti ? :muro:
Beh, sì, ma i design pattern non si applicano tutti allo stesso modo. Dipende, appunto, dal linguaggio.

In alcuni linguaggi alcuni pattern sono sostanzialmente inutili, perché il linguaggio ti permette già di realizzare la stessa cosa coi costrutti sintattici che mette a disposizione.

Nella "bibbia" della Go4 fortunatamente vengono utilizzati Smalltalk e C++ per gli esempi, ed è possibile rendersi conto di ciò.
No assembler non lo usa piu nessuno, i PLC si programmano in LUA ora...ah!Anche il kernel linux...non sono sorgenti assembler, quei file sono messi li per fare arredamento.
Sono soltanto degli esempi, e comunque mi sembra che qui nessuno abbia negato che certi linguaggi continuino ad essere privilegiati in alcuni ambiti applicativi.

Anch'io ho citato il C++ per i giochi AAA, eppure farei volentieri a meno di lavorarci perché mi fa veramente schifo come linguaggio.
Scusate il tono sarcastico, ma sta discussione sta diventando RIDICOLA.E che diamine per due puntatori e un de/allocazione manuale della memoria tutto sto baccano....manco vi avessero chiesto di ricostruire le torri gemelle con una benda agli occhi....
Eppure se guardi l'elenco dei thread correntemente aperti in questa sezione, ne trovi qualcuno in cui si legge "segfault". ;)
"e tra gli addetti ai lavori è d'uso individuare il "nabbo" chiedendo opinioni tipo queste (semmai qualcuno voglia farsi assumere)"

Ecco dove ho pescato la diatriba dell'azienda...per te avere un parere piu o meno soggettivo su una questione tecnica e da "nabbi".

Infatti è risaputo che se vuoi lavorare in una software house che produce videogame, puoi anche essere totalmente estraneo al linguaggio utilizzato.

Se entri in un team, la scelta del linguaggio è obbligatoria, altro che non influisce...
Dipende da quello che fai. Alla Lionhead la toolchain per gli asset era realizzata in Python, se non ricordo male. E lì sviluppano giochi AAA.

Alla Crytek mi pare ci fosse qualcosa di analogo per il build-system.

Ed è normale che sia così: con un solo linguaggio difficilmente si raggiungerebbero gli obiettivi.
Tipico ragionamento di chi non conosce assolutamente lo sviluppo software enterprise, le applicazioni si PROGETTANO, proprio come i giochi...se ne studia la grafica e l'interazione utente..proprio come i giochi!(Incredibile vero?:rolleyes:) E tu immagina che addirittura, la difficoltà di una piattaforma enterprise è proprio quella di "rendersi conto di quanto la difficoltà del realizzare un software ruota intorno all'integrare l'idea, i processi produttivi, le richieste, col codice..." (Cit.)
Sulla progettazione ci sarebbe di che discutere. Ad esempio da un po' di anni vanno per la maggiore le metodologie agili. Anche se in Italia è abbastanza difficile trovare aziende che ne abbiano sposata qualcuna.
Mi fai capire dove ho detto esplicitamente che C++ sia piu semplice di altri linguaggi?Chi ha affermato sta cosa?Io no...ho semplicemente detto che C++ ti lascia libero di effettuare le piu disparate operazioni, ed essendo nativo ha delle prestazioni nettamente maggiori di altri linguaggi, PUNTO.
Anche su questo ci sarebbe di che disquisire, perché non è sempre vero.

Esempio pratico (http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=java).

Nel "fasta-redux" Java impiega quasi la metà del tempo. Eppure il C++ è "nativo" e, da quanto hai detto, dovrebbe offrire prestazioni maggiori. Sempre... ;)
Rischi il memory leak ed altre cazzatine che questo benedetto linguaggio può portare, ma basta stare attenti e fare del buon e sano TEST, ovvio è che i tempi di sviluppano si allungano, ma è banale...
Se fosse così banale utilizzerebbero tutti il C++.

Le problematiche esposte purtroppo sono una vera piega, e chi ha avuto modo di lavorarci o ci lavora lo sa bene.
No sbagliato, siete VOI che ve la menate con sto "per iniziare", il topic è incominciato con tutt'altro obbiettivo, ovvero in maniera generale, qual'è il miglior linguaggio per lo sviluppo di videogiochi?Che poi il know-how dell'utente sia basso non me ne frega nulla, ha fatto una domanda, io ho dato una risposta, poi SUCCESSIVAMENTE si è parlato del livello dell'utente in questione, ma il thread era già bello che "andato".Comunque per avvalorare la mia tesi ANCHE TU sviluppi giochi in C++, quindi, di che stiamo parlando?
La frase di apertura del topic non consente di rispondere con "C++" né con qualunque altro linguaggio.

Prima bisognerebbe definire migliore rispetto a cosa. Non esiste un linguaggio migliore in assoluto di un altro senza conoscere il contesto di applicazione.

Ciò detto, una volta appurato che l'utente era effettivamente alle prime armi sono usciti fuori discorsi più "a sua misura".

D'altra parte forum come questi nascono per dare una mano a chi ha bisogno, anche se mi rendo conto che dopo tutto quello che è stato scritto l'utente inq questione potrebbe aver maturato idee suicide. :stordita:
Evita di offendere perché io non ti ho offeso, non ti conosco, non so chi sei...potresti essere Torvalds
Questa sarebbe un'offesa. :mbe:
o il fruttivendolo sotto casa,
Questa no. :D
pertanto evita le battutine mirate....
Dai, finiamola tutti con le offese. Scadere sul piano personale è abbastanza squallido.
Sei fantastico....infatti un programmatore SERIO .net NON SA ASSOLUTAMENTE cosa sia lo stack, l'heap il code segment non sa cosè lo scope, non sa cose un puntatore, non conosce la differenza tra managed ed unmanaged...non capisco il perchè di questi luoghi comuni : un programmatore è un programmatore, ed un programmatore DEVE avere determinate conoscenze...non sei d'accordo?
Ni. Deve conoscere ciò che gli serve per risolvere un determinato problema.

Questo significa che può benissimo fare a meno di conoscere l'esistenza dei puntatori.
Il C++ è un linguaggio di alto livello che in determinati ambiti può diventare un linguaggio di basso livello per effettuare determinate operazioni. Già il fatto che sia OO dice tutto.
Il fatto che metta a disposizione costrutti sintattici per la OOP non implica che sia un linguaggio di alto livello.

C'è una differenza abissale fra C++ e Python, o anche Smalltalk, Ruby, ecc. sui costrutti sintattici messi a disposizione per la OOP.

In linea generale l'approccio di C++ è di più basso livello, mentre gli altri sono di più alto livello.
P.S se vuoi, puoi darmi una DEFINIZIONE di alto e basso livello?
Basso livello = costrutti e/o dettagli che si avvicinano alla macchina.

Alto livello = not Basso livello. :D

Esempio: un vettore di numeri interi in C o C++, contro la stessa cosa, ma in Python.

Col primo ho bisogno di definire la dimensione e la tipologia degli interi, allocarne e deallocarne lo spazio. Col secondo non serve nulla di tutto.
Questo sta succedendo per un banalissimo motivo : io continuo a parlare in termini assoluti, e voi in termini di contesto, è ovvio quanto banale che le nostre opinioni non convergeranno MAI.
Ma anche parlandone in termini assoluti non se ne esce ugualmente, perché il contesto non è sufficientemente definito.
Alla fine, i concetti della OOP sono quelli, la sintassi dei linguaggi è quasi sempre c++ like...quindi seriamente non capisco questa sorta di "vade retro"...
Beh, la sintassi di C & compagnia non è che sia proprio piacevole.

Il fatto che si sia diffusa non implica che sia la migliore o da preferire.
Vi faccio un esempio : è da poco arrivato in ufficio un nuovo ragazzo che sto formando, prima di farlo passare a .net gli ho fatto studiare un po di C per un paio di mesi. Premetto che il ragazzo NON era un programmatore e non aveva MAI programmato prima d'ora. Oggi a distanza di 2 mesi e mezzo riesce a scrivere piccoli applicativi in C e applicativi medio complessi in c#.

Non è stato traumatizzato...e come lui tanti altri. Quindi, perchè questo luogo comune di far diffidare la gente dallo studiare C/C++?
Una rondine non fa primavera.

Per uno che inizia da zero preferisco consigliargli Python, col quale può sperimentare la programmazione concentrandosi sulle problematiche da risolvere piuttosto che sui dettagli di basso livello o con rogne come memory leak, double delete, segmentation fault, ecc.
Non pensate che studiano C++ si possa apprezzare meglio un linguaggio "meno complesso" e farne un uso sicuramente migliore?Dite la vostra...
Non sono della stessa idea. Come programmatore a me piace, e ho il dovere, di risolvere problemi. Nient'altro.

Se posso fare a meno di C/C++, lo faccio volentieri. L'importante è che il cliente sia contento.

Altrimenti applicando la tua stessa logica prima sarebbe meglio studiarsi l'architettura degli elaboratori e il linguaggio macchina: si apprezzerebbero molto meglio gli altri linguaggi di più alto livello, C++ incluso. ;)
Senti sei sicuramente abilissimo e sai il fatto tuo, ma credo non risponderò perchè sono troppo occupato a rilasciare un gioco su Steam :asd:
Chiamami quando con la tua abilità farai altrettanto, conto di non aspettare molto :D

PS: parlano in termini assoluti solo i preti e gli ignoranti. Non vedo croci quindi il cerchio si restringe, figliolo (semicit) :asd:
Questo, però, non aiuta il dialogo, anzi.

E poi ricorrere alla "autorità" non mi sembra carino in una questione puramente tecnica, sennò si finisce per dar credito pure a Torvalds. :asd:

[Tommo]

Per fortuna che c'è cdimauro che risponde :D

Questo, però, non aiuta il dialogo, anzi.

E poi ricorrere alla "autorità" non mi sembra carino in una questione puramente tecnica, sennò si finisce per dar credito pure a Torvalds. :asd:

Lo so lo so, mi pento... tantopiù che 3 giochi pubblicati sono poco poco in certi ambienti :D
E' difficile però non ricorrere all'"autorità" quando le tesi altrui sono basate su congetture personali, spacciate per verità allo stesso livello.
D'altra parte "non conta quanti giochi hai rilasciato" :asd:

Ovvio, l'Italia è un paese di 60 milioni di allenatori, poeti, politici, e a quanto pare anche game developers :asd:

[nico159]

Basso livello = costrutti e/o dettagli che si avvicinano alla macchina.

Alto livello = not Basso livello.

Esempio: un vettore di numeri interi in C o C++, contro la stessa cosa, ma in Python.

Col primo ho bisogno di definire la dimensione e la tipologia degli interi, allocarne e deallocarne lo spazio. Col secondo non serve nulla di tutto.
Con C++11 questa definizione IMHO non è più sufficiente:
vector<int> vettore {123, 43, 545};
Questo non include alcuna gestione della memoria, ma se tutto quello che devi fare è passare grandi dati tra varie funzioni basta usare il nuovo move semantics

Se è qualcosa da tenere nell'heap si fa uso degli smart pointer ed il codice diventa molto meno compatto:
auto vettore = shared_ptr<vector<int>>();
vettore->push_back(123);
...
Si potrebbe riscrivere così:
auto vettore = shared_ptr<vector<int>>(new vector<int>{123, 43, 545});
Forse c'è qualche altra strada, onestamente non so

Ovviamente è molto più prolisso di Python e l'utilizzo dello shared_ptr è un peso in più a runtime rispetto a gestire da sè il ciclo di vita dell'oggetto

C++11 include enormi novità, dal type inference, alle funzioni labmda al supporto nativo per i thread
Si possono scrivere cose come:
auto element = find_if(begin(vettore), end(vettore), [=](int x) {return x > 5 && x < 10;});

Che in C# verrebbe tradotto in:
var element = vettore.First(x => x > 5 && x < 10);

Ovviamente in C# è più breve, ma considerando che si sta paragonando C# + Linq a C++ non è male - inoltre la sintassi di C++ permette di fare alcune cose in più - come decidere quali variabili catturare nella funzione lambda

E' bello che type inference o le funzioni lambda mancano a Java :D

Ci sono alcuni talk come questo http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/-Not-Your-Father-s-C- dove viene fatta una panoramica di cosa c'è di nuovo in C++11

[=KaTaKliSm4=]

Ma offre anche costrutti di basso livello, come il C.


Anche...quindi anche C# è un linguaggio di basso livello : Shift operator, Classe Marshall (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal(v=vs.71).aspx), puntatori, possibilità di richiamare .dll asm...?

Beh, sì, ma i design pattern non si applicano tutti allo stesso modo. Dipende, appunto, dal linguaggio.

In alcuni linguaggi alcuni pattern sono sostanzialmente inutili, perché il linguaggio ti permette già di realizzare la stessa cosa coi costrutti sintattici che mette a disposizione.

Nella "bibbia" della Go4 fortunatamente vengono utilizzati Smalltalk e C++ per gli esempi, ed è possibile rendersi conto di ciò.


Sono soltanto degli esempi, e comunque mi sembra che qui nessuno abbia negato che certi linguaggi continuino ad essere privilegiati in alcuni ambiti applicativi.


Certo che sono degli esempi, cosa avrei dovuto dire per controbattere il : "Assembler non si usa da nessuna parte, neanche nelle librerie di sistema".


Anch'io ho citato il C++ per i giochi AAA, eppure farei volentieri a meno di lavorarci perché mi fa veramente schifo come linguaggio.


Perfetto...a te fa "schifo" ad altri no :) , dove voi trovate "odio" altri trovano "amore" e la cosa è puramente soggettiva, se vuoi puoi chiamarlo masochismo se ti aggrada di piu :D


Eppure se guardi l'elenco dei thread correntemente aperti in questa sezione, ne trovi qualcuno in cui si legge "segfault". ;)


Quando ho negato questa cosa?Quando ho negato che i problemi di segmentation fault e memory leak sono presenti??


Dipende da quello che fai. Alla Lionhead la toolchain per gli asset era realizzata in Python, se non ricordo male. E lì sviluppano giochi AAA.

Alla Crytek mi pare ci fosse qualcosa di analogo per il build-system.

Ed è normale che sia così: con un solo linguaggio difficilmente si raggiungerebbero gli obiettivi.


Ma non ho detto mai il contrario :confused: , è un dato di fatto però che la parte core dei giochi AAA sia scritta in C++, vuoi per l'enorme know-how, vuoi per le prestazioni, vuoi per una cosa X...


Sulla progettazione ci sarebbe di che discutere. Ad esempio da un po' di anni vanno per la maggiore le metodologie agili. Anche se in Italia è abbastanza difficile trovare aziende che ne abbiano sposata qualcuna.


Parere totalmente personale, non abbiamo dati alla mano e se devo parlare in maniera generale beh, i software si progettano, se le aziende non lo fanno, sbagliano.



Anche su questo ci sarebbe di che disquisire, perché non è sempre vero.

Esempio pratico (http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=java).

Nel "fasta-redux" Java impiega quasi la metà del tempo. Eppure il C++ è "nativo" e, da quanto hai detto, dovrebbe offrire prestazioni maggiori. Sempre... ;)


In percentuale, C++ è piu prestante di Java.


Se fosse così banale utilizzerebbero tutti il C++.

Le problematiche esposte purtroppo sono una vera piega, e chi ha avuto modo di lavorarci o ci lavora lo sa bene.


E dall :D (tipica espressione pugliese), SIAMO TUTTI D'ACCORDO, infatti, io (lo dico per la 5 volta) ho scelto di non sviluppare in C++ per una questione di produttività.


La frase di apertura del topic non consente di rispondere con "C++" né con qualunque altro linguaggio.

Prima bisognerebbe definire migliore rispetto a cosa. Non esiste un linguaggio migliore in assoluto di un altro senza conoscere il contesto di applicazione.

Ciò detto, una volta appurato che l'utente era effettivamente alle prime armi sono usciti fuori discorsi più "a sua misura".


A domanda generica è stata data risposta generica...


D'altra parte forum come questi nascono per dare una mano a chi ha bisogno, anche se mi rendo conto che dopo tutto quello che è stato scritto l'utente inq questione potrebbe aver maturato idee suicide. :stordita:


:D verissimo....


Dai, finiamola tutti con le offese. Scadere sul piano personale è abbastanza squallido.


Leggi i miei post, non ho mai offeso nessuno perchè la reputo una cosa non professionale ma sopratutto non educata, specie se sto parlando con persone che NON conosco...fino a prova contraria IO non ho dato dell'ignorante a nessuno...


Il fatto che metta a disposizione costrutti sintattici per la OOP non implica che sia un linguaggio di alto livello.


Ni...http://en.wikipedia.org/wiki/High-level_programming_language , la sola introduzione basta..."The amount of abstraction provided defines how "high-level" a programming language is", ciò significa che un linguaggio ad alto livello può essere a più basso livello rispetto ad altri...

Comunque sia un linguaggio è ad alto livello quando possiede costrutti simili al linguaggio umano, e i linguaggi OOP oltre ad avere questi costrutti amplificano enormemente l'astrazione dei problemi tramite classi ed oggetti...quindi si, C++ è un linguaggio ad alto livello che all'occorrenza è in grado di lavorare ad un livello più basso di altri linguaggi OOP (vedi 1° punto, C#).


C'è una differenza abissale fra C++ e Python, o anche Smalltalk, Ruby, ecc. sui costrutti sintattici messi a disposizione per la OOP.

In linea generale l'approccio di C++ è di più basso livello, mentre gli altri sono di più alto livello.


Finalmente...:D hai detto benissimo , in linea generale l'approccio di C++ è piu di basso livello, ma non stiamo parlando di un linguaggio di BASSO livello, ma di basso livello rispetto ad altri linguaggi OOP. Se c++ è di basso livello, assembly che è?


Beh, la sintassi di C & compagnia non è che sia proprio piacevole.

Il fatto che si sia diffusa non implica che sia la migliore o da preferire.


Il fatto che non piaccia a te, non implica che "non sia proprio piacevole".
La mia affermazione era riferita al fatto che Java o C# hanno una sintassi C-like e quindi il passaggio non è drastico (ripeto, a livello sintattico).


Una rondine non fa primavera.


Pensi che sia un caso isolato?Io no...e come me la pensano tanti miei colleghi, con molta piu esperienza di me.


Per uno che inizia da zero preferisco consigliargli Python, col quale può sperimentare la programmazione concentrandosi sulle problematiche da risolvere piuttosto che sui dettagli di basso livello o con rogne come memory leak, double delete, segmentation fault, ecc.


Io invece,in linea generale, sono del parere opposto. In molti casi prima o poi bisognerà affrontare determinate cose e preferisco introdurle e possibilmente capirle prima che ciò accada, ma ripeto...opinioni.


Non sono della stessa idea. Come programmatore a me piace, e ho il dovere, di risolvere problemi. Nient'altro.

Se posso fare a meno di C/C++, lo faccio volentieri. L'importante è che il cliente sia contento.


Battiamo sempre sullo stesso punto (lo dico per la 6° volta), io sviluppo per la maggiore in C# proprio per questo, ma se "domani" ho esigenze diverse non ho bisogno di sbattermi 2 mesi a capire cose che grazie al mio percorso comprendo gia o che comunque devo solo approfondire.


Altrimenti applicando la tua stessa logica prima sarebbe meglio studiarsi l'architettura degli elaboratori e il linguaggio macchina: si apprezzerebbero molto meglio gli altri linguaggi di più alto livello, C++ incluso. ;)


Si, secondo me si, ma qui si entra nel puro gusto personale, perchè ai fini professionali non serve più di tanto.


Questo, però, non aiuta il dialogo, anzi.

E poi ricorrere alla "autorità" non mi sembra carino in una questione puramente tecnica, sennò si finisce per dar credito pure a Torvalds. :asd:

Qui concordiamo alla grandissima, chi si riveste di autorità per quanto mi riguarda fa solo un gran baccano, peggio quando incomincia a fare offese gratuite...

Due cose sono infinte : l'universo e....questo thread, ma riguardo l'universo ho ancora dei dubbi :D

[=KaTaKliSm4=]

Per fortuna che c'è cdimauro che risponde :D
Lo so lo so, mi pento... tantopiù che 3 giochi pubblicati sono poco poco in certi ambienti :D
E' difficile però non ricorrere all'"autorità" quando le tesi altrui sono basate su congetture personali, spacciate per verità allo stesso livello.


Ti rifaccio la domanda : parli di esperienza, di "addetti al lavoro" ora addirittura di autorità : lavori in qualche software house?Puoi darci l'elenco dei giochi da te pubblicati?

Ti ritieni un'autorità nel mondo del game development?Fai convegni?Seminari?Hai una cattedra?

Io sto esprimendo opinioni, il mio dibattito ora si è spostato su questioni oggettive.


D'altra parte "non conta quanti giochi hai rilasciato" :asd:


Conta?Io penso di no, ricorda che non è la quantità che conta ma la qualità e le idee, con questo non sto dicendo che i tuoi prodotti non hanno qualità (non so cosa hai rilasciato), ma non sbandierare a destra e a manca un'autorità che al 90% non possiedi.


Ovvio, l'Italia è un paese di 60 milioni di allenatori, poeti, politici, e a quanto pare anche game developers :asd:

:rolleyes: i tuoi commenti risultano parecchio infantili...sintomo che non lavori professionalmente nel settore e che hai avuto pochissimi riscontri con la realtà e il mercato dello sviluppo software, probabilmente sei uno studente universitario in gamba con buoni propositi e tanta voglia di fare, hai solo un difetto : pensi di aver fatto 13 e di essere già arrivato...

P.S per quanto mi riguarda il nostro dibattito può anche finire qua ;) se vuoi rispondere rispondi, se non vuoi rispondere amen.

[Tommo]

Ti rifaccio la domanda : parli di esperienza, di "addetti al lavoro" ora addirittura di autorità : lavori in qualche software house?Puoi darci l'elenco dei giochi da te pubblicati?

Ti ritieni un'autorità nel mondo del game development?Fai convegni?Seminari?Hai una cattedra?


Non ho mai detto di essere un'autorità eh. Ho solo detto di avere abbastanza esperienza nel gamedev da reputare le tue opinioni errate.
Poi non credo di dover mostrare il curriculum per avere una discussione pacifica su hwupgrade, anche perchè, come ha fatto notare cdimauro è una bassezza e non aiuta la discussione.
Comunque, se vuoi te lo dico per PM :asd:

[=KaTaKliSm4=]

Non ho mai detto di essere un'autorità eh. Ho solo detto di avere abbastanza esperienza nel gamedev da reputare le tue opinioni errate.
Poi non credo di dover mostrare il curriculum per avere una discussione pacifica su hwupgrade, anche perchè, come ha fatto notare cdimauro è una bassezza e non aiuta la discussione.
Comunque, se vuoi te lo dico per PM :asd:

E comunque ho parlato con john romero e notch gnegnegne :asd:

Avevo ragione :rolleyes:

Comunque se vuoi, passami pure le tue pubblicazioni...e vediamo tutta questa bravura ed esperienza almeno ;)

P.S mi dispiace ma il mio quote ha preso anche la tua ultima frase, subito cancellata....QUELLA è una bassezza, non il curriculum :rolleyes:

[Tommo]

In realtà, si chiama ironia. Ma mi sono reso conto che non sarebbe stata compresa, e l'ho tolto :asd:
Inizia tu a mandarmi le tue pubblicazioni, prego,

[||ElChE||88]

Già il fatto che si parli di pubblicazioni in un thread sui giochi è alquanto indicativo.

[=KaTaKliSm4=]

In realtà, si chiama ironia. Ma mi sono reso conto che non sarebbe stata compresa, e l'ho tolto :asd:
Inizia tu a mandarmi le tue pubblicazioni, prego,

Non sono io quello che vanta pubblicazioni ;) , ti stai sempre piu dimostrando infantile...io di giochi non ne ho mai pubblicati...io "programmo i database" :sofico:

Comunque ho già fatto, non preoccuparti....e mi è bastato leggere 1 delle 2 review presenti in un famoso store, ho dato anche un'occhiata ad un tuo engine, bassa complessità, nulla che non possa fare chiunque.

Vabé dai....evito di continuare :), ti do un consiglio al di fuori di tutte queste discussioni e blablabla...sii modesto e cerca di imparare il più possibile da chiunque, e quando sei in mezzo ad un dibattito evita di offendere e di fare dell'ironia. Nel mondo del lavoro (quello vero) non si ironizza e non si offende.

Altra cosa importantissima: quando ti ritrovi a parlare con gente che non conosci EVITA di palesare la tua superiorità, a volte potresti dover ammettere il contrario e fidati, inizialmente di figure di m***a per stò fatto ne ho fatte parecchie...

Hai sicuramente del potenziale e puoi dare parecchio ma ti prego, evita di avere certi atteggiamenti :)

Giuro che non sono ironico sta volta :D

[Tommo]

Però in tutto ciò la cosa bella è che ancora stai cercando di dimostrare che sei più bravo te, per qualche motivo... non credo tu possa farmi la paternale.

Il motore è poco complesso apposta, temo. Per quel famoso discorso di cui sopra che fare un gioco è molto più della tecnica che conta fino a un certo punto, e ci sono scelte di design orientate ad ottenere un risultato invece che scrivere codice, etc.
Ma d'altra parte non ci sono shaders e templates quindi dev'essere che non sono capace.

Invece quell'altro gioco da 130.000 line di codice che sto portando su mac e linux per conto di Mojang l'hai trovato? L'altro grosso altrettanto rilasciato su Steam? Probabilmente quelli no.

Ora, possibilmente smetti di prendermi sul personale che risulti patetico, specie perchè insulti la mia esperienza che non ho MAI affermato fosse da AAA, tantopiù che occupandomi di porting, imparare dagli altri è la mia occupazione principale.
Ma anche fosse anche solo il giochino iphone è superiore a quello che hai saputo dimostrare te finora.... ancora aspetto il link al tuo gioco eh.

[=KaTaKliSm4=]

Però in tutto ciò la cosa bella è che ancora stai cercando di dimostrare che sei più bravo te, per qualche motivo... non credo tu possa farmi la paternale.

Il motore è poco complesso apposta, temo. Per quel famoso discorso di cui sopra che fare un gioco è molto più della tecnica che conta fino a un certo punto, e ci sono scelte di design orientate ad ottenere un risultato invece che scrivere codice, etc.
Ma d'altra parte non ci sono shaders e templates quindi dev'essere che non sono capace.

Invece quell'altro gioco da 130.000 line di codice che sto portando su mac e linux per conto di Mojang l'hai trovato? L'altro grosso altrettanto rilasciato su Steam? Probabilmente quelli no.

Ora, possibilmente smetti di prendermi sul personale che risulti patetico, specie perchè insulti la mia esperienza che non ho MAI affermato fosse da AAA, tantopiù che occupandomi di porting, imparare dagli altri è la mia occupazione principale.
Ma anche fosse anche solo il giochino iphone è superiore a quello che hai saputo dimostrare te finora.... ancora aspetto il link al tuo gioco eh.

Con te è una partita persa, non accetti neanche dei consigli :rolleyes:
Come te ne ho visti crollare a decine in tempi brevissimi, spero che nel tuo caso sia il contrario.

P.S 130.000 "line" di codice....quindi?Sta a dimostrare cosa?Se ti faccio lo screen delle statistiche del mio ultimo progetto che ne conta piu di 500.000 significa che sono piu bravo di te?Ma che discorsi sono?

Buona fortuna, bye ;)

P.S giuro su HWupgrade (:D) che sarai il primo a sapere se il sottoscritto pubblicherà un videogame in futuro, dubito, visto che il mio business e altro...ma se dovesse succedere, non mancherò.

Ah P.S2 Anche dare del patetico, non è molto carino... ;)

[||ElChE||88]

Il "bello" è che da 2 pagine stai cercando di sminuire l'esperienza nell'ambito dei videogiochi di Tommo, glissando sul fatto che tu non ne hai proprio.

[Tommo]

Il "bello" è che da 2 pagine stai cercando di sminuire l'esperienza nell'ambito dei videogiochi di Tommo, glissando sul fatto che tu non ne hai proprio.

Menomale qualcuno se ne accorge :asd:

[PGI-Bis]

Meno chiacchiere e più giochi! Guardate qui, guardate qui!

http://www.youtube.com/watch?v=H6d9NRx21aM&feature=youtu.be

Guardate che passo felpato! La Carla Fracci dei Mech, altro che!

Gesù, ogni modello è un parto...

[cdimauro]

Con C++11 questa definizione IMHO non è più sufficiente:
vector<int> vettore {123, 43, 545};
Questo non include alcuna gestione della memoria, ma se tutto quello che devi fare è passare grandi dati tra varie funzioni basta usare il nuovo move semantics
Penso che la definizione rimanga ugualmente valida, perché in C++11 devi specificare il tipo del dato base (int), mentre in Python o in altri linguaggi di più alto livello ciò non è necessario.

E non è semplicemente una questione di type inference: è proprio il tipo che non si deve specificare.
Se è qualcosa da tenere nell'heap si fa uso degli smart pointer ed il codice diventa molto meno compatto:

Si potrebbe riscrivere così:

Forse c'è qualche altra strada, onestamente non so

Ovviamente è molto più prolisso di Python e l'utilizzo dello shared_ptr è un peso in più a runtime rispetto a gestire da sè il ciclo di vita dell'oggetto
E' quel che capita coi linguaggi managed, ed è un dettaglio di cui si fa a meno di conoscere / utilizzare.

C++ risolve in parte il problema con shared_ptr, ma non è esattamente la stessa cosa (per lo meno con linguaggi/runtime che fanno uso di meccanismi diversi dal reference counting).

Comunque la modalità di utilizzo rimane troppo prolissa, a maggior ragione se hai a che fare con collezioni di oggetti che devono essere dichiarati come shared_ptr.
C++11 include enormi novità, dal type inference, alle funzioni labmda al supporto nativo per i thread
Si possono scrivere cose come:
auto vettore = shared_ptr<vector<int>>();
vettore->push_back(123);
...
Che in C# verrebbe tradotto in:
auto vettore = shared_ptr<vector<int>>(new vector<int>{123, 43, 545});
Ovviamente in C# è più breve, ma considerando che si sta paragonando C# + Linq a C++ non è male - inoltre la sintassi di C++ permette di fare alcune cose in più - come decidere quali variabili catturare nella funzione lambda
Anche togliendo LINQ, la sintassi di C++11 è troppo prolissa. Non mi è mai piaciuta l'implementazione degli iteratori.
E' bello che type inference o le funzioni lambda mancano a Java :D
Perché alla Sun è sempre piaciuto il codice particolarmente verboso. :asd:
Ci sono alcuni talk come questo http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/-Not-Your-Father-s-C- dove viene fatta una panoramica di cosa c'è di nuovo in C++11
Sì, avevo già visto un po' di cose su C++. Quelle che hai riportato le conoscevo.

Ce ne saranno altre, ma francamente al momento preferisco spendere il mio tempo diversamente. ;)
Anche...quindi anche C# è un linguaggio di basso livello : Shift operator,
E' aritmetica binaria. Esisteva già quando non c'era nemmeno il concetto di calcolatore elettronico.
Classe Marshall (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal(v=vs.71).aspx),
Questo non è legato al linguaggio di per sé, ma al runtime .NET.

Infatti puoi usarlo anche in IronPython e, penso, in qualunque linguaggio .NET.
puntatori,
OK, ma in maniera gestita.
possibilità di richiamare .dll
Questo è legato a .NET, ma in ogni caso parliamo di una funzionalità generale.

Sono tanti i linguaggi che consentono di importare dll/so.
asm...?
In C# no.
Certo che sono degli esempi, cosa avrei dovuto dire per controbattere il : "Assembler non si usa da nessuna parte, neanche nelle librerie di sistema".
Credo che fosse una provocazione. Per lo meno io l'ho interpretata così.
Perfetto...a te fa "schifo" ad altri no :) , dove voi trovate "odio" altri trovano "amore" e la cosa è puramente soggettiva, se vuoi puoi chiamarlo masochismo se ti aggrada di piu :D
Non è questione di odio, ma proprio di schifo. Hai presente quando una cosa ti fa ribrezzo? Non devi per forza odiarla.

- "Ho visto lo zio di Brooklyn"
* "Cosa provi?"
- "Schifo"

Veramente, se c'è una cosa che mi fa schifo è proprio la sintassi del C++.

Da sempre preferisco linguaggi più leggibili, meno criptici. Gusti / limiti miei.
Quando ho negato questa cosa?Quando ho negato che i problemi di segmentation fault e memory leak sono presenti??
Li hai fortemente minimizzati.
Ma non ho detto mai il contrario :confused: , è un dato di fatto però che la parte core dei giochi AAA sia scritta in C++, vuoi per l'enorme know-how, vuoi per le prestazioni, vuoi per una cosa X...
Nulla da dire, ma a questo punto non possiamo definirlo come il miglior linguaggio per i videogiochi, visto che le software house non fanno uso soltanto del C++ per realizzarli.
Parere totalmente personale, non abbiamo dati alla mano e se devo parlare in maniera generale beh, i software si progettano, se le aziende non lo fanno, sbagliano.
Vade retro UML et similia.
In percentuale, C++ è piu prestante di Java.
Questo è già diverso da quello che sostenevi prima. ;)

Ti sei chiesto il perché di quel risultato?
Leggi i miei post, non ho mai offeso nessuno perchè la reputo una cosa non professionale ma sopratutto non educata, specie se sto parlando con persone che NON conosco...fino a prova contraria IO non ho dato dell'ignorante a nessuno...
Sei stato comunque offensivo in alcuni tuoi precedenti messaggi.
Ni...http://en.wikipedia.org/wiki/High-level_programming_language , la sola introduzione basta..."The amount of abstraction provided defines how "high-level" a programming language is", ciò significa che un linguaggio ad alto livello può essere a più basso livello rispetto ad altri...
Non tagliare le parti che non ti fanno comodo. Riportiamola tutta la prima parte:

"A high-level programming language is a programming language with strong abstraction from the details of the computer." :read:
Comunque sia un linguaggio è ad alto livello quando possiede costrutti simili al linguaggio umano, e i linguaggi OOP oltre ad avere questi costrutti amplificano enormemente l'astrazione dei problemi tramite classi ed oggetti...quindi si, C++ è un linguaggio ad alto livello che all'occorrenza è in grado di lavorare ad un livello più basso di altri linguaggi OOP (vedi 1° punto, C#).
Permettimi: di "umano" il C++ cos'avrebbe con la sua sintassi criptica?

Se il termine di paragone è quello che hai riportato, beh, Delphi tutta la vita a questo punto:
TWords = class
private
wordCount : Integer;
wordsStart : Pointer;
function Get(Index: Integer): string;
public
property GetWord[Index : Integer] : string read Get;
published
constructor Create(count : integer);
Destructor Destroy; override;
end;
Confrontalo con un equivalente C++, e dimmi, da essere umano, quale si avvicina alle lingue che mastichi. :cool:
Finalmente...:D hai detto benissimo , in linea generale l'approccio di C++ è piu di basso livello, ma non stiamo parlando di un linguaggio di BASSO livello, ma di basso livello rispetto ad altri linguaggi OOP. Se c++ è di basso livello, assembly che è?
Molto basso? :p
Il fatto che non piaccia a te, non implica che "non sia proprio piacevole".
Chiaro. E' una questione di gusti. Di un essere umano... :p
La mia affermazione era riferita al fatto che Java o C# hanno una sintassi C-like e quindi il passaggio non è drastico (ripeto, a livello sintattico).
Sì, avevo capito. Da questo punto di vista concordo.
Pensi che sia un caso isolato?Io no...e come me la pensano tanti miei colleghi, con molta piu esperienza di me.
Che dire: siamo in completo disaccordo.

Secondo te perché al MIT qualche anno fa hanno sostituito Scheme con Python quale linguaggio per il corso di base / introduzione alla programmazione? Perché non hanno scelto C++, se è vero quello che sostieni?

Il MIT rimane il caso eclatante, visto il prestigio di quest'università, ma altri atenei hanno fatto lo stesso.

Ci sarà un perché...
Io invece,in linea generale, sono del parere opposto. In molti casi prima o poi bisognerà affrontare determinate cose e preferisco introdurle e possibilmente capirle prima che ciò accada, ma ripeto...opinioni.
YAGNI.

Stai buttando tempo su una cosa che non sai se potrà servirti in futuro.

Io preferisco impiegare il mio (scarso) tempo su quello che realmente mi serve. SE e quando mi servirà una conoscenza di più basso livello (ma anche altro: il discorso è generale), ci sbatterò la testa.
Battiamo sempre sullo stesso punto (lo dico per la 6° volta), io sviluppo per la maggiore in C# proprio per questo, ma se "domani" ho esigenze diverse non ho bisogno di sbattermi 2 mesi a capire cose che grazie al mio percorso comprendo gia o che comunque devo solo approfondire.
Io preferisco rimandare. Altrimenti, anche qui, con lo stesso principio dovrei mettermi a studiare e imparare tantissime cose soltanto perché in futuro potrebbero servirmi.

Non ha senso. E' tempo perso. Lo farò al momento opportuno.
Si, secondo me si, ma qui si entra nel puro gusto personale, perchè ai fini professionali non serve più di tanto.
Non servono nemmeno i dettagli di basso livello di C/C++ & compagnia. ;)

Sono 7 anni e mezzo che uso Python e non ho mai fatto ricorso ai puntatori...
Meno chiacchiere e più giochi! Guardate qui, guardate qui!

http://www.youtube.com/watch?v=H6d9NRx21aM&feature=youtu.be

Guardate che passo felpato! La Carla Fracci dei Mech, altro che!

Gesù, ogni modello è un parto...
Dicci almeno come l'hai realizzato.

[PGI-Bis]

Dicci almeno come l'hai realizzato.

Col sudore della fronte!

E un po' di Blender Game Engine. Che ti constringe a usare python come linguaggio ma, si sa, nessuno è Jav... ehm, perfetto :Prrr: .

[ingframin]

Col sudore della fronte!

E un po' di Blender Game Engine. Che ti constringe a usare python come linguaggio ma, si sa, nessuno è Jav... ehm, perfetto :Prrr: .

Apprezzo l'impegno però cammina un po' come un pollo... Puoi evitare di farlo alzare quando fa i passi? :sofico:

[cdimauro]

Col sudore della fronte!

E un po' di Blender Game Engine. Che ti constringe a usare python come linguaggio ma, si sa, nessuno è Jav... ehm, perfetto :Prrr: .
Musica per le mie orecchie. E' per questo che te l'ho chiesto. :cool:

[marco.r]

Ovviamente in C# è più breve, ma considerando che si sta paragonando C# + Linq a C++ non è male - inoltre la sintassi di C++ permette di fare alcune cose in più - come decidere quali variabili catturare nella funzione lambda

In questo caso il problema principale e' che il C++ e' legato ad un retaggio del C, ovvero che gli array sono degli intervalli "aperti", ha solo l'inizio ma non la fine. Volendo rendere gli algoritmi compatibili con i puntatori oltre che i contenitori della libreria standard, si e' dovuto optare per una pessima interfaccia che prende separatamente inizio e fine del contenitore (o dell'array).
C'era un interessante talk da parte di Alexandrescu da qualche parte sul web. Qui ci sono le slide : http://www.slideshare.net/rawwell/iteratorsmustgo
Il concetto e' che gli iteratori della STL sono "sbagliati" e che oltre ad essere scomodi da usare sono pure poco sicuri. Per i dettagli guardatevi le slide. Concettualmente pero' il tuo esempio usando gli intervalli verrebbe fuori qualcosa come

auto element = find_if(vettore, [=](int x) {return x > 5 && x < 10;});

Gia' meglio. Soprattutto tenendo conto che rispetto al C# il find_if e' slegato dal contenitore e quindi o e' piu' performante o hai meno duplicazione di codice (a seconda di come e' implementato in C#).

[PGI-Bis]

Deve fare così! Cioè non proprio così, se fosse un filo più fluido non mi farebbe schifo (ma cogliete l'ironia! siete vecchi siete) ma dovrebbe andare su e giù. Magari i prossimi mi verranno meglio.

Per il sadico: la costrizione suona malissimo.

[marco.r]

E non è semplicemente una questione di type inference: è proprio il tipo che non si deve specificare.

E' quel che capita coi linguaggi managed, ed è un dettaglio di cui si fa a meno di conoscere / utilizzare.

Piccola nota: ogni volta che usate l'aggettivo "managed" per indicare un generico linguaggio con GC e/o con VM, in indonesia esplode un chicco di caffe', e Ballmer gongola (sudando ancora di piu'...).
Managed e' un termine coniato da Microsoft per indicare un linguaggio gestito dal framework .NET, ne' piu' ne' meno. Quando vedo scritto che Java (o Python) e' un linguaggio "managed"... beh non si puo' leggere :D

[ingframin]

Deve fare così! Cioè non proprio così, se fosse un filo più fluido non mi farebbe schifo (ma cogliete l'ironia! siete vecchi siete) ma dovrebbe andare su e giù. Magari i prossimi mi verranno meglio.

Per il sadico: la costrizione suona malissimo.

Giovane, guarda che il tuo mech e' molto carino, ti sto prendendo in giro :Prrr:
Comunque mi hai fatto venire la voglia di provare! Quando torno a casa stasera faccio 2 prove ;)

[PGI-Bis]

Mezz'ora fa ho riaperto il file di blender... paf, animazione nuclearizzata. Sparita: blender ha deciso che non gli andava di salvarla.

Dopo aver messo seriamente in forse la mia ascesa al paradiso, ho dovuto rifarla. Adesso sembra Tony Manero, gli manca solo la musichetta dei Bee Gees in sottofondo.

Qual'è il miglior linguaggio per iniziare? Fosse quello il problema...

[Kralizek]

piú che altro, per guidare un Mech ci vuole un intestino di ferro per non vomitare dopo 3 passi...

[PGI-Bis]

Ma sai che quasi quasi mi hai dato il nome per il gioco?

Iron Guts

Non suona male :D

[Kralizek]

voglio i diritti :O

[PGI-Bis]

Vabbè dai, facciamo a metà dei primi dieci milioni di dollari che incasso.

[cdimauro]

Piccola nota: ogni volta che usate l'aggettivo "managed" per indicare un generico linguaggio con GC e/o con VM, in indonesia esplode un chicco di caffe', e Ballmer gongola (sudando ancora di piu'...).
Managed e' un termine coniato da Microsoft per indicare un linguaggio gestito dal framework .NET, ne' piu' ne' meno. Quando vedo scritto che Java (o Python) e' un linguaggio "managed"... beh non si puo' leggere :D
Hai ragione, ma ormai è entrato nell'immaginario collettivo e si capisce subito di cosa si sta parlando.

Un'alternativa altrettanto diffusa non mi viene proprio in mente, così, su due piedi. :stordita: