been working on a texturefx script for some time now, and while implementation works well on ati or nvidia cards, there is a bigger issue with a friend’s laptop card.
now when trying to find workarounds for his card I stumbled upon following problems:
the drivers support ARB_multitexture and EXT_tex_env_combine
display lists: cannot alter texcoords via texmatrix of mtex units (set before list is called, and list doesnt contain any texmatrix calls)
texgen: will always use the “last” texgen mode for all mtex units. (e.g. let first be normal texture coords and last is SPHEREMAP, then both textures are drawn with spheremap)
texmatrix: LoadIdentitiy eventually doesnt work, need to call a "scale with 111 and rotate with 0… to make sure nothing is changed.
doesnt seem to affect ALPHA Buffer (e.g. in first pass rendered the image with modified tex matrix, and in second pass using DST_BLEND, the position of the “alphas” is as if no tex matrix change was done in first pass)
texcombine: CONSTANT is all black
now with those problems (no issues on tested ati or nvi hardware), I wonder how do you actually know what you can expect to get on hardware and when to do it the safe way
like not using texture matrix but do it yourself and use texcoord arrays for all mtex units.
but how do you find out that e.g. CONSTANT isnt working on someones card ? Ask the user if he sees the effect ?
Hence I wonder, is it the “best” and most “reliable” way to do most things manually, ie. memcpy vertex data into a “render array” and then do texgen stuff manually yourself and flush that render array.
or use the “fastest” things you can get and hope that it works (display lists…) ?
it looks like one needs to create almost vendor specific renderpipeline and when you go beyond ati/nvi, its practially almost “ogl 1.1 only”
anyway it’s pretty interesting to see how different implementation on hardware is, kinda no surprise why gamedev loves consoles hehe
just am a bit frustrated after the long work being crushed by that laptop, needed a place to vent
but well since I am not as experienced as most people here are, I wondered what “backup path” exists, and how the pros deal with the multihardware issues…
is it like vendor specific pipelines and one pipeline for “worst scenario” or one pipeline which hopes to work best for most …
like how far back do you go when supporting older hardware, or is it just a “bad luck” for the user if his card&driver isnt doing what it should ?