high res textures overlapping custom texture in fan wads

gary

Yeah, I notice this problem still exits. for example, if you have the jhtp selected as an addon in Snowberry, and play a custom wad like Alien Vendetta, the in the first level, the hi res lion switch (sw1lion)texture will be somewhat enlarged and not positioned correctly on the object and part of it not displayed. another example is if you see a waterfall, it keeps switching back and forth from the low res waterfall texture to the fireblu1 and fireblu2 textures. So this forces me to deactivate the addon in Snowberry and copy the contents of the texture pack under the data folder and then cut out the conflicting textures. I recall Vermil or someone saying this issue was fixed last year, but maybe it wasn't completely fixed. I'm using the last stable release (1.11).

DaniJ

Sounds like you are using version 1.10 (this is the last stable release). Version 1.11 has only recently entered the candidate phase. The texture conflict issue is fixed in 1.11 (I've just double checked).

I will also point out there is never a need to copy add-on data into your Doomsday installation folder. If you want to load say a texture set from a directory rather than a package, you can place them wherever you want provided you tell Doomsday where they are (various methods exist for doing this, including -texdir and -vdmap).

gary

Seems that when I enter the commands, it says 'unknown identifier' when I try both of those commands. It seems -texdir is what I need, but I enter the syntax -texdir "c:\games\doom\addons" after putting the textures folders into a folder I named 'addons' and it still gives me the error. Also, can this be entered while in a map, or most it be done before selecting a game and map? Maybe the syntax I entered is incorrect too?

DaniJ

Are you trying to enter those in the console? These are what are known as command line arguments and need to be specified before starting Doomsday. If you are using the Frontend then this can be done from Settings > Developer > Custom options.

However I would recommend you update to the 1.11 release candidate as you won't have to do this at all.

Btw: Please don't mind the forums looking a little messy. We are currently in the process of switching to a new more modern look.

gary

DaniJ wrote:

Sounds like you are using version 1.10 (this is the last stable release). Version 1.11 has only recently entered the candidate phase. The texture conflict issue is fixed in 1.11 (I've just double checked).

No it isn't, see:





Which forces me to make a backup of the hi res texture pack and move it, then delete the conflicting textures in the existing one each time I notice a conflict.

DaniJ

It would appear that the suppression issue does still exist in the release build, however its working correctly in a debug build. This should mean a relatively straightforward fix once we've determined the cause...

gary

I just tried the latest unstable #951 and even removed the frontend to do a fresh install, and in the first map in AV, the lion head texture with the hi res pack is still not showing up correctly with the unaltered hi res texture pack, as see above. In the commits, it is said to be fixed as of this build, unless I misread.

DaniJ

Indeed a problem with this persists in the Windows builds produced by the autobuilder. I can however confirm that this feature is working correctly in both debug and release builds I produce myself on my own Windows dev system. Skyjake has similarly confirmed that it is working correctly on the Mac. As yet we've been unable to determine where the autobuilder is going wrong.

gary

Well, here's to hoping you find the problem. I usually do look forward to reading the list of upgrades and progress that each new build shows. It might be pretty soon (maybe a year) when the new renderer is in operation. It will be interesting to see. Maybe we will get some realism.

skyjake

gary wrote:

lion head texture with the hi res pack is still not showing up correctly

Turns out the cause for this problem wasn't where we had been looking for it.


DHTP defined another copy of the "-pwadtex" option that permits Doomsday to use high-res textures even if a PWAD defines its own. To get around this, you have to make sure this option is unchecked -- unfortunately, as seen here, the default is "Yes":


KuriKai says he's now patched it.

Naturally you also have to make sure the regular setting "Settings -> Graphics -> Allow external with PWADs" is unchecked.

gary

Good work guys. I tested the new pack and it works. Oh, and my version of snowberry seems to have a different interface than yours. Maybe yours is non-windows. Here is mine:





My snowberry looks different because it is a non-dev windows version?

skyjake

gary wrote:

My snowberry looks different because it is a non-dev windows version?

My screenshot was from Mac OS X, that's why it looks different.

gary

one more thing...I just tried it, and if pwads are not enabled, the texture conflict is fixed as stated, but the flats (floors) aren't showing up in hi-res unless pwads are enabled, though the walls are appearing hi-res as they should. Why are the flats not showing up in hi-res?

DaniJ

The same mechanism is used for all types of texture, it should work the same regardless. Can you give me an example of a situation where the suppression isn't working as you expect and I'll test it.

Edit: OK I've had a look at this and the reason this happens is because av.wad duplicates all the flats from the IWAD. Consequently Doomsday determines that they aren't from the IWAD and therefore they are custom flats.

All we can do in this situation is compare the pixel data of each flat to determine whether it has changed or not. Effectively this means comparing hashes and will definitely affect load time.

skyjake

Sounds like a separate suppression option ("-pwadflat") would be useful (assuming the AV flats are the same as the regular ones).

DaniJ

A -pwadflat option could be useful for customization but such an option wouldn't solve a situation like av.wad where the original flats have been duplicated. For that we'd need to compare the flats themselves using a similar algorithm to that used with textures defined in TEXTURE1/2 (which currently stops short of comparing hashes and bases the decision on texture definition differences).