Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

 Huawei Mate 30: la serie che reinventa tutto (anche in Italia)
Huawei Mate 30: la serie che reinventa tutto (anche in Italia)
Huawei presenta a Monaco di Baviera la sua nuova serie Mate 30 con il nuovo Mate 30 Pro capace di cose mai riuscite finora nella fotografia con uno smartphone. Il più potente e funzionale di sempre anche senza i servizi di Google che comunque potranno essere installati (in un modo o in un altro). Presentato anche Huawei Watch GT 2
Dynabook (Toshiba) Portegé X30T-E: il 2-in-1 per il business
Dynabook (Toshiba) Portegé X30T-E: il 2-in-1 per il business
E' pensato per il pubblico dei professionisti il 2-in-1 Portegé X30T-E, venduto con marchio Dynabook ma basato sulla tradizione tecnologica di Toshiba. Integra un particolare kickstand abbinato ad una base con batteria addizionale, offrendo ancora più elevata flessibilità in termini di modalitàò di utlizzo lontano dalla scrivania
Samsung Galaxy Note 10+: bello, potente e funzionale. La recensione
Samsung Galaxy Note 10+: bello, potente e funzionale. La recensione
Arriva alla numerazione 10 e come fatto per Galaxy S10 anche il Note subisce un forte cambiamento estetico come anche funzionale. Il display ora è sempre più ampio con un piccolo foro al centro, l’hardware è da vero top di gamma e la fotocamera primeggia per dettaglio ed effetto bokeh. Il resto è tutto da scoprire nella nostra recensione. 
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 14-01-2019, 18:21   #1
Redazione di Hardware Upg
www.hwupgrade.it
 
Iscritto dal: Jul 2001
Messaggi: 75180
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.
Redazione di Hardware Upg è offline   Rispondi citando il messaggio o parte di esso
Old 14-01-2019, 20:50   #2
Cunctator86
Member
 
L'Avatar di Cunctator86
 
Iscritto dal: Dec 2003
Città: Amsterdam
Messaggi: 130
"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).

Ultima modifica di Cunctator86 : 14-01-2019 alle 21:13.
Cunctator86 è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 07:18   #3
pWi
www.hwupgrade.it
 
Iscritto dal: Feb 2006
Messaggi: 413
Quote:
Originariamente inviato da Cunctator86 Guarda i messaggi
"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!
pWi è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 07:55   #4
cignox1
Senior Member
 
Iscritto dal: May 2008
Messaggi: 1039
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#...
cignox1 è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 08:26   #5
jepessen
Senior Member
 
L'Avatar di jepessen
 
Iscritto dal: Jul 2007
Città: Sicilia
Messaggi: 1993
Quote:
Originariamente inviato da cignox1 Guarda i messaggi
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...
__________________
Non abbiamo ereditato il mondo dai nostri padri
L'abbiamo preso in prestito dai nostri figli

Ultima modifica di jepessen : 15-01-2019 alle 08:44.
jepessen è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 09:15   #6
Maddog1976
Member
 
Iscritto dal: May 2013
Messaggi: 214
Quote:
Originariamente inviato da jepessen Guarda i messaggi
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
Maddog1976 è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 10:20   #7
cignox1
Senior Member
 
Iscritto dal: May 2008
Messaggi: 1039
>>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...
cignox1 è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 10:20   #8
LukeIlBello
Senior Member
 
L'Avatar di LukeIlBello
 
Iscritto dal: Jan 2010
Città: Roma
Messaggi: 4208
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)..
__________________
Intel Core i5 4570 @3,60GHz, 24 GB DDR3 Kingston HyperX @9,9,9,27 , Nvidia Gtx 1060, Enermax Chakra, Win10 PRO x64, Devuan ascii , FreeBSD 12
Banana PI: ARM® Cortex™-A7 Dual-Core, gpu Mali400MP2, 1GB DDR3 SDRAM - La soluzione definitiva per la massima sicurezza della tua attività business? TiBanDefender
LukeIlBello è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 11:10   #9
jepessen
Senior Member
 
