Nintendo Revolution

SHDR

Gullmedlem
#21
Det var noen som mente at grafikkbrikken ville være et derivativ av R350, og det tror jeg ikke stemmer. Var noen i utviklermiljøet som regnet med at den ville lande rundt x1800. Jeg aner ikke hva det innebærer, siden jeg er helt ute på viddene hva angår PC-maskinvare i disse dager, men om jeg ikke husker helt feil, så er R350 R9800 og oppover, right?

Ellers betyr vel en ~900MHz PowerPC at vi kan vente oss noe tilsvarende en ganske mye sterkere desktop-prosessor hva angår reell ytelse. Siden den helt sikkert er out-of-order, blir den litt mer fleksibel og koselig med hensyn til programmering også. 100MB RAM er jo heller ikke så katastrofalt, men høres litt lite ut. Har sannsynligvis ikke så mye å si; jeg blir ofte overrasket over hvor mye teksturer de klarer å hamre inn i minnet på GC-en og Xboxen.

Men den er svakere enn de andre. Tilpasset SDTV. Blir sannsynligvis mer enn pent nok, siden grafikkbrikken visstnok skulle støtte SM3.0 og gode greier. Noen som har noen kilder? Som ikke er gjort av folk som tenker at ~900MHz er P3-standard? Ah, og er det noen som har noen teorier om hva de 3MB-ene med VRAM skal gjøre? Er det tenkt at det skal være en AA-enhet slik som EDRAM-en i x360?
 
#22
"To be honest, it's not much more powerful than an Xbox. It's like a souped up Xbox," a major third party source revealed to us. [/b]
Skjønner ikke at alle tar dette som god fisk, det er jo totalt usannsynlig. Da kunne de likegreit brukt eksiterende gamecube hardware, som idag viser like god eller bedre grafikk som xbox. Grafikk er ikke alt, det er ikke engang veldig mye, men i spill som Metroid Prime og et ikke-celshadet Zelda er det greit å få en oppjustering i grafikken.
 

Kilik

Lokal moderator
#23
Det var noen som mente at grafikkbrikken ville være et derivativ av R350, og det tror jeg ikke stemmer. Var noen i utviklermiljøet som regnet med at den ville lande rundt x1800. Jeg aner ikke hva det innebærer, siden jeg er helt ute på viddene hva angår PC-maskinvare i disse dager, men om jeg ikke husker helt feil, så er R350 R9800 og oppover, right?
[/b]
Vel, i følge RevoGaming (jeg vet, litt dodgy kilde) vil det bli en RV530 i Revo. RV530 er kodenavnet for X1600-serien, den nye mid-range serien til ATI som kommer i Pro og XT-utgave. Jeg tror vi snakker om ca. 50% økning sammenlignet med 9800 Pro i dagens PC-spill. I tillegg støtter den 3.0 pixel og vertex shaders. En slik chip vil trolig være bra nok for next-gen i SDTV-oppløsning.

Jeg tror faktisk Nintendo kan med litt smarte designvalg kan klare å konkurrere med grafikk på SDTV-nivå. Ikke når det gjelder potensialet i hardwaren, men spillytelse i praksis. Det gjør at multiplattformspill også kan kjøres på Revo. Bare det at utviklerne slipper å sette seg inn i en helt ny, komplisert og ukjent arkitektur, slipper parallellisering av heterogene prosessorkjerner, slipper in-order prosessering etc. gjør at Revolution på mange måter har store fordeler når det gjelder utnyttelse av hardwaren. For hvor mange spill vil egentlig benytte seg av alle sju SPE-kjernene i PS3? Veldig få vil jeg tro. Kanskje bare eksklusive spill med meget lang utviklingssyklus som MGS4. Og slike spill vil jo ikke komme til Revo uansett.

Lite RAM er jo noe konsoller alltid har hatt, men har fått til det utroligste sammnenlignet med RAM-slukende Windows PC-er. PS1 hadde 2 MB RAM og kjørte spill som Metal Gear Solid. Med tanke på lavere oppløsning, vil nok Revo også klare seg med en del mindre RAM en konkurrentene. Dette vil jo også avhenge av hastighet på RAM, busser etc., noe vi ikke vet en dritt om ennå. Jeg velger å være optimist på Nintendos vegne.

