Unreal Engine: Epic valuta altro linguaggio da affiancare a C++ e Blueprint

[Redazione di Hardware Upg]

Link alla notizia: https://gaming.hwupgrade.it/news/vid...int_80129.html

Secondo alcune dichiarazioni di Tim Sweeney su Reddit Epic starebbe valutando alcuni importanti cambiamenti al suo motore grafico

Click sul link per visualizzare la notizia.

[Cunctator86]

"dynamic typing" -> "digitazione dinamica" top xD
Sarebbe "tipizzazione dinamica", si riferisce al fatto che i tipi in Python sono dedotti "dinamicamente" a tempo d'esecuzione mentre in C++ i tipi sono definiti "staticamente" a tempo di compilazione.
(Su quale dei due sia da considerarsi più debolmente tipizzato non mi pronuncio se no tra pythonisti e C++-isti si finisce a coltellate )

Invece in "we don't like the impedance mismatch between C#'s containers and managed runtime and C++ data structures" il "managed runtime" e' riferito a C# non a C++, sarebbe qualcosa tipo "non ci va a genio l'incompatibilità tra i container e il runtime gestito (ndr un ambiente esecutivo in cui la memoria è gestita automaticamente da un garbage collector) di C# e le strutture dati di C++". Questo perché in C++ I dati sono "inerti", un mera configurazione dei byte nella memoria, il cui ciclo vitale è definito dal loro "scope" (memory leaks permettendo), mentre in C# il ciclo di vita delle allocazioni dinamiche non è deterministico, il che rompe tutta una serie di assunzioni che si possono fare in C++ ma non in C# (o Java, o Python o che dir si voglia).

My 2 cents.

