DVD9 Big Enough for Next-Generation

[MistaPi]

Det må vel bety endel for loadingtider og at spillet går glatt jevnt over?

 

Jeg har merket meg at 360en sliter noe enormt når man spiller TES; Oblivion. Loadingtider er ganske lange og når man beveger seg rundt i verden opplever man ofte en liten loadingstopp på 1sek hver 50 meter man går. Kan dette ha noe med at dataen i Oblivion er så kompakt?

 

Hvis det er slik at PS3-spill kan ha bedre loadingtider, ha jevn flyt og bedre FPS (frames per second) ved å bruke større lagringsplass, vil jeg si det er en akutt fordel.

6974220[/snapback]

Ja bluray vil nok ha en fordel her, men mtp flyt i grafikken gjelder det i spill der dataene streames. På en annen side har Blueray høyere søketid enn DVD. Men streaming er uansett vanskelig å få gjordt riktig.

Jeg ville heller ikke dømt egenskapene til en konsoll ut ifra en PC port.

[kewell79]

One of the most interesting talks at London’s GDC (Games Developers Conference) this week came form one of the lesser known companies called Allegorithmic, who claim they will be able to reduce texture file sizes in games by up to 70%.

 

Their new programs, that they hope development artists will soon be using as an industry standard, are called ProFX and MaP Zone 2. Their ambition is to keep the graphical quality of game textures at the same standards as current games, whilst dramatically reducing the amount of data required for the game to work.

 

The implications of such a technology would be far reaching. As the current trend of digital distribution gains momentum a huge emphasis is being placed on games being made smaller and thus downloadable quicker. Their claim is that the current tool of choice for most games artists, Adobe Photoshop, is not ideally suited to making textures for games.

 

I was doubtful of this technology; however the company ran a demo that persuaded me otherwise. In the demo they had a bathroom full of beautiful textures, then with the flick of a button the bathroom took a more hellish look – all the while the textures looked the equal of Half Life 2.

 

The next demo was of a game that is due to come out for the XBOX Live Arcade called ‘Roboblitz’. Due to the requirement to get the game under 50MB, the developers needed to keep the textures as small in filesize as possible. Using the new texture system the overall size for all the textures was less than 280KB – watching the game (which runs on the Unreal 3 engine) I was amazed.

 

Confused by the fact that I hadn’t heard about this technology before, I spoke to one of the men behind it directly - Dr Sébastien Deguy. He assured me that there were no catches with his system, that if a game contained 1GB of textures he would be able to reduce that to 300MB and lose no quality. When I asked why everyone wasn’t using the program at the moment he explained it was due to people needing to be retrained in learning a new system. He was optimistic however, that soon all games companies will be using their new texture tools.

 

So what are the implications for you and I? In terms of traditionally packaged games that come in boxes, there probably won’t be much difference.Dr Deguy argues that if textures are smaller in file size and easier to create, then next-generation companies will be able to create even more textures for the games. We may then see a big leap forward in how richly detailed games are in the future as they triple the variety of textures the game includes.

 

The biggest impact however will be the benefits this will have to digital distribution. Games with texture quality and diversity matching Half Life 2 may soon be available in minutes of downloading rather than hours – for gamers this can only be a good thing.

 

BIT-TECH.NET

[Chaqwa]

 

XNA is a development tool that Microsoft introduced in 2004. XNA helps developers build games more quickly and more efficiently. XNA represents a refinement of everything that has been learned developing for the Xbox, which has an architecture that is very similar to the Xbox 360. As a new development tool, it represents a change in the way that game developers might program, and how it impacts on filesize is an unknown factor.

 

Editor's Note: After the initial publication of this article, we received an e-mail from Brian Keller, a Microsoft Product Manager who works on the XNA development tools. He's written an excellent and detailed post about how the XNA development tools influence final game sizes. We encourage you to read the detailed explanation of how this works, but generally speaking Brian confirms that XNA really does seem to help reduce the number of unused assets that float around during development, cluttering things up and ultimately leading to bloated programs. One example he uses is MechCommander 2, which it turns out shipped with an astonishing 40% of its textures never used during the final build of the game. XNA helps to limit this sort of underutilized scattering of textures by providing more efficient managing tools, among other things. If you're interested in this sort of discussion, his post is worth reading.

 

 

