C++

OpenGL : GROS problème

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : OpenGL : GROS problème

Kyle_Katarn

j'utilise des textures 8bits (soit 256 coul), dans mon code que j'initialise
l'affichage en 16 ou 32 bits, je me retrouve confronté à un problème que je
n'arrive pas à résoudre :

Quand mon bureau est en 16 bits : je tourne au mieux à 5 fps...
Quand mon bureau est en 32 bits : je dépasse les 25 ... (et certaines
personnes avec de grosses config dépassent même les 200 fps)

Ce qui va à l'encontre de toute logique !

Publicité

Tetedeiench

Head Of God

modo : on a un leger probleme de crossposteur la :

http://forum.hardware.fr/forum2.ph [...] h=&subcat=

http://forum.hardware.fr/forum2.ph [...] h=&subcat=

...

Kyle_Katarn

Si t'as vraiment rien d'autre à fouttre, je te conseille d'apprendre à programmer, de te renseigner sur OpenGL et de répondre à ma question.

Là, ta présence ici aura peut être un sens ...

Tetedeiench

Head Of God

Je connais OpenGL, je connais C++ et je m'indigne de voir que tu te permets plusieurs posts pour une seule et meme question, pour ton pauvre nombril esseule.

Donc je m'insurge.

Et comme ton attitude ne merite pas d'aide d'aucune maniere, comme je connais la reponse mais que tu ne merites pas selon moi que l'on t'aide, je fermerai ma gueule.

Dommage pour ti :hello:

Kyle_Katarn

Super comme point de vue.

En même temps la réponse, pour peu que tu la connaisses, tu as bien dû la trouver quelquepart .... tu n'est pas indispensable, je pense.

A bon entendeur ...

"Y'a pas de bon ou de mauvais forummeurs, y'a juste des forummeurs..."

Tetedeiench

Head Of God

Kyle_Katarn a écrit :

Oui, je l'ai trouvee en rencontrant le meme pb et en branchant mon cerveau !

Ce que tu m'as l'air incapable de faire, assurement.

Et vu que tu te prends pour quelqu'un sorti de la cuisse de jupiter, bah, demerdes toi pour trouver la raison tout seul.

Message édité par Tetedeiench le 02-03-2003 à 22:07:22

skylight

Made in France.

tetedeiench a écrit :

modo : on a un leger probleme de crossposteur la :

http://forum.hardware.fr/forum2.ph [...] h=&subcat=

http://forum.hardware.fr/forum2.ph [...] h=&subcat=

...

T'as vraiment rien compris toi [:mlc]

Kyle_Katarn

Visiblement c'est un forummeur "de poids".

Mais plus au sens "boulet" qu'au sens "influent" du terme ...

Harkonnen

Modérateur
Un modo pour les bannir tous

le iench > il est ou le crosspost ? un crosspost pour moi est une question posée sur différentes sections. Or ici, Kyle demande juste à un maximum de personnes de tester son logiciel ! Je vois pas ou est le mal...

Merci de rester poli...

---------------
J'ai un string dans l'array (Paris Hilton)

drasche

Harkonnen a écrit :

ici:
http://forum.hardware.fr/forum2.ph [...] cat=10&p=1

Kyle_Katarn a écrit :

ok

Et si tu passe la profondeur des couleurs du bureau de 16 à 32 ou de 32 à 16 t'as pas de probs de FPS ?

---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)

Publicité

Harkonnen

Modérateur
Un modo pour les bannir tous

drasche > non, honnetement, je vois pas de crosspost.

Sur le présent topic, Kyle a un problème de fps en fonction de la profondeur du bureau

Sur le topic de JV, il souhaite avoir des avis sur son jeu

Et ici, il fait un lien sur le topic de JV pour avoir d'autres avis. A la rigueur, on pourrait considérer ces 2 derniers topics comme légèrement identiques, mais ce n'est pas fait dans le but d'obtenir une quelconque réponse, mais pour avoir des avis de compatibilités sur différentes configs.

Et encore, je suis pas sur qu'il ait pas posté sur JV pour avoir l'avis sur le coté ludique, et ici pour le coté compatibilité.

A trancher. En ce qui me concerne, je ne vois pas de crosspost.

Par contre, Kyle & tetedeiench, je vous serais reconnaissant de rester polis.

---------------
J'ai un string dans l'array (Paris Hilton)

Harkonnen

Modérateur
Un modo pour les bannir tous

Tetragrammaton IHVH a écrit :

Je me demande quel est le "plus boulet", dans ce cas là...

