Microsoft conferma il supporto ai 1080p per XBox 360

Microsoft conferma il supporto ai 1080p per XBox 360

Basta un aggiornamento software per consentire a XBox 360 di eseguire giochi e film alla risoluzione 1080p.

di pubblicata il , alle 16:26 nel canale Videogames
MicrosoftXbox
 
41 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
essereumano22 Settembre 2006, 02:32 #31
Ma la ps3 è già uscita? No perchè tutta sta gente che dice che è meglio l'xbox 360 la play3 prima la deve aver provata... o parla solo con i numeri davanti....
Jon_Snow22 Settembre 2006, 05:54 #32
"Se un software è in 720p, noi siamo in grado di portare la risoluzione a 1080p, se è già in 1080p esso può essere visualizzato in 1080p"


Ovviamente se un gioco ha delle texture per 720p si deve interpolare per portare a 1080p, l'algoritmo che "crea" l'informazione deve ancora nascere.

kenjcj200022 Settembre 2006, 07:39 #33
Originariamente inviato da: essereumano
Ma la ps3 è già uscita? No perchè tutta sta gente che dice che è meglio l'xbox 360 la play3 prima la deve aver provata... o parla solo con i numeri davanti....


che bel discorso è colpa nostra se non è uscita? oppure di sony che è la terza volta che rimanda il lancio? poi se permetti le specifiche le abbiamo non è come vederla girarare ma una idea se uno se ne intende se la può fare ....oppure no?

io non vedo gente che dice che il 360 è meglio sinceramente.. la mio opinine è che non sarà migliore del 360 come quest^ultimo non sarà migliore della play3 saranno due macchine molto vicine e come al solito la differenza la faranno i giochi
vincino22 Settembre 2006, 09:07 #34
Una cosa nn mi torna! Ricordo di aver letto tempo fa che i films HD saranno riproducibili solo su interfacce digitali! Proprio in virtù dei controlli HDCP. Ricordo anche di aver letto che gli stessi contenuti verranno riprodotti automaticamente in SD in caso di una connessione analogica. Ba!
diabolik198122 Settembre 2006, 09:14 #35
Originariamente inviato da: bonzuccio
ma la xbox non monta una ati 1800?


Non è una x1800, che in codice è R520 ma un processore R500 che è molto più vicino a R580, ovvero l'attuale x1900, ma sarà ancora più simile al futuro R600, ovvero la prossima top di gamma Ati che sarà in DX10.
leoneazzurro22 Settembre 2006, 09:22 #36
Originariamente inviato da: diabolik1981
Non è una x1800, che in codice è R520 ma un processore R500 che è molto più vicino a R580, ovvero l'attuale x1900, ma sarà ancora più simile al futuro R600, ovvero la prossima top di gamma Ati che sarà in DX10.


Direi mooooolto più vicino a R600 che a R580
diabolik198122 Settembre 2006, 09:25 #37
Originariamente inviato da: leoneazzurro
Direi mooooolto più vicino a R600 che a R580



Infatti è quello che ho scritto... o si capisce male?
leoneazzurro22 Settembre 2006, 10:08 #38
Originariamente inviato da: diabolik1981
Infatti è quello che ho scritto... o si capisce male?


Ma prima di prendersela a male perchè non si cerca di capire quello che uno vuole dire... ma perchè si è così permalosi a volte. Quindi la mia era solo una conferma di quello che dicevi, non una confutazione, e magari una precisazione, dato che a parte il fatto di avere 16 TMU R580 e R500 hanno molto, ma molto poco in comune. Il primo, pur avendo un "dispatch processor" è un'architettura ancora tradizionale, con una distinzione netta tra vertex e pixel shader, mentre il secondo è un'architettura unificata con un arbiter che alloca dinamicamente le unità shader alle operazioni sui vertici e/o alle operazioni sui pixel. La logica di funzionamento è parecchio differente. Questo per dire che, anche se R600 prenderà presumibilmente spunto da alcune caratteristiche di R520/580 (che tra l'altro sono molto simili tra di loro) come il ring bus controller, il modo di operare sarà quasi identico (operazioni raster a parte) a Xenos.
diabolik198122 Settembre 2006, 10:15 #39
Originariamente inviato da: leoneazzurro
Ma prima di prendersela a male perchè non si cerca di capire quello che uno vuole dire... ma perchè si è così permalosi a volte. Quindi la mia era solo una conferma di quello che dicevi, non una confutazione, e magari una precisazione, dato che a parte il fatto di avere 16 TMU R580 e R500 hanno molto, ma molto poco in comune. Il primo, pur avendo un "dispatch processor" è un'architettura ancora tradizionale, con una distinzione netta tra vertex e pixel shader, mentre il secondo è un'architettura unificata con un arbiter che alloca dinamicamente le unità shader alle operazioni sui vertici e/o alle operazioni sui pixel. La logica di funzionamento è parecchio differente. Questo per dire che, anche se R600 prenderà presumibilmente spunto da alcune caratteristiche di R520/580 (che tra l'altro sono molto simili tra di loro) come il ring bus controller, il modo di operare sarà quasi identico (operazioni raster a parte) a Xenos.


Non me la sono assolutamente presa a male, anzi. Ho creduto di aver scritto in modo un po troppo confuso. Cmq ci siamo chiariti e come sempre tutto ok e grazie anche per la spiegazione tecnica a supporto.
leoneazzurro22 Settembre 2006, 10:41 #40
Originariamente inviato da: diabolik1981
Non me la sono assolutamente presa a male, anzi. Ho creduto di aver scritto in modo un po troppo confuso. Cmq ci siamo chiariti e come sempre tutto ok e grazie anche per la spiegazione tecnica a supporto.




xnonikname:

Sono d'accordo su quanto dici, a parte i "limiti architetturali di Xenos", dato che comunque si è nella condizione di 16 TMU su Xenos e 24 su RSX, quindi il divario teorico nelle operazioni di texture mapping è di 2/3*(500/550) ma è anche vero che Xenos ha una migliore efficienza intrinseca dovuta all'architettura unificata e che si sta apssando a situazioni dove il collo di bottiglia sono non tanto le TMU quanto i PS (se vogliamo cercare un limite architetturale in Xenos direi di parlare proprio dell'accoppiata memoria unificata+RAM embedded, che se da un lato permette l'utilizzo di AA4x a 720p, dall'altra limita l'utilizzo di risoluzioni superiori). Ad ogni modo è bene ricordare che la banda a disposizione della GPU non è eccezionale in entrambi i casi (bus a 128 bit) quindi gli sviluppatori dovranno fare i salti mortali (o utilizzare pesantemente degli algoritmi di compressione/decompressione texture e dati grafici "on the fly" per mandare alla GPU la quantità di texture promesse dai prossimi giochi.
« 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.
 
^