BD fixed a bug that creates a potential bug for some CC

Neverwinter Nights 1 Enhanced Edition
1

In the latest stable release, Beam Dog fixed a bug whereby custom TGA files in Haks and the override would overwrite vanilla DDS files. The toolset still points to the old NWN directory which means that it displays vanilla TGA rather than vanilla DDS textures.

However, it turns out that a ton of custom content on the vault (e.g. CEP & Project Q) uses TGA rather than DDS to reskin vanilla assets.

The answer it seems to me is to patch our CC with DDS textures and/or to rename the TGA reskins.

Note I have not done an exhaustive check to validate this, just the Project Q shields I was using. But I did report a bug which Greg was kind enough to explain in detail why it was really a Toolset bug and not a game bug.

Oh, and a temporary workaround is to put the TGA assets in the development directory. Greg was “shocked” (his words) that the dev dir would do that. Hopefully he’ll fix that bug.

1 Like
2

I’m not sure I’m parsing your first paragraph right. What I think you are saying is that beamdog just broke everything by making DDS higher priority than TGA first (through the whole resource hierarchy). Not sure how that is backward compatible… I though they were supposed to not break CC. That seems like they introduced a bug rather than fixing one.

Redoing all the textures in all the CC to be DDS seems bogus. If I recall the DDS format in NWN is not even real DDS and you need special tools that can handle it. Or maybe I’m mistaken about that, I was never good with models and textures.

1 Like
3

Here is what Greg wrote:

Issue #41157 has been updated by Greg Holmes.
Status changed from Submitted to New
Category Original Content added

Hey guys,

iit_medkit_001.dds is a vanilla game texture in the xp2_gui, GUI_32bit, and XP1_GUI texture pack erfs.
If you “turn off” your texture packs by switching to “16 bit compatibility mode”, which is just a setting to load all vanilla files without the “extra high resolution awesome files for people with graphics cards”, you will see your hak texture appear.

This is somewhat known/default/intended behavior. What is going is that there is a final list of all of the files in the game, and your TGA file replaces the stock iit_medkit_001.tga since there can’t be multiple files loaded to resman with the same filename. Then in the 3 different .erf files, the iit_medkit_001.dds replaces itself twice, it first shows up in GUI_32bit.erf, then that gets replaced by the .dds of the same name in XP1_GUI.erf, then that gets replaced by the .dds in XP2_GUI.erf.

That leaves you with 2 final files, that have different file names, and are both in the final “I am playing right now” version of the game. Given the choice of the two, the renderer chooses the .dds file, and your texture is unused.

I’m a little shocked that the development folder allows you to overwrite a .dds with a TGA, actually, so I guess we all learned something here today.

Solutions for you:

  1. Use a .dds and it will overwrite the stock .dds in the texture packs
  2. If you don’t want to use the vanilla iit_medkit_001.dds, you can add your .tga as iit_medkit_002.tga, and it will be available as a new icon for medkits.
  3. If you don’t want to use a DDS, and you want to convert all of the existing medkits, you can change the baseitems.2da row 39’s ItemClass from “it_medkit” to “it_mykit” or something. All items of the baseitem “39” will use a new “iit_mykit001” .tga or .dds or whatever.
  4. Ask everyone to turn off their texture packs. (Not really ideal)

Hope that helps!
Greg

4

My understanding is that now DDS takes priority over TGA only when there are duplicate file names. We can still use TGA when there is no conflict.

Whereas previously, a hak, override, or patch-hak would usually override a DDS with the same file name. Note that this wasn’t consistent in 1.69.

Now is this good or bad? I’m of two minds here. On the one hand, I like having DDS take priority over TGA consistently. However, I also like giving the power to the builder (haks) and ultimately to the player (override & patch-haks) even if that means overriding a DDS with a TGA.

Now I have to go back through Project Q and rename all the overwriting textures (shields, etc.).

5

I’m hazy about this, but didn’t .dds always trump .tga?

6

DDS was always supposed to trump TGA. But there was some exceptions in the past.

Just now I tried to recreate some of those exceptions on 1.69 and was unable. So I have edited the headline to dial back the hyperbole.

What really bugs me though, is that the Project Q shield inventory icons are tga when they should be dds. I thought for sure at some point they worked, either in a previous EE version or in 1.69. They fail in 1.69 and I can’t test earlier versions of EE.

