Suche Freiwilligen mit Radeon7500 und C-Compiler

[zeckensack]

Ich will mal wissen, ob die Radeon7500 die gleichen Hirnschäden wie die originale Radeon hat. Die 8500er sind nicht betroffen, interessiert mich also nicht.

Bitte mal folgendes ausprobieren, dazu braucht ihr Glut (http://www.xmission.com/~nate/glut.html) und die OpenGL-Header von ATI (http://www.ati.com/developer/sdk/RadeonSDK/Html/Info/Extensions/glATI.h).
*edit*
Bilder dazu gibt's weiter unten.
*noch ein edit*
Hat sich mittlerweile erledigt, dank Hilfe von Indiana Jones

//Demonstrates a flaw in Dot3 operations on the ATI Radeon's (original) third texture environment
//Flaw can be reproduced on Win98SE systems with the official driver set 4.13.9009
//version number of ATIICDXX.DLL is 6.13.10.6014
//reported GL version is 1.3.2454

//Make sure to link with glut32.lib and opengl32.lib

//#include <windows.h>
#include <gl/gl.h>
#include <gl/glati.h>
#include <gl/glu.h>
#include <gl/glut.h>
#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>

char description[64];

PFNGLACTIVETEXTUREARBPROC glActiveTextureARB;
PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARB;

static unsigned char* texture_data=NULL;
static GLuint tex_obj=0;
static int dot_unit=2;

void
init_gl_stuff()
{
glActiveTextureARB=(PFNGLACTIVETEXTUREARBPROC)wglGetProcAddress("glActiveTextureARB");
glMultiTexCoord2fARB=(PFNGLMULTITEXCOORD2FARBPROC)wglGetProcAddress("glMultiTexCoord2fARB");

if (glMultiTexCoord2fARB==NULL) glutSetWindowTitle("screeeeaaaam!!!");

glClearColor(0.0f,0.0f,0.0f,0.0f);
glGenTextures(1,&tex_obj);
texture_data=(unsigned char*)malloc(64*64*3);
//generate nice texture
for (int x=0;x<64;++x)
{
for (int y=0;y<64;++y)
{
texture_data[(x+64*y)*3]=(unsigned char)4*x;
texture_data[(x+64*y)*3+1]=(unsigned char)4*y;
texture_data[(x+64*y)*3+2]=(unsigned char)255-x-y;
}
}
glBindTexture(GL_TEXTURE_2D,tex_obj);
glTexImage2D(GL_TEXTURE_2D,0,GL_RGB,64,64,0,GL_RGB,GL_UNSIGNED_BYTE,texture_data );
free(texture_data);
texture_data=NULL;
//mipmaps not required for this demonstration
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP_TO_EDGE_EXT);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP_TO_EDGE_EXT);

//whip up a minimum projection
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluOrtho2D(0,640,480,0);

//set all three texture environments to COMBINE_ARB operation, select same sources and operands

//tex environment0 will do decal texturing
glEnable(GL_TEXTURE_2D);
glTexEnvi(GL_TEXTURE_ENV,GL_TEXTURE_ENV_MODE,GL_COMBINE_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_REPLACE);
glTexEnvi(GL_TEXTURE_ENV,GL_SOURCE0_RGB_ARB,GL_TEXTURE);
glTexEnvi(GL_TEXTURE_ENV,GL_OPERAND0_RGB_ARB,GL_SRC_COLOR);
glTexEnvi(GL_TEXTURE_ENV,GL_SOURCE1_RGB_ARB,GL_TEXTURE);
glTexEnvi(GL_TEXTURE_ENV,GL_OPERAND1_RGB_ARB,GL_SRC_COLOR);

//tex environment1 will pass through
glActiveTextureARB(GL_TEXTURE1_ARB);
glBindTexture(GL_TEXTURE_2D,tex_obj);
glEnable(GL_TEXTURE_2D);
glTexEnvi(GL_TEXTURE_ENV,GL_TEXTURE_ENV_MODE,GL_COMBINE_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_REPLACE);
glTexEnvi(GL_TEXTURE_ENV,GL_SOURCE0_RGB_ARB,GL_PREVIOUS_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_OPERAND0_RGB_ARB,GL_SRC_COLOR);
glTexEnvi(GL_TEXTURE_ENV,GL_SOURCE1_RGB_ARB,GL_PREVIOUS_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_OPERAND1_RGB_ARB,GL_SRC_COLOR);