Procedural Synthesis:

 

Procedural synthesis is has a great deal of potential to effect the Xbox 360's filesizes. In short, procedural synthesis is a way of producing graphics that Microsoft has pushed heavily with the introduction of the Xbox 360, including specific hardware functions designed to do handle procedural synthesis. It uses algorithms to produce high quality graphics out of extremely small files. For the best example of what procedural synthesis can do, check out .kkrieger, which means Warrior in German. This first person shooter is built almost entirely from procedural graphics, and as a consequence occupies about 96 Kilobytes of space. Yes, the game responsible for this screenshot here, here, and here could fit almost 14 copies on an old-fashioned 1.4 megabyte floppy disk.

 

You can download a beta version of this game from the developer's website here, but be warned that it's fairly buggy, and meant more as a technology demonstration than anything else.

 

Procedural synthesis is the reason that Elder Scrolls IV: Oblivion has such brilliant forests. Oblivion makes use of a technology called SpeedTree, a middleware product for procedurally generating forests and foliage.

[Penneknekt]

Synes dette er en kjempespennende tråd. Utrolig hva man kan få til med dagens teknologi. En plassbesparelse på 70 % er intet mindre enn fantastisk, dersom det viser seg å stemme.

Endret 5. oktober 2006 av Penneknekt

[BlastyTrasty]

Einaste problemet då, med DVD9 - såvidt eg forstår det, er at disken må snurra så inni-hampen fort rundt, at det blir jo turbulens i leiligheita.

Bråk med andre ord.

[Knebel]

Synes dette er en kjempespennende tråd. Utrolig hva man kan få til med dagens teknologi. En plassbesparelsen på 70 % er intet mindre enn fantastisk, dersom det viser seg å stemme.

7005874[/snapback]

 

All komprimering samma hvordan du vender og vrir på det kommer forøvrig på bekostning av både prosessorbruk og tid.

[lonnj89]

Einaste problemet då, med DVD9 - såvidt eg forstår det, er at disken må snurra så inni-hampen fort rundt, at det blir jo turbulens i leiligheita.

Bråk med andre ord.

7005970[/snapback]

 

Det høres på 360en for å si det sånn

[Mala]

Synes dette er en kjempespennende tråd. Utrolig hva man kan få til med dagens teknologi. En plassbesparelsen på 70 % er intet mindre enn fantastisk, dersom det viser seg å stemme.

7005874[/snapback]

 

Enig,det systemet der hørtes nesten for godt ut til å vere sannt

[Gjest Slettet+214asdf125]

PS3 er best, Cell knuser alt og kan ta over verden hvis den vil det.

6971903[/snapback]

 

Cell vil løse kreft- og aids-problemene våre! Det er et dokumentert faktum at sykehus og forskere over hele verden har bestilt PS3 for å ta seg av avanserte utregninger!

 

Hvor melder jeg meg inn i klubben?

 

On-topic så er det et godt poeng at man ikke trenger så mye plass med mindre man skal stappe i enda mer CGI osv. Plasskravet kan komme om ei stund, men i nærmeste framtid så er jeg nok i tvil om at det kommer til å bli nødvendig.

Endret 5. oktober 2006 av Slettet+214asdf125

[arnegn]

Jeg vil tro at hvis det skulle være et problem med DVD9, så er det overføringshastigheten. Den er en skikkelig flaskehals. Med komprimering så går overføringshastigheten ned, og behandlinsgtiden opp - antageligvis gjelder det å finne en balanse her. Dette er uansett like aktuelt for blu-ray, siden overføringshastigheten er enda lavere. Men der kan de forsåvidt legge de samme filene på flere steder, slik at søkehastigheten går litt ned.

 

Inmari dumt at man ikke bare kan legge spillene inn på harddisken

