Skip to content

Conversation

@UTengine
Copy link
Contributor

@UTengine UTengine commented Aug 22, 2025

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:

  • Bugfix
  • Feature
  • Code style update (formatting, renaming)
  • 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

imageimage
image

Checklist

  • I have performed a self-review of my own code.
  • 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).
  • 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).

This atleast displays the first index of GTT textures.
@twostars
Copy link
Collaborator

twostars commented Aug 22, 2025

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.

@UTengine
Copy link
Contributor Author

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.

@twostars
Copy link
Collaborator

twostars commented Aug 23, 2025

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.

@UTengine
Copy link
Contributor Author

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?

@selcukcukur
Copy link
Contributor

@UTengine Necessary changes should also be made in these parts for the GTT format. Additionally, a review is required because texture files cannot be rendered in the alpha version, so it is worth examining the reason.

if(lstrcmpi(szExt, ".dxt")!=0) return false;

if(lstrcmpi(szExt, ".DXT") == 0) // 확장자가 DXT 면 그냥 저장..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants