Just curious why the materials where changed into different classes. Was this a performance issue design, or what?
Thanks.
Engine Changes question
I think this is what he means:
changes.txt wrote: Changes in version 1.4 (... 2007)
- Major API change: All material properties which are available per texture layer (curently texture, texture matrix, texture filters, and texture wrap mode) are separated into a new struct SMaterialLayer. You can access them via the array TextureLayer[] in SMaterial. The texture matrix methods in SMaterial are still alive, and also textures can be accessed via methods in SMaterial now. But still, many places in user code need some update (usually changing material.Textures to material.TextureLayer.Texture etc.)
You'd have to ask hybrid for a definite answer, but I'm pretty sure my guess is correct. The change was likely made to simplify the SMaterial implementation a bit, and to address some seperation of concerns type issues. SMaterial was getting complicated trying to manage the texture matrices, and it is a logical split to seperate the layers out into their own type.
If you use the public methods of SMaterial, instead of accessing the public members directly, you should not be impacted by the change at all.
Travis
If you use the public methods of SMaterial, instead of accessing the public members directly, you should not be impacted by the change at all.
Travis
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Eh, yes, Vitek is right. There are still some things which will have to be added to one of the structs in the future, so just one struct would grow into a complex swamp. Moreover, there had been so many arrays which were all defining just one property of a larger thing - the layer material properties.