CustomTexture: Drop old texture format. #4453
Conversation
|
Have you been satisfied with comments on the forum? Are you ready to get this reviewed and/or merged? We really need more for the progress report... |
|
@MaJoRoesch I'm not sure. This removal has no technical reason, it's more a political one to force custom texture maintainer to convert their packs. Converting the pack however has technical reasons. |
|
@degasus please rebase this. |
degasus
force-pushed
the
custom_texture
branch
2 times, most recently
from
ae4fd9a
to
d89f4bf
Compare
There was a problem hiding this comment.
LGTM otherwise. If this goes ahead, perhaps we should consider adding a notice in the progress report and/or release notes for the next stable version describing the impact of the changes. Two stable version releases (deprecated in 5.0, dropped in 6.0) sounds reasonable to me for a feature like this.
| return name; | ||
| } | ||
| } | ||
| if (!dump && !s_check_new_format) |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
degasus
force-pushed
the
custom_texture
branch
from
d89f4bf
to
a5a0599
Compare
|
Why is this even a pull request? It seems pointless to do this when it was fine the way it was. Especially when people had... you know... an OPTION to convert or not. This just makes work. |
|
@AlexS2412 We have switched our custom texture format 3 years ago. The old one was still supported for 3 years for legacy reasons. There was even an automatical converter from the old format to the new format. The idea was to drop the old format after the 5.0 release, but we've kept it a lot longer. And there are good reasons to not use the old format any more: Deduplicated paletted textures, faster hash, fewer hash errors, no dependency on the texture cache accuracy... |
The stable release 5.0 has a built-in converter between this formats, so there is no need to keep the old format in current development builds.
This change is