//tex environment2 will perform the dot3 operation
glActiveTextureARB(GL_TEXTURE2_ARB);
glBindTexture(GL_TEXTURE_2D,tex_obj);
glEnable(GL_TEXTURE_2D);
glTexEnvi(GL_TEXTURE_ENV,GL_TEXTURE_ENV_MODE,GL_COMBINE_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_DOT3_RGB_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_SOURCE0_RGB_ARB,GL_PREVIOUS_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_OPERAND0_RGB_ARB,GL_SRC_COLOR);
glTexEnvi(GL_TEXTURE_ENV,GL_SOURCE1_RGB_ARB,GL_PREVIOUS_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_OPERAND1_RGB_ARB,GL_SRC_COLOR);
}

int
cleanup()
{
if (tex_obj)
{
glDeleteTextures(1,&tex_obj);
tex_obj=0;
}
return(0);
}

void
display()
{
glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
glBegin(GL_QUADS);
glTexCoord2f(0.0f,0.0f);
glVertex2f(0.0f,0.0f);
glTexCoord2f(1.0f,0.0f);
glVertex2f(320.0f,0.0f);
glTexCoord2f(1.0f,1.0f);
glVertex2f(320.0f,320.0f);
glTexCoord2f(0.0f,1.0f);
glVertex2f(0.0f,320.0f);
glEnd();
glutSwapBuffers();
return;
}

void
keyboard(unsigned char key,int x,int y)
{
//check for spacebar
if (key!=0x20) return;

//flip the switch
++dot_unit;
if (dot_unit==3) dot_unit=0;

//reassign texture environments
switch (dot_unit)
{
default:
case(0):
glActiveTextureARB(GL_TEXTURE0_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_DOT3_RGB_ARB);
glActiveTextureARB(GL_TEXTURE1_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_REPLACE);
glActiveTextureARB(GL_TEXTURE2_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_REPLACE);
break;
case(1):
glActiveTextureARB(GL_TEXTURE0_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_REPLACE);
glActiveTextureARB(GL_TEXTURE1_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_DOT3_RGB_ARB);
glActiveTextureARB(GL_TEXTURE2_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_REPLACE);
break;
case(2):
glActiveTextureARB(GL_TEXTURE0_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_REPLACE);
glActiveTextureARB(GL_TEXTURE1_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_REPLACE);
glActiveTextureARB(GL_TEXTURE2_ARB);
glTexEnvi(GL_TEXTURE_ENV,GL_COMBINE_RGB_ARB,GL_DOT3_RGB_ARB);
break;
}

//update description
sprintf(description,"Dot3 operation on texture environment %u",dot_unit);

glutSetWindowTitle(description);

glutPostRedisplay();
}

int
main(int argc,char** argv)
{
sprintf(description,"Press space to reassign texture environments");

glutInit(&argc,argv);
glutInitWindowSize(640,480);
glutInitDisplayMode(GLUT_RGBA|GLUT_DOUBLE);

glutCreateWindow(description);

init_gl_stuff();

glutDisplayFunc(display);
glutKeyboardFunc(keyboard);

onexit(cleanup);

glutMainLoop();

return(0);
}

[zeckensack]

Das Ergebnis sollte in jedem Fall ein reines Graustufenbild sein, bei mir sieht das dann aber auch schon mal so aus:

[zeckensack]

So wäre es richtig:

[aths]

Und woran lags nun?

[zeckensack]

Originally posted by aths
Und woran lags nun? Der Treiber und/oder die Hardware sind kaputt. Der Fehler tritt auf, wenn man eine DOT3-Operation in der dritten Textureinheit (oder besser: Blending stage) ausführt. Das 'korrekte' Bild hab ich mit DOT3 auf der zweiten Einheit gemacht, da klappt's so wie es soll.

Der gleichen Schmuh inklusive einer möglicherweise besseren Erklärung liegt auch noch im Forum von opengl.org (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/005734.html) rum. Das ist der komplette Bugreport, den ich auch so an ATI geschickt habe. Ein ATI-Mensch, den ich hier nicht nennen möchte, hat mir auch bestätigt, daß es ein Bug ist, man arbeite daran. Allerdings war er sich damals wohl selbst nicht ganz sicher, ob's an der Hardware oder am Treiber liegt.

[StefanV]

Könnte die Radeon 8500 nicht prinzipiell auch eine 4x3 Pipeline haben, von der aber eine TMU Einheit deaktiviert (Treiber/HW ist egal ;)) ist??

[StefanV]

NACHTRAG:

Sozusagen wie es Intel mit dem Sellerie 2 gemacht hat ;)

[Quasar]

Stefan Payne, du bist einer der notorischsten Posting-Sammler, die ich je gesehen habe. Oder geht mit Mozilla der Edit-Button nicht?

[Legolas]

Doch doch, mit Mozilla geht der Edit-Button sehr wohl. :) Benutze ihn schliesslich ziemlich oft :D

[Thowe]