Men så er det dette med "HD-æraen" som MS så fint kaller det. Hvis HDTV-salget virkelig tar av i 2006/2007, kan dette sette Revo i et dårlig lys. Det kan faktisk bli like viktig å ha HDTV-støtte på konsoll, som det var å ha DVD-avspilling i konsollene i 2000/2001.


Forøvrig har jeg tenkt litt på Zelda: Twilight Princess i det siste. Jeg tror det kan bli utsatt helt til Revo-lanseringen. De fleste forventer vel at spillet kommer ut til våren/sommeren, men Nintendo har ikke sagt noe mer enn TIDLIGST 2.kvartal 2006. Med tanke på hvor svakt Gamecube gjør det for tiden (flere kjeder er i ferd med å fase den ut for godt), så vil spillet neppe selge like bra som forventet. Jeg tror derfor det vil konverteres til Revo også, noe som vil være lett med tanke på så lik hardware. Med grafikkforbedringer og tilpasning til Revo-kontrollen (f.eks. legge til noen kontroll-spesifikke mini-games), så vil Nintendo ha et helvetes godt lanseringsspill høsten 2006.
 
#24
<div class='quotemain'>
Det var noen som mente at grafikkbrikken ville være et derivativ av R350, og det tror jeg ikke stemmer. Var noen i utviklermiljøet som regnet med at den ville lande rundt x1800. Jeg aner ikke hva det innebærer, siden jeg er helt ute på viddene hva angår PC-maskinvare i disse dager, men om jeg ikke husker helt feil, så er R350 R9800 og oppover, right?
[/b]
Vel, i følge RevoGaming (jeg vet, litt dodgy kilde) vil det bli en RV530 i Revo. RV530 er kodenavnet for X1600-serien, den nye mid-range serien til ATI som kommer i Pro og XT-utgave. Jeg tror vi snakker om ca. 50% økning sammenlignet med 9800 Pro i dagens PC-spill. I tillegg støtter den 3.0 pixel og vertex shaders. En slik chip vil trolig være bra nok for next-gen i SDTV-oppløsning.
[/b][/quote]

Nettopp. Tror Shadar bommet litt, jeg skrev R530 og ikke R350 (R350 er rundt 9800 Pro, ja).


Uansett så spiller dette ikke noen stor rolle. Tar jeg ikke feil så bruker vanlig Xbox en oppgradert versjon av Geforce 3, og alikevel klarte den å dra rimelig lekre spill (De er jo tilpasset, men alikevel imponerende for GF3)
 

Kilik

Lokal moderator
#25
Nintendo patents displacement mapping
Displacement mapping er jo ikke akkurat noe nytt konsept, men det er vel en ny effektiv real-time metode det er snakk om. Kanskje en helt ny algoritme som optimiserer 3D-ytelse noe enormt? Såpass mye at den utligner forspranget MS og Sony har i rå styrke på hardwaresiden? En spennende tanke...Og kanskje denne nye teknologien er implementert i Hollywood-chipen til ATI?
 
#27
Displacement mapping blir jo brukt i modeller som trenger mange detaljer, så de må også bruke flere polygoner, noe som går utover ytelsen så klart, men at 3D-ytelsen vil stige er riktig; det er nettopp det displacement mapping er kjent for- det gir en mer 3D-ish stil.

EDIT: Displacement mapping er et alternativ til bump mapping, for å lage ujevnheter i overflater. Man legger på et slags filter som jobber sammen med et tesselation-program. Man kan da lage mer levende og mer 3D-ish overflater,og derfor er det litt mer ressurskrevende enn bump mapping.

Så vidt jeg husker :svette:
 

Buggz

Jævla Buggz
Medlem av ledelsen
#28
Displacement mapping kan sammenlignes med bump mapping. Over en tekstur legger man et nytt bilde (i gråtoner) som gir informasjon om høyder (f.eks. som topografien på et kart). Displacement mapping lager så det fysiske resultatet. Mens bump mapping bare gir informasjon om hvordan lys og skygger skal fungere på en tekstur, så tar displacement mapping og forskyver de forskjellige delene av polygonet ved å legge på flere polygoner for å danne berg og daler.


Bedre forklart her
 
#29
som en oldschool og "hardcore" gamer vil jeg bare legge til at jeg desidert gleder meg mest til NR.
PS3 har vist noe nyskapende ut ifra hva jeg har hørt så langt, og det eneste jeg spiller i det siste er DS spill fordi det gir meg noe nytt. ( bort ifra musikk- og rytmespill da )


