Extended sprite naming convention - any future plans?

[Nash]

I'm just wondering if there are any plans to implement an extended sprite naming convention to accomodate for more than 4 characters for the base sprite name? Perhaps using special characters as delimiters to separate the base sprite name from the other special characters like angle information and frame number? So that means, the base sprite name can be as long as it wants (within limitation of course) then when it encounters a delimiter, it knows that the sprite name has ended.

The reason I ask is because... believe it or not, I am running out of characters to use for the project I am working on. I'm fighting against these limitations by coming up with obtuse naming conventions in an attempt to get around the character limit.

I understand that if this were to happen, it won't work with WADs. I'm asking if it could be a bonus feature of using directories.

[Enjay]

I think that there are 39 characters available as sprite names. 26 letters, 3 extended characters and 10 digits

39^4 = 2,313,441

You have over 2 million different sprite sets?

OK, OK, I realise that you probably meant that you are running out of names that are instantly meaningful to you...

[Graf Zahl]

4 short words:

Not worth the hassle.

[Nash]

OK, OK, I realise that you probably meant that you are running out of names that are instantly meaningful to you... :P

Yes that's what I meant. Here's an example of an old draft (this is out of date, I'll have to revise this, I'm sure I can cut some corners and save texture/memory space):

Code: Select all

00 00 A 1

first 2 digits: zombie variation type. limit from 00 to 1Z. Each digit has 36 values (0 to 9 + A to Z) so
                36 * 2 = 72 zombie types only. this should be plenty.

3rd, 4th: animation number AND part AND state.
          we have 34 animations, and 5 parts, all at 3 states each.
		  so we need 510 numbers. (34 * 5 * 3)
          so this should go from 00 to ZZ so we have 1296 total numbers to use

5th: frame (max 26 frames, A to Z, to keep it simple)

6th: angle. there will be no mirroring, all 8 angles will be rendered from 3ds max.

This is for multipart zombies.

Multipart human actors have a different naming convention...they are less complex, have less parts, less animations... then there's multipart HUD weapon sprites too, which need to follow a totally different naming scheme...

Anyway, I was just curious. As you've calculated, 2 million is plenty of room to play with, and as long as I document my stuff carefully, and write some automated batch tools, I should remain sane... =P

[Gez]

A possibility would be to distinguish between upper case and lower case (the Doom Legacy fork used in Sonic Robo Blast 2 does that), but that would go against ZDoom's long tradition of case-insensitivity. I mean, you can have:

Code: Select all

TROO A 5
troo A 5
TROO a 5
troo a 5

and they are all parsed to the same thing in DECORATE. So if you were to use that in your custom GZDoom fork, then you'd have to modify the parser code accordingly.

[NeuralStunner]

I think that there are 39 characters available as sprite names. 26 letters, 3 extended characters and 10 digits

Digits? It's only 29 (Letters + [, \, ]) [wiki=Sprite#Frames]as far as I know[/wiki].

[Gez]

That's a limit on frames, not on names.

Example: BOS2A1 is perfectly okay. Just open up doom2.wad if you don't believe me. BOSA21 will not work, though.



In fact, you can perfectly well use an awful sprite name like \\\\\0. It'll be \\\\ for the name, \ for the frame, and 0 for the angle. It will actually work. Though please don't do that.

[Kinsie]

OK, OK, I realise that you probably meant that you are running out of names that are instantly meaningful to you...

Yes that's what I meant. Here's an example of an old draft (this is out of date, I'll have to revise this, I'm sure I can cut some corners and save texture/memory space):

Code: Select all

00 00 A 1

first 2 digits: zombie variation type. limit from 00 to 1Z. Each digit has 36 values (0 to 9 + A to Z) so
                36 * 2 = 72 zombie types only. this should be plenty.

3rd, 4th: animation number AND part AND state.
          we have 34 animations, and 5 parts, all at 3 states each.
		  so we need 510 numbers. (34 * 5 * 3)
          so this should go from 00 to ZZ so we have 1296 total numbers to use

5th: frame (max 26 frames, A to Z, to keep it simple)

6th: angle. there will be no mirroring, all 8 angles will be rendered from 3ds max.

This is for multipart zombies.

Multipart human actors have a different naming convention...they are less complex, have less parts, less animations... then there's multipart HUD weapon sprites too, which need to follow a totally different naming scheme...

Anyway, I was just curious. As you've calculated, 2 million is plenty of room to play with, and as long as I document my stuff carefully, and write some automated batch tools, I should remain sane... =P

Maybe I'm just a grognard, but trying to force the Doom engine to comfortably handle hundreds of semi-unique multi-part zombies is kind of like trying to eat icecream with a fork - you're just plain using the wrong tool for the job.

[Enjay]

Digits? It's only 29 (Letters + [, \, ]) [wiki=Sprite#Frames]as far as I know[/wiki].

So, names like BAL2, COL1, POL6, SMT2, GOR1, HDB3, POB1, BOS2 (etc) cannot be done? Someone better tell id that their IWAD doesn't work. However, I realise that I didn't think it through. Perhaps other characters (ü, é, â etc) might be legal in the four-character part of the name?

As Gez said, the sprite angle naming is clearly defined to a small set of numbers (typically 0 and 1-8 though 16 angles are possible in ZDoom (using 9 + A-G)) and the frame names are restricted to the characters that you identified (A-Z+[, \, ]).