TEV a keeper or a loser?

[DeadlyNinja]

It already has a dual dot3 in the texture unit. What's missing is the ability to transform a light to tangent space, normalize its vector and, per pixel, pass it to the dot product matrix. In contrast, if you have a light direction, you can set up the texture unit with it to perform normal mapping on directional light. But the CPU is required to transform it.

Besides that, for normal mapping you don't need dot3 at all, I'm currently working (it already works) on a fast, all GPU, normal mapping method. It just requires an indirect- and a tev stage to do so (though it results in some less appealing artifacts, which can be dealt with by adding an additional tev stage). I'll post my dol later on for non believers (probably on gcdev).

Sounds cool, but gcdev seems pretty dead. Could you post it on this board as well? I love seeing people do crazy things with the Wii GPU since very few actual devs bother to make anything halfway decent. Unless you're an actual game dev, which is cool too.

 

[DRS]

Wouldn't it be possible to just simulate the hardwired TEV with a fully programmable pixel shader? At least they know what's inside the box, but would it be possible from a technical view?

Dolphin, the GC/Wii emulator does It emulates TEV quite well too! Though, it's about a factor 15 slower on my dual core 2GHz laptop than my Wii is (and if I'm not mistaken, homebrew still runs GC mode, thus lower clock freq). Anyway, these guys deserve some respect for building it.

BTW hardwired is a sort of short cornered term for Flipper/Hollywood; what you actually do to program it is wiring outputs to inputs and specify parameters to generate outputs using fixed calculations. For example, in the vertex shader, you can *wire* up a texture coordinate with a bump offset function and specify a base coordinate *parameter* to base the offset on.

@Entropy, my knowledge isn't complete at all. So there is still a large unexplored, fuzzy, area for me. For example, I don't have a clue how to use dual transform and it didn't came clear to me reading the patents either. Besides that, I don't have a degree in HW 3D programming, just some experience with software rendering, so things I'd like to see now could be obsolete for experienced HW programmers.

But stuff I would like to see from a fixed function point of view would be:
* Generation of interpolated, tangent space, light direction vector (per HW light, possibly accesible through color channel) if not possible yet (I doubt it is)
* Ability to wire up a tangent space light direction vector to the 3x2 dot3 unit instead of just being able to pass 2D texture coordinates
* Ability to read/write texture coordinates from Recirculating shader unit
* Ability to have an alternative to the blending operation D + (C-1)A + CB, such as AB + CD (this would enable to add diffuse and specular light in 1 tevstage instead of 2)
* More color channels (8, one for each light); my current normal mapping setup uses diffuse attenuation to switch the normal mapping stages on or off (when the light moves behind the surface). Since the Wii only has 2 channels, I'm basically limited to 2, or 4 if the alpha is used separately, HW lights as well
* A relative jump function that enables to loop between a number of stages
* for HD I guess it would be feasible to increase clock to >500MHz and use 16 pixel pipelines

Or:

Have the ability to do more "primitive" stuff in the Recirculating shader unit, such as dot3, matrix transforms, generating texture coordinates and more blending alternatives. But if they go that way, I'd rather see a modern GPU.

@DeadlyNinja, does this site have a repository to upload stuff? What I can show right now is a simple cube (got most of that from existing GC demo) with a single light, diffuse and reflective normal mapping and ambient color normal mapping (i.e. the ambient light is done using a virtual lightsource that's always in front of the surface, but I'll replace that with a direct texturemap since that will be faster). You can switch to diffuse only and diffuse+reflective using mote A and B buttons. If no options to upload it here, I'll host it myself as long as I have bandwith available. Check again end this week.

 

[Fox5]

A better graphics processor may have allowed Nintendo to serve as the 'good enough' console and shore up the hardcore gamer market as well.
Similar graphics to the 360 but at SD res. The ability to port low end versions of 360 and PS3 games to the Wii (in the same way the Ps2 got low end versions of Xbox games). It may have been able to position the Wii as the everything console, bridging its new experiences with old ones.

BTW, the wii hardware is fairly ripe for a new handheld. Imagine the next Nintendo handheld having the power of the Wii, with devs already accustomed to working on it?

