Messieurs-dames, bonjour
 
Question à destination des pro d'opengl, attention.
 
Je développe depuis quelques mois un maxi jeu de bagnoles pourri en opengl utilisant ARB_VERTEX_PROGRAM et depuis peu ARB_FRAGMENT_PROGRAM. Il tourne sur radeon 9xxx et geforceFX mais pas sur geforce3/4 et c'est là ou ça m'ennuie. Les geforce3/4 supportent bien l'extension ARB_VERTEX_PROGRAM qui n'est d'ailleurs qu'une adaptation de NV_VERTEX_PROGRAM, mais pas du tout ARB_FRAGMENT_PROGRAM. D'autre part même si ces cartes sont sensées supporter les pixels shader, je ne vois rien qui ressemble à cela dans la liste de leur extensions. Je m'attendais à une sorte de NV_FRAGMENT_PROGRAM mais nada. Que dois-je en penser ? Que ARB_FRAGMENT_PROGRAM offre des pixels shaders de 2e génération (pixel shader 2.0 ?) incompatibles avec les geforce3/4 et les radeon8xxx ?
Qu'existe-t-il alors pour programmer des pixel shaders de 1e génération sur ces cartes ? Dois-je me contenter des NV_REGISTER_COMBINERS pour les geforce ?
Mais pourquoi, pourquoi ?
 
Merci pour votre attention !
 
john_john
 
 
ps: NV_FRAGMENT_PROGRAM existe bien, mais seulement à partir des geforcefx, damned.
 
pps: Est-ce une question de version de pilote ? Je sais que des fonctions nouvelles sont parfois apportées par des nouveaux pilotes, pourtant, ici même un pilote très récent ne semble pas offrir le support de ARB_FRAGMENT_PROGRAM aux geforce4
 
ppps: A part ça pour ceux que ça intéresse, mon jeu de bagnoles pourri commence à avoir une sacrée gueule, plus d'info sur demande [:

oui ARB_fp c'est R300+ & NV30+
pour GF3/4 (comme tu l'as dit) : reg combiners
pour R8500 : ATI_fragment_shader
 
voilou
 
PS :non c'est pas une question de pilote, c'est une question de hardware.  
PPS : allez, fais péter le lien vers ton jeu (et mets des screenshots, j'ai qu'une pauvre R8500 donc pas de ARB_fp )

Ok ! Merci pour les infos.
Après quelques modifs, mon jeu sait maintenant s'adapter pour tourner sur geforce3/4 et radeon 8500. Je vais tester mais il n'y pas de raison, j'y perdrai en perf par rapport aux cartes plus récentes (comme je n'utilise pas encore les reg combiner ni les ATI_fragment_shader, je dois m'y prendre à deux fois pour dessiner mes objets) Mais le rendu est quasi identique.
 
J'ai bien un site web qui parle de mon zeu, mais il n'est pas à jour, j'en indiquerai l'adresse dès que possible (une ancienne version est en téléchargement libre, mais elle n'a plus grand chose à voir avec l'actuelle et à vrai dire elle commence à me faire un peu honte, je vais l'abandonner à la DASS d'ailleurs)
 
ps: Ce n'est pas une question de pilote dis-tu ? ok, mais ça arrive parfois. Par exemple, le support de NV/ARB_vertex_program par les Geforce2 (oui 2) a été possible à partir d'une certaine version de pilote. Me gouré-je ?
 
pps: en guise de teaser, voici les quelques trucs sympas que j'ai développés dans mon zeu pourri: bumpmapping complet, ombres volumétriques, bagnoles photogéniques (elles font les stars), détection de collisions maison, moteur physique maison (pas top d'ailleurs mais honnête pour ce qu'il a à faire), jeu en réseau, customisation des bagnoles, assurance de rigolade pendant au moins 4 minutes. Je poste des captures dès que possible.

toutes mes salutations à quelqu'un qui essayes de faire un jeu pourri dans son coin. (moi c'est un jeu super pourri de combat spacial en directx, et y'a pas de combat encore, donc tu es bien avancé sur ta liste de dev).

ARB_vp peut etre émulé par le CPU sans trop dégrader les performances, c'est pour cela que cette extension est exposée par le driver même pour les vieilles cartes (jusqu'à GeForce 256 si je ne m'abuse). On ne peut pas vraiment dire que le GPU supporte la fonctionnalité à proprement parler, mais le résultat est le même.
Pour ce qui est de ARB_fp, c'est une autre histoire. Typiquement, son execution sur CPU donne un framerate à un seul chiffre (et petit en plus, le chiffre). Donc la, pas de miracle, si c'est pas supporté en hardware par le GPU, pas de fragment program.
 
Bon et sinon grouille toi de mettre à jour le site Tu nous as mis l'eau à la bouche la ;-)
Sinon le bump j'imagine que tu le fais en DOT3, non? T'as collé un peu d'environment mapping sur les caisses histoire de faire métalique?

Super cool ! Mon new site pourri est on line.
Soyez indulgents il est un peu ... conceptuel.
http://perso.wanadoo.fr/mezzoban/
Vous y trouverez des captures d'écran du genre...

 
J'ai besoin d'un peu de temps encore pour préparer une version téléchargeable du jeu (minimum geforce3 (sauf gf4mx) ou radeon 8500).
 
Le mapping environnemental est la dernière évolution graphique que je voulais apporter au zeu... avant de m'atteler à la refonte du moteur physique. Parce que aujourd'hui la physique est ... lunaire et carrément frustrante il faut dire.
 
john_john
 
ps: salutations à tous les créateurs de zeux pourris de la terre.

j'aime bien les commentaires: "Les deux bolides rigolent"

Je vois que t'as pris la skybox d'un mod pour halflife, ce serait vachement plus beau de la faire toi même en 4-5 clicks avec terragen ou un autre soft non ?

Sapristischtroumpf ! La dernière version de mon jeu pourri est on line, je vous redirige sur mon site
http://perso.wanadoo.fr/mezzoban
section "télécharger". Cette version intermédiaire exige une Geforce3/4 ou une Radeon8500 mais est un peu plus joli sur GeforceFX ou Radeon9500 ou supérieur.
 
Honnêtement, c'est le jeu du siècle.
 
J'attends les réactions des motivés.
 
john_john
 
ps pour retrox: ayest, j'ai mis du mapping environnemental. C'est bien cool comme effet, merci du conseil.
 
pps pour whatde: skybox made in terragen, merci aussi du conseil
 
ppps pour Smaragdus qui doute avec une mauvaise foi probable de la récence des technologies opengl par rapport à dx9 dans un autre sujet: c'est de l'opengl 1.5 (la 2.0 vient de sortir) et j'utilise massivement les pixels shaders des GPU de génération NV30/R300. Et tiens-toi bien, il existe une version complètement identique de mon jeu qui tourne sous linux.

j'ai une geforce 3, carte graphique non supportée

Merdeeeuh, arf, tu veux m'en reparler sur mon adresse mail ?
(elle est dans le fichier texte)
File-moi les traces de la fenêtre dos, je réagirai le plus vite possible.
J'avoue que je n'avais pas testé sur geforce3 (sur 4 oui mais je croyais que les mêmes extensions étaient supportées).
Tu as des pilotes récents ? (question naïve)
Merci déjà d'avoir essayé !

les pilotes c'est 43.45

Pas de support de GL_ARB_vertex_buffer_object !?
Maismaismaismais ?
La geforce3 ne les supporte pas ? je suis dans l'espace.
C'est ça le problème, peut-être une mise à jour de tes pilotes qui ne sont pas récents pourraît apporter ce support et régler la question.
La geforce4 les supporte, ça je peux l'assurer. Mon jeu n'utilise que ça ou presque et tourne bien dessus. Essaie avec des pilotes plus récents situv'.
Merci encore !

Si si, VBO est supporté par à peu pres tout ce qui existe sur le marché (meme par MESA).
Le driver est trop vieux, c'est tout. (ils en sont dans les 66.XX maintenant si je me souviens bien)
 
PS : je vais télécharger la chose
 
edit : 11Mo c'est trop pour mon 56K  

ok j'essayerai (pas tout de suite)
 
pourtant les 43.45 sont pas si vieux, quand je l'ai acheter on etait meme pas  au detonator xp, ca devais etre les 12.xx
 
edit : a oui, deja 66.xx bon ok

heu oui, je vois pas pourquoi une geforce 3 supporterai pas les VBO. (c'est qu'un container à vertex après-tout)

héhé 600fps en fenêtré ça tourne pas trop mal
 
pour tes collisions, la bordure est gérée en 2D et tu testes les sommets de la bounding box de la voiture ?

waouh, 600fps !
tu dois avoir au moins un 2200+ et une geforcefx. Me trompé-je ?
Humblement, j'ai passé pas mal de temps à optimiser mon bousin, j'entends par là les optimisations de l'efficacité des appels opengl. Il me reste encore une bonne marge de progression à réaliser avec tout les tests de cône de vision pour désactiver les objets non visibles. Ce sera mon tout dernier boulot.
 
Pour les collisions, non c'est pas ça. La barrière est gérée exactement comme les voitures, en 3d, au polygone près, mais le problème que tu sembles soulever (les voitures peuvent se rentrer un peu dedans) vient du simple fait que mon moteur physique ne sait pas encore gérer les rebonds après collision. Le test de collision est exact et exhaustif mais est sous-exploité par le moteur physique en somme.
 
Et en plein écran 1280x1024 par exemple, ça donne quoi ?

9800pro et dudu 1600 passé en xp o/c à 2.2 (voir config)
 
attends je te dis pour le 1280x1024...

280/300fps..

Pas mal du tout !
Les commandes sont un peu déroutantes, par example j'ai du mal à tourner en freinant, et l'on tourne un peu trop facilement à basse vitesse, et parfois je n'y arrive pas à grande vitesse.
110 fps en 1152x864 XP1800 R9800 normale
Beau travail, les décors sont superbes, dommage qu'ils ne soient pas tjs visibles, faudrait un paysage différent, la route en bas on verrai mieux, en tout cas chapeau bas

Vraiment bien, malgrés la jouabilité selective, mais c'est le jeu
 
 
pourquoi pour le filtrage anisotropique tu le fais pas directe ?

J'ai entre 85 et 110 fps en 1280*1024 sur un 1800+ gf4ti4200.
Même remarques pour les controles que Cricri_

Hihi, merci à mes admirateurs chaque instant plus nombreux. Merci merci, vraiment, je vous aime tous. Ce que j'ai fait c'est grâce à vous, merci à tous.
 
Hem...
Alors bon, il y a deux problèmes, premièrement les roues arrières sont directionnelles. A basse vitesse elle s'opposent aux roues avant pour tourner plus vivement, à moyenne vitesse elles sont passives, et à haute elles accompagnent les roues avant pour baisser la vivacité des coups de volants et augmenter la stabilité de la bagnole. Du coup il est effectivement plus facile de tourner à basse qu'à haute vitesse, c'est une sorte d'aide à la conduite car à haute vitesse, mon moteur physique est assez intraitable sur les ecarts de trajectoires et la perte d'adhérence survient vite ce qui se traduit immanquablement par un "décollage" de la voiture. Son contrôle est totalement perdu, et la voiture file tout droit. La seule manière de récupérer le pilotage, c'est de ramener les roues dans le sens du déplacement pour récupérer de l'adhérence. Autrement les freins sont inopérants.
Je sais que c'est un peu de la bidouille, mais c'est le seul défi que propose mon jeu actuellement, celui de savoir trajecter à la limite de la perte d'adhérence. Lorsque j'aurai un vrai moteur physique (c'est le 2e problème) les choses seront vraiment différentes. D'ailleurs ça tombe bien, je devais en acheter un ce soir chez aldi.
 
pour le problème de l'aniso, j'avoue que je ne m'y suis pas encore penché, je ne sais pas comment faire pour l'activer en opengl. Mais ce serait surement bien de l'intégrer. Vouich.
 
ps: 110 fps en 1152x864 sur une radeon 9800, ça me paraît peu. Je tablerais plutôt sur du 200. Tu as du fsaa ou de l'aniso activé ?
 
pps: alors ? qui va tester le multijoueur en premier ? Moi je décline, je n'ai qu'un pov 56k provisoire.
 
ppps: parler d'aniso, je sais pas pourquoi, mais ça m'a donné soif.

 
Heuuhhh ... je n'ai pas fsaa dans opengl, y a aniso de coché, ce sont les réglages par défaut je n'y connais rien ...
et je suis en 16 bits pour l'affichage.

pour l'aniso :
 
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 2.0f);  
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);  
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR_MIPMAP_LINEAR);  
 