Years ago there was some issues with pseudo-dragon and kobold overrides that had both tga and dds. One worked in the override and the other in a hak. We had a big discussion about it in either the original Bio Board or the 2nd one. I can’t recall the details and I don’t want to bother digging up those textures to test them.

So for now, let’s consider this fix a good one. After all, DDS was always supposed to trump tga. We can always revisit this if someone can dig up the original discussion.

I must be getting old…!

7

The explanation on redmine is slightly off, but there is no bug here. In 1.69 the (typical) texture load order was:

DDS in override
TGA in override
DDS in ERF (hak, patch-hak, texturepack)
TGA in ERF (hak, patch-hak, texturepack)
DDS in BIF
TGA in BIF

In EE, it is:

KTX in directory (development, override)
DDS in directory (development, override)
TGA in directory (development, override)
KTX in nwsync
DDS in nwsync
TGA in nwsync
KTX in ERF (hak, patch-hak, module (sp only), texturepack)
DDS in ERF (hak, patch-hak, module (sp only), texturepack)
TGA in ERF (hak, patch-hak, module (sp only), texturepack)
KTX in bif
DDS in bif
TGA in bif

(KTX is a mobile friendly new texture format)

So the relative ordering has been preserved. Note that this is the most common case, but there are exceptions, of two types:

  1. In some cases, certain types of textures are skipped. For example, some GUI items must be TGA.
  2. In some cases, typical resman hierarchy is respected (development>nwsync>hak>module>override>texturepack>bif)

It is also possible that 1 and 2 are combined in some cases - e.g. if a server ever needs to check the existence of a portrait, it will only search for TGA, in resman order. However, since this is a check for existence only, the order does not really matter, so long as all the places are searched.

What you are seeing here @Grymlorde is that when your TGA is in override (or development) it is trumping the DDS in an ERF (texturepack). But once you put your TGA in an ERF (i.e. a hak), then DDS-in-ERF trumps TGA-in-ERF. You didn’t see the issue in the toolset because your toolset didn’t load the texturepack ERF, so it only had the TGA in the bif.

Other notes:

  • PLTs, TXIs and MTRs are typically loaded in resman-order, not texture-order
  • Bioware added another texture format that sits between DDS and TGA. It is entirely unused.
5 Likes
8

I am Greg and even though I’ve been correcting people about this for years, I now see I was probably wrong 20% of the time, and in this specific case, I am wrong and Sherincall is right about the parts he points out.

I think the behavior has just been… obscure and mysterious, with a lot of false information floating around and false positives as well, so it is nice that we have renewed development to end the guessing games.

Though I will contend that even for “UI” textures like icons and portraits, DDS is still a superior format for shipping than for TGA, which I had been reserving for sources and prototyping stuff only (and the occasional need for very very specific cases of 256 shades of color being required per channel), but these days I end up maintaining sources as .png and converting to DDS to test in game, since using normal DXT1 and DXT5 instead of Bioware DDS makes that part real easy.

2 Likes
9

@clippy my head nearly exploded at that point… but it’s good to understand at last that the rule for textures is different from the typical resman hierarchy.

10

This remind me, the bug with mobile devices not being able to render DDS textures is fixed already? If not, how do I fix it? Converting to tga means huge extra download size…

11

I don’t remember what the bug is exactly, but it’s only a special type of DDS textures, that happened to be used by a lot of the CC. I think it has something to do with the Alpha channel having a higher resolution than the others. @Symphony might know better.

But you can convert over to other type of DDS, or KTX.

Oh, also, @meaglyn:

If I recall the DDS format in NWN is not even real DDS and you need special tools that can handle it.

I think EE supports standard DDS types in addition to nwnDDS. It only supports a few of the compression formats of the standard DDS (DXT1 and DXT5), but it should not need special nwn-only tools.

1 Like
12

I tried to convert to TGA and then back to DDS but it did not fix the issue.

If I convert it to KTX and leave only KTX for use, will it work for all users no matter of device/OS type?

13

I think so? Haven’t tried, but technically the desktop game should support KTX.

14

@meaglyn NWN:EE now supports Bioware DXT1 and DXT5 (That’s RGB and RGBA), along with “Industry standard” DXT1 and DXT5.

