Miglior linguaggio per giochi?

[ingframin]

Originariamente inviato da =KaTaKliSm4=

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]

Originariamente inviato da PGI-Bis

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/ja...275/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]

Originariamente inviato da 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.

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]

Originariamente inviato da PGI-Bis

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 ).

[cdimauro]

Originariamente inviato da 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/ja...275/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/showpo...&postcount=330
http://www.hwupgrade.it/forum/showpo...&postcount=336

Originariamente inviato da pabloski

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.

Originariamente inviato da 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.

E' un problema degli sviluppatori. Se vuoi, puoi portare la JVM su XBox (anche la prima, per la quale c'è persino Python disponibile ).

Originariamente inviato da pabloski

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.

Originariamente inviato da banryu79

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 ).

Vedi sopra.

[pabloski]

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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]

Originariamente inviato da pabloski

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.

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?

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

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 è totalmente scritto in Lua, ed è pure complesso per essere un indie game

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 )...
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"

@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
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
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

[pabloski]

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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

Originariamente inviato da cdimauro

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/...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]

Originariamente inviato da Tommo

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

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

Originariamente inviato da Tommo

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

Originariamente inviato da Tommo

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

Originariamente inviato da Tommo

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++

Originariamente inviato da Tommo

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

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

Originariamente inviato da Tommo

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

da come hai risposto non mi sembra di aver detto boiate

Originariamente inviato da Tommo

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

affermazione molto forzata....

Originariamente inviato da Tommo

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

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

Originariamente inviato da Tommo

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]

Originariamente inviato da pabloski

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
Che poi, personalmente non l'ho mai trovato difficile. Basta usare l'OOP come si deve e ricordarsi di chiamare delete

[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