Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Maes

Custom (animated) sprites and textures

Recommended Posts

I wonder if there's a way to create new animated textures and flats in vanilla Doom or at most Boom without replacing an already existing one. At least using WinTex, I can see no "animated" property on any of the textures, and the only way I've been able to create custom animated textures was to replace existing ones which were known to be animated. Giving names such as e.g. MYTEXTA0, MYTEXTB0 or MYFLAT1, MYFLAT2 etc. didn't work.

Are the animated texture entries hardcoded in the .exe as such or is there some other entry in the IWAD which specified it (always for vanilla or at most Boom)? Does it require DEH or advanced scripting?

Same question for sprites: if I create some custom decorative sprite entries, either static or animated, how can I use them in an editor e.g. Doombuilder? Also, how do I "persuade" the vanilla doom .exe (or Boom) to treat them as animated sprites? (SPRITEA0, SPRITEB0 etc.)

Share this post


Link to post

The set of animated textures and flats is hard-coded into the Doom.exe and you cannot add more. Although you can make the existing animations longer (as the animation uses every image between a start and end image, e.g. between FWATER1 and FWATER4).

Boom allows you to create your own animated textures and flats via a lump called ANIMATED. Google for "SWANTBLS" (the tool used to create it).

Other source ports may have their own method, e.g. EDGE has ANIMS.DDF (stored in the DDFANIM lump).

For sprites, the number of objects and their animations are also hard-coded into the Doom.exe. You cannot add new objects. With DeHackEd you can modify frames, but the number of frames is also limited. Boom doesn't help much in this regard. Source ports let you add new objects and frames (e.g. EDGE uses THINGS.DDF).

Share this post


Link to post

There are a few animated textures hard-coded in the engine that are not actually used in the game (and have no textures/patches assigned to them). I belive one is called WFALL1 - WFALL3 and would probably have been used for, you guessed it, a waterfall. And often is in many wads, using that colourised blue 'slime fall' texture

Share this post


Link to post

Wow, thanks :-) I guess it's not worth it to use Boom scripting in order to add just one animated texture then. OK...

Share this post


Link to post
deathbringer said:

And often is in many wads, using that colourised blue 'slime fall' texture



You mean the waterfall from Plutonia, right? ;)

Share this post


Link to post
deathbringer said:

There are a few animated textures hard-coded in the engine that are not actually used in the game (and have no textures/patches assigned to them). I belive one is called WFALL1 - WFALL3 and would probably have been used for, you guessed it, a waterfall. And often is in many wads, using that colourised blue 'slime fall' texture


Maybe I remember it wrong, but I think that sladwall slime fall also is coded into doom2. But it is not used. Iirc, it have a name like NFALL1-4 or something similiar. I can't recall it's name.

Share this post


Link to post

The unused animated textures in doom2 that I recall are:
WFALL 1-4
SLADRIP 1-3
BLODGR 1-4

There is also the unused flat animation SWATER1-4

There might even be another animated texture that I have forgotten.

Share this post


Link to post

And BFALL1-4, however now I have another problem:

I'm trying to make a large animated wall (say 256*128) and assigned it to BLODGRO1-4, with a single patch per frame.

ZDoom and compatibles playes it just fine, but prBoom bombed saying "Bad cycle BLODGRO1-4".

I tried using other animated textures like WFALL1-4 and BFALL1-4 but it always returned the same error. I tried changing the texture size to the original one (e.g. 32*128 for BFALLx) but again, nothing.

Is this some known prBoom bug/limitation? E.g. must I also use the same exact patch names and resolutions for everything?

Share this post


Link to post

I am not certain about the prboom issue, if it is one or not. Could the animation sequence be out of sync? Holes in the texture? I won't be much help with that.

I wonder if it would be worth a question in the prboom issues thread?

I did notice you mis-spelled BLODGR in your post, is your texture mis-named?

I am pretty sure nukeage and bloodfalls textures are 64 X 128 so your size should not be a problem since you shrank it.

Can you test the texture with vanilla or chocolate ports? Maybe make a single square room with a pedestal in the middle of the room with the texture on it to test?