men en ting...

kan noen forklare meg hva HD high definition innebærer og hvorfor det kan spille så stor rolle som kilik skal ha det til å gjøre?
hva gjør det med grafikken? blir det bare meget synlig skarpere bilde?
og hva med HD-projektorer? vil det fungere like bra som HDTV?



apropo projektorer: vil NR-kontrollen fungere på projektor? jeg leste at light-gun ( time crisis etc ) spill fungerte på projektor med xbox360, men jeg har ingen anelse hvordan det går.
 

Buggz

Jævla Buggz
Medlem av ledelsen
#30
Såvidt jeg har forstått baserer NR-kontrollen seg på selve bevegelsen og ikke på å fange opp lys. Dermed skal du kunne spille fra et annet rom, sålenge det trådløse systemet duger.

High definition, HD, er et ganske misbrukt begrep. Det blir brukt i forbindelse med en signifikant økning i oppløsning på en TV, men NTSC ble en gang kalt for hi-def, og det er nettopp fordi HD ikke er et entydig beskyttet begrep at TV-produsenter kan kalle produktene sine for "HD-ready" uten at de takler de nye HD-standardene 720p og 1080p/1080i. Med HD i dag menes som oftest en TV som har støtte for de standardene og takler høye oppløsninger.

EDIT: HD har forskjellige betydninger avhengig av hvilket land/kontinent man befinner seg i. I statene erstatter man NTSC med ATSC, mens i Japan utvikler man ISDB for digital TV og radio. I tillegg er det en stor del av industrien som er med på et prosjekt kalt DVB, som skal bli en standard i europa. Jeg kan heller lite om dette, så noen må gjerne hoppe inn og opplyse oss.

En light gun fungerer ved at den fanger opp lyset fra TV-en/prosjektoren. Det lille utsnittet sammenlignes med hele bildet, og maskinen finner da ut av hvor "lyspistolen" sikter for øyeblikket.
 

SHDR

Gullmedlem
#31
Sakset fra Edge-forumet:

Opprinnelig skrevet av Mandelbrot78@Edge Online

Image Based Rendering and Lighting

This is a very broad term, referring to a set of techniques that rely on images (like photos or even video) to create a 3d representation of a scene, instead of geometry. Matrix introduced this technique in movies, and the most well known application (albeit a very simple one) is QuickTime VR. Current technologies have evolved a lot since the days of QuickTime VR: We can now move freely around a scene, relight it, or even capture a dynamic scene. These techniques are ideal for games, and any real-time 3D application, since it is photorealistic by default (it uses photos) and doesn’t need as many calculations as geometry.

