Project

General

Profile

Feature #1371

Animation table enhancments

Added by chilvence about 19 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
2005-03-19
% Done:

100%


Description

It has recently come to my attention that due to the
way animations are defined in Doomsday, none of the
custom animations contained in TNT and PLUTONIA.WAD
work properly. These wad's take advantage of the very
specific behaviour that Doom.exe used to decide what
how to animate textures to provide extra things like
long animations, animated switches etc. Since Jdoom
builds animation tables from a ded file rather than
cycle through each texture index sequentially until it
reads the last animation frame, all of these animations
are broken. It also by extension breaks any other PWAD
that uses a similair tactic.

Some good places to see these anims are: TNT map30,
behind the arachnotrons pillar in the revenant ambush
room where there is an animated switch using the BLODGR
and WFALL sequences. There is also a longer custom
animation in TNT map 19 , in the first
computer+teleport room, which uses the SLADRIP sequence
(its the spinning reels and the animated UAC computer
logo).

I would like to suggest that a new animation type be
implemented that emulates the original behaviour of
Doom.exe, so that custom animations in pwads and in
final doom work properly. By default, Doomsday should
only have the first and last frames of an animation
defined, and read the inbetween frames from the
TEXTURE1 index in the case of textures, and the lump
order in the case of flats. For custom animation
definitions, both old and new methods can be available.

Secondly, I find the inability to redefine individual
animations to be something of an oversight. Currently
if you try to change an existing animation, the
animation gets mangled because two different ded's are
trying to animate the same textures. I believe a simple
fix would be the ability to identify each animation
with a name or an id number, so that it can be
referenced and modified externally.

Also, implementing either or both of these features
will allow me to make my extra smooth liquids.pk3 addon
a lot less buggy and unreliable :)

Labels: Data

History

#1 Updated by picklebro about 19 years ago

Logged In: YES
user_id=1249988

Here is how I suggest it work, with some sample code:

#1. All anims groups be given ID#s or names - this would
allow anim.deds loaded externally to automatically replace
anim groups of the same ID if it was in the default anim.ded
file.

#2. Allow seperate pathing for anim files so you do not have
to force a user to delete existing textures - this makes it
much easier for a new user to implement an addon correctly.

Discussion: Seperate pathing for anim files combined with
group IDs would mean that you could simply add the
animation .pk3 file to your auto folder without
loading as a wad file.

It would also open up options to allow for new anim
sequences to be easily created for any flat in doom .

Below is some sample upgraded code:

GroupID = "42"
#this ID number would overwrite GroupID# 42 in the default
game anim.ded {
Flags = "tgf_smooth";
Ext = "Data\jDoom\PbsAnimTexts";
#being able to define seperate paths for anim textures to be
loaded from would allow people to not have to modify existing
files, they could simply add the pk3 to the Auto folder
Flat { ID = "SWATER1"; Tics = 8; };
Flat { ID = "SWATER2"; Tics = 8; };
Flat { ID = "SWATER3"; Tics = 8; };
Flat { ID = "SWATER4"; Tics = 8; };
}

#2 Updated by picklebro about 19 years ago

Logged In: YES
user_id=1249988

I do disagree with chilvence about making the textures be
read as they are placed in the directory between the first and
last frames as that seems more unreliable than having each
frame defined and limits texture names.

I would suggest, however, that the animation sequences in
the maps mentioned be correctly defined in subsequent
versions of DoomsDay since this is an actual bug.

#3 Updated by chilvence about 19 years ago

Logged In: YES
user_id=675595

Well, Picklebro and I agreed to agree elsewhere :)

Our complete discussion about this is here:
http://forums.newdoom.com/showthread.php?t=27168

#4 Updated by danij almost 19 years ago

Logged In: YES
user_id=849456

A method for defining switches (via DED) should be added to
the animation group support.

The difference with switches being that obviously the
animation should not be looped and should simply stay at the
same frame when the sequence ends.

As switches can change from ON<->OFF we'll either need two
groups (start->end & end->start) or the facility for a
single group animation to play backwards. I think the second
option would be a better solution as if the switch changes
states during animation it would be simpler to determine the
inter point (thinking about model decorations used for
switches).

#5 Updated by picklebro over 18 years ago

Logged In: YES
user_id=1249988

True enough, true enough - Chilvence pointed out that it would
be best for both to work, I was thinking that one or the other
could work but not both. I agree, that if both clearly defined
anim cycles and anims that used the original doom
parameters could co-exist that would be optimal.

Also available in: Atom PDF