Share this post


Link to post
Searcher said:

I am not certain about the prboom issue, if it is one or not. Could the animation sequence be out of sync? Holes in the texture? I won't be much help with that.[/i]


Well, the error appears on the startup, not even inside the game, so there's obviously "something" it doesn't like about the textures.

About mispelling...yeah, it's only in my post. I tried the following names with prBoom: WFALLx, BFALLx, BLODGRx or whatever it was.

In all cases, it recognized them as an "animation cycle" but at the same time it said that it was "bad", without being anymore specific. Shrinking (or growing, in the case of BLODGRx) didn't solve the problem.
I'll try using an ANIMATE lump with my own custom names and see what happens. As I said, ZDoom and GZDoom accept it and don't complain anywhere, only prBoom does it. Will run a test with vanilla too, to see what happens.

If that has anything to do with the matter, the offending textures are used as "lower textures" and no, they don't have holes or transparencies.

BLODGRx on the other hand has a LOT of transparency! And I noticed the TNT WAD to have some inconsistencies: e.g. WFALL1 and WFALL4 exist, but there's no WFALL2 or WFALL3, while there's a FALL3 which looks like the continuation of WFALL1/4. Weird...

Share this post


Link to post

Hear ye, hear ye, here's what actually happens:

The BLOGR1-4, as well as the WFALL1-4 lumps don't actually progress as BLOGR1, BLOGR2... WFALL1, WFALL2 etc. but they are implemented as hacks that display the correct sequence only as:

BLODGR1
SW1SKULL
BLOD3
BLODGR4

and as

WFALL1
SW2SKULL
FALL3
WFALL4

These are actually 512*128 textures meant to represent several different things based on offset, perhaps due to the limited number of animated texture resources in vanilla.

After trying with vanilla and chocodoom, I discovered that the loading routines used in vanilla, chocodoom and prBoom are semi-broken and actually have to load all animation frames sequentially, and they must appear from first to last (1-4) in the TEXTURE1 lump. Any other order breaks the loading. ZDoom however actually corrects this behavior, even for animations defined in the ANIMATED lump, and it will load textures in the correct order no matter where they were saved in the WAD.

With WinTex, make sure animations are created sequentially, and check the TEXTURE1 lump to make sure. If not, cut and "insert" textures in the right places. Now you can save this thread for posterity :-)

Share this post


Link to post

That is good info. Thanks.

I am a bit confused however.

I am using both:
WFALL 1-4
SLADRIP 1-3
in a current/ in progress map and they load and play just fine in prboom, and vanilla. Maybe the engines are just overlooking wfall 2 and 3 if I understand you correctly. Anyway I am glad mine "appears to work"

Share this post


Link to post
Searcher said:

That is good info. Thanks.

I am a bit confused however.

I am using both:
WFALL 1-4
SLADRIP 1-3
in a current/ in progress map and they load and play just fine in prboom, and vanilla. Maybe the engines are just overlooking wfall 2 and 3 if I understand you correctly. Anyway I am glad mine "appears to work"


I'm not sure if they really don't load WFALL2/3 or BLODGR2/3 (maybe they do, if they are defined) however the loading routine in vanilla/prboom seems just to seek for Animation starts (Animx Start, these are hardcoded), and their ends (Animx end, hardcoded too).

If it finds the start but not at least one other frame, then it exits with an error. If it doesn't find the end but finds at least one other texture, then the first texture is used as a "static" one. It expects the "next" frames to be immediately after the first one, so storage order is important. In my first tests, order was reversed, so as soon as it found the start of an Anim, it found nothing else and exited with an error.

From all the above, it seems the names of the intermediate frames are NOT important, only the ones of the first and last frames of each animation, but storage order of all frames IS, and should always be first to last.

ZDoom and some other ports as I said, correct this behaviour and allow more flexibility (they ofc must provide their own hardcodings for the anomalous TNT animations, since they can even handle those in a scrambled order)

Share this post


Link to post

Excellent. Thanks. That makes more sense. Good info, I need to keep the web link address to this thread for future reference. I'm glad you went the extra mile to find out the specifics of this.

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
×