srmeier
N3TexViewer GTT Files
This atleast displays the first index of GTT textures.
Pull request type
N3Texviewer it doesn't seem to recognize #ifdef _N3TOOL but I just went with the flow and edited where it would stall.
Please check the type of change your PR introduces:
- [x] Bugfix
- [x] Feature
- [x] Code style update (formatting, renaming)
- [x] Refactoring (no functional changes, no API changes)
What is the current behaviour?
Doesn't open GTT file's because it checks for the extension
What is the new behaviour?
Checks both extensions and displays them in the file dialog Not sure if I should use a second & reference when checking for the extension type.
Why and how did I change this?
Pretty obvious 2 line's of code.
Demo
Checklist
- [x] I have performed a self-review of my own code.
- [x] Where applicable, I have checked to make sure that this doesn't introduce incompatible behaviour with the official 1.298 server (e.g. unofficial opcodes or behavioural differences).
- [x] I have checked to make sure that this change does not already exist in the codebase in some fashion (e.g. UI already implemented under a different name).
I feel like it's a bit misleading for it to be able to load the file, then only load the first of the 8 textures contained within. Likewise when it goes to save.
Perhaps the extension check can be moved back up into N3TexViewer, so it can treat them specially, be it by staging them all into the resulting texture or having an option to flip through them. CN3Texture::LoadFromFile() is just useless for loading more than 1, so there's really no point in doing it there.
Was thinking about it myself. But the n3tool def didnt even kick in and since I had needed it thouvht I would just do it like this.
Most likely you were doing it in the context of the base N3Base project. It wouldn't see _N3TOOL there, only from the N3Base_tool wrapper project. It should behave, even though it doesn't show it.
I feel like it's a bit misleading for it to be able to load the file, then only load the first of the 8 textures contained within. Likewise when it goes to save.
Perhaps the extension check can be moved back up into N3TexViewer, so it can treat them specially, be it by staging them all into the resulting texture or having an option to flip through them. CN3Texture::LoadFromFile() is just useless for loading more than 1, so there's really no point in doing it there.
I see. Can try to move that logic up a level to N3Texviewer. To call 8 sections of the file, either by unpacking them in the MFC content, or splitting them in memory. Memory->header offset load file. Or have a skipfilehandle maybe like client does with tiles display them either with auto resize/tile or add left right button. Did I completely misunderstood what you meant?