In previous patches I could have sworn that the alpha channel of DXT5 was being ignored (opaque textures), but I checked a few days ago, and it seems to be working fine.

These “industry standard” DDS exports can be created with a plethora of image tools. “Crunch.exe”, which does have somewhat-hard-to-find earlier versions with unix binaries, is very flexible. Gimp 2.10, which is cross-platform, has built in block compression encoding on export to “.dds”.

The .ktx container format can be used in NWN to encode/decode ETC2 textures, though, I believe that ETC2 is compatible with any android device that can run the game, but not necessarily compatible with all graphics cards that can run the game, since it’s decoding is part of “OpenGL ES 3.0” and “OpenGL 4.3”. There are likely a decent amount of NWN:EE players that do not have OpenGL 4.3 compatible graphics cards (I used to be one of them), and the official minimum requirement on Beamdog’s Store page is OpenGL 3.0.

@Shadooow the mobile version hasn’t been updated, so nothing has been fixed there. However, after looking into this problem last year it did not look to me what everyone has been saying, that the Mobile version was unable to use DXT textures, and only able to use ETC.

What I found was that both formats were supported, and neither formats were delivered and loaded through NWsync. NWsync managed to serve and load TGA’s, but not DDS’s, and I haven’t seen people putting KTX’s (ETC2) in their NWSync. Which is fine, because I don’t think it would help anyone. BUT putting KTX’s in NWsync also did NOT work through NWsync.

In the event that someone was somewhere where they were using NWsync delivered and loaded assets, and could not see DDS (or KTX) textures, placing the DDS (or KTX, preferably, in this case) in their override folder allowed them to be served by the models that requested them, and the play experience was normal.

ETC2 compression, through crunch.exe, seems to take far far longer than .dds textures do, but it is a pretty cool encoding format, and I wish it was more widely adopted.

DXT compression, on mobile NWN, as .dds textures, is not supported by the mobile graphics processor, so it requires conversion at rendertime, I think, but the people who have playtested for me with DDS textures have not noticed serious performance problems or even noticeable decreases from this conversion, so, I’d probably only urge the use of “mobile only” KTX textures if you plan on making an extremely high definition high poly non-NWsync mobile single player experience, in the 8186 toolset, so that it will be compatible with the “not yet updated” mobile client.

For just about anywhere else, the crazy long encoding time, combined with the uncertainty of clients being able to use the textures, makes the ETC2 .ktx format nearly useless for us in NWN:EE, as far I have decided.

I may look at it later as a possible higher-bitdepth data-map texture candidate (normal maps with more than 32 shades of red and blue), but that might be a an issue solved by a 3rd and 4th type of DDS.

1 Like
15

@Symphony do you have a link to the hardware requirements for Android? Can’t seem to find them for some reason.

Slightly off topic… do you happen to know whether the OpenGL version issue is the reason for the lighting issues on Google’s Pixel C? I read that it uses the open source version of OpenGL ES 3.0 instead of the nVidia version.

16

@Proleric all I could find is https://play.google.com/store/apps/details?id=com.beamdog.nwnandroid

Which indicates that it requires Android OS 5.0

I don’t have an Android device to experiment with, or know more about, unfortunately. I’d like to some day, but, given current financial issues and the current Android NWN situation, it will have to wait.

1 Like
17

I think I ran into this, I have an old module I was updating for NWNXEE, and works fine in NWN 1.69. But NWNEE causes the building placables (NWN2 buildings) to not display. Not just invisible, but I can walk through them. I do see a floor only of one, but the rest is simply not there…

It uses NWNcq, maybe I just need to update the version, it’s very old.

18

Drat, it’s old because it’s never been updated. Anyway to fix it? Or should I find a newer hak and replace all of the placeables in the module? Any newer haks with the NWN2 building models I could use instead?

19

There are some NWN2 buildings in CEP. I’m using several of them without issues in EE. Several of them have no walkmesh (in both EE and 1.69) which I work around with placeable blockers.

I don’t recall seeing any placeables vanish entirely. Have you tried removing NWNCQ temporarily?

20

Eh, I’m using the MAnor house from NWN2 and some other items, probably in CEP. I’m trying to tie it up so I can release it for others (it’s not really complete, but it’s pretty interesting as a starting point for NWNXEE. Can’t see this stuff in NWNXEE, this pic is from 1.69…

image
image2517Ă—1370 1010 KB