[siDDis]

Er me heldige så blir flashminne så billeg snart at me får med ein disc og flashpenn på kjøpet for *store* spel

[Mala]

Inmari dumt at man ikke bare kan legge spillene inn på harddisken 

7007181[/snapback]

 

Bare synd at MS for øyeblikket tilbyr 14 GB til rådighet på nåvernede HDD. Lykke til med å legge spillene inn på den

[Vo0do0]

Synes dette er en kjempespennende tråd. Utrolig hva man kan få til med dagens teknologi. En plassbesparelsen på 70 % er intet mindre enn fantastisk, dersom det viser seg å stemme.

7005874[/snapback]

 

All komprimering samma hvordan du vender og vrir på det kommer forøvrig på bekostning av både prosessorbruk og tid.

7006000[/snapback]

 

 

Jeg vil tro at hvis det skulle være et problem med DVD9, så er det overføringshastigheten. Den er en skikkelig flaskehals. Med komprimering så går overføringshastigheten ned, og behandlinsgtiden opp - antageligvis gjelder det å finne en balanse her. Dette er uansett like aktuelt for blu-ray, siden overføringshastigheten er enda lavere. Men der kan de forsåvidt legge de samme filene på flere steder, slik at søkehastigheten går litt ned.

 

Inmari dumt at man ikke bare kan legge spillene inn på harddisken 

7007181[/snapback]

 

Det er jo ikke snakk om komprimering her. Det er kun snakk om at de klarer å få samme resultat med å bruke en mindre datamengde. Dette vil jo ikke bare være plassbesparenede, men også sørge for at man kan laste flere teksturer inn i minnet, raskere og samtidig.

 

#include <iostream>

using namespace std;

 

int main ()

{

  cout << "Yoyoyo";

}

 

 

#include <iostream>

using namespace std;

 

int main ()

{

  int var = 0;

  for(int i = 0 ; i < 100 ; i++){

      while(var<100){

          if(i != 100){

                var++;

          }

          else{

                cout << "Yoyoyo";

          }

      }

  }

}

 

Begge gir samme resultat, men dere kan jo gjette hvilken som tar mest plass, og krever mest prossesering. Dette er jo absolutt ikke et reealistisk eksempel, da dettte er gjort i samme språk, og koden er på trynet. Men poenget er der.

Tar forbehold om feil i koden, er en stund siden jeg har gjort noe i c++ nå.

[Knebel]

Snip

 

Begge gir samme resultat, men dere kan jo gjette hvilken som tar mest plass, og krever mest prossesering. Dette er jo absolutt ikke et reealistisk eksempel, da dettte er gjort i samme språk, og koden er på trynet. Men poenget er der.

Tar forbehold om feil i koden, er en stund siden jeg har gjort noe i c++ nå.

7007334[/snapback]

 

Umm.. Det er vel hovedsakelig snakk om teksturer og reduksjon av disse..

Dersom man skal holde samme kvalitet må det en eller annen form for komptimering til. Vi snakker forøvrig om en komprimerings ratio på 1GB til 300MB. Det skjer ikke uten å bruke prosessorkraft.

Endret 5. oktober 2006 av Fhj

[Vo0do0]

Snip

 

Begge gir samme resultat, men dere kan jo gjette hvilken som tar mest plass, og krever mest prossesering. Dette er jo absolutt ikke et reealistisk eksempel, da dettte er gjort i samme språk, og koden er på trynet. Men poenget er der.

Tar forbehold om feil i koden, er en stund siden jeg har gjort noe i c++ nå.

7007334[/snapback]

 

Umm.. Det er teksturer det er snakk om og reduksjon av disse.. Ikke kode..

Dersom man skal holde samme kvalitet må det en eller annen form for komptimering til. Vi snakker forøvrig om en komprimerings ratio på 1GB til 300MB. Det skjer ikke uten å bruke prosessorkraft.

7007424[/snapback]

 

Ops. Tenkte meg ikke helt om der....

