Long sprite names

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Long sprite names

Re: Long sprite names

by Graf Zahl » Thu May 26, 2022 11:50 pm

If it was that easy the feature would have been done long ago...

Re: Long sprite names

by Xeotroid » Thu May 26, 2022 5:33 pm

Understood, it was worth a shot at least.
I guess then the different syntax suggestions are irrelevant, because the issue doesn't really concern how the States block is written, right? Is it also why with MODELDEF it's possible for two actors with two different models to share the same frame names without issues – because models are loaded and organised completely differently?

Re: Long sprite names

by Graf Zahl » Thu May 26, 2022 10:41 am

Sorry, but the way sorites are looked up does not allow any of this. We'd had to change the entire sprite loader to do it. That's not really worth it.

Re: Long sprite names

by Xeotroid » Thu May 26, 2022 10:33 am

Sorry about necroing a four year old post, but I wasn't sure if a new feature suggestion would be a good idea since it would be mostly a duplicate. However, could a different approach work? Instead of trying to implement long sprite names in the States block or using folder paths as sprite name parts, what if the States block stayed the same, but the namespace where to look for sprites was customisable using an actor property?

Think of a folder structure like this:

Code: Select all

sprites
├spacelab
│├BOOKA0.png
│└BOOKB0.png
└medieval
 ├BOOKA0.png
 └BOOKB0.png

Then, in the actor definition, a SpriteNamespace property could be used that specifies the folder to look in, in this case either "sprites/spacelab" or "sprites/medieval", eg.:

Code: Select all

Default {
	SpriteNamespace "sprites/spacelab";
}
States {
Spawn:
	BOOK A -1;
	Stop;
}
Perhaps the "namespace" could be limited to the sprites folder, and the property would translate to an index offset for the list of sprites?

Re: Long sprite names

by Nash » Sun Jul 08, 2018 5:38 pm

I don't know how to make this post not look like a postCount++ but Talon's namespace idea, as well as Gez's long sprite convention idea sounds better.

Re: Long sprite names

by Gez » Sun Jul 08, 2018 4:47 pm

There's some merit to that idea, though I don't see why it'd have to be “sprites/MightyFoot/A/1.png” instead of more simply “sprites/MightyFoot/A1.png”. Since nobody has asked (and nobody better ask) for long frame names or long rotation names, those would still just be two or four characters. And it'd make viewing them in a resource editor like SLADE more convenient (no need to always navigate up/down a level in between each frame, it'd become very annoying real quick I can tell you, as would be having to create dozens of subfolders).

The main folder might have to be distinct, like lnsprites/ or something to make it easier for the engine to separate between regular sprites that have to be parsed the old way, and long name sprites that are parsed by their subfolder. So something like “lnsprites/MightyFoot/A1.png”.

Re: Long sprite names

by argv » Sun Jul 08, 2018 4:22 pm

It occurs to me that we could use folders as the delimiters Nash proposes. For example, “sprites/MightyFoot/A/0.png” would be sprite MightyFoot, frame A, orientation 0, “sprites/MightyFoot/A/1.png” would be orientation 1, and so on.

If this scheme is used, the short form “sprites/MightyFoot/A.png” should probably also be allowed, in the common case that a frame has only one orientation.

This shouldn't collide with anything existing mods do, because although sprite images in subfolders are allowed, “A.png” or “1.png” would not currently be recognized as sprite images.

Re: Long sprite names

by Talon1024 » Sun Jul 08, 2018 1:20 pm

I had a similar idea of allowing sprites to be namespaced, which I think is closer to the way GZDoom works, and prevent conflicts between sprites in different mods.

For example, instead of:

Code: Select all

FLAR A -1
A namespaced version of this could be:

Code: Select all

sprites/vfx/FLAR A -1

Re: Long sprite names

by Kinsie » Sun Jul 08, 2018 11:33 am

Yeah, there have been a number of features that have gone from [No] to [Added] when somebody else submitted a patch, or when other engine changes made it more viable. Graf is pretty brusque, to be sure, but he's not inflexible.

Re: Long sprite names

by Rachael » Sun Jul 08, 2018 1:29 am

That is a very disingenuous statement, which completely disregards that there's a bit of nuance behind the "no" answer. While it is not always clear why he gives the answer - I can tell you if there is more of a technical reason for it than a philosophical one - it can usually be reversed when someone else does the work. But it has to be done correctly, it can't just be ham-fisted, which is why a lot of such efforts end up being rejected.

If he's philosophically in support of an idea, and is able to see technical merits behind it, it's worth it to see if someone who is knowledgeable enough to do the work to do so.

Remember - ZDoom, as a whole, has never been the work of a single developer. More often than not, Graf's "No" answers are a simple indication of his desire not to work on a feature, more than it is a desire not to have it.

Re: Long sprite names

by argv » Sat Jul 07, 2018 4:18 pm

I like the idea, but I learned long ago that when Graf says no, he's not gonna change his mind. :P

Re: Long sprite names

by Cacodemon345 » Fri Jul 06, 2018 1:42 am

I actually like Nash's idea. It would be better and would allow for more sprites in a mod, as the current system is quite limited and can pose a problem on large mods.

Re: Long sprite names

by Caligari87 » Thu Jul 05, 2018 7:02 am

Well, at least the internal representation is able to handle it. While I can't say anything about the difficulty of reworking the enumerator, I imagine it's not nearly as bad as needing to rework the internal handling structure.

Piggybacking, what I'd really like to see is the ability to manually assign frames/rotations via TEXTURES. Something like

Code: Select all

Sprite ImpAttack, 24, 56 {
    Frame 0
    Rotation 0
    Offset -12, 54
    Patch "sprites/imp/attack/a.png", 0, 0
}

Sprite ImpAttack, 24, 56 {
    Frame 1
    Rotation 0
    Offset -12, 54
    Patch "sprites/imp/attack/b.png", 0, 0
}
And for the actors:

Code: Select all

States {
    Attack:
        ImpAttack [0,1] 5 A_Whatever
Granted someone smarter than me probably could come up with a much more robust system for graphics definition and handling numbered frames and whatnot. I think it's probably a good idea to try and further "deprecate" the old methods of defining graphics in favor of something more modern and robust. We're already partway there, what with offsets and sprite names being settable in TEXTURES while the patches can be (almost) any name we desire without any embedded image metadata at all.

8-)

Re: Long sprite names

by Rachael » Thu Jul 05, 2018 1:27 am

I actually like the idea, Nash. But I think the problem is it would require a rework of the sprite enumerator - the system that transforms sprites from XXXXFOFO to an internal set of numbers. Honestly I don't know how much work that would involve.

Re: Long sprite names

by Nash » Wed Jul 04, 2018 10:19 pm

Whyyyy is everyone ignoring my idea? The delimiter would separate where the engine expects angle and frame convention. So everything before that can be whatever long name you want. User is expected to follow these conventions - just like how we are already forced to obey XXXXYZ currently! The engine already fails to start if you don't obey the current convention, there's nothing different here.

Example:

Super Cyberdemon%A2A8.png
VeryLargeMedikit%A0.png
Vicious_Imp%B5.png

Is there anything missing from my logic?

Top