Long sprite names

[argv]

The current four-character sprite names have a very limited namespace. Collisions between mods seem very likely. To solve this problem, please consider allowing longer sprite names (e.g. a state “MightyFoot A 4” uses the sprite frame image “MightyFootA0”).

[Graf Zahl]

This cannot be done because the naming convention is too deeply ingrained into the sprite setup logic. Imagine a name like "BigBlurba1". What is this? Is it "BigBlurb frame A rotation 1" or is this "BigBlu frame R rotation B" and "BigBlu frame A rotation 1" mirrored. The sprite setup code could not decide which of those two options is what you want.

[Nash]

I've suggested this idea several times but haven't gotten an opinion - what about using hardcoded delimiters to separate the angle and frame portion of the sprite name?

[argv]

Oh, I forgot that sprite file names can be ambiguous like that. Damn.

[Nash]

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?

[Rachael]

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.

[Caligari87]

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.

[Cacodemon345]

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.

[argv]

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

[Rachael]

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.

[Kinsie]

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.

[Talon1024]

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

[argv]

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.

[Gez]

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”.

[Nash]

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.