Common updated standard Engine.u
Posted: Sun Feb 14, 2016 2:06 am
While I'm no fan of modifying vanilla code package as this especially in case of the DeusEx.u leads to a huge amount of incompatibilities and even prevents the usage of native subclasses of native classes out of DeusEx.u, because it's common to oversize them.
However on the Bitmap and Texture class there is a decent amount of space left blank due to alignment, so one could add serveral byte (or enum) variables to it. One of the most desired features would be to be able to set wrapping mode for textures, especially using clamp for certain textures as especially anisotropic filtering can result in more quite a few pixel values fetched off the wrong side and thus causing annoying lines at the side of textures. Especially some fractal texture like flames should ideally have UWrap=VWrap=TEXW_Clamp set, so there is never some wrapping around for those.
The big advantage is that one doesn't need to introduce any new classes (especially you won't need extra subclasses for FireTextures, etc. etc.), old texture packages stay compatible with the new updated Engine.u, while you won't get more then a warning when loading it with an old Engine.u, though if you resave the texture packages with the old Engine.u, these properties get lost.
On the render device side, you can just easily apply/fetch these settings when unpacking the texture. Afaik they would even be initialized as zero when using the old Engine.u, and as TEXW_Repeat equals zero which is the old behaviour nothing would break. However, one can basically do a check once in the renderdevice if the properties do exists (and optionally also query their offset).
Another interessting idea would be to introduce a Type property to add support for non 2D textures, especially cube map textures (and use these to do proper enviroment mapping).
As for generating cubemaps, it should be rather straight forward to add a command for taking the required six screenshots ingame and saving them, and would certainly look on the helicopter in the Mj12 hanger.
In any case, Rajada and me will use these in our Nerf 300a update, maybe I can show some proper environmapping screenshots soon.
So any thoughts on having a new standard Engine.u?
However on the Bitmap and Texture class there is a decent amount of space left blank due to alignment, so one could add serveral byte (or enum) variables to it. One of the most desired features would be to be able to set wrapping mode for textures, especially using clamp for certain textures as especially anisotropic filtering can result in more quite a few pixel values fetched off the wrong side and thus causing annoying lines at the side of textures. Especially some fractal texture like flames should ideally have UWrap=VWrap=TEXW_Clamp set, so there is never some wrapping around for those.
Code: Select all
var(Texture) const enum ETextureWrap
{
TEXW_Repeat, // That's whats currently done (GL_REPEAT).
TEXW_Clamp, // Thats what i desire (GL_CLAMP_TO_EDGE).
TEXW_MirrorRepeat, // Probably has it's uses though (GL_MIRRORED_REPEAT).
TEXW_MirrorClamp, // Probably has it's uses too (GL_MIRROR_CLAMP_TO_EDGE).
} UWrap, VWrap;
On the render device side, you can just easily apply/fetch these settings when unpacking the texture. Afaik they would even be initialized as zero when using the old Engine.u, and as TEXW_Repeat equals zero which is the old behaviour nothing would break. However, one can basically do a check once in the renderdevice if the properties do exists (and optionally also query their offset).
Another interessting idea would be to introduce a Type property to add support for non 2D textures, especially cube map textures (and use these to do proper enviroment mapping).
Code: Select all
enum ETextureType
{
TEXT_2D, // 2D texture.
TEXT_3D, // 3D texture.
TEXT_1D, // 1D texture.
TEXT_CubeMap, // cube map texture.
} Type;
In any case, Rajada and me will use these in our Nerf 300a update, maybe I can show some proper environmapping screenshots soon.
So any thoughts on having a new standard Engine.u?