Originally posted by Quasar
Stefan Payne, du bist einer der notorischsten Posting-Sammler, die ich je gesehen habe. Oder geht mit Mozilla der Edit-Button nicht?

Wie soll man sonst auf über 9000 Postings kommen, da hilft nur ignore edit.

[Quasar]

Auch auf die Gefahr hin, jetzt selber ein so einsilbiges und überflüssiges Posting zu produzieren: echt arm.

[zeckensack]

Originally posted by Stefan Payne
Könnte die Radeon 8500 nicht prinzipiell auch eine 4x3 Pipeline haben, von der aber eine TMU Einheit deaktiviert (Treiber/HW ist egal ;)) ist?? Um Radeon 8500 geht's hier eigentlich nicht. Der Fehler tritt da nicht auf, das hab' ich mir schon bestätigen lassen.

So ganz verstehe ich den Aufbau des R200 noch nicht. Man kann sechs Texturen pro Pass auflegen (ich vertraue da auf Humus' Aussage (http://www.rage3d.com/board/showthread.php?threadid=33611830)), wobei sich die Pixelfüllrate jedoch nur halbiert. Es werden also zwei Pipes zusammengefaßt. Das irre ist, daß dieser Füllratenabfall angeblich schon ab der dritten Textur (nicht erst ab der vierten) auftritt, also können zwei Pipes zusammen dreimal so viel wie eine einzelne ... ???
Eventuell liegt das an irgendeiner komischen Eigenschaft der Pixelshader-Implementierung. Ich werde mir das mal genauer ansehen, sobald ich so eine Karte zum Testen hier habe.

[ow]

@Zeckensack

AFAIK fasst der R200 keine Pipes zusammen, er macht 2-faches Loopback fuer 6tex/pass.

Folglich braucht er bereits ab der 3. Textur das 1. Loopback, daher hier der Einbruch. Bei der 5. Tex muesste ein weiterer Einbruch wegen des 2. Loopbacks erfolgen.

[zeckensack]

So, jetzt isses raus:
Die Radeon 7500 ist von der gleichen Seuche befallen.
Indiana Jones war so freundlich, das nachzuprüfen (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=17777).

[KillerSmurf]

inwiefern "seuche" is doch "nur" nen kleiner hardware bug oder steckt da mehr dahinter???

also ich mein is der fehler grob oder nich weiter schlimm wenn man davon weiss??? ich hab da nich so den peil würd aber gern mehr wissen

[zeckensack]

Originally posted by KillerSmurf
inwiefern "seuche" is doch "nur" nen kleiner hardware bug oder steckt da mehr dahinter???

also ich mein is der fehler grob oder nich weiter schlimm wenn man davon weiss??? ich hab da nich so den peil würd aber gern mehr wissen Das ist insofern peinlich, als daß die Funktionalität, die die Radeon der Geforce 2 voraus hat - und mit der damals kräftig geworben wurde - nämlich 3 TMUs und DOT3-Bumpmapping nicht wirklich immer in Kombination funktioniert.

Bis jetzt hat sich auch bei ATI niemand dazu geäußert, ob's an HW oder Treiber liegt.
Email-Antwort von ATI, 4.März 2002
Hello xxx,

I can confirm this issue is seen here on the sample you sent. I tried a Radeon 8500 which does not exhibit this problem. I've submitted a bug report on this so hopefully a fix can be found without much trouble (I don't expect there to be).

Thanks,
xxx xxx
ATI Developer Relations
devrel@ati.com

Also, er erwartete kein großes Problem (sprich: HW-Fehler), hat's aber nicht gewußt.

Die gute Nachricht für den Verbraucher:
Noch kein einziges mir bekanntes Spiel nutzt diese Kombination von drei Texturen und DOT3 am Ende der Pipeline.
Das liegt zum Teil an der weiten Verbreitung der diversen Geforces, zum Teil aber auch daran, daß das was ich da mache auch ziemlich ungewöhnlich ist. Es kann gut sein, daß ich der allererste bin, der diesen Fehler jemals entdeckt hat, ergo auch der allererste, der die Radeon in dieser Konfiguration laufen lassen wollte.
Das könnte sich uU ändern, moderne Engines wie zB Doom 3 sollen sehr stark auf DOT3-Bumpmapping setzen, sprich kein einziges Dreieck mehr ohne DOT3 rendern.
Es gibt hier in den meisten Fällen den simplen Workaround, DOT3 einfach früher in der Pipeline zu machen. Trotzdem bin ich mal gespannt, was da so passiert, schließlich wird die Radeon7500 (im Gegensatz zu meiner obsoleten Radeon 1) immer noch in Form von Grakas und in Notebooks verkauft.

