Page 1 of 1
Sprite rotations in decorative props
Posted: Fri Jun 22, 2018 11:41 pm
by 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?
Re: Sprite rotations in decorative props
Posted: Fri Jun 22, 2018 11:48 pm
by 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.
Re: Sprite rotations in decorative props
Posted: Sat Jun 23, 2018 7:05 am
by 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.
Re: Sprite rotations in decorative props
Posted: Sat Jun 23, 2018 7:30 am
by 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.
Re: Sprite rotations in decorative props
Posted: Sat Jun 23, 2018 11:43 am
by 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).
Re: Sprite rotations in decorative props
Posted: Sun Jun 24, 2018 1:05 am
by 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.
Re: Sprite rotations in decorative props
Posted: Wed Jul 04, 2018 9:37 pm
by Ultimate Freedoomer
ramon.dexter wrote: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?
Re: Sprite rotations in decorative props
Posted: Wed Jul 04, 2018 11:44 pm
by Graf Zahl
No, that would only show frame A. If you want animation you need a positive duration.
Re: Sprite rotations in decorative props
Posted: Thu Jul 05, 2018 5:57 am
by Gez
Ultimate Freedoomer wrote:ramon.dexter wrote: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.
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?
Re: Sprite rotations in decorative props
Posted: Thu Jul 05, 2018 11:45 am
by Ultimate Freedoomer
Gez wrote:Ultimate Freedoomer wrote:ramon.dexter wrote: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.
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.
Re: Sprite rotations in decorative props
Posted: Thu Jul 05, 2018 12:59 pm
by 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.
Re: Sprite rotations in decorative props
Posted: Thu Jul 05, 2018 1:19 pm
by Ultimate Freedoomer
Gez wrote: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).
Re: Sprite rotations in decorative props
Posted: Thu Jul 05, 2018 1:20 pm
by 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.
Re: Sprite rotations in decorative props
Posted: Thu Jul 05, 2018 1:30 pm
by Ultimate Freedoomer
Enjay wrote: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).