[Fixed] Using highres textures screws them

[randi]

When I implemented the high-res textures, I didn't think about people using texture packs to replace the stock textures. I only thought of people using them as new textures, in which case, alignment wouldn't be a problem.

I could add another parameter to the texture definition in TEXTUREx that determines how the offsets are done. Once an editor supports it, this should be the most convenient solution because it would allow you to set the texture's scale and offset behavior in the same place. Should I do this?

[Zell]

ask gherkin to throw into doom builder. He will add it. ^_^ and i say yeah. add it, cuz i like the idea of super definition textures. then we can get super definintrion sprites and make it feel more like quake 2! just kidding, but yeah it would be nice to have ummm nice textures

[LilWhiteMouse]

Should I do this?

How would this affect existing maps that use scaled textures?

[randi]

It would not affect existing maps because the offset behavior would be controlled by the texture.

[Chris]

Go for it, I say.

[HotWax]

Oh sure, get him to add yet ANOTHER feature that will delay the release of 2.1.0. Heh.

Time for a feature-freeze...

[Enjay]

Should I do this?

Yes. If it's all contained in the texture lump, it won't break any existing stuff which already works and it will ensure any replacement packs made with the feature will work with as many WADs as possible. No potentially conflicting MAPINFO's or anything.

Sounds good to me.

Obviously there is an editor implication, but it sounds like the kind of thing that should be easy to incorporate. He said, not knowing anything about what is involved. But again, if it is all determined by the texture, then the editor should be able to be modified to read that and offset textures by whichever method is determined by the texture.

[Hirogen2]

Same problem: It has to be done individually for each texture. Not the kind of solution I'd like. Something like this should be either global or at least map specific.

Assuming that you AT LEAST got a copy of your textures on the hard disk (-> to make them go into a WAD of course), you could do this

Code: Select all

perl -e 'print "NoScaledOffsets texture ",($_=~/(.*)\.bmp/i)[0] for<*.bmp>'

Voilà.

[Hirogen2]

I could add another parameter to the texture definition in TEXTUREx that determines how the offsets are done. Once an editor supports it, this should be the most convenient solution because it would allow you to set the texture's scale and offset behavior in the same place. Should I do this?

No please not. IMO it's useless to poke on a yet-old thing (TEXTURE1), which is even cramped (a text file like DECORATE, etc is more flexible).

[Graf Zahl]

I could add another parameter to the texture definition in TEXTUREx that determines how the offsets are done. Once an editor supports it, this should be the most convenient solution because it would allow you to set the texture's scale and offset behavior in the same place. Should I do this?

No please not. IMO it's useless to poke on a yet-old thing (TEXTURE1), which is even cramped (a text file like DECORATE, etc is more flexible).

No, it is NOT useless! TEXTUREx is currently the only means to define scaled textures. The texture definition has to be somewhere anyway (to set the scale) so this stuff should be put where it belongs (i.e. in the texture definition!) and not in yet another separate file so that nobody is going to find this stuff. It's bad enough that there are already 3 lumps to define texture animations and switches. I don't want another one!

[Hirogen2]

No, it is NOT useless! TEXTUREx is currently the only means to define scaled textures. The texture definition has to be somewhere anyway (to set the scale) so this stuff should be put where it belongs (i.e. in the texture definition!) and not in yet another separate file so that nobody is going to find this stuff. It's bad enough that there are already 3 lumps to define texture animations and switches. I don't want another one!

Yes, yes, TEXTUREx is the only way to do that... but the space in TEXTUREx is consumed by now (the two short ints have been taken by texture scaling). "in the texture definitoin" -> ANIMDEFS see above tx stuff would just fit too nice in there.
3 Lumps? WTF? Which ones? PNAMES, TEXTUREx and ANIMDEFS? Well, if you only use the "new" system (includes said TX stuff in ANIMDEFS), you'd only have one.

[Chris]

the two short ints have been taken by texture scaling

Actually, only 1 of the 4 unused shorts is used for scaling.

[Enjay]

Well, if you wanted, you could use a combination of texture1, texture2, pnames, SWITCHES lump, ANIMATED lump and ANIMDEFS to define your textures, animations and switches. Then of course, we have all the sections in a WAD that something can be put on a wall from under the new texture system.

If there is space in the TEXTUREx lump, and Randy seems to say there is, then that would be the most sensible place for it. It's already used to define scaling. Zdoom, editing tools and the people using them look in the TEXTUREx definition for this info. It makes sense to keep it all there if at all possible.

[Hirogen2]

the two short ints have been taken by texture scaling

Actually, only 1 of the 4 unused shorts is used for scaling.

But XWE says something of Xscale and Yscale which made me guess that it used both.
Oh yeah I just read UDS again and saw there are four free fields... but XWE only displays name,width,height,xscale,yscale and number of patches, so... it doesnot show the unused ones

[Cyb]

the scale number only goes up to 255