Puh.

Schaumer mal.

[ShiShingu]

Originally posted by zeckensack
Das ist insofern peinlich, als daß die Funktionalität, die die Radeon der Geforce 2 voraus hat - und mit der damals kräftig geworben wurde - nämlich 3 TMUs und DOT3-Bumpmapping nicht wirklich immer in Kombination funktioniert.

Bis jetzt hat sich auch bei ATI niemand dazu geäußert, ob's an HW oder Treiber liegt.


Also, er erwartete kein großes Problem (sprich: HW-Fehler), hat's aber nicht gewußt.

Die gute Nachricht für den Verbraucher:
Noch kein einziges mir bekanntes Spiel nutzt diese Kombination von drei Texturen und DOT3 am Ende der Pipeline.
Das liegt zum Teil an der weiten Verbreitung der diversen Geforces, zum Teil aber auch daran, daß das was ich da mache auch ziemlich ungewöhnlich ist. Es kann gut sein, daß ich der allererste bin, der diesen Fehler jemals entdeckt hat, ergo auch der allererste, der die Radeon in dieser Konfiguration laufen lassen wollte.
Das könnte sich uU ändern, moderne Engines wie zB Doom 3 sollen sehr stark auf DOT3-Bumpmapping setzen, sprich kein einziges Dreieck mehr ohne DOT3 rendern.
Es gibt hier in den meisten Fällen den simplen Workaround, DOT3 einfach früher in der Pipeline zu machen. Trotzdem bin ich mal gespannt, was da so passiert, schließlich wird die Radeon7500 (im Gegensatz zu meiner obsoleten Radeon 1) immer noch in Form von Grakas und in Notebooks verkauft.

Puh.

Schaumer mal.

heißt das etwa, dass ich mit meiner Radeon7500 keine baldigen games mehr zocken kann?!

[zeckensack]

Originally posted by ShiShingu


heißt das etwa, dass ich mit meiner Radeon7500 keine baldigen games mehr zocken kann?! Nein, das heißt es nicht. Wenn's auf einer Geforce 2 läuft, läuft es auch auf einer Radeon.
Der Fehler kann lediglich dann auftreten, wenn die Zusatz-Features der Radeon vom Spiel speziell genutzt werden, ohne daß die Entwickler es auch auf einer Ur-Radeon ausprobiert haben. Und auch dann nur unter ganz speziellen Bedingungen.
Serious Sam zB nutzt die Radeon voll aus, und läuft fehlerfrei.
Diverse Grafik-Demos von Humus (kann man sich mittlerweile bei ATI.com runterladen) nutzen massiv DOT3 und drei Texturlagen und laufen fehlerfrei - obwohl Humus nie eine Radeon 1 besessen hat.

Wenn der Fehler in freier Wildbahn auftritt, sollte er durch einen simplen Patch des Spiels zu beheben sein.

[ShiShingu]

Originally posted by zeckensack
Nein, das heißt es nicht. Wenn's auf einer Geforce 2 läuft, läuft es auch auf einer Radeon.
Der Fehler kann lediglich dann auftreten, wenn die Zusatz-Features der Radeon vom Spiel speziell genutzt werden, ohne daß die Entwickler es auch auf einer Ur-Radeon ausprobiert haben. Und auch dann nur unter ganz speziellen Bedingungen.
Serious Sam zB nutzt die Radeon voll aus, und läuft fehlerfrei.
Diverse Grafik-Demos von Humus (kann man sich mittlerweile bei ATI.com runterladen) nutzen massiv DOT3 und drei Texturlagen und laufen fehlerfrei - obwohl Humus nie eine Radeon 1 besessen hat.

Wenn der Fehler in freier Wildbahn auftritt, sollte er durch einen simplen Patch des Spiels zu beheben sein.

ok, danke für die Info-dann brauch ich mir ja keine sorgen machen...
...hab mir erst vor kurzem die Radeon 7500 Retail gekauft.

[aths]

zeckensack,

da die 3. TMU nicht trilinear filtern kann, sollte man mit ihr vielleicht nur Lightmapping machen.

Wie kamst du auf die Idee für dein Testprogramm?

[zeckensack]

Originally posted by aths
zeckensack,

