[Fixed] Using highres textures screws them

[Hirogen2]

http://forum.zdoom.org/viewtopic.php?t=594

- the sky... (it is not the usual size but you see it's not working)
- replacing, say MIDBARS1 (the texture at the chainsaw in Doom2 MAP01) is replaced by a highres one, it appears way up the sky. To clarify, X/Y offset adjusting is done before the texture is scaled down.

I'll add if I find more.

[Cyb]

yeah, that's to allow the editor a greater degree of control when setting offsets on scaled textures, so when you offset a 256x256 texture scaled down to 128x128 for instance, 32 units, it will offset the texture based on the unscaled proportions, so in this case it will appear to only be moved 16 units, but it's 32pixels relative to the texture.

it makes sense, but it doesn't allow you to simply load up a wad of hires textures and play existing maps without at least a few texture errors, I think randy was considering changing it, but I don't recall if he's done so

[Zell]

uhhhh try applying lower unpegged with the midbars thing??

[Enjay]

I don't know why the sky is borked, but offsets work a little differently to how I initially expected them to with hi-res textures.

If you have a 64 wide normal texture and offset it by 32, it moves by half its width.

If you have a 128 wide texture scaled to look like a 64 wide one, then offset it by 32, it does not move by half its width, but rather by 32 pixels from the original image - ie only quarter of its width.

I noticed this when trying to put some Hi-res crate replacements into a WAD, and when I went on to E2M2 a few of the offsets were wrong.

This does mean you can't just drop in hi-res textures and expect them to work. The other system used by ZdoomGL and Doomsday does allow you to drop in textures at their original alignment.

Edit:Dammit again. That's the third time tonight I've typed too slow.

[Cyb]

rofl

[Enjay]

Just tried a 1024x512 sky scaled to be 256x128 and got similar results to Hirogen2. ie The join between the top and bottom of the texture tiling was visible about half way up the sky.

[Graf Zahl]

yeah, that's to allow the editor a greater degree of control when setting offsets on scaled textures, so when you offset a 256x256 texture scaled down to 128x128 for instance, 32 units, it will offset the texture based on the unscaled proportions, so in this case it will appear to only be moved 16 units, but it's 32pixels relative to the texture.

it makes sense, but it doesn't allow you to simply load up a wad of hires textures and play existing maps without at least a few texture errors, I think randy was considering changing it, but I don't recall if he's done so

This method of scaling really should be made optional. It is completely contrary to my way of thinking (in map units) and as this thread shows can cause a lot of unnecessary work when replacing textures. Having both options selectable though a MAPINFO entry would certainly the best solution for maximum compatibility and usability.

[Chris]

This method of scaling really should be made optional.

I agree. Although I don't know a good solution to enable/disable it except for in a MAPINFO lump maybe..?

Code: Select all

defaultmap
highresoffsets

[Hirogen2]

Why should anyone want "not-highresoffsets", that is, the current situation? That's like crap, if you got an extension pack to something and the offsets only work with one of those.

[Enjay]

As Cyb said, this method of doing things is to allow greater control (which it does).

It does mean, however, that simply dropping in hi-res textures to replace existing ones will not work a lot of the time but this was considered, by a quite a few people who posted, to be something that most people wouldn't want to do.

My preference would be to have the original offsets maintained rather than the current situation because I too have run into problems when trying to replace existing textures with hi-res ones, but the bulk of opinion seemed to be against me.

The MAPINFO suggestion makes sense, but there is a little problem with it. If you are trying to create a WAD of hi res textures to "plug in" to existing levels you do not want to have to make a MAPINFO to include in that WAD because you want your hi-res WAD to be compatible with every existing WAD (as far as possible). Including a MAPINFO would break compatability with some of those WADs. So this implies not putting a comment in the MAPINFO should mean textures use world unit offsets - ie preserve the appearance of their low res cousins - by default.

However, there are already existing mods that take advantage of hi-res textures, and which use the more precise method of offsetting. These will not have anything in the MAPINFO to instruct Zdoom to use the precise method, so making the preserve offsets method the default and requiring a MAPINFO entry for precise offsets would break any existing mods with hi-res textures instead.

[Hirogen2]

Maybe the whole situation can be "concluded" in a new (yet again) lump, say, TEXINFO.
BTW/first, ask yourself "how will you use highres textures", that is, how do you scale them, when not using TEXTUREx lumps, i.e. TX_*? The answer is, you need something to describe them, best would be a lump. If there is such a lump (or a skeleton of it, as of now), adding a flag to toggle "good behavior" (Enjay:"preserve the appearance of their low res cousins").

Code: Select all

BROWN1 { // original: 128x128
  Scale 0.5; // new: 256x256, so 0.5
  DoItCorrectly;
}

[Graf Zahl]

Maybe the whole situation can be "concluded" in a new (yet again) lump, say, TEXINFO.
BTW/first, ask yourself "how will you use highres textures", that is, how do you scale them, when not using TEXTUREx lumps, i.e. TX_*? The answer is, you need something to describe them, best would be a lump. If there is such a lump (or a skeleton of it, as of now), adding a flag to toggle "good behavior" (Enjay:"preserve the appearance of their low res cousins").

Code: Select all

BROWN1 { // original: 128x128
  Scale 0.5; // new: 256x256, so 0.5
  DoItCorrectly;
}

Ugh, I most certainly don't want to type such a thing for each and every texture. There should be a global solution.

I don't think adding yet another resource is a good idea. Let's restrict texture scaling to textures in the TEXTUREx lump.
It doesn't make much sense to invent convoluted solutions to such a minor problem.

Anyway, does any level exist that actually uses scaled hires textures? If not I'd say change it to map unit offsets and compatibility-option it.

[LilWhiteMouse]

<g> This conversation seems familiar....

Why not add a parameter to the existing ANIMDEFS lump?

Code: Select all

NoScaledOffsets texture TEXTURE_Name

NoScaledOffsets would override the existing offset method. I've used hi-res textures (nothing released though, except adessa.wad), and I seem to recall when I brought this up other wads were listed.

[Hirogen2]

o_O ANIMDEFS ownz.

[Graf Zahl]

<g> This conversation seems familiar....

Why not add a parameter to the existing ANIMDEFS lump?

Code: Select all

NoScaledOffsets texture TEXTURE_Name

NoScaledOffsets would override the existing offset method. I've used hi-res textures (nothing released though, except adessa.wad), and I seem to recall when I brought this up other wads were listed.

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.