Build 118 rilasciata

R: Build 118 rilasciata

Lo dico a me sembra più road america dopo lo scollinamento.... breve rettilineo curva a destra in discesa con rettilineo annesso poi curva a sinistea e così via....

Piccola curiositá.... quella palla arancio sulla sinistra.... che roba è? un ufo? :D

Inviato dal mio GT-I9300 con Tapatalk 2
 
Rik said:
Sicuramente Lime Rock. Road Atlanta non ha i guard rail.

Forse in questo punto:

rf2twitter.jpg


limerockp.jpg
Click to expand...
Esattamente questo punto Bravo Rik,poi coincidono alberi e guard rail e anche le reti.
Secondo me no vi e alcun dubbio che sia Lime Rock.


Babs:)
 
in effetti sembrerebbe lime rock (vedi secondo 0'49''), xò l'ultima curva non mi sembra così particolare, come indicava il post di Tim.



xò potrebbe essere anche road atlanta (vedi secondo 0'35''):

 
Last edited by a moderator:
max per il "versante" danni sai se i ragazzi hanno intenzione di creare danni classici (perdita paraurti, spoiler ecc.) oppure di far si che i componenti si distruggano creando diversi detriti?
 
Questo non lo so.

Immagino che ogni singolo detrito in movimento, eventualmente, andrà ad appesantire la CPU perchè, anche se in modo semplificato, dovrà cmq rispettare le leggi della fisica.

Al momento questo è un fattore delicato perchè appesantire il carico fisico della CPU potrebbe portare alla perdita del real time ... nella build 49, per dire, lo "slowmotion bug" era causato da oggetti in movimento (in particolare erano i coni). Naturalmente l'ottimizzazione del codice ha risolto il problema, ma nel caso avessimo centinaia di frammenti che volano mi chiedo se la più efficiente ottimizzazione sarebbe in grado di impedire il sovraccarico della CPU fisica.

Questa ipotesi potebbe essere aggirata nel caso che i frammenti agissero secondo "regole precalcolate" anzichè secondo le leggi fisiche fissate dal motore ISI, ma onestamente non conosco le intenzioni ISI e in ogni caso è un argomento probabimente un po' prematuro. :)
 
Max Angelo said:
Questo non lo so.

Immagino che ogni singolo detrito in movimento, eventualmente, andrà ad appesantire la CPU perchè, anche se in modo semplificato, dovrà cmq rispettare le leggi della fisica.

Al momento questo è un fattore delicato perchè appesantire il carico fisico della CPU potrebbe portare alla perdita del real time ... nella build 49, per dire, lo "slowmotion bug" era causato da oggetti in movimento (in particolare erano i coni). Naturalmente l'ottimizzazione del codice ha risolto il problema, ma nel caso avessimo centinaia di frammenti che volano mi chiedo se la più efficiente ottimizzazione sarebbe in grado di impedire il sovraccarico della CPU fisica.

Questa ipotesi potebbe essere aggirata nel caso che i frammenti agissero secondo "regole precalcolate" anzichè secondo le leggi fisiche fissate dal motore ISI, ma onestamente non conosco le intenzioni ISI e in ogni caso è un argomento probabimente un po' prematuro. :)
Click to expand...

certo certo :D lo chiedo perchè in effetti è da un bel pò di anni che non si vedono grandi novità nei danni delle auto e vedendo anche le gare in tv noto come i detriti siano la componente quasi principale di molte gare con molte forature... ora non dico che sarebbe bello avere un'alettone che si spacca in 100000000000000000000 pezzi (ho esagerato con gli 0 :p sarebbe un sogno) ma già vederlo che si rompe in 5/6 parti e se preso in pieno causa qualche danno... bhè è già un gran passo avanti......

Comunque staremo a vedere a tempo debito... ;)
 
Max Angelo said:
A me sembra la luce di una casa o magari di un lampione, altri pensano possa essere la luna, non saprei, di notte non ci ho mai girato. :)
Click to expand...

aumentando la luminosità del monitor si vede il profilo degli alberi..... o è la luna oppure boh... una lucciola davanti all'obbiettivo :D
 
You must log in or register to reply here.
Back
Top