da die 3. TMU nicht trilinear filtern kann, sollte man mit ihr vielleicht nur Lightmapping machen.Ich filtere in diesem Fall bilinear ohne Mipmaps. In der realen Anwendung (su) filtere ich überhaupt nicht, also Point Sampling ohne Mipmaps.
Wie kamst du auf die Idee für dein Testprogramm? Das sollte der erste auf Radeons vernünftig lauffähige Glide-Wrapper der Welt werden. Da alle anderen Wrapper regelmäßig abkotzen, wenn man sie für was anderes als UltraHLE einsetzt, habe ich es mir zum Ziel gesetzt, gleichzeitig auch den ersten vollständigen Glide-Wrapper daraus zu machen. Was mir bisher auch beinahe gelungen ist. UT läuft, Quake2 läuft, Gex läuft, MDK läuft, alles was ich so an Glide-Spielen hier rumfliegen habe (teilweise Demo-Versionen) und alle Tests aus dem Glide-SDK laufen.

Eigentlich isser fertig. Was zur Perfektion jetzt noch fehlt, ist Chroma-Keying. Das können moderne Grakas nicht, es sei denn mit Pixel Shadern. Die - in wirklich allen Fällen - korrekte Emulation für mittelalte Grafikchips erfordert Multipass und mindestens drei blending stages in Kombination mit Alpha-Test, Stencil und DOT3. Im ersten Pass braucht man dafür zwingend DOT3 in der dritten blending stage. Anders geht's nicht ohne zu schummeln.

Und so bin ich dann auf den Fehler gestoßen.

Schon witzig, angefangen hab' ich, weil Ultima 9 nicht ordentlich lief. Bis ich dann ein paar Monate später bei euch gesehen habe, daß die Radeon gerade für das Spiel wohl die beste Grafikkarte ist.

[StefanV]

Ähm, was ist Chroma Keying??

Ich kann mich dunkel daran erinnern...
Kann es sein, daß es aus der Urzeit der 3D Beschleuniger kommt??
Und daß das die Virge und Rendition konnten??


Was es nun machte, daran kann ich mich nicht mehr soo genau erinnern, aber kann das was mit Nebel/Transparenz zu tun gehabt haben??

[zeckensack]

Originally posted by Stefan Payne
Ähm, was ist Chroma Keying??Quasi sowas wie Bluescreens in alten Filmproduktionen, alles was blau ist, ist nicht sichtbar.
Nur daß man beim Chroma-Keying die Farbe frei wählen kann. Die Voodoos können das Ergebnis ihres Texturcombiners oder eine interpolierte Farbe mit dieser 'Referenzfarbe' vergleichen, bei Übereinstimmung wird der Bildpunkt verworfen, genauso wie Pixel verworfen werden, die den Z-Test nicht schaffen.

Ich hab' Spiele gesehen, bei denen die Referenzfarbe ganz einfach schwarz ist, hab aber auch eins hier, bei dem rosa gewählt wurde.

Anwendungsbereiche sind schnell aufgezählt:
1)Texturen mit Löchern drin rendern, ohne Alphakanäle verwenden zu müssen.

Das ist heutzutage nicht mehr relevant, da moderne Grafikkarten sich die größeren Texturformate mit Alphakanälen ganz gut leisten können. Die Voodoo 1 arbeitet aber am liebsten mit 8bit-Formaten wie RGB332. Für mehr hat sie bei annehmbaren Details auch nicht genug Speicher.

[Legolas]

Wird wohl z.b. in Half-Life für Geländer und Gitter benutzt. Auch hier kommt man ohne Alphakanal für die Texturen aus, also wohl Chroma Keying. Ach ja.. kann es sein, dass man dieses Feature auch Color Key nennt?

[zeckensack]

Originally posted by Legolas
Wird wohl z.b. in Half-Life für Geländer und Gitter benutzt. Auch hier kommt man ohne Alphakanal für die Texturen aus, also wohl Chroma Keying.Glaub ich nicht so recht. Weder NVIDIA-Chips noch ATI-Chips beherrschen das. Ich würde mal schätzen, daß hier RGBA5551-Texturen zur Anwendung kommen. Ein bit für'n Alphakanal reicht ja schon für sowas.Ach ja.. kann es sein, dass man dieses Feature auch Color Key nennt?Ja.

[ow]

@Zeckensack

Ich kenne keinen Chip, der color/chroma keying NICHT beherrscht.

[zeckensack]

Originally posted by ow
@Zecensack

Ich kenne keinen Chip, der color/chroma keying NICHT beherrscht. Schau mal:
OpenGL:
OpenGL does not support the "colour key" (a selected colour is not rendered) approach to making textures (e.g. sprites) partially transparent, since it raises awkward issues in the interface definition (e.g. what should be done with a chroma key colour during mip map generation?). The same effect can be achieved by providing a texture map with at least one bit of alpha and using the GL_ALPHA_TEST pathway.
http://216.239.37.100/search?q=cache:SgXkWYISt68C:talika.fie.us.es/~titan/ogl/faq/shading.html+Chroma+key+opengl&hl=en&ie=utf-8


Direct3D:
Issue six. The TNT implements colorkeying with alpha testing.

