theberto
08-03-2008, 00:04
come posso programmare giochi in c++ come ad esempio supermario?
View Full Version : [C++]programmare giochi
Naufr4g0
08-03-2008, 01:43
Di supermario ne abbiamo fin troppi! :'D
Cmq per creare giochi 2D ho letto che sono buone come librerie le Allegro e le SDL, che ti permettono anche di fare cose 3D.
Nulla ti vieta anche di usare le DirectX. :)
Dipende cmq dalla tua conoscenza del linguaggio..
Cmq per creare giochi 2D ho letto che sono buone come librerie le Allegro e le SDL, che ti permettono anche di fare cose 3D.
Nulla ti vieta anche di usare le DirectX. :)
Dipende cmq dalla tua conoscenza del linguaggio..
theberto
08-03-2008, 11:03
io conosco un po' di c++
fek
08-03-2008, 11:12
io conosco un po' di c++
Allora non provare a programmarci giochi, ti ci vorrebbero anni solo per imparare i concetti base.
Impara C# e gioca con XNA Studio 2.0, oppure impara Java e prova a programmare su Diamonds.
Allora non provare a programmarci giochi, ti ci vorrebbero anni solo per imparare i concetti base.
Impara C# e gioca con XNA Studio 2.0, oppure impara Java e prova a programmare su Diamonds.
ndakota
08-03-2008, 12:08
Allora non provare a programmarci giochi, ti ci vorrebbero anni solo per imparare i concetti base.
Impara C# e gioca con XNA Studio 2.0, oppure impara Java e prova a programmare su Diamonds.
ma java è usato per programmare i giochi in ambito professionale? o è solo un vostro "esperimento"?
Impara C# e gioca con XNA Studio 2.0, oppure impara Java e prova a programmare su Diamonds.
ma java è usato per programmare i giochi in ambito professionale? o è solo un vostro "esperimento"?
vladix
08-03-2008, 12:15
:fagiano: non sono un esperto , ma un consiglio lo posso dare : se vuoi fare giochi fps , jav di sicuro e il linguaggio meno adatto ( xche e un linguaggio interpretato , e quindi + lento )
71104
08-03-2008, 12:21
:fagiano: non sono un esperto, si vede :fagiano:
ma un consiglio lo posso dare: no guarda, era meglio che non lo davi :fagiano:
ma un consiglio lo posso dare: no guarda, era meglio che non lo davi :fagiano:
vladix
08-03-2008, 12:27
beh , ti dispiacerebbe dirmi il perche ?
vladix
08-03-2008, 12:53
io nn ho mica detto che non puoi scrivere giochi fps in java , io ho detto solo che non e il + adatto , e questo e vero e nn lo dicco io , e se 6 cosi esperto , invecce di offendere la gente ( ma ti capisco ... e sabato mattina ... ) , xchè non mi spieghi perchè e il + adatto . :hic:
Tommo
08-03-2008, 13:06
io nn ho mica detto che non puoi scrivere giochi fps in java , io ho detto solo che non e il + adatto , e questo e vero e nn lo dicco io , e se 6 cosi esperto , invecce di offendere la gente ( ma ti capisco ... e sabato mattina ... ) , xchè non mi spieghi perchè e il + adatto . :hic:
Si potrebbe evitare di dire anche stavolta che Java è più veloce di tutti ma la gente non lo sa? I giochi non sono mai fatti in Java, a parte robetta... può essere che c'è un motivo.:rolleyes:
Cmq per tornare IT secondo me dovresti provare prima C# e XNA che mi dicono essere semplice e intuitivo... poi se vuoi conoscere le cose più a fondo puoi passare a C++ & motori di terze parti per finire con C++ & DirectX/OpenGL :D
Si potrebbe evitare di dire anche stavolta che Java è più veloce di tutti ma la gente non lo sa? I giochi non sono mai fatti in Java, a parte robetta... può essere che c'è un motivo.:rolleyes:
Cmq per tornare IT secondo me dovresti provare prima C# e XNA che mi dicono essere semplice e intuitivo... poi se vuoi conoscere le cose più a fondo puoi passare a C++ & motori di terze parti per finire con C++ & DirectX/OpenGL :D
71104
08-03-2008, 13:20
beh , ti dispiacerebbe dirmi il perche ? perché java non è interpretato :fagiano:
71104
08-03-2008, 13:22
Si potrebbe evitare di dire anche stavolta che Java è più veloce di tutti ma la gente non lo sa? :fagiano: quanto mi piacerebbe più in generale chiedere cose come "si può evitare di dire stronzate anche stavolta?" :rolleyes:
I giochi non sono mai fatti in Java, a parte robetta... può essere che c'è un motivo.:rolleyes: si, ed è che in Java non puoi usare DirectX se non tramite Java3D. se invece devi usare OpenGL allora Java non presenta nessun problema (vedi Jake, il porting Java di QuakeII).
I giochi non sono mai fatti in Java, a parte robetta... può essere che c'è un motivo.:rolleyes: si, ed è che in Java non puoi usare DirectX se non tramite Java3D. se invece devi usare OpenGL allora Java non presenta nessun problema (vedi Jake, il porting Java di QuakeII).
Tommo
08-03-2008, 13:27
WOW Quake in Java fa 30 fps! Ma che prodiggio della tecnica :muro:
E' una cosa stupida e inutile se lo fai girare su pc moderni... raccontami come gira Jake su un PII... su cui Quake andava benissimo :rolleyes:
Cmq non credo che sta cosa sia inerente al topic...
E' una cosa stupida e inutile se lo fai girare su pc moderni... raccontami come gira Jake su un PII... su cui Quake andava benissimo :rolleyes:
Cmq non credo che sta cosa sia inerente al topic...
0rph3n
08-03-2008, 13:41
[censored]
voi con la matematica siete partiti subito con le equazioni differenziali?
...o siete partiti con addizione e sottrazione?
e poi mi sfugge il post dove qualcuno avrebbe detto che java è il più indicato...
voi con la matematica siete partiti subito con le equazioni differenziali?
...o siete partiti con addizione e sottrazione?
e poi mi sfugge il post dove qualcuno avrebbe detto che java è il più indicato...
fek
08-03-2008, 13:58
:fagiano: non sono un esperto , ma un consiglio lo posso dare : se vuoi fare giochi fps , jav di sicuro e il linguaggio meno adatto ( xche e un linguaggio interpretato , e quindi + lento )
Se vuole fare un fps da solo il problema non si pone, non fa un fps perche' e' impossibile :)
Java (o C# o Python, che Cesare ce ne scampi e liberi, o LUA o qualunque linguaggio ad alto livello) e' perfettamente indicato per scrivere la stragrande maggioranza di codice di un gioco anche commerciale su PC o Console. Praticamente quasi tutto il gameplay puo' essere (anzi oggi e') scritto in un linguaggio ad alto livello. L'Engine 3D (o fisico o sonoro) e' un discorso un po' diverso. Qui il problema non e' la velocita' di esecuzione dove Java va benissimo, ma il controllo sul ciclo di vita delle risorse: un Engine 3D ha bisogno di un controllo piuttosto preciso su quando gli oggetti sono creati e distrutti, dove sono posizionati in memoria, sui pattern di accesso e uso. Con un garbage collector di mezzo questo controllo diventa difficoltoso.
Ma chi vuole imparare a scrivere giochi e sta iniziando ora difficilmente si trovera' a scrivere un Engine 3D prima di parecchi anni (o magari mai), quindi il problema non gli si pone e il C++ non gli serve. Java o C# o chi per loro vanno benissimo.
Se vuole fare un fps da solo il problema non si pone, non fa un fps perche' e' impossibile :)
Java (o C# o Python, che Cesare ce ne scampi e liberi, o LUA o qualunque linguaggio ad alto livello) e' perfettamente indicato per scrivere la stragrande maggioranza di codice di un gioco anche commerciale su PC o Console. Praticamente quasi tutto il gameplay puo' essere (anzi oggi e') scritto in un linguaggio ad alto livello. L'Engine 3D (o fisico o sonoro) e' un discorso un po' diverso. Qui il problema non e' la velocita' di esecuzione dove Java va benissimo, ma il controllo sul ciclo di vita delle risorse: un Engine 3D ha bisogno di un controllo piuttosto preciso su quando gli oggetti sono creati e distrutti, dove sono posizionati in memoria, sui pattern di accesso e uso. Con un garbage collector di mezzo questo controllo diventa difficoltoso.
Ma chi vuole imparare a scrivere giochi e sta iniziando ora difficilmente si trovera' a scrivere un Engine 3D prima di parecchi anni (o magari mai), quindi il problema non gli si pone e il C++ non gli serve. Java o C# o chi per loro vanno benissimo.
fek
08-03-2008, 14:01
I giochi non sono mai fatti in Java, a parte robetta... può essere che c'è un motivo.:rolleyes:
La maggior parte dei giochi commerciali oggi sono scritti in larga parte in linguaggi come Python o LUA, che si pongono ad un piu' alto livello di astrazione di Java.
La maggior parte dei giochi commerciali oggi sono scritti in larga parte in linguaggi come Python o LUA, che si pongono ad un piu' alto livello di astrazione di Java.
vladix
08-03-2008, 14:32
perché java non è interpretato :fagiano:
mi auguro che tu stia scherzando
mi auguro che tu stia scherzando
vladix
08-03-2008, 14:40
[censored]
e poi mi sfugge il post dove qualcuno avrebbe detto che java è il più indicato...
...
Impara C# e gioca con XNA Studio 2.0, oppure impara Java e prova a programmare su Diamonds.
ma java è usato per programmare i giochi in ambito professionale? o è solo un vostro "esperimento"?
io ho solo espresso il mio parare , e stato poi l'uomo numero , con la sua affermazione a dire che java e il miglior in assoluto ( ma non e credibile xche lui afferma che ....
perché java non è interpretato :fagiano:
e poi mi sfugge il post dove qualcuno avrebbe detto che java è il più indicato...
...
Impara C# e gioca con XNA Studio 2.0, oppure impara Java e prova a programmare su Diamonds.
ma java è usato per programmare i giochi in ambito professionale? o è solo un vostro "esperimento"?
io ho solo espresso il mio parare , e stato poi l'uomo numero , con la sua affermazione a dire che java e il miglior in assoluto ( ma non e credibile xche lui afferma che ....
perché java non è interpretato :fagiano:
Tommo
08-03-2008, 14:50
La maggior parte dei giochi commerciali oggi sono scritti in larga parte in linguaggi come Python o LUA, che si pongono ad un piu' alto livello di astrazione di Java.
Beh si, linguaggi di scripting sono usati per tutte quelle situazioni "non riciclabili" e di alto livello, come la definizione di armi nemici e livelli, e magari anche per l'AI.
Ma da qui a dire che Java è perfettamente adatto per lo sviluppo (si sottointendeva completo) di un gioco ce ne corre parecchio... tutte le parti più "pesanti" sono sicuramente scritte in C++... o anche i C in rari casi.
Beh si, linguaggi di scripting sono usati per tutte quelle situazioni "non riciclabili" e di alto livello, come la definizione di armi nemici e livelli, e magari anche per l'AI.
Ma da qui a dire che Java è perfettamente adatto per lo sviluppo (si sottointendeva completo) di un gioco ce ne corre parecchio... tutte le parti più "pesanti" sono sicuramente scritte in C++... o anche i C in rari casi.
Naufr4g0
08-03-2008, 14:50
mi auguro che tu stia scherzando
StraQuoto! Java è interpretatissimo!
Però è vero che è più facile da imparare di linguaggi più a basso livello come il c++, e ne condivide tra l'altro parte della sintassi, rendendone il passaggio a C++ successivo più facile.
Cmq secondo me se uno deve imparare un signor linguaggio, impara il C++, è lui il padre di tutti i linguaggi moderni.
Io tra parentesi conosco il Java e l'ho usato per scrivere un giochino in Java j2me per cellulari e in quell'ambito se la cava bene, per il PC se uno deve imparare a fare giochini è meglio il Flash del Java. :)
Se uno deve fare cose serie le fa in C++ e DirectX o Opengl.
StraQuoto! Java è interpretatissimo!
Però è vero che è più facile da imparare di linguaggi più a basso livello come il c++, e ne condivide tra l'altro parte della sintassi, rendendone il passaggio a C++ successivo più facile.
Cmq secondo me se uno deve imparare un signor linguaggio, impara il C++, è lui il padre di tutti i linguaggi moderni.
Io tra parentesi conosco il Java e l'ho usato per scrivere un giochino in Java j2me per cellulari e in quell'ambito se la cava bene, per il PC se uno deve imparare a fare giochini è meglio il Flash del Java. :)
Se uno deve fare cose serie le fa in C++ e DirectX o Opengl.
fek
08-03-2008, 15:14
Beh si, linguaggi di scripting sono usati per tutte quelle situazioni "non riciclabili" e di alto livello, come la definizione di armi nemici e livelli, e magari anche per l'AI.
Non sto parlando di scripting ne' di linguaggi di scripting. Sto parlando del codice del gioco.
Ma da qui a dire che Java è perfettamente adatto per lo sviluppo (si sottointendeva completo) di un gioco ce ne corre parecchio... tutte le parti più "pesanti" sono sicuramente scritte in C++... o anche i C in rari casi.
Nessun linguaggio e' adatto per lo sviluppo completo di un gioco. Il C++ decisamente non lo e', e' forse il meno indicato di tutti data la complessita' dei sistemi che si scrivono oggi.
Un gioco oggi si sviluppa in diversi linguaggi (anche tre o quattro alla volta) a seconda del sistema che si sta scrivendo e delle esigenze. Il C++, come ho descritto, non serve per scrivere le parti piu' pesanti, ma per scrivere i sistemi dove e' necessario avere il totale controllo sul ciclo di vita degli oggetti, e la loro dislocazione in memoria.
Java e' perfettamente adatto a sviluppare videogiochi anche molto complessi.
Il C e' perfettamente inutile per scrivere un gioco ovunque sia disponibile un compilatore C++.
StraQuoto! Java è interpretatissimo!
Java non e' interpretato. Il codice Java e' solitamente compilato in un bytcode che viene compilato in codice nativo a runtime. Il bytecode non e' mai eseguito direttamente sulle piattaforme Java piu' evolute. Nessuno vieta di compilare codice Java direttamente in codice nativo senza passare dal bytecode.
Non sto parlando di scripting ne' di linguaggi di scripting. Sto parlando del codice del gioco.
Ma da qui a dire che Java è perfettamente adatto per lo sviluppo (si sottointendeva completo) di un gioco ce ne corre parecchio... tutte le parti più "pesanti" sono sicuramente scritte in C++... o anche i C in rari casi.
Nessun linguaggio e' adatto per lo sviluppo completo di un gioco. Il C++ decisamente non lo e', e' forse il meno indicato di tutti data la complessita' dei sistemi che si scrivono oggi.
Un gioco oggi si sviluppa in diversi linguaggi (anche tre o quattro alla volta) a seconda del sistema che si sta scrivendo e delle esigenze. Il C++, come ho descritto, non serve per scrivere le parti piu' pesanti, ma per scrivere i sistemi dove e' necessario avere il totale controllo sul ciclo di vita degli oggetti, e la loro dislocazione in memoria.
Java e' perfettamente adatto a sviluppare videogiochi anche molto complessi.
Il C e' perfettamente inutile per scrivere un gioco ovunque sia disponibile un compilatore C++.
StraQuoto! Java è interpretatissimo!
Java non e' interpretato. Il codice Java e' solitamente compilato in un bytcode che viene compilato in codice nativo a runtime. Il bytecode non e' mai eseguito direttamente sulle piattaforme Java piu' evolute. Nessuno vieta di compilare codice Java direttamente in codice nativo senza passare dal bytecode.
71104
08-03-2008, 15:22
mi auguro che tu stia scherzando mi auguro che tu invece non stia scherzando, perché altrimenti mi toglieresti tutto il divertimento :asd:
71104
08-03-2008, 15:23
io ho solo espresso il mio parare , e stato poi l'uomo numero , con la sua affermazione a dire che java e il miglior in assoluto dov'è che l'avrei detto? :rolleyes:
71104
08-03-2008, 15:25
Beh si, linguaggi di scripting sono usati per tutte quelle situazioni "non riciclabili" e di alto livello, come la definizione di armi nemici e livelli, e magari anche per l'AI.
Ma da qui a dire che Java è perfettamente adatto per lo sviluppo (si sottointendeva completo) di un gioco ce ne corre parecchio... ma nessuno conosce Jake? :fagiano:
tutte le parti più "pesanti" sono sicuramente scritte in C++... o anche i C in rari casi. giusto, perché quando servono performances estreme non basta neanche il C++: serve proprio il C :asd:
certe volte persino l'assembly :rotfl:
Ma da qui a dire che Java è perfettamente adatto per lo sviluppo (si sottointendeva completo) di un gioco ce ne corre parecchio... ma nessuno conosce Jake? :fagiano:
tutte le parti più "pesanti" sono sicuramente scritte in C++... o anche i C in rari casi. giusto, perché quando servono performances estreme non basta neanche il C++: serve proprio il C :asd:
certe volte persino l'assembly :rotfl:
71104
08-03-2008, 15:34
StraQuoto! Java è interpretatissimo! omg, erano secoli che non capitavano sul forum niubbih di questa portata :rotfl:
Cmq secondo me se uno deve imparare un signor linguaggio, impara il C++, è lui il padre di tutti i linguaggi moderni. ma allora perché non imparare SmallTalk, che è il padre della programmazione a oggetti? :D
per il PC se uno deve imparare a fare giochini è meglio il Flash del Java. :) oddio questa mi mette con le spalle al muro :asd:
fek aiutami tu che io non so neanche cosa rispondere, sono combattuto tra i sentimenti di pena ed ilarità :rotfl:
Se uno deve fare cose serie le fa in C++ e DirectX o Opengl. povero niubboh vittima dei luoghi comuni :friend:
Cmq secondo me se uno deve imparare un signor linguaggio, impara il C++, è lui il padre di tutti i linguaggi moderni. ma allora perché non imparare SmallTalk, che è il padre della programmazione a oggetti? :D
per il PC se uno deve imparare a fare giochini è meglio il Flash del Java. :) oddio questa mi mette con le spalle al muro :asd:
fek aiutami tu che io non so neanche cosa rispondere, sono combattuto tra i sentimenti di pena ed ilarità :rotfl:
Se uno deve fare cose serie le fa in C++ e DirectX o Opengl. povero niubboh vittima dei luoghi comuni :friend:
71104
08-03-2008, 15:37
Da Wikipedia:
Compilazione Just-In-Time
[...] come il garbage collector, che se da un lato fanno risparmiare tempo ed errori in fase di sviluppo dei programmi, dall'altro consumano memoria e tempo di CPU in fase di esecuzione del programma finito.
;)
certo pure Wikipedia ci mette del suo eh :muro:
Compilazione Just-In-Time
[...] come il garbage collector, che se da un lato fanno risparmiare tempo ed errori in fase di sviluppo dei programmi, dall'altro consumano memoria e tempo di CPU in fase di esecuzione del programma finito.
;)
certo pure Wikipedia ci mette del suo eh :muro:
71104
08-03-2008, 15:43
to', me n'ero perso uno :fagiano:
WOW Quake in Java fa 30 fps! Ma che prodiggio della tecnica :muro:
E' una cosa stupida e inutile se lo fai girare su pc moderni... raccontami come gira Jake su un PII... su cui Quake andava benissimo :rolleyes: e tu prova, chè potrebbe stupirti :rolleyes:
e comunque vorrei farti presente che non sono in molti oggi a sviluppare videogames per Pentium 2 :fagiano:
WOW Quake in Java fa 30 fps! Ma che prodiggio della tecnica :muro:
E' una cosa stupida e inutile se lo fai girare su pc moderni... raccontami come gira Jake su un PII... su cui Quake andava benissimo :rolleyes: e tu prova, chè potrebbe stupirti :rolleyes:
e comunque vorrei farti presente che non sono in molti oggi a sviluppare videogames per Pentium 2 :fagiano:
Naufr4g0
08-03-2008, 15:47
omg, erano secoli che non capitavano sul forum niubbih di questa portata :rotfl:
ma allora perché non imparare SmallTalk, che è il padre della programmazione a oggetti? :D
oddio questa mi mette con le spalle al muro :asd:
fek aiutami tu che io non so neanche cosa rispondere, sono combattuto tra i sentimenti di pena ed ilarità :rotfl:
povero niubboh vittima dei luoghi comuni :friend:
Va bene per il fatto che il java non è prettamente interpretato, ma utilizza un linguaggio intermedio che è il bytecode, ma cmq non potrà mai essere efficiente quanto un programma scritto in c++ e compilato.
Ma dire che l'efficienza dei giochi scritti in DirectX e Opengl sia solo un luogo comune... ma fammi il piacere...
ma allora perché non imparare SmallTalk, che è il padre della programmazione a oggetti? :D
oddio questa mi mette con le spalle al muro :asd:
fek aiutami tu che io non so neanche cosa rispondere, sono combattuto tra i sentimenti di pena ed ilarità :rotfl:
povero niubboh vittima dei luoghi comuni :friend:
Va bene per il fatto che il java non è prettamente interpretato, ma utilizza un linguaggio intermedio che è il bytecode, ma cmq non potrà mai essere efficiente quanto un programma scritto in c++ e compilato.
Ma dire che l'efficienza dei giochi scritti in DirectX e Opengl sia solo un luogo comune... ma fammi il piacere...
Naufr4g0
08-03-2008, 15:49
to', me n'ero perso uno :fagiano:
e tu prova, chè potrebbe stupirti :rolleyes:
e comunque vorrei farti presente che non sono in molti oggi a sviluppare videogames per Pentium 2 :fagiano:
Allora è giusto fare giochi che una volta giravano tranquillamente per Pentium 2 e ora per farli funzionare con linguaggi più ad alto livello ci vogliono i dual core?
Quanto più ci si allontana dal codice macchina, tanto più si peggiora l'efficienza, e non ci sono storie...
e tu prova, chè potrebbe stupirti :rolleyes:
e comunque vorrei farti presente che non sono in molti oggi a sviluppare videogames per Pentium 2 :fagiano:
Allora è giusto fare giochi che una volta giravano tranquillamente per Pentium 2 e ora per farli funzionare con linguaggi più ad alto livello ci vogliono i dual core?
Quanto più ci si allontana dal codice macchina, tanto più si peggiora l'efficienza, e non ci sono storie...
fek
08-03-2008, 15:51
Va bene per il fatto che il java non è prettamente interpretato, ma utilizza un linguaggio intermedio che è il bytecode, ma cmq non potrà mai essere efficiente quanto un programma scritto in c++ e compilato.
Potenzialmente, in alcuni scenari, puo' essere anche piu' efficiente visto che e' possibile compilare il bytecode a runtime in base alla piattaforma e ai dati di profiling presi durante l'esecuzione.
Il luogo comune "Java e' sempre piu' lento del C++" e', appunto, un luogo comune. Dipende.
Quanto più ci si allontana dal codice macchina, tanto più si peggiora l'efficienza, e non ci sono storie...
Assolutamente falso. Prendi un algoritmo poco piu' che banale, implementalo in C++ o C# o Java e poi prova a implementarlo in assembly per architettura Intel o AMD. Dimmi se in assembly riesci a produrre codice piu' veloce.
Non ci riesci. (E non ci riesco neppure io)
Potenzialmente, in alcuni scenari, puo' essere anche piu' efficiente visto che e' possibile compilare il bytecode a runtime in base alla piattaforma e ai dati di profiling presi durante l'esecuzione.
Il luogo comune "Java e' sempre piu' lento del C++" e', appunto, un luogo comune. Dipende.
Quanto più ci si allontana dal codice macchina, tanto più si peggiora l'efficienza, e non ci sono storie...
Assolutamente falso. Prendi un algoritmo poco piu' che banale, implementalo in C++ o C# o Java e poi prova a implementarlo in assembly per architettura Intel o AMD. Dimmi se in assembly riesci a produrre codice piu' veloce.
Non ci riesci. (E non ci riesco neppure io)
71104
08-03-2008, 15:53
azz, quasi dimenticavo di postare questo:
http://msdn2.microsoft.com/en-us/library/bb318659(VS.85).aspx
Benefits of DirectX 9.0 for Managed Code
By eliminating the Component Object Model (COM) interoperability layer, DirectX 9.0 for Managed Code improves performance. Managed code can reduce the volume of code and increase productivity. The interface is more intuitive, inheriting from the powerful and easy-to-use Microsoft .NET Framework common types. Managed code also frees you from having to deal with most memory management tasks, such as releasing objects. In the SDK you will find managed Visual C# samples and tutorials that duplicate many of the unmanaged code samples.
:D
http://msdn2.microsoft.com/en-us/library/bb318659(VS.85).aspx
Benefits of DirectX 9.0 for Managed Code
By eliminating the Component Object Model (COM) interoperability layer, DirectX 9.0 for Managed Code improves performance. Managed code can reduce the volume of code and increase productivity. The interface is more intuitive, inheriting from the powerful and easy-to-use Microsoft .NET Framework common types. Managed code also frees you from having to deal with most memory management tasks, such as releasing objects. In the SDK you will find managed Visual C# samples and tutorials that duplicate many of the unmanaged code samples.
:D
71104
08-03-2008, 15:55
Ma dire che l'efficienza dei giochi scritti in DirectX e Opengl sia solo un luogo comune... ma fammi il piacere... dov'è che l'ho detto? :rolleyes:
Naufr4g0
08-03-2008, 16:06
Potenzialmente, in alcuni scenari, puo' essere anche piu' efficiente visto che e' possibile compilare il bytecode a runtime in base alla piattaforma e ai dati di profiling presi durante l'esecuzione.
E' solo più portabile! Il java è nato per essere portabile e discretamente efficiente, e per molti versi c'è riuscito.
Il c++ lo è molto di meno, ma è decisamente più efficiente.
Il luogo comune "Java e' sempre piu' lento del C++" e', appunto, un luogo comune. Dipende.
Quando cominci a usare finestre, bottoni e menu, noti subito la differenza.
Assolutamente falso. Prendi un algoritmo poco piu' che banale, implementalo in C++ o C# o Java e poi prova a implementarlo in assembly per architettura Intel o AMD. Dimmi se in assembly riesci a produrre codice piu' veloce.
Non ci riesci. (E non ci riesco neppure io)
Di questo ho i miei dubbi, entrambi i linguaggi generano codice macchina (o per meglio dire i loro compilatori), e l'assembly è senz'altro il più vicino al codice macchina (non puoi negarlo), quindi in teoria l'ottimizzazione potrebbe essere estrema! Il c++ a limite può eguagliarlo...
E' solo più portabile! Il java è nato per essere portabile e discretamente efficiente, e per molti versi c'è riuscito.
Il c++ lo è molto di meno, ma è decisamente più efficiente.
Il luogo comune "Java e' sempre piu' lento del C++" e', appunto, un luogo comune. Dipende.
Quando cominci a usare finestre, bottoni e menu, noti subito la differenza.
Assolutamente falso. Prendi un algoritmo poco piu' che banale, implementalo in C++ o C# o Java e poi prova a implementarlo in assembly per architettura Intel o AMD. Dimmi se in assembly riesci a produrre codice piu' veloce.
Non ci riesci. (E non ci riesco neppure io)
Di questo ho i miei dubbi, entrambi i linguaggi generano codice macchina (o per meglio dire i loro compilatori), e l'assembly è senz'altro il più vicino al codice macchina (non puoi negarlo), quindi in teoria l'ottimizzazione potrebbe essere estrema! Il c++ a limite può eguagliarlo...
fek
08-03-2008, 16:33
Il c++ lo è molto di meno, ma è decisamente più efficiente.
No, dipende dallo scenario. In generale la differenza e' del tutto trascurabile.
Di questo ho i miei dubbi, entrambi i linguaggi generano codice macchina (o per meglio dire i loro compilatori), e l'assembly è senz'altro il più vicino al codice macchina (non puoi negarlo), quindi in teoria l'ottimizzazione potrebbe essere estrema! Il c++ a limite può eguagliarlo...
Puoi avere tutti i dubbi di questo mondo, ma continuerai a non riuscire a produrre manualmente codice assembly piu' efficiente :)
Qui non si parla di teoria, qui si parla di pratica. Ad esempio un essere umano non e' in grado di allocare i registri in maniera efficiente come puo' fare un compilatore per nascondere le latenze. Non e' in grado di riordinare le istruzioni in base ai pattern di accesso alla memoria. Non e' in grado di organizzare il layout degli oggetti per minimizzare i cache miss. In pratica non riuscirai mai a produrre codice assembly piu' veloce di quello che puo' produrre un compilatore C++ o Java se non in particolarissimi scenari che rappresentano una sparuta minoranza.
Esempio di uno scenario nel quale un compilatore Java puo' produrre codice piu' efficiente di un compilatore C++:
for (...)
{
if (test)
{
++counter;
}
else
{
DoSomethingMaybeInline();
}
}
DoSomethingMaybeInline() e' da mettere inline o no? Dipende :)
Se test e' true il 99% delle volte, allora mettere la funzione inline renderebbe il loop piu' lento per via dei cache miss, se test e' true l'1% delle volte, alora mettere la funzione inline renderebbe il codice piu' veloce perche' salverebbe una chiamata a funzione con relativo passaggio via stack e cache miss dati.
Un compilatore C++ non puo' prendere questa decisione, perche' non ha quei dati, un compilatore JIT si', e produrrebbe potenzialmente codice piu' veloce.
No, dipende dallo scenario. In generale la differenza e' del tutto trascurabile.
Di questo ho i miei dubbi, entrambi i linguaggi generano codice macchina (o per meglio dire i loro compilatori), e l'assembly è senz'altro il più vicino al codice macchina (non puoi negarlo), quindi in teoria l'ottimizzazione potrebbe essere estrema! Il c++ a limite può eguagliarlo...
Puoi avere tutti i dubbi di questo mondo, ma continuerai a non riuscire a produrre manualmente codice assembly piu' efficiente :)
Qui non si parla di teoria, qui si parla di pratica. Ad esempio un essere umano non e' in grado di allocare i registri in maniera efficiente come puo' fare un compilatore per nascondere le latenze. Non e' in grado di riordinare le istruzioni in base ai pattern di accesso alla memoria. Non e' in grado di organizzare il layout degli oggetti per minimizzare i cache miss. In pratica non riuscirai mai a produrre codice assembly piu' veloce di quello che puo' produrre un compilatore C++ o Java se non in particolarissimi scenari che rappresentano una sparuta minoranza.
Esempio di uno scenario nel quale un compilatore Java puo' produrre codice piu' efficiente di un compilatore C++:
for (...)
{
if (test)
{
++counter;
}
else
{
DoSomethingMaybeInline();
}
}
DoSomethingMaybeInline() e' da mettere inline o no? Dipende :)
Se test e' true il 99% delle volte, allora mettere la funzione inline renderebbe il loop piu' lento per via dei cache miss, se test e' true l'1% delle volte, alora mettere la funzione inline renderebbe il codice piu' veloce perche' salverebbe una chiamata a funzione con relativo passaggio via stack e cache miss dati.
Un compilatore C++ non puo' prendere questa decisione, perche' non ha quei dati, un compilatore JIT si', e produrrebbe potenzialmente codice piu' veloce.
Naufr4g0
08-03-2008, 16:50
Se test e' true il 99% delle volte, allora mettere la funzione inline renderebbe il loop piu' lento per via dei cache miss, se test e' true l'1% delle volte, alora mettere la funzione inline renderebbe il codice piu' veloce perche' salverebbe una chiamata a funzione con relativo passaggio via stack e cache miss dati.
Un compilatore C++ non puo' prendere questa decisione, perche' non ha quei dati, un compilatore JIT si', e produrrebbe potenzialmente codice piu' veloce.
Il discorso che fai tu è corretto, ma questo è un caso molto particolare, se test=true per il 50% delle volte, cade tutto il discorso.
Bisogna vedere preventivamente se un codice si avvantaggia di una compilazione di tipo JIT e utilizzare il linguaggio più consono in base al risultato.
Ma per programmi che fanno massicci calcoli e che hanno una data struttura predeterminata e il fattore scelta sia poco importante, il C++ resta il migliore.
Cmq per concludere il discorso: io non patteggio nè per l'uno, nè per l'altro linguaggio e anzi io conosco meglio il Java perchè l'ho già usato, mentre il C++ e le relative GUI, le conosco poco. Quindi è inutile questa competizione.
Però ultimamente ho deciso di imparare a usare anche il C++ perchè cmq lo ritengo fondamentale nella conoscenza informatica e mi piace avere gli eseguibili in formato .exe! :D
P.S. Messaggio per 71104: guarda non ti ho risposto per come dovevo a i tuoi post precedenti, cmq prima di prendere per ignorante una persona, leggi bene quello che ha da dire prima, invece di basarti su semplici affermazioni.
Chiunque se gli chiedi ti dirà che Java è interpretato, mentre il C++ è compilato. E' una classificazione classica. Quindi una affermazione come quella che ho fatto sopra puo' far ridere solo te. :)
Un compilatore C++ non puo' prendere questa decisione, perche' non ha quei dati, un compilatore JIT si', e produrrebbe potenzialmente codice piu' veloce.
Il discorso che fai tu è corretto, ma questo è un caso molto particolare, se test=true per il 50% delle volte, cade tutto il discorso.
Bisogna vedere preventivamente se un codice si avvantaggia di una compilazione di tipo JIT e utilizzare il linguaggio più consono in base al risultato.
Ma per programmi che fanno massicci calcoli e che hanno una data struttura predeterminata e il fattore scelta sia poco importante, il C++ resta il migliore.
Cmq per concludere il discorso: io non patteggio nè per l'uno, nè per l'altro linguaggio e anzi io conosco meglio il Java perchè l'ho già usato, mentre il C++ e le relative GUI, le conosco poco. Quindi è inutile questa competizione.
Però ultimamente ho deciso di imparare a usare anche il C++ perchè cmq lo ritengo fondamentale nella conoscenza informatica e mi piace avere gli eseguibili in formato .exe! :D
P.S. Messaggio per 71104: guarda non ti ho risposto per come dovevo a i tuoi post precedenti, cmq prima di prendere per ignorante una persona, leggi bene quello che ha da dire prima, invece di basarti su semplici affermazioni.
Chiunque se gli chiedi ti dirà che Java è interpretato, mentre il C++ è compilato. E' una classificazione classica. Quindi una affermazione come quella che ho fatto sopra puo' far ridere solo te. :)
fek
08-03-2008, 16:57
Il discorso che fai tu è corretto, ma questo è un caso molto particolare, se test=true per il 50% delle volte, cade tutto il discorso.
Bisogna vedere preventivamente se un codice si avvantaggia di una compilazione di tipo JIT e utilizzare il linguaggio più consono in base al risultato.
Innanzitutto non e' un caso particolare, e' uno scenario, perfettamente possibile e per altro molto comune, dove un compilatore JIT puo' produrre codice piu' veloce di un compilatore statico come quello del C++. Comunque esistono anche per C++ compilatori che ottimizzano a partire da dati di profiling, che non possono essere accurati come i dati raccolti da un JIT ma possono avvicinarsi.
Come ho detto: dipende dagli scenari, la regola "Java e' sempre piu' lento del C++" e' sbagliata.
Ma per programmi che fanno massicci calcoli e che hanno una data struttura predeterminata e il fattore scelta sia poco importante, il C++ resta il migliore.
No, il C++ non resta il migliore, dipende anche qui dallo scenario. Ad esempio, se cerci la miglior efficienza e i dati sono parallelizzabili la migliore implementazione e'... HLSL. Da eseguire su una GPU. E il frontend puo' essere scritto in Java o C#. Hai una soluzione anche ordini di grandezza piu' veloce di una soluzione equivalente scritta interamente in C++.
Quindi dipende anche qui dallo scenario. Il C++ e' uno strumento utilissimo in alcuni scenari, non in tutti.
Cmq per concludere il discorso: io non patteggio nè per l'uno, nè per l'altro linguaggio e anzi io conosco meglio il Java perchè l'ho già usato, mentre il C++ e le relative GUI, le conosco poco. Quindi è inutile questa competizione.
Però ultimamente ho deciso di imparare a usare anche il C++ perchè cmq lo ritengo fondamentale nella conoscenza informatica e mi piace avere gli eseguibili in formato .exe! :D
Diamonds scritto in Java e' rilasciato come .exe (http://fcarucci.homeip.net:8080/artifacts/diamonds-nightly/20080308010011/) :)
Qui non si tratta di parteggiare per uno o per l'altro linguaggio, ma di chiarire in quali ambiti uno strumento e' consigliabile e in quali ambiti non lo e'. Io programmo in C++ da vent'anni dei quali gli ultimi dieci a fare videogiochi e credo di poter dire con una certa sicurezza quando e' molto meglio non usare il C++.
Bisogna vedere preventivamente se un codice si avvantaggia di una compilazione di tipo JIT e utilizzare il linguaggio più consono in base al risultato.
Innanzitutto non e' un caso particolare, e' uno scenario, perfettamente possibile e per altro molto comune, dove un compilatore JIT puo' produrre codice piu' veloce di un compilatore statico come quello del C++. Comunque esistono anche per C++ compilatori che ottimizzano a partire da dati di profiling, che non possono essere accurati come i dati raccolti da un JIT ma possono avvicinarsi.
Come ho detto: dipende dagli scenari, la regola "Java e' sempre piu' lento del C++" e' sbagliata.
Ma per programmi che fanno massicci calcoli e che hanno una data struttura predeterminata e il fattore scelta sia poco importante, il C++ resta il migliore.
No, il C++ non resta il migliore, dipende anche qui dallo scenario. Ad esempio, se cerci la miglior efficienza e i dati sono parallelizzabili la migliore implementazione e'... HLSL. Da eseguire su una GPU. E il frontend puo' essere scritto in Java o C#. Hai una soluzione anche ordini di grandezza piu' veloce di una soluzione equivalente scritta interamente in C++.
Quindi dipende anche qui dallo scenario. Il C++ e' uno strumento utilissimo in alcuni scenari, non in tutti.
Cmq per concludere il discorso: io non patteggio nè per l'uno, nè per l'altro linguaggio e anzi io conosco meglio il Java perchè l'ho già usato, mentre il C++ e le relative GUI, le conosco poco. Quindi è inutile questa competizione.
Però ultimamente ho deciso di imparare a usare anche il C++ perchè cmq lo ritengo fondamentale nella conoscenza informatica e mi piace avere gli eseguibili in formato .exe! :D
Diamonds scritto in Java e' rilasciato come .exe (http://fcarucci.homeip.net:8080/artifacts/diamonds-nightly/20080308010011/) :)
Qui non si tratta di parteggiare per uno o per l'altro linguaggio, ma di chiarire in quali ambiti uno strumento e' consigliabile e in quali ambiti non lo e'. Io programmo in C++ da vent'anni dei quali gli ultimi dieci a fare videogiochi e credo di poter dire con una certa sicurezza quando e' molto meglio non usare il C++.
Tommo
08-03-2008, 17:50
Nessun linguaggio e' adatto per lo sviluppo completo di un gioco. Il C++ decisamente non lo e', e' forse il meno indicato di tutti data la complessita' dei sistemi che si scrivono oggi.
Un gioco oggi si sviluppa in diversi linguaggi (anche tre o quattro alla volta) a seconda del sistema che si sta scrivendo e delle esigenze. Il C++, come ho descritto, non serve per scrivere le parti piu' pesanti, ma per scrivere i sistemi dove e' necessario avere il totale controllo sul ciclo di vita degli oggetti, e la loro dislocazione in memoria.
Mi fai un esempio dei giochi e dei relativi linguaggi usati? Io da semplice user constatavo che la maggior parte dei titoli recenti ha un framework in C++ interfacciabile scriptando... ad esempio Crysis e il suo editor, oppure Civilization IV. Senza contare ovviamente i linguaggi grafici.
Cmq non ci metterei la mano sul fuoco in effetti...
Java e' perfettamente adatto a sviluppare videogiochi anche molto complessi.
Ma paradossalmente, Java è anche uno dei linguaggi meno usati in questo ambito. Lua e Phyton in confronto sono abusati :rolleyes:
Perchè? A questo punto non lo so...
Il C e' perfettamente inutile per scrivere un gioco ovunque sia disponibile un compilatore C++.
Certi pezzi dell'eseguibile saranno sempre scritti in C però, un esempio le librerie OpenAL. Certo non intendevo dire che si dovrebbe scrivere qualcosa in C.
Un gioco oggi si sviluppa in diversi linguaggi (anche tre o quattro alla volta) a seconda del sistema che si sta scrivendo e delle esigenze. Il C++, come ho descritto, non serve per scrivere le parti piu' pesanti, ma per scrivere i sistemi dove e' necessario avere il totale controllo sul ciclo di vita degli oggetti, e la loro dislocazione in memoria.
Mi fai un esempio dei giochi e dei relativi linguaggi usati? Io da semplice user constatavo che la maggior parte dei titoli recenti ha un framework in C++ interfacciabile scriptando... ad esempio Crysis e il suo editor, oppure Civilization IV. Senza contare ovviamente i linguaggi grafici.
Cmq non ci metterei la mano sul fuoco in effetti...
Java e' perfettamente adatto a sviluppare videogiochi anche molto complessi.
Ma paradossalmente, Java è anche uno dei linguaggi meno usati in questo ambito. Lua e Phyton in confronto sono abusati :rolleyes:
Perchè? A questo punto non lo so...
Il C e' perfettamente inutile per scrivere un gioco ovunque sia disponibile un compilatore C++.
Certi pezzi dell'eseguibile saranno sempre scritti in C però, un esempio le librerie OpenAL. Certo non intendevo dire che si dovrebbe scrivere qualcosa in C.
Tommo
08-03-2008, 17:53
to', me n'ero perso uno :fagiano:
e tu prova, chè potrebbe stupirti :rolleyes:
e comunque vorrei farti presente che non sono in molti oggi a sviluppare videogames per Pentium 2 :fagiano:
Si ma qua la gente fa finta di non capire... mettere Quake II e Jake SULLA STESSA CONFIG si chiama EQUA COMPETIZIONE!
Ed è anche l'unico modo per capire quale è davvero più veloce.
Grazie che Jake va come Quake su un Core2! Se fosse stato il contrario sarebbe stato proprio da ridere! :rolleyes:
Cmq a quando il porting di Crysis in Java? :rolleyes:
e tu prova, chè potrebbe stupirti :rolleyes:
e comunque vorrei farti presente che non sono in molti oggi a sviluppare videogames per Pentium 2 :fagiano:
Si ma qua la gente fa finta di non capire... mettere Quake II e Jake SULLA STESSA CONFIG si chiama EQUA COMPETIZIONE!
Ed è anche l'unico modo per capire quale è davvero più veloce.
Grazie che Jake va come Quake su un Core2! Se fosse stato il contrario sarebbe stato proprio da ridere! :rolleyes:
Cmq a quando il porting di Crysis in Java? :rolleyes:
fek
08-03-2008, 17:56
Mi fai un esempio dei giochi e dei relativi linguaggi usati? Io da semplice user constatavo che la maggior parte dei titoli recenti ha un framework in C++ interfacciabile scriptando... ad esempio Crysis e il suo editor, oppure Civilization IV. Senza contare ovviamente i linguaggi grafici.
Cmq non ci metterei la mano sul fuoco in effetti...
Civ4 e' scritto quasi interamente in Python (Cesare, calmo, non correre a comprarlo ora!!).
WoW e' scritto in larga parte in LUA.
Ma paradossalmente, Java è anche uno dei linguaggi meno usati in questo ambito. Lua e Phyton in confronto sono abusati :rolleyes:
Perchè? A questo punto non lo so...
Credo per una questione culturare e anche perche' personalmente sceglierei Java quando ho bisogno della miglior portabilita' (Diamonds ad esempio), mentre per un progetto monopiattaforma mi orienterei piu' verso C# o LUA.
LUA e' usatissimo perche' e' banale da interfacciare al C++.
Cmq a quando il porting di Crysis in Java? :rolleyes:
Oddio, Crysis non e' proprio un'esempio di efficienza ;)
Ho visto ora il tuo link, iniziativa lodevole.
Se mi permetti di darti qualche suggerimento:
- Non scrivete un "game engine", scrivete un gioco. Been there down that, non e' una buona idea ;)
- Fate le cose semplici, non cercate di scrivere tecnologia riutilizzabile, non la riutilizzerete. Scrivete un gioco, il piu' semplice possibile, che possa ragionevolmente essere concluso in un tempo breve (uno o due anni). Un game engine non mostra nulla, un gioco mostra che riuscite a produrre qualcosa ed e' l'unica cosa che conta se in un futuro volete lavorare in questo campo. Una tech demo non vi serve perche' ci sono centinaia di team di sviluppo professionisti con tecnologia migliore della vostra, piu' esperienza, piu' tempo a disposizione. Non dovete scontrarvi con loro, sulla tecnologia perderete sempre e comunque; dovete produrre cose originali.
- Non cercate un publisher. Non fate pitch. Non li guarderanno neppure e se li guardano e' perche' sono disperati e vogliono fregarvi. Perderete solo tempo. Producete qualcosa e rilasciatelo in internet.
- Meglio ancora, convertite TUTTO a XNA Studio 2.0 in C#. Vantaggi: produrrete un gioco nella meta' del tempo, potete pubblicarlo su Xbox360 Live, se va bene qualcuno lassu' lo nota sicuro. Svantaggi: per voi nessuno.
Cmq non ci metterei la mano sul fuoco in effetti...
Civ4 e' scritto quasi interamente in Python (Cesare, calmo, non correre a comprarlo ora!!).
WoW e' scritto in larga parte in LUA.
Ma paradossalmente, Java è anche uno dei linguaggi meno usati in questo ambito. Lua e Phyton in confronto sono abusati :rolleyes:
Perchè? A questo punto non lo so...
Credo per una questione culturare e anche perche' personalmente sceglierei Java quando ho bisogno della miglior portabilita' (Diamonds ad esempio), mentre per un progetto monopiattaforma mi orienterei piu' verso C# o LUA.
LUA e' usatissimo perche' e' banale da interfacciare al C++.
Cmq a quando il porting di Crysis in Java? :rolleyes:
Oddio, Crysis non e' proprio un'esempio di efficienza ;)
Ho visto ora il tuo link, iniziativa lodevole.
Se mi permetti di darti qualche suggerimento:
- Non scrivete un "game engine", scrivete un gioco. Been there down that, non e' una buona idea ;)
- Fate le cose semplici, non cercate di scrivere tecnologia riutilizzabile, non la riutilizzerete. Scrivete un gioco, il piu' semplice possibile, che possa ragionevolmente essere concluso in un tempo breve (uno o due anni). Un game engine non mostra nulla, un gioco mostra che riuscite a produrre qualcosa ed e' l'unica cosa che conta se in un futuro volete lavorare in questo campo. Una tech demo non vi serve perche' ci sono centinaia di team di sviluppo professionisti con tecnologia migliore della vostra, piu' esperienza, piu' tempo a disposizione. Non dovete scontrarvi con loro, sulla tecnologia perderete sempre e comunque; dovete produrre cose originali.
- Non cercate un publisher. Non fate pitch. Non li guarderanno neppure e se li guardano e' perche' sono disperati e vogliono fregarvi. Perderete solo tempo. Producete qualcosa e rilasciatelo in internet.
- Meglio ancora, convertite TUTTO a XNA Studio 2.0 in C#. Vantaggi: produrrete un gioco nella meta' del tempo, potete pubblicarlo su Xbox360 Live, se va bene qualcuno lassu' lo nota sicuro. Svantaggi: per voi nessuno.
Tommo
08-03-2008, 18:04
Civ4 e' scritto quasi interamente in Python (Cesare, calmo, non correre a comprarlo ora!!).
WoW e' scritto in larga parte in LUA.
Bhe sono due casi isolati comuque, anche se non c'è dubbio che la tendenza è questa.
Certamente è più comodo per chi sviluppa il gioco... cmq Civ4 era anche davvero lento! Cioè, riusciva a mettere in crisi un P4 (con 7 avversari, verso la fine) nonostante il suo gameplay lentissimo e "semplice"... gran gioco ma richiedeva proprio troppa CPU rispetto a quello che offriva...
Oddio, Crysis non e' proprio un'esempio di efficienza ;)
beh appunto :D bella sfida no?
WoW e' scritto in larga parte in LUA.
Bhe sono due casi isolati comuque, anche se non c'è dubbio che la tendenza è questa.
Certamente è più comodo per chi sviluppa il gioco... cmq Civ4 era anche davvero lento! Cioè, riusciva a mettere in crisi un P4 (con 7 avversari, verso la fine) nonostante il suo gameplay lentissimo e "semplice"... gran gioco ma richiedeva proprio troppa CPU rispetto a quello che offriva...
Oddio, Crysis non e' proprio un'esempio di efficienza ;)
beh appunto :D bella sfida no?
fek
08-03-2008, 18:06
Bhe sono due casi isolati comuque, anche se non c'è dubbio che la tendenza è questa.
Certamente è più comodo per chi sviluppa il gioco... cmq Civ4 era anche davvero lento! Cioè, riusciva a mettere in crisi un P4 (con 7 avversari, verso la fine) nonostante il suo gameplay lentissimo e "semplice"... gran gioco ma richiedeva proprio troppa CPU rispetto a quello che offriva...
Non sono casi isolati, oggi e' la norma :)
Certamente è più comodo per chi sviluppa il gioco... cmq Civ4 era anche davvero lento! Cioè, riusciva a mettere in crisi un P4 (con 7 avversari, verso la fine) nonostante il suo gameplay lentissimo e "semplice"... gran gioco ma richiedeva proprio troppa CPU rispetto a quello che offriva...
Non sono casi isolati, oggi e' la norma :)
Tommo
08-03-2008, 18:12
Se mi permetti di darti qualche suggerimento:
- Non scrivete un "game engine", scrivete un gioco. Been there down that, non e' una buona idea ;)
- Fate le cose semplici, non cercate di scrivere tecnologia riutilizzabile, non la riutilizzerete. Scrivete un gioco, il piu' semplice possibile, che possa ragionevolmente essere concluso in un tempo breve (uno o due anni). Un game engine non mostra nulla, un gioco mostra che riuscite a produrre qualcosa ed e' l'unica cosa che conta se in un futuro volete lavorare in questo campo. Una tech demo non vi serve perche' ci sono centinaia di team di sviluppo professionisti con tecnologia migliore della vostra, piu' esperienza, piu' tempo a disposizione. Non dovete scontrarvi con loro, sulla tecnologia perderete sempre e comunque; dovete produrre cose originali.
- Non cercate un publisher. Non fate pitch. Non li guarderanno neppure e se li guardano e' perche' sono disperati e vogliono fregarvi. Perderete solo tempo. Producete qualcosa e rilasciatelo in internet.
- Meglio ancora, convertite TUTTO a XNA Studio 2.0 in C#. Vantaggi: produrrete un gioco nella meta' del tempo, potete pubblicarlo su Xbox360 Live, se va bene qualcuno lassu' lo nota sicuro. Svantaggi: per voi nessuno.
Sono d'accordo con tutto, ma ci sono ragioni se abbiamo fatto così: prima di tutto essendo alle prime armi abbiamo voluto imparare come "sono fatte le cose", quindi facendo "in casa" il più possibile.
Abbiamo tentato di creare un engine generico nonostante avessimo il gioco bene in mente sempre per imparare a programmare "ad alto livello", e i risultati sono stati molto buoni (GameObjects a moduli, fisica con ragdolls e fluidi, HDR, DOF e PerPixelMotion Blur)...
alla fine però ci è servito avere un engine così generico: abbiamo fatto il tuo stesso ragionamento ed abbiamo iniziato lo sviluppo di un gioco semplice ma innovativo, da pubblicare su internet per dire che qualcosa lo sappiamo fare.
Poi si riprenderà il "progettone" :D
- Non scrivete un "game engine", scrivete un gioco. Been there down that, non e' una buona idea ;)
- Fate le cose semplici, non cercate di scrivere tecnologia riutilizzabile, non la riutilizzerete. Scrivete un gioco, il piu' semplice possibile, che possa ragionevolmente essere concluso in un tempo breve (uno o due anni). Un game engine non mostra nulla, un gioco mostra che riuscite a produrre qualcosa ed e' l'unica cosa che conta se in un futuro volete lavorare in questo campo. Una tech demo non vi serve perche' ci sono centinaia di team di sviluppo professionisti con tecnologia migliore della vostra, piu' esperienza, piu' tempo a disposizione. Non dovete scontrarvi con loro, sulla tecnologia perderete sempre e comunque; dovete produrre cose originali.
- Non cercate un publisher. Non fate pitch. Non li guarderanno neppure e se li guardano e' perche' sono disperati e vogliono fregarvi. Perderete solo tempo. Producete qualcosa e rilasciatelo in internet.
- Meglio ancora, convertite TUTTO a XNA Studio 2.0 in C#. Vantaggi: produrrete un gioco nella meta' del tempo, potete pubblicarlo su Xbox360 Live, se va bene qualcuno lassu' lo nota sicuro. Svantaggi: per voi nessuno.
Sono d'accordo con tutto, ma ci sono ragioni se abbiamo fatto così: prima di tutto essendo alle prime armi abbiamo voluto imparare come "sono fatte le cose", quindi facendo "in casa" il più possibile.
Abbiamo tentato di creare un engine generico nonostante avessimo il gioco bene in mente sempre per imparare a programmare "ad alto livello", e i risultati sono stati molto buoni (GameObjects a moduli, fisica con ragdolls e fluidi, HDR, DOF e PerPixelMotion Blur)...
alla fine però ci è servito avere un engine così generico: abbiamo fatto il tuo stesso ragionamento ed abbiamo iniziato lo sviluppo di un gioco semplice ma innovativo, da pubblicare su internet per dire che qualcosa lo sappiamo fare.
Poi si riprenderà il "progettone" :D
fek
08-03-2008, 18:23
Sono d'accordo con tutto, ma ci sono ragioni se abbiamo fatto così: prima di tutto essendo alle prime armi abbiamo voluto imparare come "sono fatte le cose", quindi facendo "in casa" il più possibile.
Abbiamo tentato di creare un engine generico nonostante avessimo il gioco bene in mente sempre per imparare a programmare "ad alto livello", e i risultati sono stati molto buoni (GameObjects a moduli, fisica con ragdolls e fluidi, HDR, DOF e PerPixelMotion Blur)...
alla fine però ci è servito avere un engine così generico: abbiamo fatto il tuo stesso ragionamento ed abbiamo iniziato lo sviluppo di un gioco semplice ma innovativo, da pubblicare su internet per dire che qualcosa lo sappiamo fare.
Poi si riprenderà il "progettone" :D
Le ragioni per le quali avete fatto cosi' sono indifferenti. Non fatelo ;)
Ripartite con un engine semplice e non generico, tanto non lo riutilizzerete. Usatelo semplicemente come prototipo sul quale avete fatto esperienza, che fa comunque bene. Fate tutto possibilmente con XNA Studio in C#. Ti dico queste cose perche' ho visto decine (ma dico decine e decine, me compreso) di team fare esattamente la vostra strada... nessuno ne ha cavato un ragno dal buco.
Non lo dico per spaventarti, ma per metterti sulla via piu' efficiente se vuoi fare videogiochi "da grande". E aggiungo: se questa e' la strada che hai scelto, non farai videogiochi con questo team e non lo farai in Italia. Quindi preparati a dover andar via.
Abbiamo tentato di creare un engine generico nonostante avessimo il gioco bene in mente sempre per imparare a programmare "ad alto livello", e i risultati sono stati molto buoni (GameObjects a moduli, fisica con ragdolls e fluidi, HDR, DOF e PerPixelMotion Blur)...
alla fine però ci è servito avere un engine così generico: abbiamo fatto il tuo stesso ragionamento ed abbiamo iniziato lo sviluppo di un gioco semplice ma innovativo, da pubblicare su internet per dire che qualcosa lo sappiamo fare.
Poi si riprenderà il "progettone" :D
Le ragioni per le quali avete fatto cosi' sono indifferenti. Non fatelo ;)
Ripartite con un engine semplice e non generico, tanto non lo riutilizzerete. Usatelo semplicemente come prototipo sul quale avete fatto esperienza, che fa comunque bene. Fate tutto possibilmente con XNA Studio in C#. Ti dico queste cose perche' ho visto decine (ma dico decine e decine, me compreso) di team fare esattamente la vostra strada... nessuno ne ha cavato un ragno dal buco.
Non lo dico per spaventarti, ma per metterti sulla via piu' efficiente se vuoi fare videogiochi "da grande". E aggiungo: se questa e' la strada che hai scelto, non farai videogiochi con questo team e non lo farai in Italia. Quindi preparati a dover andar via.
Tommo
08-03-2008, 18:37
Le ragioni per le quali avete fatto cosi' sono indifferenti. Non fatelo ;)
Ripartite con un engine semplice e non generico, tanto non lo riutilizzerete. Usatelo semplicemente come prototipo sul quale avete fatto esperienza, che fa comunque bene. Fate tutto possibilmente con XNA Studio in C#. Ti dico queste cose perche' ho visto decine (ma dico decine e decine, me compreso) di team fare esattamente la vostra strada... nessuno ne ha cavato un ragno dal buco.
Non lo dico per spaventarti, ma per metterti sulla via piu' efficiente se vuoi fare videogiochi "da grande". E aggiungo: se questa e' la strada che hai scelto, non farai videogiochi con questo team e non lo farai in Italia. Quindi preparati a dover andar via.
Perchè dovremmo usare XNA e C# quando la nostra engine ha più features, è più efficiente ed è più controllabile?
Abbiamo la grafica di Ogre3D, la fisica di PhysX (che in XNA non c'è), suono 3d perfettamente integrato e altro.
Fossimo a 0 si poteva pensare, ma ora è stupido.
Poi non sono d'accordo sul non generico... le nuove engines fanno così affidamento sullo scripting soprattutto per essere riciclate a volontà, e il trend del futuro è usare solo middleware molto generico (UE3, Cryengine)...
Cmq io lo faccio per imparare, e XNA non mi da nulla da questo punto di vista. Io anzi sto pensando di scrivermi un engine da me più avanti... sennò quando chiedono "esperienza in DirectX e Sottosistemi video" io gli dico che ho usato XNA? :rolleyes:
Cmq ci ho già contato di dover andare all'estero, e nemmeno mi dispiace come idea. Anche se in fondo questo team è in piedi già da un anno e credo che abbiamo qualche probabilità... mai dire mai ;)
PS: Sto ancora al liceo, ho tempo ancora...
Ripartite con un engine semplice e non generico, tanto non lo riutilizzerete. Usatelo semplicemente come prototipo sul quale avete fatto esperienza, che fa comunque bene. Fate tutto possibilmente con XNA Studio in C#. Ti dico queste cose perche' ho visto decine (ma dico decine e decine, me compreso) di team fare esattamente la vostra strada... nessuno ne ha cavato un ragno dal buco.
Non lo dico per spaventarti, ma per metterti sulla via piu' efficiente se vuoi fare videogiochi "da grande". E aggiungo: se questa e' la strada che hai scelto, non farai videogiochi con questo team e non lo farai in Italia. Quindi preparati a dover andar via.
Perchè dovremmo usare XNA e C# quando la nostra engine ha più features, è più efficiente ed è più controllabile?
Abbiamo la grafica di Ogre3D, la fisica di PhysX (che in XNA non c'è), suono 3d perfettamente integrato e altro.
Fossimo a 0 si poteva pensare, ma ora è stupido.
Poi non sono d'accordo sul non generico... le nuove engines fanno così affidamento sullo scripting soprattutto per essere riciclate a volontà, e il trend del futuro è usare solo middleware molto generico (UE3, Cryengine)...
Cmq io lo faccio per imparare, e XNA non mi da nulla da questo punto di vista. Io anzi sto pensando di scrivermi un engine da me più avanti... sennò quando chiedono "esperienza in DirectX e Sottosistemi video" io gli dico che ho usato XNA? :rolleyes:
Cmq ci ho già contato di dover andare all'estero, e nemmeno mi dispiace come idea. Anche se in fondo questo team è in piedi già da un anno e credo che abbiamo qualche probabilità... mai dire mai ;)
PS: Sto ancora al liceo, ho tempo ancora...
Naufr4g0
08-03-2008, 19:15
Qui non si tratta di parteggiare per uno o per l'altro linguaggio, ma di chiarire in quali ambiti uno strumento e' consigliabile e in quali ambiti non lo e'. Io programmo in C++ da vent'anni dei quali gli ultimi dieci a fare videogiochi e credo di poter dire con una certa sicurezza quando e' molto meglio non usare il C++.
Per fare videogiochi cosa usi? E a me cosa consigli per creare giochi 2D? A me interessano scrolling, livelli di parallasse, gestione degli sprite e delle collisioni...
Io ho solo esperienza col j2me, che ho trovato molto pratico e con librerie che semplificano molto l'utilizzo della grafica.
Ho visto che ci sono varie librerie per C++ (Allegro, SDL) che aiutano per questi lavori, ma non saprei quale utilizzare, oppure cambio proprio linguaggio?
Per fare videogiochi cosa usi? E a me cosa consigli per creare giochi 2D? A me interessano scrolling, livelli di parallasse, gestione degli sprite e delle collisioni...
Io ho solo esperienza col j2me, che ho trovato molto pratico e con librerie che semplificano molto l'utilizzo della grafica.
Ho visto che ci sono varie librerie per C++ (Allegro, SDL) che aiutano per questi lavori, ma non saprei quale utilizzare, oppure cambio proprio linguaggio?
fek
08-03-2008, 20:15
Perchè dovremmo usare XNA e C# quando la nostra engine ha più features, è più efficiente ed è più controllabile?
Abbiamo la grafica di Ogre3D, la fisica di PhysX (che in XNA non c'è), suono 3d perfettamente integrato e altro.
Fossimo a 0 si poteva pensare, ma ora è stupido.
Ah le stesse cose che dicevo io quando iniziai dieci anni fa :)
Non e' affatto stupido ricominciare da zero con XNA con l'esperienza gia' acquisita perche':
- per un gioco semplice le feature, l'efficienza e la controllabilita' non vi servono, vi serve la semplicita' e la possibilita' di produrre qualcosa
- scrivendo in C# e non in C++ sarete molto piu' produttivi
- con XNA potete rilasciare il gioco sia per PC sia per X360
C'e' tutto da guadagnare, nulla da perdere: voi non dovete giocare sulle feature di un engine o sulla sua efficienza, dovete produrre qualcosa di tangibile e finito.
Poi non sono d'accordo sul non generico... le nuove engines fanno così affidamento sullo scripting soprattutto per essere riciclate a volontà, e il trend del futuro è usare solo middleware molto generico (UE3, Cryengine)...
A parte che i nuovi engine sono prodotti da team di decine di persone con decine di anni di esperienza e nonostante tutto il fatto di essere generici gli crea enormi problemi. UE3 e il Cryengine non sono gli engine piu' efficienti, al contrario, proprio perche' c'erano di essere generici.
Ed Epic produce engine da vent'anni, come pensi di poter produrre qualcosa di generico e usabile senza esperienza?
Non puoi, quindi fai le cose semplici, quelle feature non vi servono. Non vi serve HDR, non avreste neppure gli artisti in grado di farne uso in maniera sensata, non vi serve il rag doll, non vi serve nulla di tutto cio': vi serve un gioco semplice e nient'altro.
Cmq io lo faccio per imparare, e XNA non mi da nulla da questo punto di vista. Io anzi sto pensando di scrivermi un engine da me più avanti... sennò quando chiedono "esperienza in DirectX e Sottosistemi video" io gli dico che ho usato XNA? :rolleyes:
Si', gli dici che hai usato XNA e che conosci le problematiche della programmazione per console e vedrai che saranno piu' impressionati di quanto lo sarebbero se gli dicessi "ho scritto un engine 3d generico che fa HDR ed e' efficientissimo" :)
Quando mi si presenta una cosa simile ad un colloquio, il colloquio dura dieci minuti.
Ripeto, io sono gia' passato attraverso tutto quello che hai citato, facendo esattamente tutti i discorsi che fai tu adesso. Poi ho iniziato a lavorare nel campo ed ho imparato.
Tu pensa che Federico che ora lavora in Codemasters, l'anno scorso ha fatto esperienza in Java su Diamonds e sul curriculum ha potuto scrivere un progetto concluso e rilasciato assieme ad un team di sviluppo. Non c'era ne' HDR ne' DOF ne' POM ne' 3D.
Abbiamo la grafica di Ogre3D, la fisica di PhysX (che in XNA non c'è), suono 3d perfettamente integrato e altro.
Fossimo a 0 si poteva pensare, ma ora è stupido.
Ah le stesse cose che dicevo io quando iniziai dieci anni fa :)
Non e' affatto stupido ricominciare da zero con XNA con l'esperienza gia' acquisita perche':
- per un gioco semplice le feature, l'efficienza e la controllabilita' non vi servono, vi serve la semplicita' e la possibilita' di produrre qualcosa
- scrivendo in C# e non in C++ sarete molto piu' produttivi
- con XNA potete rilasciare il gioco sia per PC sia per X360
C'e' tutto da guadagnare, nulla da perdere: voi non dovete giocare sulle feature di un engine o sulla sua efficienza, dovete produrre qualcosa di tangibile e finito.
Poi non sono d'accordo sul non generico... le nuove engines fanno così affidamento sullo scripting soprattutto per essere riciclate a volontà, e il trend del futuro è usare solo middleware molto generico (UE3, Cryengine)...
A parte che i nuovi engine sono prodotti da team di decine di persone con decine di anni di esperienza e nonostante tutto il fatto di essere generici gli crea enormi problemi. UE3 e il Cryengine non sono gli engine piu' efficienti, al contrario, proprio perche' c'erano di essere generici.
Ed Epic produce engine da vent'anni, come pensi di poter produrre qualcosa di generico e usabile senza esperienza?
Non puoi, quindi fai le cose semplici, quelle feature non vi servono. Non vi serve HDR, non avreste neppure gli artisti in grado di farne uso in maniera sensata, non vi serve il rag doll, non vi serve nulla di tutto cio': vi serve un gioco semplice e nient'altro.
Cmq io lo faccio per imparare, e XNA non mi da nulla da questo punto di vista. Io anzi sto pensando di scrivermi un engine da me più avanti... sennò quando chiedono "esperienza in DirectX e Sottosistemi video" io gli dico che ho usato XNA? :rolleyes:
Si', gli dici che hai usato XNA e che conosci le problematiche della programmazione per console e vedrai che saranno piu' impressionati di quanto lo sarebbero se gli dicessi "ho scritto un engine 3d generico che fa HDR ed e' efficientissimo" :)
Quando mi si presenta una cosa simile ad un colloquio, il colloquio dura dieci minuti.
Ripeto, io sono gia' passato attraverso tutto quello che hai citato, facendo esattamente tutti i discorsi che fai tu adesso. Poi ho iniziato a lavorare nel campo ed ho imparato.
Tu pensa che Federico che ora lavora in Codemasters, l'anno scorso ha fatto esperienza in Java su Diamonds e sul curriculum ha potuto scrivere un progetto concluso e rilasciato assieme ad un team di sviluppo. Non c'era ne' HDR ne' DOF ne' POM ne' 3D.
fek
08-03-2008, 20:16
Per fare videogiochi cosa usi? E a me cosa consigli per creare giochi 2D? A me interessano scrolling, livelli di parallasse, gestione degli sprite e delle collisioni...
Io ho solo esperienza col j2me, che ho trovato molto pratico e con librerie che semplificano molto l'utilizzo della grafica.
Ho visto che ci sono varie librerie per C++ (Allegro, SDL) che aiutano per questi lavori, ma non saprei quale utilizzare, oppure cambio proprio linguaggio?
Se hai esperienza con j2me e vuoi fare un gioco 2D continua pure con Java che va benissimo. In Diamonds usiamo LWGL.
Io ho solo esperienza col j2me, che ho trovato molto pratico e con librerie che semplificano molto l'utilizzo della grafica.
Ho visto che ci sono varie librerie per C++ (Allegro, SDL) che aiutano per questi lavori, ma non saprei quale utilizzare, oppure cambio proprio linguaggio?
Se hai esperienza con j2me e vuoi fare un gioco 2D continua pure con Java che va benissimo. In Diamonds usiamo LWGL.
Tommo
08-03-2008, 20:45
...
D'infatti io ho detto che abbiamo fatto un ragionamento come il tuo e ci siamo buttati su un one-month-game da regalare su internet, basato semplicemente su un concetto carino e divertente! :D
Non che la tecnica sia del tutto scrausa, non mancheremo di mettere qualche feature avanzata; solo che in questo caso, lo scopo principale è finire il progetto... cosa non del tutto scontata di solito!
E cmq lo facciamo col nostro engine perchè funziona ed è completo (non finito). Non vedo perchè reimparare un engine che non ci offre nulla di più del nostro... è anche portabile su console, essendo basato su DX e PhysX... il problema in quel caso sono i pacchi di soldi che partono! (solo physx sono 50.000$)
D'infatti io ho detto che abbiamo fatto un ragionamento come il tuo e ci siamo buttati su un one-month-game da regalare su internet, basato semplicemente su un concetto carino e divertente! :D
Non che la tecnica sia del tutto scrausa, non mancheremo di mettere qualche feature avanzata; solo che in questo caso, lo scopo principale è finire il progetto... cosa non del tutto scontata di solito!
E cmq lo facciamo col nostro engine perchè funziona ed è completo (non finito). Non vedo perchè reimparare un engine che non ci offre nulla di più del nostro... è anche portabile su console, essendo basato su DX e PhysX... il problema in quel caso sono i pacchi di soldi che partono! (solo physx sono 50.000$)
fek
08-03-2008, 22:03
Io ti ho raccontato la mia esperienza e dato i consigli che ne derivano. Per il resto, buona fortuna ;)
cdimauro
08-03-2008, 22:05
ma java è usato per programmare i giochi in ambito professionale? o è solo un vostro "esperimento"?
Su mobile Java è LA piattaforma di riferimento. Più precisamente lo è J2ME.
Google Android, poi, è basato su Java (proprio Java, al completo, e non J2ME) e infatti si possono fare cose egregie.
Questo lato mobile (visto che per lavoro mi occupo di questo campo), ma il discorso è perfettamente applicabile anche a piattaforme di intrattenimento diverse.
Civ4 e' scritto quasi interamente in Python (Cesare, calmo, non correre a comprarlo ora!!).
Avessi il tempo per giocare!!! :cry:
Se mi permetti di darti qualche suggerimento:
- Non cercate un publisher. Non fate pitch. Non li guarderanno neppure e se li guardano e' perche' sono disperati e vogliono fregarvi. Perderete solo tempo.
A chi lo dici: i pitch sono un terno al lotto. Sia quelli che creiamo "internamente" ("original concept") sia quelli che ci vengono richiesti dagli stessi publisher ("work for hire", che è il tipo di lavoro che tipicamente ci perviene), hanno ben poche probabilità avere un futuro e di essere pubblicati. :muro:
Bisogna trovare un'idea veramente azzeccatissima (merce più unica che rara) oppure, come dici tu, il publisher disperato che sta cercando di riempire lo slot per il "Quarter x" con qualcosa di pronto (o quasi) e che il reparto sales ritenga sufficiente proficuo.
Insomma, un inferno. Oggi il mercato è veramente molto... troppo difficile. :muro: :muro: :muro:
Su mobile Java è LA piattaforma di riferimento. Più precisamente lo è J2ME.
Google Android, poi, è basato su Java (proprio Java, al completo, e non J2ME) e infatti si possono fare cose egregie.
Questo lato mobile (visto che per lavoro mi occupo di questo campo), ma il discorso è perfettamente applicabile anche a piattaforme di intrattenimento diverse.
Civ4 e' scritto quasi interamente in Python (Cesare, calmo, non correre a comprarlo ora!!).
Avessi il tempo per giocare!!! :cry:
Se mi permetti di darti qualche suggerimento:
- Non cercate un publisher. Non fate pitch. Non li guarderanno neppure e se li guardano e' perche' sono disperati e vogliono fregarvi. Perderete solo tempo.
A chi lo dici: i pitch sono un terno al lotto. Sia quelli che creiamo "internamente" ("original concept") sia quelli che ci vengono richiesti dagli stessi publisher ("work for hire", che è il tipo di lavoro che tipicamente ci perviene), hanno ben poche probabilità avere un futuro e di essere pubblicati. :muro:
Bisogna trovare un'idea veramente azzeccatissima (merce più unica che rara) oppure, come dici tu, il publisher disperato che sta cercando di riempire lo slot per il "Quarter x" con qualcosa di pronto (o quasi) e che il reparto sales ritenga sufficiente proficuo.
Insomma, un inferno. Oggi il mercato è veramente molto... troppo difficile. :muro: :muro: :muro:
a2000.1
08-03-2008, 22:17
insomma Tommo comprati una PlayStation (2) e non rompere i c. :mad: :D
cionci
09-03-2008, 01:12
insomma Tommo comprati una PlayStation (2) e non rompere i c. :mad: :D
Dai a2000, non mi sembra il caso.
Dai a2000, non mi sembra il caso.
theberto
09-03-2008, 14:17
qual'è il gioco piu sempilce da fare in c++?
pong?
pong?
71104
09-03-2008, 14:42
qual'è il gioco piu sempilce da fare in c++?
pong? no, perché pong deve essere per forza grafico. il gioco più semplice che si possa fare deve essere testuale (CUI, Console User Interface).
pong? no, perché pong deve essere per forza grafico. il gioco più semplice che si possa fare deve essere testuale (CUI, Console User Interface).
Tommo
09-03-2008, 14:50
EDIT - Fa niente:rolleyes:
cionci
09-03-2008, 14:52
Tommo: l'avevo già ripreso io, non c'era bisogno di questo tuo intervento.
theberto
09-03-2008, 19:56
no, perché pong deve essere per forza grafico. il gioco più semplice che si possa fare deve essere testuale (CUI, Console User Interface).
quindi quale potrebbe essere?
utilizzando solo caretteri ascii ovviamente
quindi quale potrebbe essere?
utilizzando solo caretteri ascii ovviamente
cdimauro
09-03-2008, 20:10
Quello del serpentone, nibble.
In qualche thread MOLTO vecchio troverai la versione di Fran e quella mia, che "in gioventù" ci siamo cimentati nella sua (ri)scrittura. :p
In qualche thread MOLTO vecchio troverai la versione di Fran e quella mia, che "in gioventù" ci siamo cimentati nella sua (ri)scrittura. :p
71104
09-03-2008, 20:40
cdimauro ha un debole per i serpenti :asd:
comunque non è possibile programmare uno snake in C++ standard perché non è possibile collocare caratteri ASCII in posizioni arbitrarie sulla console (o sul terminale o su quello che è): lo standard output è uno stream, è un flusso unidirezionale.
per un controllo più approfondito dell'interfaccia CUI è necessario ricorrere a funzioni specifiche della piattaforma.
comunque non è possibile programmare uno snake in C++ standard perché non è possibile collocare caratteri ASCII in posizioni arbitrarie sulla console (o sul terminale o su quello che è): lo standard output è uno stream, è un flusso unidirezionale.
per un controllo più approfondito dell'interfaccia CUI è necessario ricorrere a funzioni specifiche della piattaforma.
wingman87
09-03-2008, 21:56
A proposito di giochi fatti di caratteri... quando ero piccolo avevo un gioco che si chiamava "jimmy il bruco", qualcuno lo conosce? O conosce il suo nome originale? Il fatto è che il nome era scritto sul dischetto da 5¼ pollici, l'aveva scritto mio padre ma non so quale fosse il nome originale perché sicuramente era in inglese e io non ne capivo niente (avrò avuto 5 anni). Praticamente jimmy era una "S" o un "$" non ricordo più e doveva arrivare all'uscita del livello saltando ostacoli salendo scale e cose così... Cercando su google l'unico riferimento che ho trovato è questo: LINK (http://www.qnait.com/giochi/3018-giochi-2ci.html)
E' solo curiosità, è un ricordo di infanzia, forse da qualche parte ce l'ho ancora :)
E' solo curiosità, è un ricordo di infanzia, forse da qualche parte ce l'ho ancora :)
marco.r
09-03-2008, 22:38
cdimauro ha un debole per i serpenti :asd:
comunque non è possibile programmare uno snake in C++ standard perché non è possibile collocare caratteri ASCII in posizioni arbitrarie sulla console (o sul terminale o su quello che è): lo standard output è uno stream, è un flusso unidirezionale.
per un controllo più approfondito dell'interfaccia CUI è necessario ricorrere a funzioni specifiche della piattaforma.
Dire "C++ standard" non vuol dire usare solo la libreria standard :mbe:, anche se ho capito cosa vuoi dire.
In realta' si potrebbe anche fare in modo portabile (ci sono versioni dellle curses anche per windows ad esempio), ma forse a questo punto diventa piu' facile partire con la gui :p
comunque non è possibile programmare uno snake in C++ standard perché non è possibile collocare caratteri ASCII in posizioni arbitrarie sulla console (o sul terminale o su quello che è): lo standard output è uno stream, è un flusso unidirezionale.
per un controllo più approfondito dell'interfaccia CUI è necessario ricorrere a funzioni specifiche della piattaforma.
Dire "C++ standard" non vuol dire usare solo la libreria standard :mbe:, anche se ho capito cosa vuoi dire.
In realta' si potrebbe anche fare in modo portabile (ci sono versioni dellle curses anche per windows ad esempio), ma forse a questo punto diventa piu' facile partire con la gui :p
m.distrutti
09-03-2008, 23:07
come posso programmare giochi in c++ come ad esempio supermario?
mi sa che ti hanno snobbato qui nel topic ahahah
scusate sto piccolo spam ma non siamo arrivati OT :rolleyes:
mi sa che ti hanno snobbato qui nel topic ahahah
scusate sto piccolo spam ma non siamo arrivati OT :rolleyes:
Naufr4g0
09-03-2008, 23:49
Curioso, anch'io ho programmato un giochino sul serpente anni e anni fa, col Qbasic del dos! ;)
Era in un labirinto e avevo inserito delle features come il teletrasporto.. peccato che è andato perso insieme all'HD del vecchio portatile, che si è fuso.
Sarà la tappa obbligata del programmatore? huahuahu
Era in un labirinto e avevo inserito delle features come il teletrasporto.. peccato che è andato perso insieme all'HD del vecchio portatile, che si è fuso.
Sarà la tappa obbligata del programmatore? huahuahu
Fallingwater
01-02-2011, 21:19
A proposito di giochi fatti di caratteri... quando ero piccolo avevo un gioco che si chiamava "jimmy il bruco", qualcuno lo conosce? O conosce il suo nome originale? Il fatto è che il nome era scritto sul dischetto da 5¼ pollici, l'aveva scritto mio padre ma non so quale fosse il nome originale perché sicuramente era in inglese e io non ne capivo niente (avrò avuto 5 anni). Praticamente jimmy era una "S" o un "$" non ricordo più e doveva arrivare all'uscita del livello saltando ostacoli salendo scale e cose così... Cercando su google l'unico riferimento che ho trovato è questo: LINK (http://www.qnait.com/giochi/3018-giochi-2ci.html)
E' solo curiosità, è un ricordo di infanzia, forse da qualche parte ce l'ho ancora
Scusate l'up...
Wingman: questo 3d è spuntato fuori in una ricerca su Jimmy il Bruco... anche io avevo questo gioco sul mio stravecchio PC1 Olivetti. Recentemente ho recuperato il computer e i dischetti, e volevo rigiocarci in memoria dei vecchi tempi (era il mio gioco preferito), ma i dati nel dischetto sono andati al Valhalla... non è che riusciresti a recuperarlo, se i tuoi dischi hanno avuto più fortuna?
E' solo curiosità, è un ricordo di infanzia, forse da qualche parte ce l'ho ancora
Scusate l'up...
Wingman: questo 3d è spuntato fuori in una ricerca su Jimmy il Bruco... anche io avevo questo gioco sul mio stravecchio PC1 Olivetti. Recentemente ho recuperato il computer e i dischetti, e volevo rigiocarci in memoria dei vecchi tempi (era il mio gioco preferito), ma i dati nel dischetto sono andati al Valhalla... non è che riusciresti a recuperarlo, se i tuoi dischi hanno avuto più fortuna?
wingman87
02-02-2011, 00:02
Scusate l'up...
Wingman: questo 3d è spuntato fuori in una ricerca su Jimmy il Bruco... anche io avevo questo gioco sul mio stravecchio PC1 Olivetti. Recentemente ho recuperato il computer e i dischetti, e volevo rigiocarci in memoria dei vecchi tempi (era il mio gioco preferito), ma i dati nel dischetto sono andati al Valhalla... non è che riusciresti a recuperarlo, se i tuoi dischi hanno avuto più fortuna?
Vorrei recuperarlo ma non so dove cercarlo, c'è una tale confusione a casa mia. Oltretutto temo, ma non sono sicuro, che mia madre abbia buttato via tutto anni fa.
Wingman: questo 3d è spuntato fuori in una ricerca su Jimmy il Bruco... anche io avevo questo gioco sul mio stravecchio PC1 Olivetti. Recentemente ho recuperato il computer e i dischetti, e volevo rigiocarci in memoria dei vecchi tempi (era il mio gioco preferito), ma i dati nel dischetto sono andati al Valhalla... non è che riusciresti a recuperarlo, se i tuoi dischi hanno avuto più fortuna?
Vorrei recuperarlo ma non so dove cercarlo, c'è una tale confusione a casa mia. Oltretutto temo, ma non sono sicuro, che mia madre abbia buttato via tutto anni fa.
Tommo
02-02-2011, 02:08
rileggere posts del 2008 di me che parlo di game dev mi ha ricordato che c'è sempre un sacco da imparare :D
Però dopo questi 3 anni java continua ad essere pessimo per fare giochi :asd:
Però dopo questi 3 anni java continua ad essere pessimo per fare giochi :asd:
pabloski
02-02-2011, 12:40
rileggere posts del 2008 di me che parlo di game dev mi ha ricordato che c'è sempre un sacco da imparare :D
Però dopo questi 3 anni java continua ad essere pessimo per fare giochi :asd:
dai, non è vero che java è pessimo per fare giochi....prendi ad esempio jmonkeyengine che è un ottimo motore scritto in java
ad ogni modo non è peggio di c# e xna, stanno sulla stessa barca alla fine
imho la risposta di fek era la migliore e cioè che un engine NON PUO' essere scritto in linguaggio garbage collected, a meno di amare lo spreco di risorse e questo vale tanto per java quanto per c#
però nessuno ti vieta di usare c/c++ e jni e hai fatto il colpaccio....teniamo presente che ci sono compilatori che compilano codice java in codice nativo e quindi si risolve pure l'eventuale problema di perdita di performance dovuta alla compilazione jit
Però dopo questi 3 anni java continua ad essere pessimo per fare giochi :asd:
dai, non è vero che java è pessimo per fare giochi....prendi ad esempio jmonkeyengine che è un ottimo motore scritto in java
ad ogni modo non è peggio di c# e xna, stanno sulla stessa barca alla fine
imho la risposta di fek era la migliore e cioè che un engine NON PUO' essere scritto in linguaggio garbage collected, a meno di amare lo spreco di risorse e questo vale tanto per java quanto per c#
però nessuno ti vieta di usare c/c++ e jni e hai fatto il colpaccio....teniamo presente che ci sono compilatori che compilano codice java in codice nativo e quindi si risolve pure l'eventuale problema di perdita di performance dovuta alla compilazione jit
banryu79
02-02-2011, 13:13
dai, non è vero che java è pessimo per fare giochi....
Lascia perdere, era una palese provocazione :D
(C'è un thread dello scorso autunno dove si parlava di giochi e engine 3D e si citavano giochi commerciali in cui si evinceva che l'uso di linguaggi ad alto livello di astrazione, Java compreso, era molto consistente ai fini dell'implementazione del gioco inteso come logica. Ovviamente non per l'engine grafico, ma per tutto il resto sì (e non è poco)).
Lascia perdere, era una palese provocazione :D
(C'è un thread dello scorso autunno dove si parlava di giochi e engine 3D e si citavano giochi commerciali in cui si evinceva che l'uso di linguaggi ad alto livello di astrazione, Java compreso, era molto consistente ai fini dell'implementazione del gioco inteso come logica. Ovviamente non per l'engine grafico, ma per tutto il resto sì (e non è poco)).
Tommo
02-02-2011, 14:27
Ancora co sto jit... il problema di Java nei giochi è che si è ormai totalmente orientato al business.
Ad esempio nei giochi Indie/PC, le prestazioni non contano più nulla: basti pensare a giochi come Braid, World of Goo, Cave Story, Minecraft, Plants Vs Zombies, e un fottio di altri che vanno di lusso sul più scrauso dei netbook.
L'idea di stare stretti nelle risorse di un PC moderno solo perchè c'è un GC è del tutto ridicola, se si sa dove mettere le mani, e nè Java nè C# sono più interpretati :read:
A meno che non si abbia le risorse per fare un gioco AAA, e allora Java va stretto perchè è troppo lento, ma questo non ci riguarda.
Il problema del Java per noi comuni mortali è la mancanza di librerie, documentazione e community a proposito del gamedev, che ormai è troppo grave perchè possa mai recuperare.
C++ offre tutto quello che è "pro", C# ha XNA, MSDN e un fiorire di motori (e Xbox e WP7 come piattaforme), Flash ha il web, e anche Python che di sicuro è molto più lento di Java sta conoscendo un'ottima diffusione grazie a librerie che ti mollano tutta la pappa pronta come Pyglet o Pygame...
java invece ha poca roba incompleta e mal documentata, e soprattutto è visto come un business language (e ammetto che per questo tanti game dev lo odiano per partito preso :asd: )
Non è una questione tecnica, è pura economia di scala :D
Ad esempio nei giochi Indie/PC, le prestazioni non contano più nulla: basti pensare a giochi come Braid, World of Goo, Cave Story, Minecraft, Plants Vs Zombies, e un fottio di altri che vanno di lusso sul più scrauso dei netbook.
L'idea di stare stretti nelle risorse di un PC moderno solo perchè c'è un GC è del tutto ridicola, se si sa dove mettere le mani, e nè Java nè C# sono più interpretati :read:
A meno che non si abbia le risorse per fare un gioco AAA, e allora Java va stretto perchè è troppo lento, ma questo non ci riguarda.
Il problema del Java per noi comuni mortali è la mancanza di librerie, documentazione e community a proposito del gamedev, che ormai è troppo grave perchè possa mai recuperare.
C++ offre tutto quello che è "pro", C# ha XNA, MSDN e un fiorire di motori (e Xbox e WP7 come piattaforme), Flash ha il web, e anche Python che di sicuro è molto più lento di Java sta conoscendo un'ottima diffusione grazie a librerie che ti mollano tutta la pappa pronta come Pyglet o Pygame...
java invece ha poca roba incompleta e mal documentata, e soprattutto è visto come un business language (e ammetto che per questo tanti game dev lo odiano per partito preso :asd: )
Non è una questione tecnica, è pura economia di scala :D
pabloski
02-02-2011, 14:54
Il mio intervento era riferito all'aspetto tecnologico e di performance. Logicamente java è usato in ambiti molto diversi dal game dev e chiaramente non ha le millemila librerie tipiche di altri ambiti.
Il punto è che c# o java sono una scommessa a perdere se vuoi fare un nuovo crysis et similia. Il fatto che i pc di oggi siano potenti non deve trarti in inganno e pensare che possiamo affidare tutto ad un gc tanto abbiamo 8 gb di ram. I game dev sanno come distruggere un hardware ultrapotente fino a ridurlo all'impotenza.
Il fatto che si usi c++ per i game engine è proprio dovuto alla necessità di ottimizzare il codice all'inverosimile e sfruttare la memoria nel modo più parsimonioso possibile.
Non è un caso che si fanno giochi sfruttando python, lua e tanti altri linguaggi per il game play, ma poi il motore è sempre in c++.
Ovviamente nè java nè c# sono interpretati ma rimane un gap prestazionale tra compilazione jit e statica che per un gioco può equivalere a scavarsi la fossa.
Il punto è che c# o java sono una scommessa a perdere se vuoi fare un nuovo crysis et similia. Il fatto che i pc di oggi siano potenti non deve trarti in inganno e pensare che possiamo affidare tutto ad un gc tanto abbiamo 8 gb di ram. I game dev sanno come distruggere un hardware ultrapotente fino a ridurlo all'impotenza.
Il fatto che si usi c++ per i game engine è proprio dovuto alla necessità di ottimizzare il codice all'inverosimile e sfruttare la memoria nel modo più parsimonioso possibile.
Non è un caso che si fanno giochi sfruttando python, lua e tanti altri linguaggi per il game play, ma poi il motore è sempre in c++.
Ovviamente nè java nè c# sono interpretati ma rimane un gap prestazionale tra compilazione jit e statica che per un gioco può equivalere a scavarsi la fossa.
Tommo
02-02-2011, 15:28
Il punto è che c# o java sono una scommessa a perdere se vuoi fare un nuovo crysis et similia.
Il punto è che tu, noi, e chiunque altro passi da questo forum (ok apparte fek :D ) non si trova a fare il nuovo crysis per tanti motivi, tra cui i costi esagerati degli artwork.
Crysis è ormai una piccola fetta del gamedev in termini numerici, smuove sì tanti $$$, ma la stragrande maggioranza degli sviluppatori, oggi, lavora su progetti che non arrivano nemmeno per errore a sfruttare tutte le risorse della macchina, e sono molto più concentrati su altri "values" (come il gameplay, il social, uno stile convincente etc ) quali giochi Indie, per IOS, per Android, Flash, Facebook o HTML5.
I giochi "alla Crysis" (detti AAA) si sono da parecchio tempo spostati su console, e lì Java e C# sono cose remote.
Per cui se il problema fossero le prestazioni Java potrebbe tranquillamente essere usato dalla maggior parte degli sviluppatori (Minecraft per esempio è fatto in Java, e non è lento a causa di Java) , ma questo non succede per altri motivi :read:
Il punto è che tu, noi, e chiunque altro passi da questo forum (ok apparte fek :D ) non si trova a fare il nuovo crysis per tanti motivi, tra cui i costi esagerati degli artwork.
Crysis è ormai una piccola fetta del gamedev in termini numerici, smuove sì tanti $$$, ma la stragrande maggioranza degli sviluppatori, oggi, lavora su progetti che non arrivano nemmeno per errore a sfruttare tutte le risorse della macchina, e sono molto più concentrati su altri "values" (come il gameplay, il social, uno stile convincente etc ) quali giochi Indie, per IOS, per Android, Flash, Facebook o HTML5.
I giochi "alla Crysis" (detti AAA) si sono da parecchio tempo spostati su console, e lì Java e C# sono cose remote.
Per cui se il problema fossero le prestazioni Java potrebbe tranquillamente essere usato dalla maggior parte degli sviluppatori (Minecraft per esempio è fatto in Java, e non è lento a causa di Java) , ma questo non succede per altri motivi :read:
insane74
02-02-2011, 15:47
quando c'è da "tirar fuori il righello" linko sempre questo sito: http://shootout.alioth.debian.org/
cmq, come detto da persone molto + capaci di me, veloce != migliore.
:sofico:
cmq, come detto da persone molto + capaci di me, veloce != migliore.
:sofico:
pabloski
02-02-2011, 15:48
ovviamente parlando di giochini che possono quasi essere definiti amatoriali, il problema delle risorse non si pone
ma mi chiedo quanti giochi in java e c# ci sono in giro....no perchè se uno deve fare il giochino, lo fa in flash e lo mette pure sul web....fa prima e lo rende pure più facilmente giocabile
ma mi chiedo quanti giochi in java e c# ci sono in giro....no perchè se uno deve fare il giochino, lo fa in flash e lo mette pure sul web....fa prima e lo rende pure più facilmente giocabile
banryu79
03-02-2011, 12:55
....no perchè se uno deve fare il giochino, lo fa in flash e lo mette pure sul web....fa prima e lo rende pure più facilmente giocabile
Guarda mamma (http://impactjs.com/drop/), senza Flash! :D
[sorgente] (http://impactjs.com/documentation/drop-source-code)
P.S.: Era troppo simpatico per non segnalarlo :)
Potrebbe essere un apporccio molto soft & divertente per i primi "smantettamenti"...
@Edit: la libreria non è gratuita.
Guarda mamma (http://impactjs.com/drop/), senza Flash! :D
[sorgente] (http://impactjs.com/documentation/drop-source-code)
P.S.: Era troppo simpatico per non segnalarlo :)
Potrebbe essere un apporccio molto soft & divertente per i primi "smantettamenti"...
@Edit: la libreria non è gratuita.
pabloski
03-02-2011, 13:11
questi esagerano, addirittura usare html5 e javascript :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.