L'Avatar di jepessen
 
Iscritto dal: Jul 2007
Città: Sicilia
Messaggi: 1993
Quote:
Originariamente inviato da cignox1 Guarda i messaggi
>>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).

Quote:
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.
__________________
Non abbiamo ereditato il mondo dai nostri padri
L'abbiamo preso in prestito dai nostri figli

Ultima modifica di jepessen : 15-01-2019 alle 11:13.
jepessen è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 13:14   #10
Cunctator86
Member
 
L'Avatar di Cunctator86
 
Iscritto dal: Dec 2003
Città: Amsterdam
Messaggi: 130
Quote:
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#.

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

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

Quote:
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

Quote:
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.)
__________________
Xeon X5670 @4Ghz+NH-D14 18GB DDR3 @1.8Ghz Dominator GT+HyperX Fury Gigabyte GTX 1070 G1 850Pro 256GB+MX500 1TB

Ultima modifica di Cunctator86 : 15-01-2019 alle 15:44.
Cunctator86 è offline   Rispondi citando il messaggio o parte di esso
Old 15-01-2019, 16:22   #11
LukeIlBello
Senior Member
 
L'Avatar di LukeIlBello
 
Iscritto dal: Jan 2010
Città: Roma
Messaggi: 4208
Quote:
Originariamente inviato da Cunctator86 Guarda i messaggi
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

Quote:
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
__________________
Intel Core i5 4570 @3,60GHz, 24 GB DDR3 Kingston HyperX @9,9,9,27 , Nvidia Gtx 1060, Enermax Chakra, Win10 PRO x64, Devuan ascii , FreeBSD 12
Banana PI: ARM® Cortex™-A7 Dual-Core, gpu Mali400MP2, 1GB DDR3 SDRAM - La soluzione definitiva per la massima sicurezza della tua attività business? TiBanDefender
LukeIlBello è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


 Huawei Mate 30: la serie che reinventa tutto (anche in Italia) Huawei Mate 30: la serie che reinventa tutto (a...
Dynabook (Toshiba) Portegé X30T-E: il 2-in-1 per il business Dynabook (Toshiba) Portegé X30T-E: il 2-i...
Samsung Galaxy Note 10+: bello, potente e funzionale. La recensione Samsung Galaxy Note 10+: bello, potente e funzio...
SIMjacker, ecco cosa ci insegna l'ultima grave falla dei dispositivi mobile SIMjacker, ecco cosa ci insegna l'ultima grave f...
Winblu T-Rok: il sistema da gaming su base ASUS TUF Winblu T-Rok: il sistema da gaming su base ASUS ...
WhatsApp, ecco tutte le novità in...
G-Evolution e IBM spingono per adottare ...
E' di Samsung l'SSD per i datacenter pen...
LG annuncia i primi due TV 8K per il mer...
iOS 13 disponibile per tutti. Ecco tutte...
ELIO: la rivoluzione dello shopping onli...
Nuova Fiat 500 elettrica: produzione di ...
Come risparmiare oggi su Amazon: guardat...
Profoto C1 e C1 Plus: i flash portatili ...
Giove con l'eclissi di Io in alcune imma...
Tesla Model 3: è il modello più venduto ...
Cascade Lake-X: evoluzione, non rivoluzi...
Ghost Recon Breakpoint: Open Beta nella ...
Brendan Barry: il fotografo che ha trasf...
Call of Duty Modern Warfare Beta: specif...
Paint.NET
AVG Internet Security
AVG Antivirus Free
Google Chrome Portable
Avast! Free Antivirus
Firefox Portable
Process Lasso
Opera Portable
Opera 63
EZ CD Audio Converter
Firefox 69
SmartFTP
Dropbox
Driver Booster
NTLite
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 12:53.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Served by www3v
1