C'est peut être celui qui ne sait pas résoudre un problème aussi évident...

Une autre réflexion de ce genre et c'est le TT. Il débute en OpenGL, c'est pas une raison pour l'enfoncer.
Et si t'es si malin, au lieu de le casser, tu ferais mieux de lui donner la solution, qu'on en finisse avec ce topic qui se rapproche dangeureusement du combat de rues.

---------------
J'ai un string dans l'array (Paris Hilton)

Kyle_Katarn

Tetragrammaton IHVH a écrit :

Je me demande quel est le "plus boulet", dans ce cas là...

C'est peut être celui qui ne sait pas résoudre un problème aussi évident...

Si c'était si évident que ça on m'aurait peut être déjà donné la réponse non ?

Message édité par Kyle_Katarn le 03-03-2003 à 13:23:07

bjone

Insert booze to continue

Gangs of HFR

bjone

Insert booze to continue

sinon pour l'histoire, j'ai pas pratiqué l'opengl, juste lorgné, mais le fait de passer en 16bpp pour ton front/back buffer, fait que tu as un couple back buffer/zbuffer non supporté et tu parts en rendu logiciel via le driver crosoft :??:
sinon autrement je vois poa comme ça...

antp

Super Administrateur
Champion des excuses bidons

[:ciler]

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire

chrisbk

BJOne a écrit :

ca me paraitrait chelou qu'une carte supporte pas le zb en 16.
Par contre si il utilise le stencil buffer alors la c different (mais je ne crois pas, vu qu'il n'en fait pas mention)

t'as essaye en utilisant des textures 16bits ? (histoire de ?)

bjone

Insert booze to continue

par contre tu pourrais mettre un peu de filtrage trilinéaire boudiou

Message édité par bjone le 03-03-2003 à 14:48:31

Kyle_Katarn

Voilà donc ma fonction d'initialisation :

Code :

bool bSetupPixelFormat(HDC hdc)
{
PIXELFORMATDESCRIPTOR pfd;
int pixelformat;
pfd.nSize = sizeof(PIXELFORMATDESCRIPTOR); // Set the size of the structure
pfd.nVersion = 1; // Always set this to 1
// Pass in the appropriate OpenGL flags
pfd.dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER;
pfd.dwLayerMask = PFD_MAIN_PLANE; // We want the standard mask (this is ignored anyway)
pfd.iPixelType = PFD_TYPE_RGBA; // We want RGB and Alpha pixel type
pfd.cColorBits = SCREEN_DEPTH; // Here we use our #define for the color bits
pfd.cDepthBits = SCREEN_DEPTH; // Depthbits is ignored for RGBA, but we do it anyway
pfd.cAccumBits = 0; // No special bitplanes needed
pfd.cStencilBits = 0; // We desire no stencil bits
// This gets us a pixel format that best matches the one passed in from the device
if ( (pixelformat = ChoosePixelFormat(hdc, &pfd)) == FALSE )
{
MessageBox(NULL, "ChoosePixelFormat failed", "Error", MB_OK);
return FALSE;
}
// This sets the pixel format that we extracted from above
if (SetPixelFormat(hdc, pixelformat, &pfd) == FALSE)
{
MessageBox(NULL, "SetPixelFormat failed", "Error", MB_OK);
return FALSE;
}
return TRUE; // Return a success!
}

que SCREEN_DEPTH vaille 16 ou 32, j'ai le même problème quand le bureau est en 16.
Le probème apparait sur toute congif (de ma CG S3Twister à des G4 Ti) donc c'est apparamment un problème de code...

Kyle_Katarn

Up désespéré.

Autre truc que je comprend pas, je peux mettre SCREEN_DEPTH à 2 ou même 0 ça change strictement rien ...

bjone

Insert booze to continue

bin le problème, c'est que quand tu fais du rendu en fenêtre, si le format pixel du mode opengl est différent de celui du bureau, le driver doit faire un changement de format au lieu d'une bête recopie.

Kyle_Katarn

Le problème est que ça le fait aussi quand je passe en plein écran et que ça le fait même quand je mets tout en 16 bits

Kyle_Katarn

Espérons que tetedeiench finissent par nous donner la solution qu'il dit connaitre ...

Taiche

