SetTextureStageState( 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1 );
SetTextureStageState( 0, D3DTSS_COLORARG1, D3DTA_TEXTURE );
SetTextureStageState( 0, D3DTSS_COLORARG2, D3DTA_DIFFUSE );

SetTextureStageState( 0, D3DTSS_ALPHAOP, D3DTOP_MODULATE );
SetTextureStageState( 0, D3DTSS_ALPHAARG1,D3DTA_DIFFUSE );
SetTextureStageState( 0, D3DTSS_ALPHAARG2, D3DTA_TFACTOR );

This will make the colour come from the texture entirely, and the alpha from the vertex modulated by the texture factor.

Stay Casual,

Ken
Drunken Hyena

I haven''t tested this, but at 4am it looks good.

Add:
SetTextureStageState( 1, D3DTSS_COLOROP, D3DTOP_SELECTARG1 );
SetTextureStageState( 1, D3DTSS_COLORARG1, D3DTA_CURRENT );
SetTextureStageState( 1, D3DTSS_COLORARG2, D3DTA_DIFFUSE );

SetTextureStageState( 1, D3DTSS_ALPHAOP, D3DTOP_MODULATE );
SetTextureStageState( 1, D3DTSS_ALPHAARG1,D3DTA_CURRENT );
SetTextureStageState( 1, D3DTSS_ALPHAARG2, D3DTA_TEXTURE );

This assumes your card can do multi-texturing. Otherwise you''ll have to pre-combine your TFACTOR with your vertex alpha by doing a Lock/modify/Unlock combo.

Stay Casual,

Ken
Drunken Hyena

Most cards will support 2 stages. The best thing to do is check the CAPS at startup and if it doesn''t support 2 stages, you can either use another code path (pre-combining the TFACTOR into the diffuse alpha, which will be a lot slower) or you can gracefully exit and tell the user their card isn''t supported.

Obviously the seperate code path is the most friendly approach, but it will take more work from you. If this is something you want to release (especially for sale) then it''s prolly best to cover as many bases as you (reasonably) can since pro developers typically ignore this part of the market which makes it a good target for indie developers.

Stay Casual,

Ken
Drunken Hyena

To add to what DrunkenHyena said - checking the caps should always be the first line of tests in your program to determine the *rough* feature set of the chip.

With multitexturing setup, after you''ve determined *rough* support you should set up all the states and textures you intend using and call ValidateDevice() to check that the *combination* of states, textures etc will work together.

For (hypothetical) example a chip might expose D3DFMT_A8L8, but may have a restriction that you can''t have D3DTSS_COLOROP set to say D3DTOP_ADD while D3DRS_FOGTABLEMODE is set to D3DFOG_LINEAR.

The same chip may expose caps to say it can do all of the above - but due to it''s hardware design might not be able to do them together!.


What our engine does at startup time (after caps checking) is to set up the renderstates and texture stage states for each of the "shaders" (programmable and fixed function) the game uses and set dummy textures of each format we intend on using before calling ValidateDevice() - the return code from ValidateDevice determines how the engine decides to scale the effect down.

quote:If this is something you want to release (especially for sale) then it''s prolly best to cover as many bases as you (reasonably) can since pro developers typically ignore this part of the market which makes it a good target for indie developers.

Pac-Man:Adventures In Time (Creative Asylum/Hasbro/Infogrames) supports everything down to 2Mb graphics cards without hardware acceleration. I learnt a lot about writing scalable 3D engines doing that (some of it painfully ).
[It''s a shame Infogrames haven''t done anything with it since it''s release - I''d love to be able to release the ''enhanced'' version we were doing for nVidia - from 2mb in software up to bump mapping and envmapping]




--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com