This can have ramifications on your application. In step four above, the colorkeyed color is removed by alpha testing. You use the alpha testing to control how much how this alpha value is discarded.

If you enable alpha testing, and do not discard the value zero in the alpha test function then colorkeying will not be performed. If alpha testing is disabled, the driver will enable it to perform the colorkey.
http://216.239.37.100/search?q=cache:kco2Eb2JV5gC:developer.nvidia.com/docs/IO/1335/ATT/ColorKey.doc+Direct3D+chroma+key&hl=en&ie=utf-8

[ow]

Und was heisst das auf 'deutsch'?

Unterstützung für CC ja oder nein?

Der 3DWinbench nennt´s color key transparency, es funzt auf allen von mir getesteten Chips.

[Exxtreme]

@ zeckensack
Gibt es deinen Glide-Wrapper irgendwo zum Download?

Gruß
Alex

[zeckensack]

Originally posted by Exxtreme
@ zeckensack
Gibt es deinen Glide-Wrapper irgendwo zum Download?

Gruß
Alex Jetzt schon. Seit ungefähr zwei Minuten habe ich eine Homepage *eg*
http://home.t-online.de/~zsack/

Dokumentation fehlt noch, also zur Vorsicht:
Läuft nur auf ATI-Karten, Radeon oder besser, ansonsten schmiert's wahrscheinlich mehr oder weniger elegant ab. Getestet bisher nur auf Windows 98SE. OpenGL-Optionen sollten relativ wurscht sein, allerdings sollte man Stencil-Buffering erlauben (wird noch nicht genutzt, aber angefordert). Texturkonvertierung (32 bit Hintergrundbilder blabla) wirkt eher kontraproduktiv. 32bit Desktop-Farbtiefe sollte nicht unbedingt erforderlich sein, kann aber helfen.

*edit*
Ups, ganz vergessen:
Nutzt momentan noch MOVNTQ, auf deutsch: es braucht mindestens eine 'halbe' SSE-Implementierung. Also entweder Athlon/Duron, oder Prozessoren mit voller SSE-Unterstützung. Werde das (und anderes) bei Gelegenheit beheben.

[Exxtreme]

Und die Datei in das Spieleverzeichnis kopieren und dann funktionierts? Was noch nicht schlecht wäre, ist ein Wrapper für Glide3. Trotzdem Thanks für deine Mühe.

Gruß
Alex

[ow]

Hi Zeckensack

Gib mir mal einen Tip, wie ich dein Testprog kompiliert kriege, es klappt nämlich nicht:

Kompilierung läuft...
Cpp1.cpp
C:\Eigene Dateien\Cpp1.cpp(14) : error C2501: 'PFNGLACTIVETEXTUREARBPROC' : Fehlende Deklaration
C:\Eigene Dateien\Cpp1.cpp(14) : error C2239: Unerwartetes Token 'identifier' nach der Deklaration von 'PFNGLACTIVETEXTUREARBPROC'
C:\Eigene Dateien\Cpp1.cpp(14) : error C2061: Syntaxfehler : Bezeichner 'glActiveTextureARB'
C:\Eigene Dateien\Cpp1.cpp(15) : error C2501: 'PFNGLMULTITEXCOORD2FARBPROC' : Fehlende Deklaration
C:\Eigene Dateien\Cpp1.cpp(15) : error C2239: Unerwartetes Token 'identifier' nach der Deklaration von 'PFNGLMULTITEXCOORD2FARBPROC'
C:\Eigene Dateien\Cpp1.cpp(15) : error C2061: Syntaxfehler : Bezeichner 'glMultiTexCoord2fARB'
C:\Eigene Dateien\Cpp1.cpp(22) : error C2659: '=' : Ueberladene Funktion als linker Operand
C:\Eigene Dateien\Cpp1.cpp(22) : error C2146: Syntaxfehler : Fehlendes ';' vor Bezeichner 'wglGetProcAddress'
C:\Eigene Dateien\Cpp1.cpp(23) : error C2659: '=' : Ueberladene Funktion als linker Operand
C:\Eigene Dateien\Cpp1.cpp(23) : error C2146: Syntaxfehler : Fehlendes ';' vor Bezeichner 'wglGetProcAddress'
C:\Eigene Dateien\Cpp1.cpp(40) : error C2065: 'texture_dat' : nichtdeklarierter Bezeichner
C:\Eigene Dateien\Cpp1.cpp(40) : error C2146: Syntaxfehler : Fehlendes ')' vor Bezeichner 'a'
C:\Eigene Dateien\Cpp1.cpp(40) : error C2059: Syntaxfehler : ')'
C:\Eigene Dateien\Cpp1.cpp(57) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(58) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(59) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(60) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(61) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(67) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(68) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(69) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(70) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(71) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(77) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(78) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(79) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(80) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(81) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(124) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(126) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(128) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(132) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(134) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(136) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(140) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(142) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(144) : error C2664: 'glTexEnvi' : Konvertierung des Parameters 2 von 'const int' in 'GLenum' nicht moeglich
C:\Eigene Dateien\Cpp1.cpp(163) : error C2065: 'onexit' : nichtdeklarierter Bezeichner
Fehler beim Ausführen von cl.exe.

