[Can't fix] Texture Aliment Issue GZDoom 3.7

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Re: Texture Aliment Issue GZDoom 3.7

Postby Graf Zahl » Sun Feb 10, 2019 6:28 am

The easiest thing you can so is to just set the option in MAPINFO and use the unscaled original textures for placement. If you do that it will scale the same for both.

I have no idea how well supported this panning stuff is by the editors.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture Aliment Issue GZDoom 3.7

Postby Steve5563 » Sun Feb 10, 2019 6:48 am

ok,
i added this to the map info and i have no idea if its correct? the aliment issue is still the same with this written in the map info like this,
please correct it if i have it wrong. cheers

gameinfo
{
forceworldpanning = true
}
User avatar
Steve5563
 
Joined: 27 Jan 2019
Location: Australia

Re: Texture Aliment Issue GZDoom 3.7

Postby Enjay » Sun Feb 10, 2019 6:49 am

Steve5563 wrote:ok i kinda get what your saying and i have no idea what per-texel panning is.


Graf Zahl wrote:Take a line that is 128 map units long. And take a texture that is 640 pixels wide with a scale factor of 5. Per texel panning means that the offsetsyou need to specify range from 0-640, not 0-128.


To expand further, the practicality of this in GZDoom is that the pixel resolution of the original image (640 wide in Graf's example) is what is being referred to as texels.

So, in Graf's example, the 640 wide graphic has been scaled to 1/5 it's original size, making it effectively a 128 wide texture. The scaled with = 1/5 of 640 = 128. Its texel width is 640, its world units width is 128.

If you were to put that texture on a line in a map and give it an offset of 64, it would behave very differently, depending on whether per-texel or world offsets were being used.

With per-texel offsets, the texture would move by 64 of the pixels of the original graphic's resolution. So, our scaled 128 wide texture would move by 64 original resolution units (which, of course, is 1/10 or the original graphic's width) and so would only appear to move by 1/10 of the scaled width (12.8 world units). This, unfortunately (for historical reasons, as Graf explained), is the default. Of course, with different scaling factors, exactly how far the texture effectively moves will be different for each scaling factor. This is basically the root of the problem that you have experienced.

With world offsets, the scaled texture behaves exactly as you would expect a texture of the scaled size to behave. e.g. our 640 graphic scaled to an effective 128 units wide behaves like a normal 128 wide 1:1 scaled texture. Given an offset of 64 it would move by half its width, even though that would mean 320 pixels from the original graphic.


Generally, using world offsets is far more useful because it means that once your texture is set up, it behaves just like any texture of that effective size - making regular mapping less difficult to wrap your head around and drop-in replacements easy.

To my mind the only real advantage of per-texel offsets is that it allows very fine adjustments of the texture position. To go back to Graf's example, world offsets means that every unit of offset moves the graphic by 64 original resolution pixels. Per-texel offsets mean that every unit of offset moves the texture by 1/5th of a world unit. How often that level of precision is needed, I really don't know.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Texture Aliment Issue GZDoom 3.7

Postby Steve5563 » Sun Feb 10, 2019 7:09 am

ok thanks for the explanation i understand whats going on now.
this raises another question --- why did this need to be changed?
User avatar
Steve5563
 
Joined: 27 Jan 2019
Location: Australia

Re: Texture Aliment Issue GZDoom 3.7

Postby Enjay » Sun Feb 10, 2019 7:18 am

Because the different renderers were behaving differently with respect to how this was being handled, and they shouldn't have been.

More info viewtopic.php?f=56&t=62633
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Texture Aliment Issue GZDoom 3.7

Postby Steve5563 » Sun Feb 10, 2019 7:41 am

ok thanks enjay.
User avatar
Steve5563
 
Joined: 27 Jan 2019
Location: Australia

Re: Texture Aliment Issue GZDoom 3.7

Postby Graf Zahl » Sun Feb 10, 2019 7:50 am

Enjay wrote:Because the different renderers were behaving differently with respect to how this was being handled, and they shouldn't have been.

More info viewtopic.php?f=56&t=62633



Not only that, the calculations in the hardware renderer were flat out wrong and didn't match either system if both kinds of scaling were added up.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture Aliment Issue GZDoom 3.7

Postby Steve5563 » Sun Feb 10, 2019 8:26 am

Idea???---- if we want to scale the textures eg. 0.5 is there a setting that can be added to gzdoom builder that when it's checked(ticked),
and when you save the map you have made,
this setting will create a mapinfo lump and add the "forceworldpanning" script to it like you mentioned graf so the textures will scale the same?
User avatar
Steve5563
 
Joined: 27 Jan 2019
Location: Australia

Re: Texture Aliment Issue GZDoom 3.7

Postby Rachael » Sun Feb 10, 2019 8:47 am

Please use GZDBBF's discussion topic here to discuss ideas pertaining to GZDBBF.

That is not a project that we develop or support. It just happens to be the most popular editor that we all use.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle

Re: Texture Aliment Issue GZDoom 3.7

Postby Enjay » Sun Feb 10, 2019 12:54 pm

Honestly, if you need to create a MAPINFO lump, you're probably going to want to create other MAPINFO entries (music, sky, endtext, whatever). Asking GZDoombuilder to have special code for this one option, when maybe hundreds of potential MAPINFO entries are possible seems odd to me.

Also, for what it's worth, it is actually possible to set the type of offsetting within the texture definition itself (both via the text TEXTURES lump and the older Doom-format TEXTURE1 lump). So it is possible to set some textures within a mod to use texel offsets and others to use world offsets. Some people might have a need for that.

I actually have a really old map like that but, to be fair, it wasn't really by design. It was right when hi-res textures were being introduced. I set up a few textures using the texel offsetting because that was the default (in fact, it may have been the only option when I started the map) but by the time I finished the map, I knew about world panning (or world panning had been added). So any subsequent hi-res textures in the map used world panning because that was easier to work with. Given that going back to realign all the texel offset textures would have been more effort that it was worth, I just left it so that some textures used world offsets and some used texel offsets. :shrug:
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Texture Aliment Issue GZDoom 3.7

Postby Graf Zahl » Sun Feb 10, 2019 1:43 pm

The problem here is a bit different: If you replace a normal scale texture with a hires replacement its panning mode changes. The oversight so many years ago that is now causing all the trouble is not the texel panning itself, but that for unscaled textures the panning mode is set to texel - which is fine as long as a 1:1 scale is used. The problems arise if you add a per-sidedef scale for such a texture and THEN add a hires replacement. That's the one case where I have no good idea what to do.

I cannot change the panning mode of the base texture because that'd break pretty much any mod ever using this feature and there is no good way in such a case to tell a hires texture how to behave to perfectly mimic the base texture's panning mode.
Even if I do the only sane thing and officially deprecate the broken scaling options and replace them it doesn't help, because people will just continue to use the old ones because that's what the editors give them.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture Aliment Issue GZDoom 3.7

Postby Enjay » Sun Feb 10, 2019 1:57 pm

My relative unfamiliarity with UDMF meant that I was forgetting about per-sidedef scaling. I can see how that adds another level of confusion to an already confusing situation. I can see why a good solution isn't making itself apparent. I'm not sure that there is one.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Texture Aliment Issue GZDoom 3.7

Postby Graf Zahl » Sun Feb 10, 2019 2:24 pm

The per-sidedef scaling would have been fine, had it been done properly in the software renderer. But as things were it fell victim to a bad combination of default settings.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Texture Aliment Issue GZDoom 3.7

Postby Steve5563 » Sun Feb 10, 2019 9:23 pm

Enjay wrote:Honestly, if you need to create a MAPINFO lump, you're probably going to want to create other MAPINFO entries (music, sky, endtext, whatever). Asking GZDoombuilder to have special code for this one option, when maybe hundreds of potential MAPINFO entries are possible seems odd to me.


the toggleable setting would be used once when you first create the map / wad, then for future saves you deselect / uncheck the setting. from there you could add to the map info lump like normal.

this is just my opinion but going by what has been discussed in this thread and the road blocks that you guys are having to deal with is pretty crazy, and i applaud you for what has been done with the engine.
and from my point of view and the issues that have been discussed in this thread is kinda saying to me that gzdoom should probably be left at 3.6,
and with future updates / big changes from 3.6,
the engine needs to be renamed, and for it to completely break away from the zdoom flaws that you guys have mentioned here and other threads.
and do what you guys really want to do with the engine, rather then trying to make things still progress forward without breaking the old stuff ( walking on egg shells with the community ) a lot of mappers / players that i have seen are jumping back to zandronum 3.0 just for the fps gains that the old gzdoom engine gives you including myself.
with the new engine keep the good stuff from gzdoom and take out the trash. :D
User avatar
Steve5563
 
Joined: 27 Jan 2019
Location: Australia

Re: Texture Aliment Issue GZDoom 3.7

Postby Nash » Mon Feb 11, 2019 11:36 am

A word about "ForceWorldPanning" -

GZDB-BF currently does not recognize this flag so if you are using scaled textures, it will look completely wrong in the editor.
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia with Vulkan support

Previous

Return to Closed Bugs

Who is online

Users browsing this forum: Semrush [Bot] and 1 guest