FAO Developers and Kyro 2

Since developers sometimes post on this board I would like to ask whether or not their current games in development are being:

1) Validated for the Kyro 2 (ie they will run on it)
2) Contain a code path that uses some of its better features (8 texture layers etc) that it supports (ie some kind of optimisation)

I just want to get an idea whether or not developers on the whole take this card seriously, or whether it will get left behind in the DX8 and above environment that is becoming prevalent.

Thanks in advance
 
PVR_Extremist said:
2) Contain a code path that uses some of its better features (8 texture layers etc) that it supports (ie some kind of optimisation)
I'm not an application developer, but from my experience as a driver developer, I can say that 8 simultaneous textures are supported by very few applications. In fact, the only one I can think off top of my head is 3D Mark in the multitexture fillrate test. Most applications use four or fewer simultaneous textures, with the majority using only one or two at a time.

Doom 3 uses something like 7 simultaneous textures, so maybe it will set a new trend.
 
Despite touting it, IIRC when Croteam went to add multitexturing support into SS even PowerVR didn't expose the full 8 through their ICD - only 4 (which which why Croteam stuck to 4). Dunno if thats changed now though.
 
Tagrineth said:
Kyro supports 8 layers in Direct3D but only 4 in OpenGL... has to do with the APIs' max specs IIRC.

No, thats not true. From the OpenGL 1.2.1 specs:
The Specification is written using four texture units though the actual number supported is implementation dependent and can be larger or smaller than four.

So any number of textures per pass can be exposed in OpenGL.
 
Minimum number of texture units must be at least 2, there is no upper limit. Number 32 is just number of defines from glext.h header file, GL_TEXTURE0 to GL_TEXTURE31.

Thanks.
 
Thowllly said:
Tagrineth said:
Kyro supports 8 layers in Direct3D but only 4 in OpenGL... has to do with the APIs' max specs IIRC.

No, thats not true. From the OpenGL 1.2.1 specs:
The Specification is written using four texture units though the actual number supported is implementation dependent and can be larger or smaller than four.

So any number of textures per pass can be exposed in OpenGL.

Four texture units.

Loopback acts as though there are more physical TMU's...

But even DirectX 6 with a concrete 8 TMU limit can apply more through multiple passes.
 
Tagrineth said:
Thowllly said:
Tagrineth said:
Kyro supports 8 layers in Direct3D but only 4 in OpenGL... has to do with the APIs' max specs IIRC.

No, thats not true. From the OpenGL 1.2.1 specs:
The Specification is written using four texture units though the actual number supported is implementation dependent and can be larger or smaller than four.

So any number of textures per pass can be exposed in OpenGL.

Four texture units.


The example given in the text uses four texture units. The actual implementation can have any number of texture units.


Loopback acts as though there are more physical TMU's...

But even DirectX 6 with a concrete 8 TMU limit can apply more through multiple passes.


Yes, and...? I'm not quite following what you are trying to say. I'm not talking about multipass here (And I'm not trying to say that GL is better than DX). Through OpenGL you could expose hardware capable of 100 textures per pass. Whether this is achieved through 100 TMUs or 1 TMU doing 99 loopbacks is irrelevant. It's still one pass and looks the same to the software either way.

In OpenGL, the only limit to the amount of textures that can be applied in a single pass is the underlying hardware (and the drivers, of course).
 
If reality was made out from what people *think* or *believe* it would be really weird ^^
 
Hmm, so why would PowerVR allow a full 7 loops in Direct3D but only 3 in OpenGL? Weird. Oh well, not like it matters that much anyway...
 
Tagrineth said:
Hmm, so why would PowerVR allow a full 7 loops in Direct3D but only 3 in OpenGL? Weird. Oh well, not like it matters that much anyway...

That is a very good question, and I have no idea why. All I'm saying is it's not OpenGLs fault. (I might just have said: I'm not trying to say that GL is better than DX... but I think it is anyway :D)
 
Back
Top