Backwards compatible multi texture support in pms format. #80
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Soldat portion of PMS multi texture support tested as working with multitexture_ctf_Ash.pms from here: multitexture.zip
I made the map with a janky test program which is also attached (run with
fpc MapFile.pas && ./MapFile SomeRandom.pms, it will apply different textures to the polies).To store the additional texture filenames it reuses the
Sceneryarray like helloer suggested in #79, I think this is the best option. Adding another array at the end of the file seems fragile, and PolyWorks is putting some data about lights and sketch lines there so that approach would probably wind up ugly.To distinguish between scenery and textures in that array I'm checking for a long prefix ('SOLDATTEX_') on the filename. This works but reduces the max number of characters for texture filenames. It would be better to use a sentinel value of the
DateonTMapSceneryif one exists but I haven't looked into that yet.For the per-polygon texture indexes it uses first byte of
TMapPolygon.Normals[1].z. None of the normal z coordinates are used so this should be fine. If the map only has one texture, every polygon's texture index is set to 0 like it was before for backwards compatibility.I'd like to try and use a
Datesentinel, and figure out what a good value forMAX_TEXTURESis, or if we should have a limit on that. When those things are resolved this will be good to merge.