# Radeon loses TexCoords in VP (kinda solved)

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Givin any of my VP's I have, My Radeon9800 just seems to "Forget" that I gave it texture coords while my GeforceFX runs them fine. [crying] heres an example of a VP I tested
!!ARBvp1.0\n
ATTRIB OriginalPos	= vertex.position;\n
ATTRIB Color            = vertex.color;\n
ATTRIB Texture          = vertex.texcoord[0];\n
\n
OUTPUT OutPos		= result.position;\n
OUTPUT OutColor		= result.color;\n
OUTPUT TexOutA	        = result.texcoord[0];\n
OUTPUT TexOutB	        = result.texcoord[1];\n
\n
PARAM ModelViewProj[4]  = { state.matrix.mvp };\n
\n
# Transform point\n
DP4 OutPos.x, ModelViewProj[0], OriginalPos;\n
DP4 OutPos.y, ModelViewProj[1], OriginalPos;\n
DP4 OutPos.z, ModelViewProj[2], OriginalPos;\n
DP4 OutPos.w, ModelViewProj[3], OriginalPos;\n
\n
# Copy Data to final output\n
MOV TexOutA, Texture;\n
MOV TexOutB, Texture;\n
MOV OutColor, Color;\n
END


Ive toyed with this for more then 4 hours, and Ive tried new drivers in an attempt to try to find WHY its doing this, and frankly im rather angry with it at the moment [evil], so I thought I would ask, Has anyone else seen this happen, and if so how did you fix it? or if anyone has any ideas on how I could try to fix it, perhapes I didn't think of something. im quite desperate. PS: it runs fine on the radeon if i just turn the VP off, and use a vertex array to feed it the texture coords for both unit0 and unit1. but if I enable Vp's its bad. any help would be vastly appreciated. Edit:(Changed Thread Title) [Edited by - Xero-X2 on December 16, 2004 8:20:46 PM]

##### Share on other sites
please post the code you use to setup the system for drawing (allocation of arrays, enabling, telling gl what they are etc) and the drawing its self

Its gonna be something you've done, the chances of this kinda bug slipping past all this time is pretty slim tbh [wink]

##### Share on other sites
Have you tried skipping mnemonics, for instance replace :
MOV TexOutB, Texture;
with :
MOV result.texcoord[1], vertex.texcoord[0];

##### Share on other sites
Quote:
 Original post by _the_phantom_please post the code you use to setup the system for drawing (allocation of arrays, enabling, telling gl what they are etc) and the drawing its selfIts gonna be something you've done, the chances of this kinda bug slipping past all this time is pretty slim tbh [wink]

hard to do as its in a program with a couple other 12,000 lines of code, but I'm working on it, once I extract it and get it running by itself I'll post again to note all init steps and such.

Quote:
 Original post by vincoofHave you tried skipping mnemonics, for instance replace :MOV TexOutB, Texture;with :MOV result.texcoord[1], vertex.texcoord[0];

tried it, has no effect.

##### Share on other sites
Ok when I remove the code so it runs alone, It all works fine. so, now Im kinda back where I started, cept now we know its not some kind of driver error for certain. so, any ideas on how to find what state in opengl would cause this? any niffty OGL debuging tools that give you a print out of all the current states or something? *is hopeful* any way, I'll go back and see if I can isolate it some how. thanks for the ideas thus far.

##### Share on other sites
I've used glIntercept to log the OpenGL calls to track down errors, it can be used in a mode where it only logs one frame, which should be helpfull to you

##### Share on other sites
Quote:
 Original post by _the_phantom_I've used glIntercept to log the OpenGL calls to track down errors, it can be used in a mode where it only logs one frame, which should be helpfull to you

thanks for the link, i'll try it out.

Ah, another update on my progess, and its pretty much the end of the road till I know why this is happening, Im creating Pbuffers and useing wglShareLists to share the information between my main context and pbuffers, so does anyone know why this would cause it, if i comment the wglShareLists out it runs fine, except for when it needs to render to the pbuffers at least.

so, Why would wglShareLists do such a thing? *Runs of to continue his work*

##### Share on other sites
ordering of the hdc wrong in the function call?

##### Share on other sites
I dont think so,
wglShareLists(MainhRC, PbufferHRC);
where
bool wglShareLists(HGLRC hglrc1, HGLRC hglrc2); hglrc2 needs to be empty, so I think ive got it right. plus if I switch the order vertex shaders dont work at all, prolly cause they are init'ed before the Pbuffers are made... could that be a problem? I wouldn't think it would be, sence pbuffers are designed to be destoryed and recreated when being used and not being used however I guess I could be wrong, but I belive I read the extention specification right

##### Share on other sites
Hmm some new information, It works perfectly fine if I init my Fragment and Vertex Progs after I setup my Pbuffers [crying] but thats a horrible limitation, tho I am only useing a few set Pbuffers, its still a limiation.

edit: spelling errors

##### Share on other sites
hmmm did I read that right and that you are creating and destorying pbuffers as you use them?
I'm not convinced thats the best way to go about it, each time you create you making a new context, its probably better to create a couple of contexts on startup and reuse them as needed (and pray a proper render-to-texture extension appears soon... )

##### Share on other sites
Sorry for the misundrestanding, Im not doing it personally, but Pbuffers are designed to beable to do that. at least thats what I belive the specification stated

I use my allocated pbuffers consistantly every frame so I would have no need to destory them.

Quote:
 Original from OpenGL Extension Registry Note that pbuffers use framebuffer resources so applications should consider deallocating them when they are not in use.

##### Share on other sites
yeah, you can free and recreate them as needed, however in a game situation its pretty safe just to reserve them up front and leave them around until you dont need them for a prolonged period or until the game ends [smile].

Granted, it is possible that the driver could well reclaim the pbuffer for some reason (most RTT code I've seen has a check to make sure the pbuffer is still alive), but i've never seen it happen and i dont know why it would (I guess it could happen if you create all your contexts, delete them and recreate them (say to change screen res) and dont indicate you have done so...