Still, I suppose the things that made Hollywood win out were (as previously stated):
Reusing old code/engines/design skills. Maybe not so important for 3rd parties, but important for Nintendo's large group of internal software developers.
Keep power consumption low. There may be DX9 level parts that could fit in the same die size as Hollywood. When you include sound and everything else that was integrated, you may have been looking at Radeon Xpress 200 level hardware. And that may still generate more heat than Hollywood, and it lacks vertex shaders too.

But doesn't Nintendo use OpenGL for their games? I suppose TEV code would have to be converted to shader code, but other than that, how much work would it be to convert? (they could even have the compiler automatically substitute standard shader code for TEV functions)

BTW, why couldn't DX9/10 level parts have been done years earlier than they were? Some of the low end DX9/10 parts had comparable transistor counts to the older hardware, while offering more features and better performance.

Oh well, I just hope the next nintendo console finally has 32-bit color.

 

[StefanS]

But doesn't Nintendo use OpenGL for their games? I suppose TEV code would have to be converted to shader code, but other than that, how much work would it be to convert? (they could even have the compiler automatically substitute standard shader code for TEV functions)

OpenGL and DirectX are APIs. Having DirectX9/10/11 certified hardware doesn't preclude the use of OpenGL. Case in point, RSX is DirectX9 hardware but supports OpenGL ES2.0.

BTW, if I am not completely wrong GCN/Wii used a customized version of OpenGL.

 

[AlNom]

BTW, why couldn't DX9/10 level parts have been done years earlier than they were? Some of the low end DX9/10 parts had comparable transistor counts to the older hardware, while offering more features and better performance.

Who is footing the bill for R&D for a design that may or may not be in the PC space in the future? MS already did a bit of that for Xenos and the tesselator, unified shaders.... MS clearly has some control over the PC spec anyway. Timing is also a factor.

vs. existing hardware ala RSX, which would be a cheaper and faster method - majority of the work is already done.

 

[forumaccount]

BTW, the wii hardware is fairly ripe for a new handheld. Imagine the next Nintendo handheld having the power of the Wii, with devs already accustomed to working on it?

Developers have been accustomed to working with this hardware since 2001. It can be fun and all but I hope it doesn't live through another cycle, even as a handheld.

But doesn't Nintendo use OpenGL for their games? I suppose TEV code would have to be converted to shader code, but other than that, how much work would it be to convert? (they could even have the compiler automatically substitute standard shader code for TEV functions)

No, there's no OpenGL... I'm not sure what you're talking about here... recompiling for a future TEV-less console? I don't think I know many graphics programmers that will shed a tear for Dolphin/Flipper. A clean break from fixed function to programmable can be a pain and you throw out a lot of code, but we've done it before. A TEV emulator w/ shaders could be done but I doubt it'd be drop-in... it might not even be worth the effort.

Oh well, I just hope the next nintendo console finally has 32-bit color.

No, how dare they use ideas from this millenium!

BTW, if I am not completely wrong GCN/Wii used a customized version of OpenGL.

Not really, GX has no relation to OpenGL.

 

[wsippel]

Not really, GX has no relation to OpenGL.

Except for the fact that both GL and GX were developed by Dr. Wei Yen.

 

[Nightz]

How about the Indirect Texturing stuff? Has it got a future.

 

[forumaccount]

How about the Indirect Texturing stuff? Has it got a future.

Like TEV, it adds nothing interesting compared to today's programmable hardware.

 

[DRS]

True, but how about a single cycle op that takes two textures, two coordinates and a 3x2 matrix and returns the resulting texel? I'm not really up to date on current hw capabilities so perhaps such an op already exists=)

 

[freezamite]

So TEV and the entire Flipper is, literally, 10 year old technology. The Hollywood is really the same. Other than 50% (1.5x) faster clockspeed, some minor tweaks, and a smaller manufacturing process, Hollywood has an identical architecture to Flipper. It's little more than a speedbump, not even a typical GPU 'refresh'.

This is FALSE.
Hollywood is only an overclocked flipper, there isn't a single "minor tweak" on it.
Its the exact same GPU of GC overclocked, there is nothing more on it, so don't say stuff like that because then some "nintenerds" try to put the Wii at the same level of the first Xbox.

Regards.