(╯°□°）╯︵ ┻━┻

Kyle_Katarn a écrit :

Espérons que tetedeiench finissent par nous donner la solution qu'il dit connaitre ...

Mai cai supair, dis-moi, de relancer la baston qui avait pourtant l'air d'être terminée [:dawa]

---------------
Everyone thinks of changing the world, but no one thinks of changing himself | It is the peculiar quality of a fool to perceive the faults of others and to forget his own | Early clumsiness is not a verdict, it’s an essential ingredient.

Kyle_Katarn

J'essaie pas de relancer la baston mais il disait avoir la solution et vu que personne ne semble pouvoir résoudre mon problème je suis près à faire un post d'excuse lui étant consacré si effectivement il se révèle capable de répondre à mon appel à l'aide.

Taiche

(╯°□°）╯︵ ┻━┻

Kyle_Katarn a écrit :

Ah OK alors dans ce cas-là, j'ai rien dit.

Kyle_Katarn

Personne pour m'aider ? (snif)

bjone

Insert booze to continue

à la limite, un truc pour essayer:

si tu peux logger dans un fichier le nom du pilote opengl utilisé (quake3 te l'affiche, ainsi que les extensions), ça permetterai de savoir si dans les cas où ça chie tu part avec le renderer opengl software de microsoft. mé bon c'est histoire de continuer dans mon trip initial

bjone

Insert booze to continue

enfin chez moi, pour que ça ralentisse, il faut partir en fenêtre avec le bureau en 16bpp. le plein écran ne joues pas.

donc fait un exe en 16 bpp, et un autre en 32 bpp, qu'on soit fixé si c'est bien uniquement le fait d'avoir un rendu fenêtré avec le format pixel différent du bureau.

Kyle_Katarn

Si tu veux le même exe, a des perfs différentes en bureau 16 et bureau 32.

Et l'étant du bureau lors de la compialtion ne fait rien ....

Comment on récupère le nom du pilote de rendu utilisé ?

Zzozo

Un peu, passionément, à la fol

Ca va ptet pouvoir t'aider ... ...
http://www.plunk.org/~shreiner/SIG [...] ce.OpenGL/

EDIT :
This might help too ... :sleep:
http://www.opengl.org/developers/f [...] indows.htm

Message édité par Zzozo le 04-03-2003 à 09:01:49

Kyle_Katarn

ok je regarde ça

Kyle_Katarn

Merci pour l'info.

J'ai ajouté ce bout de code

Code :

DescribePixelFormat (hdc, pixelformat, sizeof(PIXELFORMATDESCRIPTOR), &pfd);
if ((pfd.dwFlags & PFD_GENERIC_ACCELERATED) ||
!(pfd.dwFlags & PFD_GENERIC_FORMAT))
MessageBox(NULL,"Accceleration Hardware","r",MB_OK);
else
MessageBox(NULL,"Accceleration Software","r",MB_OK);

et visiblement je ne suis en soft que quand le bureau est en 16 bits et que je joue en mode fenêtré...
En plein écran ça passe en hard dans tous les cas.

Zzozo

Un peu, passionément, à la fol

Kyle_Katarn a écrit :

Merci pour l'info.

J'ai ajouté ce bout de code

Code :

DescribePixelFormat (hdc, pixelformat, sizeof(PIXELFORMATDESCRIPTOR), &pfd);
if ((pfd.dwFlags & PFD_GENERIC_ACCELERATED) ||
!(pfd.dwFlags & PFD_GENERIC_FORMAT))
MessageBox(NULL,"Accceleration Hardware","r",MB_OK);
else
MessageBox(NULL,"Accceleration Software","r",MB_OK);

et visiblement je ne suis en soft que quand le bureau est en 16 bits et que je joue en mode fenêtré...
En plein écran ça passe en hard dans tous les cas.

Pour moi, ca dépend de l'implémentation OpenGL sous jacente du système ...
Cé ce qui explique les perfs si différentes d'un système à un autre ... la combinaison hard + drivers est différente d'une config à une autre, et cé ce qui explique toutes ces différence de perfs ...

Zzozo

Un peu, passionément, à la fol

Kyle_Katarn a écrit :

Merci pour l'info.

J'ai ajouté ce bout de code

Code :

DescribePixelFormat (hdc, pixelformat, sizeof(PIXELFORMATDESCRIPTOR), &pfd);
if ((pfd.dwFlags & PFD_GENERIC_ACCELERATED) ||
!(pfd.dwFlags & PFD_GENERIC_FORMAT))
MessageBox(NULL,"Accceleration Hardware","r",MB_OK);
else
MessageBox(NULL,"Accceleration Software","r",MB_OK);

et visiblement je ne suis en soft que quand le bureau est en 16 bits et que je joue en mode fenêtré...
En plein écran ça passe en hard dans tous les cas.

Tu as remis à jour ton exe ? que je teste chez moi ...
EDIT : Et une version Linux, cé trop demander ? :ange:

Message édité par Zzozo le 04-03-2003 à 09:32:02

Kyle_Katarn

Ben là je débute donc je fais du Win mais je passerais sous linux dès que possible.

Si tu me donne ton adresse mail (par MP) je peux même te mailler le code source si tu peux m'aider ...

Sur les sites cités (!) ils disent vaguement d'utilier ChoosePixelFormat de manière itérative jusqu'à avoir le flag PFD_GENERIC_ACCELERATED mais je vois pas trop comment faire ...

Zzozo

Un peu, passionément, à la fol

Kyle_Katarn a écrit :

Ben je pense que tu peux t'inspirer de ce bout de code là (tiré de
http://www.plunk.org/~shreiner/SIG [...] lTests.cxx )

Code :

void
runTests( int width, int height )
{
int i;
void* pixels;
PixelFormat* format;
struct timeval start, finish;
//
// Initialize OpenGL state
//
glRasterPos2i( 0, 0 );
for ( format = formats; format->value != GL_ZERO; ++format ) {
format->error = GL_NO_ERROR;
pixels = genData( format->value, width, height );
glPixelStorei( GL_PACK_ALIGNMENT, format->alignment );
glClear( GL_COLOR_BUFFER_BIT );
glDrawPixels( width, height, GL_RGBA, format->value, pixels );
gettimeofday( &start, NULL );
for ( i = 0; i < numTrials; ++i )
glDrawPixels( width, height, GL_RGBA, format->value, pixels );
glFinish();
gettimeofday( &finish, NULL );
format->time = finish.tv_usec - start.tv_usec;
if ( format->time < 0 ) {
--finish.tv_sec;
format->time += 1000000;
}
format->time /= 1000000;
format->time += (finish.tv_sec - start.tv_sec);
GLenum error;
while ( (error = glGetError()) != GL_NO_ERROR ) {
format->time = -1.0;
format->error = error;
}
free( pixels );
}
double minTime = formats[0].time;
for ( format = &formats[1]; format->value != GL_ZERO; ++format )
if ( format->time > 0 && minTime > format->time )
minTime = format->time;
for ( format = formats; format->value != GL_ZERO; ++format ) {
printf( " %-35s: ", format->name );
if ( format->time > 0 )
printf( "%6f secs [ % 7.3f ]\n", format->time, format->time / minTime );
else
printf( "Returned '%s' error\n", gluErrorString(format->error) );
}
}

A priori, sa boucle for ressemble fort à cette itération dont tu as besoin justement ...

EDIT : 10 heures ... :ouch: !!! ... Faut que j'aille prendre mon petit déj moi ... ... @+ :hello:

Message édité par Zzozo le 04-03-2003 à 10:05:13

Kyle_Katarn

lol

Zzozo

Un peu, passionément, à la fol

QQ résultats :
La config : Celeron Tualatin 1,2 GHz + 256 Mo SD-RAM + GeForce 2 Ti 64 Mo
- Sous Windows XP : ca oscille entre 80 et 500 fps suivant les modes
- Sous Linux, en émulation avec Winex-cvs et avec un MP3 en fond musical ( [:joce] ) :
ca oscille entre 80 et 110 fps ( Remarque : pas testé en plein écran sous Linux ... à cause de la résolution de mon bureau)

Il semble que la GeForce 2 et ses pilotes fassent bien leur boulot ...

Je vais voir pour un portage en natif sous Linux ...
[:zerod]

MAJ : 180-190 fps sous Linux, toujours en émulation, en changeant un paramètre ... :whistle:

Message édité par Zzozo le 04-03-2003 à 12:46:06

Kyle_Katarn

et pour mon problème de mode fenétré (bureau 16 bits) ?

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

C++

OpenGL : GROS problème

Sujets relatifs
Mon premier jeu en OpenGL : donnez moi votre avis	[c] problème d'affichage de variable avec outtextxy()
[YACC] Problème de récursion à droite	Probleme de validation de formulaire... page2
[apache/axis] problème avec Java2WSDL	Probleme de connexion avec php sur une base de donnees
Gros doute sur une structure...	Problème d'affichage pour Mac en 800*600
Problème d'affichage	problème taille de buffer /socket
Plus de sujets relatifs à : OpenGL : GROS problème

Page générée en 0.156 secondes