Console spam when using TEXTURES for offsets

Ask about editing graphics, sounds, models, music, etc here!
Shaders (GLSL) and SNDINFO questions also go here!

Moderators: GZDoom Developers, Raze Developers

Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.

Console spam when using TEXTURES for offsets

Postby Caligari87 » Tue Nov 10, 2020 9:51 am

I have several graphics / sprites in Ugly as Sin which don't have their offsets defined in the file, but rather in the TEXTURES lump, as so:
Code: Select allExpand view
Sprite "UGSIE0", 25, 14
{
   XScale 1.500
   YScale 1.500
   Offset 12, 14
   Patch "UGSIE0", 0, 0
}

Sprite "UGSIF0", 17, 18
{
   XScale 1.500
   YScale 1.500
   Offset 7, 18
   Patch "UGSIF0", 0, 0
}

However I'm getting a lot of console spam for many of these with developer logging enabled (two of many)
Code: Select allExpand view
Resolved self-referencing texture by picking an older entry for UGSIE0
Resolved self-referencing texture by picking an older entry for UGSIF0

Wondering what's the right way to avoid this console spam and still set my sprite offsets using only TEXTURES.

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Console spam when using TEXTURES for offsets

Postby Caligari87 » Tue Nov 10, 2020 10:01 am

Possibly may have solved my own question by searching after posting :laff:

viewtopic.php?f=2&t=62103

What I'm gleaning in this thread indicates that graphics defined in this manner should be put in the patches/ folder to avoid circular definitions?

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Console spam when using TEXTURES for offsets

Postby Rachael » Tue Nov 10, 2020 11:02 am

I really would like to see an officially supported "simple modification mechanism" for the textures lump - i.e. not having to redefine the sizes for each texture, being able to change simple things like offset, translation, and/or tint, etc, while avoiding said circular definitions.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Console spam when using TEXTURES for offsets

Postby Graf Zahl » Tue Nov 10, 2020 4:24 pm

Caligari87 wrote:Possibly may have solved my own question by searching after posting :laff:

viewtopic.php?f=2&t=62103

What I'm gleaning in this thread indicates that graphics defined in this manner should be put in the patches/ folder to avoid circular definitions?

8-)


Either that or you reference them by their proper type. All this is an unfortunate side effect of the texture system's namespacing rules necessitated by how Doom was initially designed.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Console spam when using TEXTURES for offsets

Postby Caligari87 » Tue Nov 10, 2020 4:32 pm

I thought I was referencing them by their proper type. They're sprites
Code: Select allExpand view
Sprite "UGSIE0", 25, 14
{
   XScale 1.500
   YScale 1.500
   Offset 12, 14
   Patch "UGSIE0", 0, 0
}

Is this not the right way to define a sprite?

EDIT: Dammit, this is why I should stop trusting SLADE to use the right syntax. Today I learned that patches also have namespace considerations.
https://zdoom.org/wiki/TEXTURES#Patch
Patch Name, X-Origin, Y-Origin
Graphic Name, X-Origin, Y-Origin
Sprite Name, X-Origin, Y-Origin


[...]
Instead of "patch", the "graphic" or "sprite" keyword can be used. The only practical difference is in namespace prioritizing, which is only relevant for PK3 archives since, in a WAD file, both patches and graphics are in the global namespace.


So to clarify, my definition should look like this if I keep my source graphics in the sprites/ folder, right?
Code: Select allExpand view
Sprite "UGSIE0", 25, 14
{
   XScale 1.500
   YScale 1.500
   Offset 12, 14
   Sprite "UGSIE0", 0, 0
}


8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Console spam when using TEXTURES for offsets

Postby Caligari87 » Wed Nov 11, 2020 8:41 pm

Okay, just updating that this didn't seem to work. Example taken from HDest this time because it seems to be unavoidable in a use case like this:
Code: Select allExpand view
sprite PISTA0,27,15
{
   offset 13,15
   xscale 1.5
   yscale 1.5
   patch PISTA0,0,0{}
}

I tried patch, sprite, and graphic on the patch definition and still get the same error.

Based on this, I think a self-reference warning happens whenever the new definition and the patch are of the same type, which is... less than awesome if you're redefining / adjusting graphics from an IWAD or previously-loaded resource file where you can't move the original to another namespace.

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089

Re: Console spam when using TEXTURES for offsets

Postby Graf Zahl » Tue Nov 17, 2020 4:40 pm

You really should not use non-patches of the same name as the texture you are defining. Although there's code trying to handle this case it is rather volatile.
If you want to create sprites out of patches, put the patches in the "patches" folder so that you do not get namespace collisions.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Console spam when using TEXTURES for offsets

Postby Caligari87 » Tue Nov 17, 2020 11:45 pm

Certainly doable when the graphics are in my mod, of course. However it's a tad frustrating that I have to consider the lump and the definition as two semantically-separate graphical entities when really all I want to do is change the offsets without bloating my repository history with binary files or needing to use some special tool (SLADE, while convenient and really the only remotely modern lump editor on Linux, is dangerously unstable and finnicky at times).

Also the issue that sometimes a mod needs to create override definitions of graphics from a separate file, including IWAD graphics. In this case it's impossible to avoid the conflict by changing namespaces.

Is there any way that either of these use cases could be addressed in a manner that doesn't fall afoul of "volatile" code or possible undefined behavior?

8-)
User avatar
Caligari87
I'm just here for the community
User Accounts Assistant
 
Joined: 26 Feb 2004
Location: Salt Lake City, Utah, USA
Discord: Caligari87#3089


Return to Assets (and other stuff)

Who is online

Users browsing this forum: No registered users and 0 guests