Teksturer... Bilder... Komprimering.... Ja...

[Vo0do0]

Hmm... Men det må da finnes en måte å lage bilder mindre på i oppbygginsfasen uten koprimering...

Her har jeg ikke peiling på noe egentlig, men det forundrer meg om det ikke skal gå ann å lage de samme teksturene, uten å komprimere, og likevell få samme kvalitet.

[KayAU]

Begge gir samme resultat, men dere kan jo gjette hvilken som tar mest plass, og krever mest prossesering. Dette er jo absolutt ikke et reealistisk eksempel, da dettte er gjort i samme språk, og koden er på trynet. Men poenget er der.

Tar forbehold om feil i koden, er en stund siden jeg har gjort noe i c++ nå.

7007334[/snapback]

Nummer to trur eg ikkje vil gi noko resultat, faktisk...i det betingelsen (i != 100) blir usann, vil ikkje for-løkka køyre fleire gongar. Og sjølv om ho hadde gjort det, ville du ikkje få køyrt "else"-blokka, sidan denne ligg inni ei "while"-blokk der betingelsen vart usann for lenge, lenge sidan (i første køyring av "for"-blokka). Ellers anbefalar eg deg å bruke prefiks-versjonane av inkrementerings- og dekrementerings-operatorane med mindre du treng å få den gamle verdien returnert (til dømes dersom du har noko slikt som "int value = anothervalue++", og vil at value skal innehalde verdien anothervalue hadde før inkrementering). Det er meir effektivt.

 

Novel, nok off-topic.

 

EDIT: Rota saman prefiks- og postfiks-operatorane...rakk heldigvis å rette det før nokon sa noko.

 

Kay

Endret 5. oktober 2006 av KayAU

[Dinsdale]

Ops. Glemte å quote. Postet forresten for en stund siden noenlunde det samme. Derfor har jeg aldri vært i tvil. Komprimeringsteknologien blir bedre og bedre.

Endret 5. oktober 2006 av Dinsdale

[Vo0do0]

Begge gir samme resultat, men dere kan jo gjette hvilken som tar mest plass, og krever mest prossesering. Dette er jo absolutt ikke et reealistisk eksempel, da dettte er gjort i samme språk, og koden er på trynet. Men poenget er der.

Tar forbehold om feil i koden, er en stund siden jeg har gjort noe i c++ nå.

7007334[/snapback]

Nummer to trur eg ikkje vil gi noko resultat, faktisk...i det betingelsen (i != 100) blir usann, vil ikkje for-løkka køyre fleire gongar. Og sjølv om ho hadde gjort det, ville du ikkje få køyrt "else"-blokka, sidan denne ligg inni ei "while"-blokk der betingelsen vart usann for lenge, lenge sidan (i første køyring av "for"-blokka). Ellers anbefalar eg deg å bruke prefiks-versjonane av inkrementerings- og dekrementerings-operatorane med mindre du treng å få resultatet av operasjonen returnert (til dømes dersom du har noko slikt som "int value = anothervalue++", og vil at value skal innehalde verdien av anothervalue pluss 1). Det er meir effektivt.

 

Novel, nok off-topic.

 

Kay

7007542[/snapback]

 

Hehe.

Ja, dette kan nok du, som har programmert hele livet, bedre enn meg.

Jeg går for en mer driftsrettet utdanning. Og C++ var absolutt et av de faga jeg likte minst.

Men jeg ser at det er feil nå. Forhåpentligvis får jeg ikke brukt for dette senere i livet.

[Bromlexl]

Einaste problemet då, med DVD9 - såvidt eg forstår det, er at disken må snurra så inni-hampen fort rundt, at det blir jo turbulens i leiligheita.

Bråk med andre ord.

7005970[/snapback]

 

Det høres på 360en for å si det sånn

7006035[/snapback]

HÆÆÆÆ!!!

 

DU MÅ SKRIVE HØYERE, 360EN BRÅKER SÅ MYE AT JEG IKKE KAN LESE ET ORD AV DET DU SKRIVER!!!