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

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

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

di pubblicata il , alle 19:21 nel canale Videogames
Epic
 

Tim Sweeney sta pensando a dei cambiamenti strutturali per la sua creazione, Unreal Engine 4. Su Reddit, infatti, chiede il parere della community a proposito dell'opportunità a introdurre un linguaggio intermedio tra C++ e Blueprint, ovvero il metodo di scripting visuale interno a Unreal Engine 4.

"Ne abbiamo discusso molto internamente e l'idea ci piace", ha scritto il CEO di Epic Games. "Vediamo l'introduzione di un altro livello di programmazione come una decisione che è vincolante per tutto ciò che faremo per un decennio o più, quindi non dobbiamo prendere decisioni affrettate".

Unreal Engine 4

In altre parole, Sweeney vuole andare alla ricerca di una soluzione intermedia tra un linguaggio di alto livello come C++ e una soluzione meramente visiva come il Blueprint incluso in Unreal Engine 4. La nuova soluzione intermedia deve essere in grado di dialogare con i linguaggi già esistenti in Ue4. "Ci piace la semplicità di C # ma non va bene la mancata corrispondenza tra i container e il runtime gestito di C # con le strutture dati di C++. Ciò rende difficile condividere i dati tra i mondi C # e C ++. UnrealScript aveva una corrispondenza molto più diretta tra i due mondi, tuttavia il carico dei dati di mirroring era significativo".

Quindi Sweeney, come ragionando a voce alta insieme alla community, passa a valutare tutte le opzioni a disposizione per realizzare questo cambiamento: "Amiamo la semplicità di Python, ma presenterebbe problemi simili a UnrealScript e diffidiamo della tipizzazione dinamica. Anche Lua potrebbe essere una soluzione. Generalmente, invece, siamo spaventati da JavaScript".

"Esiste anche la possibilità di creare un linguaggio personalizzato, come lo era UnrealScript, elaborato per interagire con il motore e risolvere i problemi di gioco. Ma vorremmo che tutti voi vi esprimeste in proposito".

Per altri dettagli sul funzionamento di Unreal Engine 4 consultate il nostro speciale qui e qui
In un altro post, va a esaminare le soluzioni adottate dalle tecnologie rivali. "Frostbite ha fatto un passo in avanti con il codice incaricato del gameplay multithreading, che si traduce in maggiore scalabilità. Tuttavia questo espone i programmatori della parte gameplay a dover gestire molte tipologie di dati e alla complessità della sincronizzazione che si crea con il multiprocessing della memoria condivisa".

"Unity sta portando avanti una direzione interessante con il loro ECS (Entity-Component System), che mira a eludere al sovraccarico di C # spostando i dati dagli oggetti di alto livello collegati da puntatori a un layout dei dati molto più snello. Ciò che è sconosciuto riguarda come questo approccio possa incidere nella programmazione del gameplay per via del data model più ristretto. Per esempio, nutro dei dubbi che questo approccio possa scalare al punto da poter andare bene a un team che lavora su un grosso gioco multiplayer".

"Un'altra possibile direzione potrebbe essere quella del 'message-passing concurrency' nello stile di Erlang, che esegue una simulazione dei nodi nei data center, all'interno di un modello in cui multithreading e calcolo distribuito fanno parte dello stesso framework". Secondo Sweeney, però, questo approccio porterebbe alla negoziazione di troppe interazioni richiedendo protocolli molto elaborati e portando a eccessiva complessità in fase di debug.

Trovare il giusto equilibrio in tutto questo non è facile, perché la tecnologia deve adattarsi alle esigenze sia di piccoli team di sviluppo dove tutti i programmatori si conoscono molto bene tra di loro sia alle esigenze di grossi studi dove tantissimi programmatori sviluppano componenti concepite in maniera indipendente tra di loro ma che devono dialogare insieme nel prodotto finale.

10 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Cunctator8614 Gennaio 2019, 21:50 #1
"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).
pWi15 Gennaio 2019, 08:18 #2
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!
cignox115 Gennaio 2019, 08:55 #3
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#...
jepessen15 Gennaio 2019, 09:26 #4
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/10221...ghty-Dog-Engine
http://twvideo01.ubm-us.net/o1/vaul...The_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...
Maddog197615 Gennaio 2019, 10:15 #5
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/10221...ghty-Dog-Engine
http://twvideo01.ubm-us.net/o1/vaul...The_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
LukeIlBello15 Gennaio 2019, 11:20 #6
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)..
cignox115 Gennaio 2019, 11:20 #7
>>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...
jepessen15 Gennaio 2019, 12:10 #8
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.
Cunctator8615 Gennaio 2019, 14:14 #9
Originariamente inviato da: LukeIlBello]certo che se la loro esigenza è
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 <
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ù
Bei tempi, fra tutte le soluzioni implementative "esotiche" per spremere la CPU la mia preferita e' sempre stata questa

[QUOTE=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.)
LukeIlBello15 Gennaio 2019, 17:22 #10
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

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^