Perry su GaiKai: organizzazione dei server e aspetti tecnici

Perry su GaiKai: organizzazione dei server e aspetti tecnici

Dave Perry ha rivelato nuovi dettagli tecnici sulla tecnologia di cloud computing per videogiochi che sta sviluppando.

di pubblicata il , alle 15:42 nel canale Videogames
 
17 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
II ARROWS20 Luglio 2009, 22:07 #11
Non hai capito Mantis, la latenza indica il tmpo necessario ad una informazione per raggiungere il destinatario. Questo fantomatico sistema deve ricevere i dati di input dall'utente, elabolarli e inviare il video sullo schermo del giocatore.
Quando giochi i tuoi input non devono percorrere alcun tragitto quindi non esiste lag, che appare quando giochi in rete. Se il sistema impiega un decimo di secondo solo per ricevere i dati, ne consegue che non può calcolare più di dieci fotogrammi al secondo.
CountDown_020 Luglio 2009, 22:49 #12
Non direi, II ARROWS. Ne può calcolare anche molti di più, di fotogrammi al secondo, e inviarli al giocatore, ma tutti saranno colpiti da un ritardo sistematico di 0.1 secondi nel mostrare a video il risultato della pressione del tasto. Questo però non limita il frame rate: in un gioco di corse tu potresti anche stare fermo, alla partenza (senza cioè inviare alcun comando), e vedere tutti gli altri che partono, e dopo un po' che ti doppiano, ecc, con un frame rate elevatissimo (banda permettendo). Allo stesso modo, potresti anche decidere di inviare molto più di 10 comandi al secondo: il risultato di ciascuno di essi lo vedresti dopo 0.1 secondi, ma teoricamente potresti benissimo inviare, che so, 25 comandi/secondo e allo stesso tempo vedere il gioco a 60 fps. Banda permettendo...

Comunque, anche per me 100 ms di ritardo per un FPS sono troppi, e in generale per i giochi d'azione, sono troppi. Per altri giochi, invece, penso possano andare.
Mantis-8920 Luglio 2009, 23:48 #13
Originariamente inviato da: CountDown_0
Non direi, II ARROWS. Ne può calcolare anche molti di più, di fotogrammi al secondo, e inviarli al giocatore, ma tutti saranno colpiti da un ritardo sistematico di 0.1 secondi nel mostrare a video il risultato della pressione del tasto. Questo però non limita il frame rate: in un gioco di corse tu potresti anche stare fermo, alla partenza (senza cioè inviare alcun comando), e vedere tutti gli altri che partono, e dopo un po' che ti doppiano, ecc, con un frame rate elevatissimo (banda permettendo). Allo stesso modo, potresti anche decidere di inviare molto più di 10 comandi al secondo: il risultato di ciascuno di essi lo vedresti dopo 0.1 secondi, ma teoricamente potresti benissimo inviare, che so, 25 comandi/secondo e allo stesso tempo vedere il gioco a 60 fps. Banda permettendo...

Comunque, anche per me 100 ms di ritardo per un FPS sono troppi, e in generale per i giochi d'azione, sono troppi. Per altri giochi, invece, penso possano andare.


Esatto

Originariamente inviato da: II ARROWS
Non hai capito Mantis, la latenza indica il tmpo necessario ad una informazione per raggiungere il destinatario. Questo fantomatico sistema deve ricevere i dati di input dall'utente, elabolarli e inviare il video sullo schermo del giocatore.
Quando giochi i tuoi input non devono percorrere alcun tragitto quindi non esiste lag, che appare quando giochi in rete. Se il sistema impiega un decimo di secondo solo per ricevere i dati, ne consegue che non può calcolare più di dieci fotogrammi al secondo.


Non è che ti confondi con la latenza dei monitor?
II ARROWS21 Luglio 2009, 15:38 #14
Non hai letto per nulla il mio messaggio...

Non avessi specificato PER NON NOTARE DIFFERENZE...
Mantis-8921 Luglio 2009, 16:08 #15
Se non ho capito io prova a spiegarmi meglio che a volte ci arrivo in ritardo alle cose.
Mantis-8921 Luglio 2009, 16:26 #16
Da quanto ne so io, se c'è una latenza di 100ms significa che i segnali d


la latenza indica il tmpo necessario ad una informazione per raggiungere il destinatario

Giusto.
Questo fantomatico sistema deve ricevere i dati di input dall'utente, elabolarli e inviare il video sullo schermo del giocatore.

Più che giusto.
Quando giochi i tuoi input non devono percorrere alcun tragitto quindi non esiste lag

Più la macchina è potente meno si vede, diciamo che non è percepibile
Se il sistema impiega un decimo di secondo solo per ricevere i dati, ne consegue che non può calcolare più di dieci fotogrammi al secondo.

Non è che il sistema impega 1 decimo di secondo a ricevere i dati, ma che li riceve dopo 1 decimo di secondo rispetto a quando sono stati spediti(anzi li riceve sopo 50ms in quanto la latenza indica il tempo di risposta non di ricezione), quindi in 1 decimo di secondo può ricevere anche 200 segnali di input dell'utente ma tutti vecchi di mezzo decimo di secondo. In questo decimo di secondo quindi il server può elaborare tutti i fotogrammi che è in grado, facciamo un esempio realistico di 20-30 fotogrammi al secondo per utente ed inviarli ma l'utente li riceverà vecchi del tempo di latenza.
Sbaglio qualcosa in questo..?

Resta il fatto che in certe categorie di giochi vedere fotogrammi "vecchi" di 100ms non sia sufficiente per garantire un gioco fluido.
II ARROWS26 Luglio 2009, 23:51 #17
PER NON NOTARE DIFFERENZE.
« Pagina Precedente     Pagina Successiva »

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