Cpp1.obj - 38 Fehler, 0 Warnung(en)

[zeckensack]

ow,

Die ersten paar Fehler deuten darauf hin, daß glAti.h nicht korrekt gefunden wurde. Bitte die neueste Version runterladen und in das "Include\gl" Unterverzeichnis der VC-Installation kopieren.

Die Sache mit texture_dat und a); liegt daran, daß sich da wohl ein Zeilenumbruch eingeschlichen hat. Werd' das mal korrigieren.
*edit
Den Zeilenumbruch hat sich das Board hier ausgedacht. Ich kann ihn auch nicht wegeditieren. Die Zeile sollte am Ende so aussehen:
glTexImage2D(............,texture_data);
*/edit

Die ganzen const int-Teile liegen wohl ebenfalls an einer falschen Header-Datei.

Das onexit-Dingens kann ich nicht ganz nachvollziehen. Bei mir macht er das nicht. Zur Sicherheit editier ich auch nochmal folgendes oben rein: #include <stdlib.h>

[ow]

Originally posted by zeckensack
ow,

Die ersten paar Fehler deuten darauf hin, daß glAti.h nicht korrekt gefunden wurde. Bitte die neueste Version runterladen und in das "Include\gl" Unterverzeichnis der VC-Installation kopieren.

Die Sache mit texture_dat und a); liegt daran, daß sich da wohl ein Zeilenumbruch eingeschlichen hat. Werd' das mal korrigieren.
*edit
Den Zeilenumbruch hat sich das Board hier ausgedacht. Ich kann ihn auch nicht wegeditieren. Die Zeile sollte am Ende so aussehen:
glTexImage2D(............,texture_data);
*/edit

Die ganzen const int-Teile liegen wohl ebenfalls an einer falschen Header-Datei.

Das onexit-Dingens kann ich nicht ganz nachvollziehen. Bei mir macht er das nicht. Zur Sicherheit editier ich auch nochmal folgendes oben rein: #include <stdlib.h>


glati.h müsste er finden, ansonsten sagt VC das. War am Anfang so, als ich die noch nicht im Verzeichnis hatte.
btw, glut müsste ebenfalls drin sein.

Den Rest muss ich mal prüfen.

thx:)
ow


/edit: ohne glati.h kommt´s nicht weiter als so:

Kompilierung läuft...
Cpp1.cpp
C:\Eigene Dateien\Cpp1.cpp(8) : fatal error C1083: Include-Datei kann nicht geoeffnet werden: 'gl/glati.h': No such file or directory
Fehler beim Ausführen von cl.exe.


/edit2: hat sich nix geändert, geht immer noch nicht. Zeilnumbruch ist weg.

[zeckensack]

Originally posted by ow
/edit2: hat sich nix geändert, geht immer noch nicht. Zeilnumbruch ist weg.

Hmmm, komisch. Was haste denn jetzt so an Fehlermeldungen?

[zeckensack]

Nochma watt älteres:Originally posted by ow
Und was heisst das auf 'deutsch'?

Unterstützung für CC ja oder nein?

Der 3DWinbench nennt´s color key transparency, es funzt auf allen von mir getesteten Chips. Das ist eine Emulation, die nur unter bestimmten Bedingungen funktioniert. Der Alpha-Test wird für die Emulation verblasen, diese Einschränkung gibt es bei Voodoos nicht. Die können jede Beliebige Alphatest-Funktion mit beliebigen Referenzwerten und gleichzeitig Chroma-Keying mit beliebiger Referenzfarbe. Sie haben halt für beides 'richtige' Hardware.
Die Emulation mag NVidia hier besser gelingen als mir, da sie schließlich innerhalb des Treibers sehr viel näher an die Hardware herankommen. Wie man sieht, brauchen sie auch kein DOT3 dafür. Trotzdem ist's geschummelt. Die Unterstützung für ein DX-Feature bedeutet nicht, daß es allgemein nutzbar ist. Wie du mittlerweile gemerkt haben solltest halte ich nicht sonderlich viel von Direct3D. Ist mir einfach zu schlabberig spezifiziert, das hier ist wieder mal ein Beispiel dafür.

