Mon Sep 15, 2003 7:06 pm

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?

Mon Sep 15, 2003 7:12 pm

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! :P just kidding, but yeah it would be nice to have ummm nice textures :D :P

Mon Sep 15, 2003 7:31 pm

randy wrote:Should I do this?

How would this affect existing maps that use scaled textures?

Mon Sep 15, 2003 8:07 pm

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

Mon Sep 15, 2003 8:14 pm

Go for it, I say. :D

Tue Sep 16, 2003 12:47 am

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

Time for a feature-freeze...

Tue Sep 16, 2003 3:39 am

randy wrote: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.

Tue Sep 16, 2003 7:14 am

Graf Zahl wrote: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 :P
Code:
perl -e 'print "NoScaledOffsets texture ",($_=~/(.*)\.bmp/i)[0] for<*.bmp>'

VoilĂ .

Tue Sep 16, 2003 7:25 am

randy wrote: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).

Tue Sep 16, 2003 8:05 am

Hirogen2 wrote:
randy wrote: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!

Tue Sep 16, 2003 8:10 am

Graf Zahl wrote: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 :P 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.

Tue Sep 16, 2003 8:15 am

the two short ints have been taken by texture scaling


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

Tue Sep 16, 2003 8:18 am

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.

Tue Sep 16, 2003 8:34 am

Chris wrote:
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 :evil:
Last edited by Hirogen2 on Tue Sep 16, 2003 8:53 am, edited 1 time in total.

Tue Sep 16, 2003 8:43 am

the scale number only goes up to 255