(Fico comunque che abbiano interpellato la comunità sull'argomento).

[pWi]

Originariamente inviato da Cunctator86

"dynamic typing" -> "digitazione dinamica" top xD
Sarebbe "tipizzazione dinamica", si riferisce al fatto che i tipi in Python sono dedotti "dinamicamente" a tempo d'esecuzione mentre in C++ i tipi sono definiti "staticamente" a tempo di compilazione.
(Su quale dei due sia da considerarsi più debolmente tipizzato non mi pronuncio se no tra pythonisti e C++-isti si finisce a coltellate )

Invece in "we don't like the impedance mismatch between C#'s containers and managed runtime and C++ data structures" il "managed runtime" e' riferito a C# non a C++, sarebbe qualcosa tipo "non ci va a genio l'incompatibilità tra i container e il runtime gestito (ndr un ambiente esecutivo in cui la memoria è gestita automaticamente da un garbage collector) di C# e le strutture dati di C++". Questo perché in C++ I dati sono "inerti", un mera configurazione dei byte nella memoria, il cui ciclo vitale è definito dal loro "scope" (memory leaks permettendo), mentre in C# il ciclo di vita delle allocazioni dinamiche non è deterministico, il che rompe tutta una serie di assunzioni che si possono fare in C++ ma non in C# (o Java, o Python o che dir si voglia).

My 2 cents.

(Fico comunque che abbiano interpellato la comunità sull'argomento).

Corretto. Grazie mille per le segnalazioni!

[cignox1]

Interessante davvero la loro idea, ma é un peccato che non possano considerare maggiormente l'uso di c#. Intanto perché credo che sia uno dei migliori candidati al ruolo, oltre che (potenzialmente) aprire le porte ad altri linguaggi .net.
Non lavoro in c# ormai da quasi 10 anni (a parte un paio di piccoli tools fatti piú di recente) ma mi pareva di ricordare che avesse dei meccanismi di chiamata di codice non gestito, quindi mi domando se non possano creare un thin layer per interfacciarsi con gli oggetti nativi partendo da codice c#...

[jepessen]

Originariamente inviato da cignox1

Interessante davvero la loro idea, ma é un peccato che non possano considerare maggiormente l'uso di c#. Intanto perché credo che sia uno dei migliori candidati al ruolo, oltre che (potenzialmente) aprire le porte ad altri linguaggi .net.
Non lavoro in c# ormai da quasi 10 anni (a parte un paio di piccoli tools fatti piú di recente) ma mi pareva di ricordare che avesse dei meccanismi di chiamata di codice non gestito, quindi mi domando se non possano creare un thin layer per interfacciarsi con gli oggetti nativi partendo da codice c#...

La chiamata a codice non gestito non dovrebbe essere mai utilizzata. L'unico caso accettabile e' quando si creano binding con librerie di altri linguaggi e occorre gestire la memoria a basso livello, ma lo vedo personalmente piu' come un workaround per poter far comunicare queste librerie. Un programmatore C# scafato pone molta meno enfasi sulla gestione della memoria rispetto ad un programmatore C++ dove devi gestirla autonomamente (e poveretti quelli che pensano che con gli smart pointer il problema si risolve da solo, ma non sono I soli, ci sono cascato pure io quando li hanno introdotti).

Uno dei problemi e' che I videogiochi di un certo livello hanno tutta una loro concezione di gestione della memoria e dei thread, per minimizzare l'overhead dovuto ad allocazioni e deallocazioni e quindi dedicare piu' cicli di processore alla logica del gioco piuttosto che alla gestione interna del programma.

Molti team di sviluppo che creano giochi in C++ ad esempio sono molto restii ad utilizzare STL cosi' come sono, perche' hanno una gestione della memoria che non e' ottimizzata per I loro scopi, e preferiscono riscriversi le funzioni adatte a loro. Ad esempio utilizzano dei propri allocator che allocano all'inizio una grossa porzione di memoria, e poi man mano che si creano e distruggono oggetti associano porzioni di questo segmento gia' allocato. Infatti quando vedi il consumo di memoria di un gioco in genere dopo la fase di inizializzazione rimane costante. Utilizzano anche algoritmi per minimizzare la deframmentazione della memoria. Insomma, cose che fino ad un utilizzo piu' che intermedio del C++ uno manco ci fa caso, e giustamente (prima scrivere codice che funziona, e solo alla fine ottimizzare eventuali colli di bottiglia, altrimenti si rischia di ottimizzare codice la' dove non serve).

in C# ed altri linguaggi dove la gestione della memoria e' automatica, e' difficile realizzare software con requisiti soft-realtime perche' non sapendo a priori quando avviene la deallocazione non possono allocare perfettamente tutte le risorse, quindi puo' capitare che il garbage collector si avvii durante una fase di calcolo intensiva, facendo cosi' saltare un frame. Per programmi "normali" e giochi non molto intensivi, l'overhead e' trascurabile, tant'e' che Unity viene utilizzato da studi indie per lo piu' dove fanno giochi anche molto belli ma che non spremono tutti i cicli di CPU/GPU, dove in quel caso bisogna andare di C++.

Tanto per fare un esempio pratico, questo e' un talk di quelli della Naughty Dogs (mica gli ultimi arrivati) su come ottimizzare l'utilizzo di una CPU utilizzando i jobs per parallelizzare il lavoro, cosa che normalmente si fa con I thread ma evidentemente a loro non bastava:

https://www.gdcvault.com/play/102218...hty-Dog-Engine
http://twvideo01.ubm-us.net/o1/vault...he_Naughty.pdf

Parla un po' anche degli allocator per spiegare come ottimizzare l'allocazione di memoria, ma purtroppo ne parla meno del dovuto (non era il main topic della presentazione), ma ti posso assicurare che c'e' molto da dire anche li.

I miei two cents sono che secondo me non hanno bisogno di un altro linguaggio di programmazione compilato, come il C++. Hanno bisogno di un linguaggio di scripting, come Lua o Falcon (meglio perche' object oriented). In questo modo avrebbero il grosso vantaggio di avere un linguaggio che puo' essere modificato a runtime e ad alte prestazioni perche' direttamente incluso nel codice C++.

il vantaggio del runtime e' che puoi modificare il codice a gioco avviato: ad esempio mentre stai giocando puoi modificare in real time il codice di gestione della telecamera, in maniera tale da poter vedere in tempo reale come cambia il comportamento, senza dover ogni volta stoppare il gioco, ricompilare, riavviare e rimetterti in quella situazione, con un enorme risparmio di tempo.

Le prestazioni, rispetto a python, sono elevate perche' puoi includere l'interprete direttamente nel codice C++, quindi non sarebbe una cosa a parte. Essendo comunque interpretato a runtime non hai le stesse prestazioni del codice nativo, ma non e' un male. Sempre nell'esempio di prima, puoi modificare il codice per gestire la telecamera velocemente, magari durante una riunione con I project manager e, quando tutti sono contenti, puoi implementare il codice risultante in C++: in questo modo la prototipazione della telecamera e' stata veloce, e hai direttamente l'algoritmo piu' efficace che poi puoi implementare direttamente in C++, e lo fai una volta sola, e solo se e' necessario.

Secondo me dovrebbe essere questa la strada da seguire, o meglio ancora, si potrebbe definire un AST dinamico, ovvero una rappresentazione intermedia del codice, un po' come il CIL di .NET, e poi lasciare che la comunita' definisca il linguaggio front-end che piu' piace: alcuni potrebbero implementare LUA, altri Python e cosi' via...

Insomma, possibilita' ce ne sono infinite...

[Maddog1976]

Originariamente inviato da jepessen

La chiamata a codice non gestito non dovrebbe essere mai utilizzata. L'unico caso accettabile e' quando si creano binding con librerie di altri linguaggi e occorre gestire la memoria a basso livello, ma lo vedo personalmente piu' come un workaround per poter far comunicare queste librerie. Un programmatore C# scafato pone molta meno enfasi sulla gestione della memoria rispetto ad un programmatore C++ dove devi gestirla autonomamente (e poveretti quelli che pensano che con gli smart pointer il problema si risolve da solo, ma non sono I soli, ci sono cascato pure io quando li hanno introdotti).

Uno dei problemi e' che I videogiochi di un certo livello hanno tutta una loro concezione di gestione della memoria e dei thread, per minimizzare l'overhead dovuto ad allocazioni e deallocazioni e quindi dedicare piu' cicli di processore alla logica del gioco piuttosto che alla gestione interna del programma.

Molti team di sviluppo che creano giochi in C++ ad esempio sono molto restii ad utilizzare STL cosi' come sono, perche' hanno una gestione della memoria che non e' ottimizzata per I loro scopi, e preferiscono riscriversi le funzioni adatte a loro. Ad esempio utilizzano dei propri allocator che allocano all'inizio una grossa porzione di memoria, e poi man mano che si creano e distruggono oggetti associano porzioni di questo segmento gia' allocato. Infatti quando vedi il consumo di memoria di un gioco in genere dopo la fase di inizializzazione rimane costante. Utilizzano anche algoritmi per minimizzare la deframmentazione della memoria. Insomma, cose che fino ad un utilizzo piu' che intermedio del C++ uno manco ci fa caso, e giustamente (prima scrivere codice che funziona, e solo alla fine ottimizzare eventuali colli di bottiglia, altrimenti si rischia di ottimizzare codice la' dove non serve).

in C# ed altri linguaggi dove la gestione della memoria e' automatica, e' difficile realizzare software con requisiti soft-realtime perche' non sapendo a priori quando avviene la deallocazione non possono allocare perfettamente tutte le risorse, quindi puo' capitare che il garbage collector si avvii durante una fase di calcolo intensiva, facendo cosi' saltare un frame. Per programmi "normali" e giochi non molto intensivi, l'overhead e' trascurabile, tant'e' che Unity viene utilizzato da studi indie per lo piu' dove fanno giochi anche molto belli ma che non spremono tutti i cicli di CPU/GPU, dove in quel caso bisogna andare di C++.

Tanto per fare un esempio pratico, questo e' un talk di quelli della Naughty Dogs (mica gli ultimi arrivati) su come ottimizzare l'utilizzo di una CPU utilizzando i jobs per parallelizzare il lavoro, cosa che normalmente si fa con I thread ma evidentemente a loro non bastava:

https://www.gdcvault.com/play/102218...hty-Dog-Engine
http://twvideo01.ubm-us.net/o1/vault...he_Naughty.pdf

Parla un po' anche degli allocator per spiegare come ottimizzare l'allocazione di memoria, ma purtroppo ne parla meno del dovuto (non era il main topic della presentazione), ma ti posso assicurare che c'e' molto da dire anche li.

I miei two cents sono che secondo me non hanno bisogno di un altro linguaggio di programmazione compilato, come il C++. Hanno bisogno di un linguaggio di scripting, come Lua o Falcon (meglio perche' object oriented). In questo modo avrebbero il grosso vantaggio di avere un linguaggio che puo' essere modificato a runtime e ad alte prestazioni perche' direttamente incluso nel codice C++.

il vantaggio del runtime e' che puoi modificare il codice a gioco avviato: ad esempio mentre stai giocando puoi modificare in real time il codice di gestione della telecamera, in maniera tale da poter vedere in tempo reale come cambia il comportamento, senza dover ogni volta stoppare il gioco, ricompilare, riavviare e rimetterti in quella situazione, con un enorme risparmio di tempo.

Le prestazioni, rispetto a python, sono elevate perche' puoi includere l'interprete direttamente nel codice C++, quindi non sarebbe una cosa a parte. Essendo comunque interpretato a runtime non hai le stesse prestazioni del codice nativo, ma non e' un male. Sempre nell'esempio di prima, puoi modificare il codice per gestire la telecamera velocemente, magari durante una riunione con I project manager e, quando tutti sono contenti, puoi implementare il codice risultante in C++: in questo modo la prototipazione della telecamera e' stata veloce, e hai direttamente l'algoritmo piu' efficace che poi puoi implementare direttamente in C++, e lo fai una volta sola, e solo se e' necessario.

Secondo me dovrebbe essere questa la strada da seguire, o meglio ancora, si potrebbe definire un AST dinamico, ovvero una rappresentazione intermedia del codice, un po' come il CIL di .NET, e poi lasciare che la comunita' definisca il linguaggio front-end che piu' piace: alcuni potrebbero implementare LUA, altri Python e cosi' via...

Insomma, possibilita' ce ne sono infinite...

I miei complimenti, mi hai dissipato i dubbi che mi sorgevano leggendo l'articolo.

Ps quando in tempi più antichi la CPU faceva quel che poteva (frazione infinitesima di oggi) per ottenere un effetto RT ho dovuto innsetare al programma in C la parte ASM per spremere registri e pairing delle istruzioni

[cignox1]

>>Uno dei problemi e' che I videogiochi di un certo livello hanno tutta una loro concezione di gestione della memoria

Si, é quello a cui mi riferivo. Rendono accessibile la loro libreria interna scritta in c++ per la gestione delle risorse (memoria etc) tramite una interfaccia .net che richiama codice non gestito. Sarebbe eventualmente limitata alla parte piú importante del motore.
A prescindere da quale soluzione adotteranno, dovranno comunque sia implementare una interfaccia al loro codice c++ sia mettere a disposizione strumenti di gestione automatica delle risorse (altrimenti non vedo il senso di tutta questa operazione ).

L'idea di un linguaggio di scripting é buona per le ragioni che hai descritto (e ha senso, se vogliamo offrire una alternativa al c++, che sia davvero diversa). Certo, impelagarsi in un progetto come questo per la sola prototipizzazione non mi pare il massimo. Neppure inventarsi un nuovo linguaggio sarebbe l'idea del secolo imho.
Python potrebbe essere una cosa interssante, ma le prestazioni vanno tenute sotto controllo...

[LukeIlBello]

poco ma sicuro il C# e i linguaggi a deallocazione non deterministica non vanno bene..
certo che se la loro esigenza è debuggare ed eventualmente modificare roba a runtime, la roba suggerita da jepessen è quella più adatta..
altrimenti io farei un altro strato in c++, magari esponendo metodi che rendono trasparente la gestione della memoria, che a sua volta sarebbe gestita dal container sottostante (già esistente)..

[jepessen]

Originariamente inviato da cignox1

>>Uno dei problemi e' che I videogiochi di un certo livello hanno tutta una loro concezione di gestione della memoria

Si, é quello a cui mi riferivo. Rendono accessibile la loro libreria interna scritta in c++ per la gestione delle risorse (memoria etc) tramite una interfaccia .net che richiama codice non gestito. Sarebbe eventualmente limitata alla parte piú importante del motore.
A prescindere da quale soluzione adotteranno, dovranno comunque sia implementare una interfaccia al loro codice c++ sia mettere a disposizione strumenti di gestione automatica delle risorse (altrimenti non vedo il senso di tutta questa operazione ).

Anche se nel codice non gestito implementi la gestione della memoria customizzata, non puoi fare a meno del suo garbage collector per tutto il resto dell'applicazione. Se poi devi fare tutti questi maneggi per adattare un linguaggio di programmazione ai tuoi scopi, forse forse non e' quello il linguaggio che ti serve... D'altronde anche nell'articolo si legge che gli sviluppatori di Unity stanno tentando i salti mortali per aumentare le prestazioni con il loro modello ECS, cercando di superare i limiti imposti dal linguaggio, e affermano pure che per un gioco di un certo livello semplicemente non va bene. Purtroppo Unity legandosi a C# si e' legato anche ai suoi limiti, ma va bene, non tutti i giochi devono essere AAA e ci sono giochini indie che sono meglio di molti blockbuster. Semplicemente la tecnologia non permette di creare giochi molto intensivi, come richiesto ad esempio da giochi con forte componente online (il netcode e' sempre stato una brutta bestia).

L'idea di un linguaggio di scripting é buona per le ragioni che hai descritto (e ha senso, se vogliamo offrire una alternativa al c++, che sia davvero diversa). Certo, impelagarsi in un progetto come questo per la sola prototipizzazione non mi pare il massimo. Neppure inventarsi un nuovo linguaggio sarebbe l'idea del secolo imho.
Python potrebbe essere una cosa interssante, ma le prestazioni vanno tenute sotto controllo...

I linguaggi di scripting embeddabili hanno in linea di massima prestazioni superiori ai puri interpretati. Se includi Lua nel tuo codice C++ puoi far andare le cose abbastanza velocemente. Se poi la velocita' non e' abbastanza, di certo non e' un altro interpretato che ti risolve la situazione, ne' tantomeno un interprete esterno che si lega al tuo core tramite librerie e binding vari.
La prototipazione e' una cosa fondamentale invece, perche' ti permette di sviluppare le tue idee in tempi rapidi; l'esempio della telecamera ad esempio era proprio una delle cose utilizzate da Naughty Dogs per lo sviluppo del primo capitolo di The Last of Us. Io ho usato lo scripting in uno dei miei progetti per definire le regole di comportamento di alcuni player delle simulazioni che eseguivo, e modificare il comportamento a piacere modificando semplicemente lo script, senza riavviare il simulatore (che se e' professionale/militare con motion, ci vuole anche mezz'ora, il che significa migliaia di euro persi dato il costo di un'ora di lezione al simulatore) e' una comodita' impareggiabile.
Non a caso comunque si e' parlato dello scripting per una logica di funzionamento, e non per il calcolo vero e proprio dei quaternioni che vengono fatti ad un livello piu' basso, proprio perche' bisogna capire quali sono le parti di codice da ottimizzare e quali no.

[Cunctator86]

Originariamente inviato da LukeIlBello

certo che se la loro esigenza è debuggare ed eventualmente modificare roba a runtime, la roba suggerita da jepessen è quella più adatta..

Credo che il loro obiettivo non sia tanto di aggiungere chissa' quali strumenti di manipolazione dell'ambiente a runtime o di prototipizzazione, ma sia di rendere l'editor piu' appetibile agli utenti mainstream, ed espandere cosi' il loro raggio d'efficacia anche al mercato Indie che per lo piu' e' dominato da Unity. Per quello alla fine sceglieranno (sempre imho) un linguaggio noto e diffuso come Python, Java o, piu' probabilmente, C#.

Originariamente inviato da jepessen

Secondo me dovrebbe essere questa la strada da seguire, o meglio ancora, si potrebbe definire un AST dinamico

L'idea di un AST vero e proprio e' fica ma secondo me non applicabile ad un framework cosi' complesso con centinaia di entita' e migliaia di metodi. Proprio volendo l'AST c'e' gia': sono i simboli C++ esposti dal framework, nessuno vieta alle software house di integrare un interprete Python/Lua/Javascript in un gioco pilotato da UE4 e manipolare qualsivoglia entita' via script.

Originariamente inviato da jepessen

In questo modo avrebbero il grosso vantaggio di avere un linguaggio che puo' essere modificato a runtime e ad alte prestazioni perche' direttamente incluso nel codice C++.

L'editing in real time e' possibile anche in C++ con le dovute accortezze, tempo fa (ad esempio) realizzai una sandbox per OpenGL che ricompila il codice sorgente alla modifica del sorgente e ricarica la libreria dinamica a runtime, rifacendo il binding dei simboli esportati dinamicamente, ovviamente ogni tanto esplode ma se ci stai un minimo attento la funzionalita' ci sta tutta. Usai un approccio simile su Android con le JNI, abbattei il tempo di deploy dell'applicazione sul device da 30/40 secondi a <1s (in C).

Originariamente inviato da jepessen

Molti team di sviluppo che creano giochi in C++ ad esempio sono molto restii ad utilizzare STL cosi' come sono, perche' hanno una gestione della memoria che non e' ottimizzata per I loro scopi, e preferiscono riscriversi le funzioni adatte a loro. Ad esempio utilizzano dei propri allocator che allocano all'inizio una grossa porzione di memoria

La STL offre gia' la possibilita' di usare allocatori custom, in effetti la sua grande flessibilita' e' anche il motivo per cui e' cosi' complessa da utilizzare (e debuggare ) per un programmatore alle prime armi, anche volendo evitare completamente l'uso dello heap puoi sempre fare uso delle strutture dati della STL.
Per quanto riguarda l'uso dei fiber/microthread in userspace secondo me hanno poco senso in un gioco, Naughty Dogs li ha adottati perche' voleva riutilizzare il knowhow (e proabilmente la codebase) sviluppata durante la realizzazione di giochi per PS3, dove l'architettura della console aveva imposto un certo tipo di approccio, ma i giochi non richiedono mai quel livello di parallelizzazione (guarda caso i giochi non richiedono mai piu' di 4 core fisici). Quel modello di threading e' piu' tipico di sistemi di gestione di servizi, GO per esempio integra le goroutine proprio a quello scopo, e di certo non e' un linguaggio teso allo sviluppo di videogiochi (Google non fa videogiochi, fatta eccezione per lui).

Originariamente inviato da Maddog1976

Ps quando in tempi più antichi la CPU faceva quel che poteva (frazione infinitesima di oggi) per ottenere un effetto RT ho dovuto innsetare al programma in C la parte ASM per spremere registri e pairing delle istruzioni

Bei tempi, fra tutte le soluzioni implementative "esotiche" per spremere la CPU la mia preferita e' sempre stata questa

Originariamente inviato da pWi

Corretto. Grazie mille per le segnalazioni!

Utenti e redattori uniti per un solo scopo: Make HWU great again! (per favore dite due parole a Rosario Grasso, io capisco che il modello di business di una testata online e' cambiato profondamente negli ultimi anni, ma a lungo andare finira' per allontanare gli utenti dal sito, io sono iscritto al forum dal 2003, leggo la rivista da prima ma ad ogni articolo click-bait/troll sono sempre piu' tentato di lasciar perdere HWU.)

[LukeIlBello]

Originariamente inviato da Cunctator86

Credo che il loro obiettivo non sia tanto di aggiungere chissa' quali strumenti di manipolazione dell'ambiente a runtime o di prototipizzazione, ma sia di rendere l'editor piu' appetibile agli utenti mainstream,

se così fosse allora dovrebbero ripiegare ad occhi chiusi su C#, certamente dei linguaggi interpretati è quello con cui i dev di unity hanno più dimestichezza, e nello stesso tempo (secondo la mia exp) è quello che scende a livello più basso rispetto agli altri.. ovviamente a patto di usare codice non gestito

Utenti e redattori uniti per un solo scopo: Make HWU great again! (per favore dite due parole a Rosario Grasso, io capisco che il modello di business di una testata online e' cambiato profondamente negli ultimi anni, ma a lungo andare finira' per allontanare gli utenti dal sito, io sono iscritto al forum dal 2003, leggo la rivista da prima ma ad ogni articolo click-bait/troll sono sempre piu' tentato di lasciar perdere HWU.)

secondo me vanno bene anche un pò di clickbait / troll news.. l'importante è non limitarsi solo a quelle