Bonjour Bonjour.

Je sais que tres tres peu d´entre vous serez capable de me repondre.
Mais ma carte graphique ne gerant que le pixel shader et vertex shader 1.1, cela me pose un problem pour un programme ayant du code fonctionnant en pixel shader 2.0.

mon problem, que je ne comprends pas bien non plus , est que mon pixel shader n´arrive pas a recuperer ma structure de sortie de mon vertex shader en version 1.1. Il me fait une erreur de lecture memoire.

En Cg pas de probleme, la sortie du vertex shader rentre bien dans le pixel shader.

"Pous gollumaker qui pourrait me repondre (ben fais tout en Cg !) non, pour notre moteur en DirectX on a besoin de passer un objet de type D3DEFFECT, donc HLSL only"

le code
http://rafb.net/paste/results/lXWz4677.html

Sinon me passer un lien d´un forum pouvant me renseiger ce simpathique.

Desolé d´avoir ecorché ton pseudo Gollunkawder

avec un coup d´oeil rapide, je ne vois rien de particulier qui soit trivial.
Soit c´est qqch de tres idiot, et on passe a cote, ou au contraire, c´est bien tordu.

Je conseillerai de tester le shader avec un device en REF, histoire de mettre l´HAL hors de cause (les compilos HLSL de DX etaient pas mal bugges dans des versions un peu anciennes).
Essaye de faire tourner le shader dans FX Composer.
Essaye de le tracer avec le PIX, si le shader compile proprement.

(au passage, evite le swizzling avec des operandes de tailles mixtes ; i.e. un .xyz avec un float3 et un float4)

Avec le viewer de DX, il me le compile pas.
l´erreur qu´il me dis est :

(38)Warning : texcoord input used directly (that is, other than sampling from texture) in shader body in ps 1_1 are always clamped from 0 to 1.

(38) error : cannot map expression to pixel shader instruction set.

Et donc : compilation failed

Je debute dans le HLSL donc j´ai pas bien capté ce qu´il me veut, enfin juste que le warning entraine l´erreur.

aaah, ben ca va etre tres simple alors :D
l´instruction normalize n´est dispo cote PS qu´en pixel shader 2.0 et plus (comme tu precises au debut, mais sans detail sur les instructions en question).
Par contre c´est dispo cote VS a partir de 1.1 ; donc normalise tes donnees AVANT de les transmettre au pixel shader, cote VS donc.
Dans ton cas c´est simple, mais si tu faisais des calculs dans le PS qui devraient ensuite etre normalises, il faudrait feinter (genre grosse approx a coup de dot et de series, ou texture de sqrt en precacl, etc.).

details : pour le warning, c´est un soucis qui va entrainer un mauvais fonctionnement de ton shader. Vu que tu passes des infos via les interpolateurs des TEXCOORD (normal, au passage), on te previent qu´ils sont bornes a [0, 1] en PS1. Donc un vecteur avec des composantes negatives va etre deforme...
solution : fait comme on fait habituellement pour des normal maps par ex ; tu resamples tes composantes en 0-1 cote VS (betement (x + 1.0f)*0.5f), et du fais l´inverse cote PS (donc x*2.0f - 1.0f)

l´erreur en elle meme indique clairement que le jeu d´instruction PS1.1 ne permet pas les operations que tu fais.

=> change de CG, tu va t´emmerd... sur bcp de points, avec un GPU ne supportant pas au moins les VS/PS 2.0

ah oui, et le warning et l´erreur sont ici independants ;)

what LGV said (je vois pas quoi rajouter de plus..)

Je t´aurais pas dit de le faire en CG, le CG c´est supayr mais c´est vieux, le HLSL c´est actuel et actualisé, d´ailleurs j´en ai fait un peu c´est pas mal..

(Vengeaaaaaaaaaaaaance pour mon pseudo )

Sinon LGV a raison vaudrait mieux que tu changes de GPU =/ Puisque tu sembles etre dans les premieres GeForce Si tu as pas beaucoup de sous une alternative dans les GeForce FX peut etre interessante (certains te diront qu´elles sont decevantes, mais le core est plus actuel que ceux des 4 Ti par ex. et supportent bien mieux les dernieres technologies). Sinon si tu es un gros bourgeois plein de fric (j/k) tapes dans les 6x00, t´en as pour un bout de temps avec ça. Coté ATI ya bien les 9800 qui tiennent la route, et les series Xx00 maibon, sapusaymal^^ (& don´t feed it !)

Merci beaucoup.

Pour le changement de carte graphique je comptait le faire, mais d´un autre coté. Pour le coté dev, si on passe tout en pixel et vertex shader 2.0 nos jeux ne seront plus accessible a tout le monde.

De toute facon si je change de carte c´est pour une tip top, 6800 de nVidia.

Je regarde pour mon code tout de suite.
Encore merci

Re: LGV et gollum.
J´ai un autre petit soucis, c´est pour le passage de plusieur texture a ma carte graphique.
J´a n´arrive qu´a en recuperer une seul avec ma methode en shader 1.1, en 2.0 ca marche nikel.

http://rafb.net/paste/results/FhHsvu94.html

donc le probleme est au niveau du
sampler maintexSampler : register(s1) = sampler_state

