I strongly advocate erradicating every trace of spheremaps, and making a decisive switch to cubemaps, burning the bridges behind. There is no practical need to support spheremaps, as hardware vendors have supported cubemaps for a whole decade, already. I managed to win Klauss to my point of view; not sure if I've succeeded with Safemode. The only real problem, IMO, is getting a windows binary. I would hate to have to delay the official inauguration of dds cubemaps because we can't offer them to Windows users. On the other hand, I would hate even more to have to have two sets of shaders, and to make cubemaps a configuration option.JsnMtth wrote:That seems like an excessive amount of "configuration" to expect an end user to have to do. It would be better IMO to have the program load a different shader when cubemaps are enabled and the shader in use is highend. Another option is to enable cubemaps in the configuration file, instead of using the preprocessor flag. This is of course assuming we're going to support bother cubemaps and spheremaps. If we're not going to support them, then it doesn't matter how we make the transition. Eventually everyone uses cubemaps, the spheremaps code and shaders disappear.
Well, this amounts to having a non-windows branch until windows can catch up. The problem has nothing to do with cubemaps, really; rather with our inability to compile for windows. But it's probably the least of all evils, tho.Can Windows users use the development data with the last binary that was built? Because they can't build a binary at the moment telling them to compile it won't work. If they can use the development data, then committing cubemap shaders to trunk is a bad idea. They won't be able to use new models and such that don't depend on cubemaps. A cubemap branch would need to be created and the cubemaps change committed there. Then when the cubemap code works on all the "supported" platforms, it can get merged into trunk.
EDIT:
Yeah, I think what we should do is create a Windows tag; NOT a cubemaps branch; a Windows compilation problem addressing freeze-point.
Why?
Because, again, the problem is un-related to cubemaps; and it will rear its ugly head again with the next feature, and the next.. Until we can
compile for Windows again.
So the correct modeling of the problem is to just have a Windows branch for /data which only gets updates that are compatible with the current
Windows binary.