Sprite rotations, their absence, and stuff

[Lioyd_Irving]

It's always been bugging me a bit, but rarely has anything bugged me as much as it has for the last few days.

---

Had a fair bit of success in constructing a framework for a personal project of mine (which, as some may have guessed, is a 2D fighter).

And when inevitably confronted with the need to make my characters turn around, I've been given the lovely choice of [wiki=Sprite#Angles]1) an obscenely enormous waste of space[/wiki], or [wiki=TEXTURES]2) a marginally lesser waste of space that's hacky, messy, inconvenient and painstaking.[/wiki]

I'm talking stuff like manually, individually tweaking every single sprite's offset, one by fecking one, only to serve a flimsy, buggy, and horrendously unnecessary mess that gets all but unworkable past 29 sprites.

Thing is, well -- fighting game. 29 sprites isn't even enough for one move.

Does it really have to be that way? Are missing rotations really that big of a deal? Whatever rotations ZDoom doesn't find, what's to stop it from simply displaying nothing -- like it does with missing sprites -- instead of flat-out refusing to run at all? Is it something with the Doom code?

---

And will you be so kind as to try not to let your response be influenced by how much of an execrable feckwit I've come to be known as?

[Graf Zahl]

Displaying nothing won't work.

For example, if 4-angle rotations were added how would the engine know if it has to deal with an incomplete 8-angle sprite, a fully defined 4-angle sprite or even an incomplete 16-angle sprite?

And seeing the project you need this for, my advice would be to use unrotated sprites and mirroring for the second fighter. Ok, you'd need another actor for that but you don't need sprite duplicates if you name them 'figha0b0' or similarly.

As it is the suggestion simply won't work.

[Nash]

I've made a post about this somewhere early this year... I'll try my best to avoid the evil J word, but is it not possible to get ZDoom to "quantize" the missing angles?

[Lioyd_Irving]

I see. About this point, though:

For example, if 4-angle rotations were added how would the engine know if it has to deal with an incomplete 8-angle sprite, a fully defined 4-angle sprite or even an incomplete 16-angle sprite?

Would it be possible, assuming the crash is dropped entirely, for the relevant actors to tell the engine through a property? Failing that, could ZDoom try and determine what to display based on which rotations it finds?

[Gez]

I'd go with 0 rotations and different "right-facing" and "left-facing" states.

Also, the limit to 29 frames by sprites isn't a problem because you can do this:

Code: Select all

States
{
Spawn:
    ABCD E 5
    FGHI J 5
    KLMN O 5
    PQRS T 5
    UVWX Y 5
    Loop
}

[Lioyd_Irving]

I suppose an even simpler solution for my problem (and that of everybody who's ever tried to make something 2D...) would be to allow for negative scaling, but that's probably for another topic.

[Project Shadowcat]

Is Gez's solution not good enough? You don't have to bloat the WAD/PK3 with more sprite entries, just define them in TEXTURES with a horizontal mirror.

[Lioyd_Irving]

It's a solution to the sprite limit, but not to the general flimsiness and inconvenience. Working with batches of 29 sprites means having to stick angle checks in places where they don't belong (ie more things begging to go wrong), and does nothing for the unholy torture of the offset.

---

I already had a f**king solution. Going with mirrored *0 sprites, I had intended to use a single large vertical sheet which I'd take cutouts of in TEXTURES, but my computer had other plans. Namely being an overpriced pile of rubbish that takes a full minute to process every single operation involving that sheet. I'm not asking this for the hell of it.

[Graf Zahl]

Well, I'm sorry, but that's bound to happen if you want to make things with the engine it was never designed for.

[Lioyd_Irving]

There's nothing to apologize for. I knew what I was getting myself into.

While I'm at it, though, might as well spare a topic: Is negative scaling a feasible thing to implement?

(I'm alright with a one-word reply.)

[Gez]

There's already two ways to mirror sprites... Unless you want to mirror them vertically? I'm not sure what else than mirroring you could mean by "negative scaling".

Suppose your left-facing state is FITE L, and the right-facing state is FITE R... You can name your sprite FITEL0R0 and it'll be mirrored automatically.

Note that you can pretty much use the sprite names for the state, so you're not limited to batches of 29. You are instead limited to batches of 1874161 (A-Z, 0-9, _ : 37 characters, 37^4 combinations).

[Lioyd_Irving]

I do mean a third sort of mirroring, by [wiki=A_SetScale]scaling[/wiki] a sprite to a negative value. It alone would be infinitely simpler than to take twice the number of namespaces.

Still, for the matter of conserving namespaces, stuff like SPRIL0R0 had gone completely over my head. (Shows what I know.) Wouldn't that require an angle check at the beginning of every move, though?

[Project Shadowcat]

Unless you're trying to hit a specific direction, no.