sur la texture courante

Ah ouais, c'est clair, chuis tout con passé à côté. C'est décoiffant de complexité.
Merci mec ! Je croyais que c'était plus complexe que ça.
 
pour cricri_ : pour info, fsaa = antialiasing = anti-crénelage en français du massif central. Et si tu as en plus de l'aniso 4 ou 8x, c'est normal que tes performances chutent un peu. Par contre, 16bits en affichage c'est un peu ... démodé, je te conseille vivement 32. Tu as tout à y gagner.

ben entre 16 et 32 bits (pour le mode video) je sais pas si on  vois vraiment une difference (je parle pas de la profondeur des texture)
 
mais en 16 bits ca pourra etre legerement plus performant vu que les frame buffer (en double ou en triple) sont moins  gros -> gains en bande passante
 
corrigez moi si je me trompe

oui & non.
 
les contrôleurs mémoire des cartes actuelles sont optimisés pour un format pixel de 32bits.
 
vu la résolution des textures employées, je doutes que la bande-passante soit la limite sur une carte moderne (disons rad9800).
 
après tu t'en fous, tu laisse l'option à l'utilisateur.
 
par contre oublie l'antialiasing en 16bpp. (remarque ça dépends de la technique utilisée)

Merci pour les infos
 
J'ai esayé de bricoler avec ces options mais ça n'a pas l'air de changer grand chose, j'ai tout remis à préférences de l'application.