A premiere vu le registre S1 il refuse de me le lire en shader 1.1.
Y aurais pas un moyen de contourner cela ?

c´est p-e une limite du nb d´interpolateurs utilises.
Ne specifie aucun registre (le compilo fait ca tres bien automatiquement, et evite souvent des bourdes perf-killer), et re-teste. En tentant d´assigner les samplers, il crachera p-e des warnings.

Dans tous les cas, donne nous TOUTES les infos : les symptomes, les msg de compilo, si ca marche sous FXEdit, si ca marche en REF, etc.

au passage, tu ne definis pas de texture pour ton sampler ; selon comment tu t´en sers, ca va marcher ou non.. est-ce que c´est voulu ?

tant qu´a y etre, specifie toujours le type des operandes immediates ; tu melanges par ex. des "1" avec des float. Dans certain cas ca peut confusionner le compilo HLSL qui va faire qq operations "a blanc" pour faire passer ca. En collant un "1.0f", tu es sur de faciliter le boulot du compilo.

En realité, ce code, n´est pas de moi, ou en petite partie seulement pour de ce qui est du passage de texture. J´ai compris ce que ca fais mais pas le pourquoi.

J´en suis qu´a ma deuxieme journée en HLSL.

pour les attribution afin de facilité le travaille du compilo, je le fait, c´est juste que j´ai pas fais attention, au 1 au lieu du 1.0f.

sinon je veux bien ne pas attribuer de registre mais, je sais pas comment m´y prendre

Sinon pour la deuxieme structure (sampler) il prend la texture de l´object celle qui est defini dans le .x

visiblement tu sautes qq etapes, si ce code n´est pas de toi et que tu ne peux pas aisement le manipuler. Je te conseillerai de lire la doc du Cg (si si,c´est tres proche du HLSL, et surtout tres bien detaille), puis celle du HLSL dans la doc DX, puis les sample du HLSL Workshop, entierement detaille.
Ensuite seulement tu seras a meme de saisir toutes les finesses. Ca ne devrait pas te prendre tres longtemps ; commence par ca, et reviens quand tu pourras un peu tripatouiller le code en connaissance de cause

OK OK, je fais ca ce soir.
Pour le Cg ca fais deja 3 semaines que j´en fais.

On en reparle demain ou apres demain
Merci bien en tout cas, je pensais pas avoir de reponse ici, mais je me suis trompé

" je pensais pas avoir de reponse ici, mais je me suis trompé"

eh eh, on ne dirait pas, mais il y a des gens dont c´est le boulot, quand meme ;)

Wahou c´est terrible ce genre de topics, ca doit donner envie aux débutants

Evidement en montrant le resultat et pas le code ca aurait ete plus attractif, mais bon c´etait pas le but non plus.
Et puis c´est vrai qu´on est loin des script RPGMaker
High Level Shading Language, ca pete comme non !

Arf et ca sert à quoi? A faire des ombres portées?

Le premier c´etait simplement pour de l´eclairage. Le second c´est pour du bump mapping et un eclairage en vertex shader.

Globalement les HLSLs (celui de microsoft, nvidia et celui de SGI/ARB) sont des langages haut niveau qui permettent de manipuler des instructions très puissantes directement envoyées au GPU, le Graphic Processing Unit, cad ce pourquoi ta carte graphique next gen est si chere ^^ (avec la ram embarquée of coz).
Dedans on distingue deux choses. Les Vertex shaders et les Pixels shaders (tout simplement parcequ´en fait ton GPU est consituté de deux unité de traitement, le vertex processor et le fragment processor (aka pixel processor).

Les vertex shaders permettent au programmeur de ´court-circuiter´ les traitement standard effectué par l´API et la carte gfx sur les vertices et les remplacer par un programme a ta sauce, completement presonnalisé traitement géometrique et illumination des vertices a gogo.
Ca permet de decharger le CPU en tache, et donc d´avoir de bonnes perfs pour des "arse-kickaz FX"
I.e: tweening, morphing, modif dynamique des matrices de projection, anim locales des objs, particules (miam) et autres illuminations complexes.

Les pixels shaders permettent au programmeur de controler la partie lié a l´imagerie relative au pixels transparance, mélange et plus sournoisement convolutions/filtres, traitements d´illumination, manip des textures realtime et effet de couleurs les plus extravagants..
I.e: effets de profondeur, volumtric fog, ombres locales, cell shading, effets de peinture et calcul de textures realtime...

A la base tout ça c´etait en langage ´assembleur´ et pas très pratique. Debugger un gros shader en assembleur devenait vite du "cutting edge" comme dirait les gars de la Silicon. Bref un truc horrible, méchamment puissant mais a courte durée de vie etant donné le ratio de difficulté et les boites d´aspirine a la ligne de code. Heureusement ! Nos amis Microsoft et Nvidia travaillèrent main dans la main pour creer le Cg et le Ms HLSL. Langage haut niveaux qui permettent toussa, sans trop se casser la tete. D´autant plus qu´avec les tools d´aujourd´hui ça devient incontournablement la source de tout effet qui se respecte dans tout bon block buster du game dev ^^

Pour plus d´info cf la doc nvidia, microsoft et opengl dispo respecitvements dans les SDKs et le site web de SGI..

voilou j´espere t´avoir eclairé sans avoir trop dit de baitizes...