[zeckensack]

ow,

Die Nummer mit der Konvertierung von const int nach GLenum raffe ich überhaupt nicht. GLenum ist in den Headern als 'unsigned int' deklariert. Die const ints, die hier für die symbolischen Namen eingesetzt werden, sollten dazu passen.

Was noch komischer ist, die anderen Parameter für die GL-Funktionen sind vom gleichen Typ und auf die gleiche Weise definiert. Es wundert mich also, daß dein Compiler sich über GL_OPERAND0_RGB_ARB beschwert, aber nicht über GL_TEXTURE_ENV.

Du scheinst Probleme mit allen Bezeichnern zu haben, die aus glAti.h kommen. Dieser Header wird hier für die DOT3 und die Combiner-Extensions genutzt. Ich kann aber ehrlich gesagt überhaupt nicht nachvollziehen, was da passiert. Ich hab hier an meinen Compileroptionen rumgemurkst so gut ich konnte und bin total ratlos ...
Mindestens drei Leute haben diesen Samplecode auf Anhieb zum Laufen gebracht, ohne auf diese Fehler zu stoßen.

Selbst wenn ich 'böswillig' die Definitionen lösche und stattdessen zB GL_TEXTURE_2D als const int deklariere, schluckt der Compiler den Code klaglos.

Ich kann nur empfehlen, das Projekt erstmal zu löschen, ein neues zu erstellen (btw: Glut-Projekte setzt man am besten als "Win32 console application" auf, das erklärt die Fehler aber trotzdem nicht), alles auf default zu lassen, und nur in den Linkeroptionen glut32.lib einzutragen (Project Settings->Link->General, dann unten in die Liste reinschreiben).

[ow]

Originally posted by zeckensack

Hmmm, komisch. Was haste denn jetzt so an Fehlermeldungen?


Sieht nicht viel anders aus.
Sind immer noch 35 von obigen 38 Meldungen.
Hab VC5 mit ServicePack, falls dir das hilft.

[ow]

Originally posted by zeckensack
ow,

Die Nummer mit der Konvertierung von const int nach GLenum raffe ich überhaupt nicht. GLenum ist in den Headern als 'unsigned int' deklariert. Die const ints, die hier für die symbolischen Namen eingesetzt werden, sollten dazu passen.

Was noch komischer ist, die anderen Parameter für die GL-Funktionen sind vom gleichen Typ und auf die gleiche Weise definiert. Es wundert mich also, daß dein Compiler sich über GL_OPERAND0_RGB_ARB beschwert, aber nicht über GL_TEXTURE_ENV.

Du scheinst Probleme mit allen Bezeichnern zu haben, die aus glAti.h kommen. Dieser Header wird hier für die DOT3 und die Combiner-Extensions genutzt. Ich kann aber ehrlich gesagt überhaupt nicht nachvollziehen, was da passiert. Ich hab hier an meinen Compileroptionen rumgemurkst so gut ich konnte und bin total ratlos ...
Mindestens drei Leute haben diesen Samplecode auf Anhieb zum Laufen gebracht, ohne auf diese Fehler zu stoßen.

Selbst wenn ich 'böswillig' die Definitionen lösche und stattdessen zB GL_TEXTURE_2D als const int deklariere, schluckt der Compiler den Code klaglos.

Ich kann nur empfehlen, das Projekt erstmal zu löschen, ein neues zu erstellen (btw: Glut-Projekte setzt man am besten als "Win32 console application" auf, das erklärt die Fehler aber trotzdem nicht), alles auf default zu lassen, und nur in den Linkeroptionen glut32.lib einzutragen (Project Settings->Link->General, dann unten in die Liste reinschreiben).


ich werde das spaeter (heute abend) mal probieren, Thx.:)

[zeckensack]

Originally posted by ow
Hab VC5 mit ServicePack, falls dir das hilft. Hab' hier VC6 mit SP5. Kenne mich mit VC5 leider nicht so sonderlich aus. ???

[zeckensack]

Dummdidummdidumm :D
Uralt-Post, aber hab' gerade was dazu gefunden ;)
Originally posted by ow
Der 3DWinbench nennt´s color key transparency, es funzt auf allen von mir getesteten Chips.

Aus diesem Dokument (http://msdn.microsoft.com/library/en-us/dndxgen/html/directx8faq.asp):
How do I use color keying?

DirectX 8 does not support color keying. You should use alpha blending/testing instead, which is in general a more flexible technique that does not suffer from some of the problems associated with color keying.
Wie's aussieht, wurde color keying aus DirectX 8 wieder rausgekickt. Meine Vermutung: keine Hardware, außer Voodoos unterstützt es 'ordentlich'. ;)