bjone > ok
 
j'ai pas trop compris comment etait foutu la lumiere (celle qui bouge, plutot speculaire), des fois  on dirais qu'elle suit la voiture, puis elle disparait et reapparais par intermitance...
 
c'est dommage car c'est ce qui met en valeur le bump mapping (pour les ombres projettés ca doit etre une lumiere fixe je suppose)
donc des fois ya pas de lumiere et la route est toute noir, on voit aucun details

Euuuuuh g pas tout lu mais g cru comprendre que tu faisais ta physique. Si ton but c'est juste de faire le jeu, pourquoi ne pas utiliser une lib ? Y'a Tokamak qu'est gratuit, et ODE qu'est open-source (Tokamak est nettement plus rapide).

bah la curiositée je suppose

Oui sinon il aurait probablement utilisé un moteur 3d tout fait aussi.

Ouich, quelque chose comme ça.
 
Pour ce qui est du problème de la lumière sautillante sur la route, je sais qu'il y a un pitit soucis, comme si la lumière bougeait selon nos propres mouvements.
En réalité, comme on est collé sur la route lorsqu'on conduit, les demi-vecteurs H utilisés dans le calcul spéculaire varient très violemment d'un vertex à un autre d'un même polygone. Je dois encore investiguer mais c'est le coeur du problème je crois. Il suffit de passer en mode caméra libre et de s'élever suffisamment pour s'apercevoir que ce problème disparaît et que l'effet spéculaire est enfin correct.

La version Linux, la version Linux !

 
c'est soit un problème de normalisation, soit de la manière dont tu calcules le vecteur vue.
 
en fait pour ton bump, normalement tu ramènes le vecteur vue et lumière dans le repère du vertex par vertex (logique), ces deux vecteurs sont interpolés (et se retrouvent potentiellement dénormalisés) par pixels, et ensuite par pixel tu fais tes scalaires entre ces vecteurs (via le half-way).
 
enfin bref, tu as deux problèmes:
 
1) dénormalisation potentielle
2) vecteur vue imprécis si proche d'un gros triangle
 
de manière générale tu auras plus de précisions sur une radeon 9500+ / geforce fx.
 
en fait le maximum de précision viens en interpolant la base de chaque vertex ainsi que la coordoonée spaciale, le tout par pixel, afin de calculer le vecteur vue->coordoonée spaciale et lumière->coordoonée spaciale, et de les ramener dans le repère texture, ce par pixel.
 
au lieu, de ramener la vue et la lumière dans le repère texture par vertex.
 
je sais j'ai expérimenté la chose sur mon propre code, et pour les cas où la caméra est très proche des triangles bumpés, c'est ce qui génére le max de précision.
 
mais oublie la chose sans radeon 9500+/geforce fx.

tu as aussi du banding un peu partout, enfin bref, vive les cartes en virgule flottante par pixel.

Voici le programme qui s'occupe de l'effet spéculaire de la route:

l'unité 0 contient le cubemap normalisant, la 1 la normal map, la 2 rien, la 3 la texture de base.
Comme tu vois, je normalise mes vecteur vue et lumière avant de les additionner et de projeter le résultat sur la base de chaque vertex. Et cette projection est elle même normalisée par le cubemap puis interpolée en chaque pixel.
Je ne saisis pas où pour survenir la dénormalisation.
 
Autrement, je préférerais autant que possible trouver une solution qui se passe de fragment program, histoire de rester compatible avec les nv20/r200.
 
Ca te dit quelque chose ?