Sprite rotations in decorative props

[Ultimate Freedoomer]

Hi. I'm thinking of adding rotations to the spawn state sprite in a decorative prop, & I was wondering If there's any special rules to follow when determining the tic rate in static prop sprite rotations?

[ramon.dexter]

What do you mean by tic rate for static props? It doesnt move, so it has one tic of animation. For the rotations, you have to use as much as needed.

[Gez]

Tic rates and rotations are unrelated. For example, animated props like the burning barrel do not have rotations. Inversely, it is possible to have rotations for static props (KDiZD does so).

See [wiki]Sprite[/wiki] for rotations and [wiki]State[/wiki] for animation.

[wildweasel]

There's really nothing stopping you from adding the rotation sprites to the burning barrel (save for drawing them in the first place); even doom.exe will respect them as long as all eight are present.

[Ultimate Freedoomer]

You’ll have to forgive me, I was under the impression that setting the tic rate in such a spawn state as either “0” or “-1” would cause it to not show up right (or at all).

[ramon.dexter]

No. 0 mesns it will not show up (tic time is set for zero, so it cannot show up). -1 means it will be shown forever.

[Ultimate Freedoomer]

No. 0 mesns it will not show up (tic time is set for zero, so it cannot show up). -1 means it will be shown forever.

Ah. So I can do "SSCO ABCDEFGHIJKLMNOPQRSTUVWX -1" to have a full 360-degree rotation (24 sprite names, 15 rotations per name) in my decorative Wolf SS corpse without it constantly spinning?

[Graf Zahl]

No, that would only show frame A. If you want animation you need a positive duration.

[Gez]

No. 0 mesns it will not show up (tic time is set for zero, so it cannot show up). -1 means it will be shown forever.

Ah. So I can do "SSCO ABCDEFGHIJKLMNOPQRSTUVWX -1" to have a full 360-degree rotation (24 sprite names, 15 rotations per name) in my decorative Wolf SS corpse without it constantly spinning?

I think you're getting frames and rotations confused.

You do not put rotations in the actor code. Only the frames. Rotations are made automatically by the engine depending on the relative angle the actor is seen from.

Code: Select all

SSCO ABCDEFGHIJKLMNOPQRSTUVWX -1

As Graf said, what happens with that code is that the actor will remain forever (-1 means forever) in each of these frames. Since it stays forever in each of these frames, it means that it will stay forever in the first frame, since it will never leave that first frame to go to the second.

The first frame is SSCOA. It corresponds to the sprite SSCOA0 if it doesn't have rotations, or SSCOA1, SSCOA2, etc. to SSCOA8 if it has eight rotations.

The second frame is SSCOB. Likewise, the sprites will be SSCOB0 or SSCOB1 to SSCVOB8. Get it?

Rotations are only used by sprites. Models and voxels don't need them since they're already 3D objects. So a voxel version of your actor would have voxels for SSCOA, SSCOB, and so on, but it wouldn't have SSCOA1 or whatever -- no rotation marker.

If you want a looping animation, you can use something like this:

Code: Select all

Anim:
SSCO ABCDEFGHIJKLMNOPQRSTUVWX 3
Loop

There I put 3 tics per frame so it stays 3 tics on the A frame then move to the B frame where it also stays for three tics before moving to the C frame, and so on. Once it spends 3 tics on the X frame, thanks to the Loop keyword, it goes back to the latest state label encountered, which in this case Anim:, meaning that it loops back to the A frame.

Is it clearer now?

[Ultimate Freedoomer]

No. 0 mesns it will not show up (tic time is set for zero, so it cannot show up). -1 means it will be shown forever.

Ah. So I can do "SSCO ABCDEFGHIJKLMNOPQRSTUVWX -1" to have a full 360-degree rotation (24 sprite names, 15 rotations per name) in my decorative Wolf SS corpse without it constantly spinning?

I think you're getting frames and rotations confused.

You do not put rotations in the actor code. Only the frames. Rotations are made automatically by the engine depending on the relative angle the actor is seen from.

Code: Select all

SSCO ABCDEFGHIJKLMNOPQRSTUVWX -1

As Graf said, what happens with that code is that the actor will remain forever (-1 means forever) in each of these frames. Since it stays forever in each of these frames, it means that it will stay forever in the first frame, since it will never leave that first frame to go to the second.

The first frame is SSCOA. It corresponds to the sprite SSCOA0 if it doesn't have rotations, or SSCOA1, SSCOA2, etc. to SSCOA8 if it has eight rotations.

The second frame is SSCOB. Likewise, the sprites will be SSCOB0 or SSCOB1 to SSCVOB8. Get it?

Rotations are only used by sprites. Models and voxels don't need them since they're already 3D objects. So a voxel version of your actor would have voxels for SSCOA, SSCOB, and so on, but it wouldn't have SSCOA1 or whatever -- no rotation marker.

If you want a looping animation, you can use something like this:

Code: Select all

Anim:
SSCO ABCDEFGHIJKLMNOPQRSTUVWX 3
Loop

There I put 3 tics per frame so it stays 3 tics on the A frame then move to the B frame where it also stays for three tics before moving to the C frame, and so on. Once it spends 3 tics on the X frame, thanks to the Loop keyword, it goes back to the latest state label encountered, which in this case Anim:, meaning that it loops back to the A frame.

Is it clearer now?

Kind of. I just figured I could use the above method to smooth out the rotations in a way that got around the stupid “16 rotations per sprite frame” limit without having to resort to voxels or 3D models.

[Gez]

If you want more than 16 rotations, you should just use a model.

Doom and the other games only use 8 rotations in the first place and they're fine.

[Ultimate Freedoomer]

If you want more than 16 rotations, you should just use a model.

Doom and the other games only use 8 rotations in the first place and they're fine.

fair enough. In general, I was trying to avoid 3D models because they kind of clash, & animated voxels tend to make hardware rendered explode (even though all of the “using voxels with openGL problems” have otherwise been fixed).

[Enjay]

It's a bit of a shame that so few people have used the 16 angle capability of ZDoom. It's understandable, but a shame nevertheless. I think LWM might be the only person who has used them regularly.

[Ultimate Freedoomer]

It's a bit of a shame that so few people have used the 16 angle capability of ZDoom. It's understandable, but a shame nevertheless. I think LWM might be the only person who has used them regularly.

I feel you. Honestly, I’m more miffed by the fact that the (otherwise perfect) voxel handling methods (GZDoom is - as far as I know - the only fully GPL-compliant port to actually have full voxel support, after all) tend to hiccup when doing animated voxels on OpenGL. Come to think of it, I think the only time I’ve seen voxel monsters at all was Solace Dreams. Didn’t even think that animated voxels were physically possible before then (all the voxel animations I’ve seen before were cases where a particle effect was used to represent moving parts on an otherwise static sprite, like flames in torches & stuff like that).