I think is overkill to mantain informations on texture origin only for this. All calls to texture injection API already pass (or should pass) a read/write flag as parameter. I have been thinking of logging messages as soon as a texture is requested to be readable but is not; i have decided against it for now for two reasons:jimfcarroll wrote: ↑Thu Sep 19, 2019 2:17 pmThanks for the explanation. That makes sense.
Perhaps I could automate determining which ones require it. Any texture passed to PackTextures here:
https://github.com/Interkarma/daggerfal ... er.cs#L423
... fails if the read/write flag isn't set. The problem is, the context of which textures are passed there (that is, their origin) is lost by the time that call is made, so I can't track where the textures originally came from without some changes. Would it be worth doing that?
- Unlike new Unity versions, current one doesn't expose this flag at runtime. You need to execute an operation that requires it and catch the thrown exception to detect it, and this comes with a performance cost.
- There are still a few situations where a texture is requested to be readable but is actually not necessary. This can be optimized over time but i prefer to solve all of them before logging incorrect warning messages.
If you mean doing that at run time, it is not possible. The whole point of Read/Write flag is to have the ability to read the texture at run time.jimfcarroll wrote: ↑Thu Sep 19, 2019 2:17 pmAlso, would it be worth programatically setting the read/write flag in places like that call. I know this isn't trivial and if it's possible, probably requires something along the lines of rewriting the texture to disk then using editor functionality to change the flag, then reloading them.