Will it be done? HDRI is the next big thing (an IBL technique) even if the industry has just discovered it (there is a real-time 3d demo on a Geforce 2, which appeared a long time ago:(http://www.debevec.org/Research/HDRTM/). Without knowing any details, I suspect that “Fight Night: round 3” is using IBR techniques. So I don’t know: It’s just a matter of some developer breaking the mould and moving towards that direction.

Problems with IBR: They are still on experimental stages and there aren’t any commercial tools available (apart from Image Modellers). Also, they need a different kind of 3D accelerator: http://www.cs.unc.edu/~ibr/projects/HQWarp...ityWarping.html (although there are hybrid geometry/IBR techniques that make use of current hardware technology). Again, as with Voxels, texture memory is a big issue.

A few links:
http://www.debevec.org/
http://people.csail.mit.edu/wojciech/
http://grail.cs.washington.edu/projects/slf/
http://grail.cs.washington.edu/projects/realface/
http://grail.cs.washington.edu/projects/ldi/
http://www.cs.unc.edu/~ibr/
http://www.cs.cmu.edu/afs/cs/project/Virtu...rtualizedR.html
http://http.cs.berkeley.edu/projects/vision/ibr/
Mitt svar:
Opprinnelig skrevet av SHDR@Edge Online
The good (or rather wretched) Ken Silverman has actually released a voxel engine, source code, editing tools, documentation and all for free from his horrible mess of a website: http://advsys.net/ken/voxlap.htm

I've had a little look at it, and it's actually pretty awesome. Fully destructible environments (although slightly weird collision detection cripples the effect, but I'm sure some proper physics programming can be integrated into the source code), and apparently it can use displacement maps. Textures actually look meatier and more tangible when represented by voxels than trilinear'd pixels. I haven't tried doing anything with it (although I have some awesome ideas for a 2D-genre mix'em-up that might be made sometime in the future, for which this is simply perfect), but maybe some of you can have a gander.

I don't think anyone has actually used the engine for anything. I want to end that trend.

Also, about image-based rendering. Didn't Nintendo file a (bunch of?) patents about that around a year back? I seem to remember reading about compositing fully interactive 3D visuals from a set of images or photographies. Perhaps the Revolution is built around this? Could go some way in explaining their different architecture and the fact that we don't really know anything about their GPU yet.

Perhaps it is built around IBR?

I'm gonna see if I can find those patent papers ...

"Method and apparatus for obtaining a scalar value directly from a vector register


Abstract
A method and apparatus for obtaining a scalar value from a vector register for use in a mixed vector and scalar instruction, including providing a vector in a vector register file, and embedding a location identifier of the scalar value within the vector in the bits defining the mixed vector and scalar instruction. The scalar value can be used directly from the vector register without the need to load the scalar to a scalar register prior to executing the instruction. The scalar location identifier may be embedded in the secondary op code of the instruction, or the instruction may have dedicated bits for providing the location of the scalar within the vector.


FIELD OF THE INVENTION

This invention relates to information processors, such as microprocessors, and, more particularly, to a method and apparatus which improves the operational efficiency of information processors having a vector processing unit by enabling a scalar value to be directly selected from a vector register for use, for example, in a mixed vector and scalar operation.

BACKGROUND OF THE INVENTION

The electronic industry is in a state of evolution spurred by the seemingly unquenchable desire of the consumer for better, faster, smaller, cheaper and more functional electronic devices. In their attempt to satisfy these demands, the electronic industry must constantly strive to increase the speed at which functions are performed by data processors. Videogame consoles are one primary example of an electronic device that constantly demands greater speed and reduced cost. These consoles must be high in performance and low in cost to satisfy the ever increasing demands associated therewith. The instant invention is directed to increasing the speed at which a vector processing units of information processors can perform mathematical operations when a scalar is needed from a vector register to perform the operation.

Microprocessors typically have a number of execution units for performing mathematical operations. One example of an execution unit commonly found on microprocessors is a fixed point unit (FXU), also known as an integer unit, designed to execute integer (whole number) data manipulation instructions using general purpose registers (GPRs) which provide the source operands and the destination results for the instructions. Integer load instructions move data from memory to GPRs and store instructions move data from GPRs to memory. An exemplary GPR file may have 32 registers, wherein each register has 32 bits. These registers are used to hold and store integer data needed by the integer unit to execute integer instructions, such as an integer add instruction, which, for example, adds an integer in a first GPR to an integer in a second GPR and then places the result thereof back into the first GPR or into another GPR in the general purpose register file.

Another type of execution unit found on most microprocessors is a floating point unit (FPU), which is used to execute floating point instructions involving non-integers or floating point numbers. Floating point numbers are represented in the form of a mantissa and an exponent, such as 6.02.times.10.sup.3 A floating point register file containing floating point registers (FPRs) is used in a similar manner as the GPRs are used in connection with the fixed point execution unit, as explained above. In other words, the FPRs provide source operands and destination results for floating point instructions. Floating point load instructions move data from memory to FPRs and store instructions move data from FPRs to memory. An exemplary FPR file may have 32 registers, wherein each register has 64 bits. These registers are used to hold and store floating point data needed by the floating point execution unit (FPU) to execute floating point instructions, such as a floating point add instruction, which, for example, adds a floating point number in a first FPR to a floating point number in a second FPR and then places the result thereof back into the first FPR or into another FPR in the floating point register file.

Microprocessor having floating point execution units typically enable data movement and arithmetic operations on two floating point formats: double precision and single precision. In the example of the floating point register file described above having 64 bits per register, a double precision floating point number is represented using all 64 bits of the FPR, while a single precision number only uses 32 of the 64 available bits in each FPR. Generally, microprocessors having single precision capabilities have single precision instructions that use a double precision format.

For applications that perform low precision vector and matrix arithmetic, a third floating point format is sometimes provided which is known as paired singles. The paired singles capability can improve performance of an application by enabling two single precision floating point values to be moved and processed in parallel, thereby substantially doubling the speed of certain operations performed on single precision values. The term "paired singles" means that the floating point register is logically divided in half so that each register contains two single precision values. In the example 64-bit FPR described above, a pair of single precision floating point numbers comprising 32 bits each can be stored in each 64 bit FPR. Special instructions are then provided in the instruction set of the microprocessor to enable paired single operations which process each 32-bit portion of the 64 bit register in parallel. The paired singles format basically converts the floating point register file to a vector register file, wherein each vector has a dimension of two. As a result, part of the floating point execution unit becomes a vector processing unit (paired singles unit) in order to execute the paired singles instructions.

Some information processors, from microprocessors to supercomputers, have vector processing units specifically designed to process vectors. Vectors are basically an array or set of values. In contrast, a scalar includes only one value, such as a single number (integer or non-integer). A vector may have any number of elements ranging from 2 to 256 or more. Supercomputers typically provide large dimension vector processing capabilities. On the other hand, the paired singles unit on the microprocessor described above involves vectors with a dimension of only 2. In either case, in order to store vectors for use by the vector processing unit, vector registers are provided which are similar to those of the GPR and FPR register files as described above, except that the register size corresponds to the dimension of the vector on which the vector processing unit operates. For example, if the vector includes 64 values (such as integers or floating point numbers) each of which require 32 bits, then each vector register will have 2048 bits which are logically divided into 64 32-bit sections. Thus, in this example, each vector register is capable of storing a vector having a dimension of 64. FIG. 2 shows: an exemplary vector register file 2 storing four 64 dimension vectors A, B, C and D.

A primary advantage of a vector processing unit with vector register as compared to a scalar processing unit with scalar registers is demonstrated with the following example: Assume vectors A and B are defined to have a dimension of 64, i.e. A=(A.sub.0 . . . A.sub.63) and B=(B.sub.0 . . . B.sub.63). In order to perform a common mathematical operation such as an add operation using the values in vectors A and B, a scalar processor would have to execute 64 scalar addition instructions so that the resulting vector would be R=((A.sub.1 +B.sub.1). (A.sub.63 +B.sub.63)). Similarly, in order to perform a common operation known as Dot_Product, wherein each corresponding value in vectors A and B are multiplied together and then each element in the resulting vector are added together to provide a resultant scalar, 128 scalar instructions would have to be performed (64 multiplication and 64 addition). In contrast, in vector processing a single vector addition instruction and a single vector Dot_Product instruction can achieve the same result. Moreover, each of the corresponding elements in the vectors can be processed in parallel when executing the instruction. Thus, vector processing is very advantageous in many information processing applications.

One problem, however, that is encountered in vector processing, is that sometimes it is desired to perform an operation using a scalar value contained within a vector register. For example, some applications may require mixed vector and scalar calculations, wherein the scalar needed (e.g. C.sub.10) to perform the calculation is a single element within a particular vector (e.g. C) stored in a vector register. In other words, while a vector processing unit may easily execute a vector instruction which adds vector A to B and places the result in vector C (i.e. C=A+B), the vector processing unit cannot directly perform a mixed vector and scalar operation when the desired scalar is an element in a vector register (i.e. D=C.sub.10 +A). The primary reason for this limitation is that mixed scalar and vector instructions require that the scalar used in the operation be stored is a scalar register. In other words, such instructions do not have the ability to select a particular scalar element, such as C.sub.10, from a vector register. FIG. 1 shows an exemplary format of prior art instructions for mixed scalar and vector instructions.

As can be seen in FIG. 1, the typical format for a mixed scalar and vector instruction 3 includes a primary op-code 4, a scalar register address 5, a vector register address 6 and a destination register address 7. The primary op-code identifies the particular type of instruction, such as vector-scalar multiplication, and may, for example, comprise the most significant 6 bits (bits 0-5) of the instruction. The scalar register address 5 provides the particular address of the register in the GPR file that contains the scalar value needed to execute the instruction. The vector register address 6 provides the particular address of the vector register in the vector register file which contains the vector needed to execute the instruction. The destination register address 7 provides the location for the result of the operation. It is noted that the instruction format 3 of FIG. 1 is only exemplary and that prior art instructions may have other formats and/or include other parts, such as a secondary op-code, status bits, etc., as one skilled in the art will readily understand. However, as explained above, regardless of the particular format of the instruction, the instruction still requires that a scalar register be used to store the scalar value needed to execute the instruction.

As a result, if the required scalar is a particular element of a vector register (e.g. C.sub.10), the entire vector register must first be copied to memory in order to enable the desired scalar (C.sub.10) to be loaded into a scalar register. In other words, the prior art provides no suitable mechanism for enabling a scalar to be used from a vector register. Thus, while such mixed scalar and vector instructions can be performed, they require significant overhead in terms of time required to store the vector to memory and load the scalar from memory to a scalar register, so that the scalar register contains the required scalar value to execute the instruction. Even assuming that the required vector is in a cache (high speed on-chip memory), thereby eliminating the need to access external memory, significant overhead still exists. For example, a typical cache may require approximately 30-50 CPU clock cycles (a time unit by which the central processing unit (CPU) operates) to load data from a 64-bit 128 dimension vector. Moreover, if cache is not available or if a cache miss occurs, the overhead would be approximately an order of magnitude higher to load or access the vector in an external memory as compared to a cache. Thus, large CPU cycle overhead is required to execute an instruction that, without the above limitations, could execute in for example, as fast as 10 clock cycles, i.e. 40 to 100s of clock cycle overhead for a 10 cycle instruction.

Accordingly, a need exists for reducing the large overhead associated with such mixed scalar and vector instructions, so that the operations associated therewith can be performed faster and so that application performance can be improved.

SUMMARY OF THE INVENTION

The instant invention provides a mechanism and a method for enabling mixed scalar and vector instructions to run more efficiently and with less CPU cycle overhead by eliminating the need to load a value from a vector register into a scalar register in order to be used during execution of the instruction. The invention provides an improved instruction format which may be used in connection with any suitable type of data processor, from microprocessors to supercomputers, having a vector processing unit in order to improve the operational efficiency thereof.

In accordance with the invention, the improved instruction format has an embedded bit or a plurality of embedded bits that identify a particular element in a vector to be used as a scalar during execution of the instruction. In this way, a mixed scalar and vector instruction can be executed without the need to load the scalar operand into a scalar or general purpose register. By identifying, in the instruction, the location of the scalar in the vector, the scalar can be directly used from the vector register file for execution of the instruction.

In accordance with a preferred embodiment of the invention, the instruction format for mixed scalar and vector operations includes a primary op code, a first source vector register address, a second source vector register address, a destination register vector address, and at least one position bit which indicates the location of a desired scalar in one of the vector registers needed to execute the instruction. The number of bits needed to indicate the position of the desired scalar within a vector depends on the particular dimension of the vector involved. For example, if the vector has a dimension of 64, then six bits are needed to provide a unique identifier for the particular scalar within the vector. In other words, if the dimension of the vector is 2.sup.n, then n bits are needed, in this embodiment, to indicate the location of any scalar within the vector.

In another embodiment of the invention, the location of the scalar within the vector is determined based on the value of a secondary op code in the instruction. It is noted, however, that the invention is not limited to any particular implementation of the scalar position indicator in the instruction. Instead, the invention covers any suitable way in which the location of a scalar within the vector can be represented or embedded in the bit format comprising the instruction.

In a preferred embodiment, the invention is implemented on a microprocessor, such as the microprocessors in IBM's PowerPC (IBM Trademark) family of microprocessors (hereafter "PowerPC"), wherein the microprocessor has been modified or redesigned to include a vector processing unit, such as a paired singles unit. For more information on the PowerPC microprocessors see PowerPC 740 and PowerPC 750 RISC Microprocessor Family User Manual, IBM 1998 and PowerPC Microprocessor Family: The Programming Environments, Motorola Inc. 1994, both of which are hereby incorporated by reference in their entirety.

In the modified PowerPC example described above, the paired singles operation may be selectively enabled by, for example, providing a hardware implementation specific special purpose register (e.g. HID2) having a bit (e.g. 3.sup.rd bit) which controls whether paired single instructions can be executed. Other bits in the special purpose register can be used, for example, to control other enhancement options that may be available on the microprocessor.

The invention also provides specific instruction definitions for mixed vector and scalar operations. The invention is also directed to a decoder, such as a microprocessor or a virtual machine (e.g. software implemented hardware emulator), which is capable of decoding any of all of these particular instructions disclosed herein. The invention further relates to a storage medium which stores any or all of the particular instructions disclosed herein.
That's something. Going hunting for more.

Edit: Damn. I thought I read something about using planar textures to simulate space sometime. Perhaps it was something I derived from reading this patent? I can't remember anymore. Guess I'll just have to read the patent thoroughly once more.

Edit2: This might be something. I'm a bit tired now, but this looks somewhat interesting: http://appft1.uspto.gov/netacgi/nph-Parser...ndo&RS=nintendo[/b]
Det er ikke bare displacement mapping som er "nytt" med Revo, med mindre det er noen som har misforstått image-based rendering og tatt det for å være en teknikk for displacement mapping, hvilket det på en måte er.

Jeg har ikke tid til å skrive noe mer nå, enjoy my research. :p
 
#32
(...)
Og det er her poenget mitt ligger. Freeman, og jeg tror det er flere slike som ham, er ikke lenger interessert i 20 levler, redd høna, oppgrader sverdet, se CG outroen 50 ganger, stirr på veggen med trippel-bum-reflection-mapping. Som en god bok er han interessert i hver gang han setter seg inn i en ny blekke å oppleve noe nytt, ikke en evolusjon av den forrige boken.
(...)
[/b]
Hihi, bum-mapping er jo et spennende konsept. Rear Software presents Captain Recto & The Ring of Evil.
Huff :ehm...: Tror jeg bør dra hjem snart.

Uansett, om de får til en god løsning til displacement-mapping vil det lette arbeidet til hardwaren en god del, håper de fikser dette. Displacement er jo som Shadar sier en form for IBR, så om de skal utvikle mer rundt dette tror jeg vi får rimelig behagelig grafikk selv om det er lavere specs. Får de igang image-based lighting og blir det sykt lekkert, da har vi jo nesten GI (bare litt fake). Radiosity blir vel mer riktig, men uansett kommer det til å bli sylt mye deiligere å se på. Gleder meg, tror dette kan bli en spennende maskin.
 
#33
Satoru Iwata har sagt at Nintendo vil utnytte avansert teknologi til å gjere Revolution meir effektiv.
Frå intervjuet Seattle Post ( http://seattlepi.nwsource.com/business/225097_e3iwata20.html) hadde med Iwata etter E3:
Question: All three consolemakers, yourself included, have unveiled their plans for the next console generation. How do you feel about Nintendo's prospects with Revolution at this point?

Iwata: In the first place, Sony and Microsoft are taking about the same approach for the future by making machines with powerful and sophisticated technology. Nintendo is taking a little bit different approach, and I think this is an interesting contrast.

Of course, we are applying advances in technology. But when you use those advances just to boost the processing power, the trade-off is that you increase power consumption, make the machine more expensive and make developing games more expensive. When I look at the balance of that trade-off -- what you gain and what you lose -- I don't think it's good. Nintendo is applying the benefits of advanced technology, but we're using it to make our machines more power-efficient, quieter and faster to start. And we're making a brand-new user interface. I think that way of thinking is the biggest difference.[/b]
I tillegg til Displacement patentet har du det noko eldre cube-mapping patentet som går ut på å bruke pre-rendered bilete i real time 3D. Patentteksta er i stor grad lettlest;
[0003] Modern home video games are more exciting and realistic than ever before. Relatively inexpensive 3D home video game platforms contain as much processing power as advanced computer graphics workstations of yesteryear. They can dynamically, interactively produce rich, realistic interesting displays of characters and other objects moving about in and interacting with a simulated three-dimensional world. From your living room on a home color television set, you can now fly virtual fighter planes and spacecraft through simulated battles, drive virtual race cars over simulated race tracks, ride virtual snowboards over simulated snow fields and ski slopes, race simulated jet skis over simulated water surfaces, and journey through exciting virtual worlds encountering all sorts of virtual characters and situations--just to name a few examples--all with highly realistic and exciting 3D images.

[0004] While home video game systems are now relatively powerful, even the most advanced home video game system lacks the processing resources that video game designers dream about. Home video game systems, after all, must be affordable yet have the extremely demanding task of producing high quality images dynamically and very rapidly (e.g., thirty or sixty frames per second). They must respond in real-time to user controls--reacting essentially instantaneously from the standpoint of the user. At the same time, video game developers and their audiences continually desire ever richer, more complex, more realistic images. More complicated and detailed images place exceedingly high demands on relatively inexpensive video game system processors and other internal circuitry. If the image is too complicated, the video game platform will not be able to render it in the time available. This can sometimes result in incomplete, only partially rendered images that may appear flawed and unrealistic and thus disappoint users.

[0005] One approach to help solve this problem involves pre-rendering complicated scenes in advance and then adapting or otherwise manipulating those scenes in real-time to provide interactive video game play. For example, it is possible for a video game designer at the time he or she creates a video game to use a very powerful computer to pre-calculate and pre-render background scenery and other images. Developing a new video game can sometimes take a year or more, so using a high-power computer graphics workstation or even a supercomputer for hours at a time to render individual complicated background images is feasible. Such interesting and complicated background images are then often essentially "pasted" onto 3D surfaces through use of texture mapping during real-time video game play. This technique can be used to provide rich and interesting background and other video game play elements without a corresponding substantial increase in real-time processing overhead.

[0006] While such pre-rendered texture maps have been used with substantial advantageous results in the past, they have some shortcomings in interactive video game play. For example, texture-mapping a pre-rendered image onto a 3D surface during interactive video game play can successfully create impressive visual complexity but may let down the user who wants his or her video game character or other moving object to interact with that complexity. The tremendous advantageous 3D video games have over 2D video games is the ability of moving objects to interact in three dimensions with other elements in the scene. Pre-rendered textures, in contrast, are essentially 2D images that are warped or wrapped onto 3D surfaces but still remain two-dimensional. One analogy that is apt for at least some applications is to think of a texture as being like a complex photograph pasted onto a billboard. From a distance, the photograph can look extremely realistic. However, if you walk up and touch the billboard you will immediately find out that the image is only two dimensional and cannot be interacted with in three dimensions.

[0007] We have discovered a unique way to solve this problem in the context of real-time interactive video game play. Just as Alice was able to travel into a 3D world behind her mirror in the story "Alice Through the Looking Glass", we have developed a video game play technique that allows rich pre-rendered images to create 3D worlds with depth.

[0008] In one embodiment, we use a known technique called cube mapping to pre-render images defining a 3D scene. Cube mapping is a form of environment mapping that has been used in the past to provide realistic reflection mapping independent of viewpoint. For example, one common usage of environment mapping is to add realistic reflections to a 3D-rendered scene. Imagine a mirror hanging on the wall. The mirror reflects the scene in the room. As the viewer moves about the room, his or her viewpoint changes so that different objects in the room become visible in the mirror. Cube mapping has been used in the past or provide these and other reflection effects.

[0009] We use cube mapping for a somewhat different purpose--to pre-render a three-dimensional scene or universe such as for example a landscape, the interior of a great cathedral, a castle, or any other desired realistic or fantastic scene. We then add depth to the pre-rendered scene by creating and supplying a depth buffer for each cube-mapped image. The depth buffer defines depths of different objects depicted in the cube map. Using the depth buffer in combination with the cube map allows moving objects to interact with the cube-mapped image in complex, three-dimensional ways. For example, depending upon the effect desired, moving objects can obstruct or be obstructed by some but not other elements depicted in the cube map and/or collide with such elements. The resulting depth information supplied to a panoramically-composited cube map provides a complex interactive visual scene with a degree of 3D realism and interactivity not previously available in conventional strictly 2D texture mapped games.[/b]
Er nok ikkje tvil om at Hollywood vil vere bra optimalisert og innehalde ein del ny teknologi, men i kva grad det vil kunne jamne ut forskjellen til 360 og PS3 får vel vise seg. Det er kanskje ikkje utenkeleg at det fysisk sett kan finnast andre metodar til å lage meir avansert grafikk enn ved berre å auke datakrafta.
 
#36
Bør ikke dette emnet døpes om til Nintendo Wii nå :ehm...:

Synes forøvrig navnet var greit, litt lite punch, men har en del kreativitet i seg i forhold til Revolution...
 

Lodin

Der Waaaah
#38
Nei, det uttales som We, som i vi, som i oss som kommer å sparker den neste personen som drar en pisse-vits i nøttene. =D

EDIT: ikke det nei...
 
D

Doctor Downs

Gjest
#39
"We" og "wee" uttaltes likt sist jeg sjekka. Kanskje en tad lenger "ii" i "wee". Og btw. Peewee.