Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
suicidal pencil

pseudo texture animations

Recommended Posts

I think I should explain what I call pseudo texture animation. Think of the textures BFALL1 to BFALL4. They change in such a way that it looks like blood is running down the wall. Now, I'm curious on how to actually accomplish this. What do I actually do to create such a texture? (Can't be the naming, since you don't see ASHWALL6 and ASHWALL7 animating together <_<)

Share this post


Link to post

In normal doom2, it actually is the naming. The game has a limited number of animated textures, to make a new one, you have to replace an old one, and use it's name. However a few animated names aren't used in doom2, like WFALL and the dripping slime grate from Doom1, so you can use those and not replace an existing texture.
Zdoom handles animated textures differently so it might be easier if you don't care about compatibility, etc.

Share this post


Link to post

AFAIK you can add new animated textures in anything Boom-compatible for that matter, not just ZDoom. There's a lump called ANIMDEFS that controls it, for those ports.

Share this post


Link to post
Stilgar said:

There's a lump called ANIMDEFS that controls it, for those ports.

No the BOOM lump is called ANIMATED.
There is a BOOM lump for switches too called SWITCHES.
They both can be generated by old program called SWANTBLS.EXE or possibly with some newer programs.

Share this post


Link to post

If you are replacing the Doom II textures, then be aware that the BFALL and WFALL textures will not leave bullet holes, but some of the others will. I was making a map once where I replaced one of the Doom II animated textures with a computer screen and another with a lavafall, but since I replaced the wrong textures the lavafall could get bullet holes, which looked really ugly, and the screen would not, which was just weird. Also, with the Doom grate texture, there is a way (you can see it in TNT.WAD) to add a lot of extra animation frames, if you want them.

Share this post


Link to post
StupidBunny said:

If you are replacing the Doom II textures, then be aware that the BFALL and WFALL textures will not leave bullet holes


That only matters with ports that add decal's to doom. I wouldn't base my choices around that.

In the original Doom engine, the engine simply searched for two textures of hardcoded name inside a wad and then played an animated sequence consisting of those two textures and every other texture in-between them. Hence you could extend or shorten one of the original games animated texture sequences by reordering the textures

Some source ports however define the entire sequence graphic by graphic meaning this Vanilla Doom hack wouldn't work.

Certainly though, the Boom ANIMATED lump should work on every major port (but obviously not the original Doom engine) out there from Doomsday through ZDoom because every major port supports Boom to some extent.

Share this post


Link to post

ANIMDEFS: ZDoom's lump for animated textures/flats.

ANIMATED: Boom's lump for animated textures/flats (I think). By the way, I find it much easier with ZDoom's method, and, anyway, there isn't much problem with people needing ZDoom-compatible ports to play your WAD...


Good luck...

Share this post


Link to post
swordgrunt said:

there isn't much problem with people needing ZDoom-compatible ports to play your WAD...

It is a problem if you're preventing all the other sourceports from playing your wad just to do something that's not even a ZDoom-specific feature.

Share this post


Link to post

The most pathetic thing is that almost no other port has implemented basic Hexen ANIMDEFS functionality so far. What is it with the 'basic' ports to refuse even implementing the simplest features that would make life easier?

Sorry, all you ZDoom haters, but if that won't change there will always be maps that use ZDoom or any other high end port just for convenience.

Share this post


Link to post

Stilgar said:
AFAIK you can add new animated textures in anything Boom-compatible for that matter, not just ZDoom. There's a lump called ANIMDEFS that controls it, for those ports.

You can also make use of additional animated texturing that works in any engine by adding them to existing animated textures.

Graf Zahl said:
all you ZDoom haters,

"You're either with us or against us!"

Seriously, how is esselfortium a ZDoom hater when he currently makes ZDoom levels?

Share this post


Link to post
Graf Zahl said:

The most pathetic thing is that almost no other port has implemented basic Hexen ANIMDEFS functionality so far.

Rubbish, EDGE has had a text editable animation definitions ever since it first came out, namely ANIMS.DDF (stored in the DDFANIM lump), and I think it was in DOSDoom before that.

Share this post


Link to post

I said 'almost' no other port.

That said, each port doing its own thing instead of supporting something that could be considered standard is also something that doesn't really help. And the only non-Boom thing I could see become standard is Hexen's ANIMDEFS implementation, particularly now that Raven's code is GPL.

myk said:

Seriously, how is esselfortium a ZDoom hater when he currently makes ZDoom levels?



I don't think esselfortium would be bothered by maps that are ZDoom exclusive. But some here obviously are as some vocal complaints in certain threads show. What is it with some people here that they feel the need to distort a statement into something it doesn't mean? :?

Share this post


Link to post
myk said:

You can also make use of additional animated texturing that works in any engine by adding them to existing animated textures.

That is a ugly, hacky way to do it and it can be broken by people using hi-res texture packs. Also, it limits how you can use the new texture (and the original) because it will force you to do stupid things like breaking a long wall into several tiny linedefs so that the texture mixing doesn't show.

Share this post


Link to post
Graf Zahl said:

What is it with some people here that they feel the need to distort a statement into something it doesn't mean? :?

For some it's reverse snobbery, the others just like rattling your cage.

Share this post


Link to post

Graf Zahl said:
But some here obviously are as some vocal complaints in certain threads show. What is it with some people here that they feel the need to distort a statement into something it doesn't mean? :?

I distorted nothing because you replied to essel's comment, not who-knows-what-from-where. Unless you mean you just made a generic flame bait post addressing people you don't name and who probably haven't even posted in the thread, resentfully reacting to something they said in another part of the forum or community.

It's like you can sense the community is shrinking, so you get all jealous when you see other people are preferring something other than what you prefer or think would "help". Why not just work with what there is and do your own stuff rather than complain that the community is letting you down? Are you a masochist or something?

Gez said:
That is a ugly, hacky way to do it and it can be broken by people using hi-res texture packs. Also, it limits how you can use the new texture (and the original) because it will force you to do stupid things like breaking a long wall into several tiny linedefs so that the texture mixing doesn't show.

Well, your mom is ugly and stupid too, and those limitations you mentioned are offset by the limitations of the other methods. Lots of people find vanilla satisfying (either generally preferring it or using it for some of their projects), either because of the game behavior or because it's perpetual (or both, of course); it doesn't depend on some dudes coding and updating a few engines or on the whims of certain people supporting this or that in whatever way it ends up coming out.

I'd use it any day for a plain level, and reserve the other methods for when I want things like Boom extensions, scripting, slopes, or DDF customizability and 3D floors. It runs on anything on whatever platform and it'll be around in 15 years if DOOM is still played, no matter what modified source ports evolve into, if they are still maintained then. And it delivers the simple in-your-face DOOM gameplay mechanics we know.

Besides, high res resources? Those are a problem more often than not when resources are included in the WAD because if you change certain resources, they look pretty much out of place. Never mind a PC or TC, where stuff is rearranged or tweaked; a huge mess may often occur.

Using the ZDoom method or whatever may be easier or more convenient in some ways and some will use it for whatever reason, but it's clear that if you use it in a WAD that would otherwise work on other engines, you immediately restrict the engines people can use for a functionality that would work in the engines they would prefer to use unless something else is really necessary. They are naturally going to point that out. It's not like they're going to go to the Shores Of ZDoom thread and say "oh no, this doesn't work in PrBoom, I'm going to die" because it's pointless and most don't care, but if they see a WAD that would work in Chocolate Doom but doesn't because it uses one little thing that could still be done in vanilla in another way they'll say "this is bullshit".

Share this post


Link to post

Whatever. It's a clumsy, cumbersome and rather limited way to do it no matter how you rationalize it with the "other ports" argument. First, what if you need more frames? Some ports do the animation by name, not by taking whatever is in between the first and the last. Secondly, what if you need a different speed?

Furthermore, since you speak of Chocolate Doom, you know there's a strong chance for it getting ANIMDEFS support somewhat soon anyway, what with Chocolate Hexen being planned. It's not like it'd alter look, gameplay or demo compatibility since it's just a better, cleaner way to achieve something that was already possible through widespread hacks.

Share this post


Link to post

Gez said:
Whatever. It's a clumsy, cumbersome and rather limited way to do it no matter how you rationalize it with the "other ports" argument.

To you. To people intent on working with vanilla for reasons you do not seem to value, making things non-cumbersome is not necessarily priority number one. Many will just weight between using this "clumsy" method (full vanilla possibilities) or no new animated textures ("non-cumbersome" vanilla). I'm not interested in convincing you, just pointing out how people will disagree with you so you don't bother trying to convince others in vain.

Furthermore, since you speak of Chocolate Doom, you know there's a strong chance for it getting ANIMDEFS support somewhat soon anyway, what with Chocolate Hexen being planned. It's not like it'd alter look, gameplay or demo compatibility since it's just a better, cleaner way to achieve something that was already possible through widespread hacks.

Check this thread out. You're seeing this from a viewpoint that applies to ZDoom and other new-feature-oriented ports, but not to something that serves a pretty different purpose. Anyone interested in making such a combination of features (one would think for more than just a lousy animated texture) should better make a level set for an advanced engine, like ZDoom or the Eternity Engine.

Share this post


Link to post
Graf Zahl said:

That said, each port doing its own thing instead of supporting something that could be considered standard is also something that doesn't really help.

I agree. A good example of that is a port which added a feature for defining new things and weapons, and could have used an existing standard for that (DDF), with some improvements (DDF lacks inheritance for example). Instead a completely new and incompatible system was developed.

Heh, I am joking, but it shows that it's a lot easier to tell everybody to follow standards when you are the one setting the standard and not the one who has to follow somebody else's standard.

Gez said:

furthermore, since you speak of Chocolate Doom, you know there's a strong chance for it getting ANIMDEFS support somewhat soon anyway

Actually I think that is unlikely, because Chocolate Doom is not about adding features but maintaining compatibility with the original DOOM binary.

Share this post


Link to post

I'm struggling to think of a "major" port that does not have a means to define new animated texture/flat sequences. As for ANIMDEFS support I'll add it to my todo list for future jDoom and jHeretic releases.

The Zdoom devs really shouldn't moan about other ports not adopting features from Zdoom, so as to standardize. Given the sheer number of features that Zdoom has gained that were already present in one port or another, yet it was necessary for whatever reason to re-invent.

To be blunt, Zdoom doesn't exactly have a great track record when it comes to supporting designed-for-Zdoom features, with more than a few that have been depreciated or changed in a non-backwards compatible way. So even the idea of taking a Zdoom feature without going through the design process ones self strikes me as foolish to say the least and thats before practical, license and code-level considerations.

Do please note that I'm neither bashing the port nor the devs but... you started it:P

Share this post


Link to post
DaniJ said:

I'm struggling to think of a "major" port that does not have a means to define new animated texture/flat sequences. As for ANIMDEFS support I'll add it to my todo list for future jDoom and jHeretic releases.

The Zdoom devs really shouldn't moan about other ports not adopting features from Zdoom, so as to standardize. Given the sheer number of features that Zdoom has gained that were already present in one port or another, yet it was necessary for whatever reason to re-invent.


Yes, some things had to be reinvented - for the sole reason that all existing schemes had unacceptable limitations or were just not really usable. And since you posted this I'll just list DED's actor definitions as a case in point. I can remember a long discussion I had with you a few years ago about this. ;)

To be blunt, Zdoom doesn't exactly have a great track record when it comes to supporting designed-for-Zdoom features, with more than a few that have been depreciated or changed in a non-backwards compatible way. So even the idea of taking a Zdoom feature without going through the design process ones self strikes me as foolish to say the least and thats before practical, license and code-level considerations.


Please name one feature that has been changed in a non-compatible way. Bugs excepted of course. Sometimes it sadly happens that bugs creep into the engine and some users start to exploit them. Unfortunately later they have to be fixed and the problems start.

Yes, I know of WADs that intentionally or accidentally exploit bugs. But how should we deal with it? Leave the bugs in and cripple the engine or fix them and render a handful of levels inoperable but ensure future stability.

Share this post


Link to post

All I was trying to say is this:

If you're only using vanilla (or limit-removing or whatever) features in your map, you could add new animations by replacing any of the ones that you're not using. Unless you're making a 32-map megawad, it's very unlikely that you're already using every animation defined in the game. There are some, like WFALL (not used at all in Doom1 or Doom2), BLODRIP and BLODGR (very rarely used), DBRAIN (could be replaced with an actual lava texture or something else), the SWATER flats (not used in any iwads), etc. that are obvious candidates for replacement. You can even make the animations longer by sticking more frames in between the first and last one. And that's all while still allowing every existing sourceport (unless there exists a sourceport that breaks vanilla compatibility *that* badly) to play your map...

If you're using Boom features, which (let's be honest here), are capable of a lot more than most advanced-sourceport editors will give them credit for, you could either use the vanilla replacement method or the ANIMATED lump, as was mentioned. It's true that it's a slightly less convenient method than the text-based ANIMDEFS lump, but if your project is otherwise only using Boom features, it would make sense to use this instead of something that's restricted to one port. Because that would be about as silly as releasing a vanilla map that has untagged lifts because you only tested it in ZDoom and just assumed that everyone else would play it in that, too.

There's no problem with making wads for ZDoom or other "advanced" engines, and my stance on that should be obvious considering I'm currently involved with several ZDoom (and/or Skulltag) projects, two Eternity projects, one Boom project, and two vanilla projects. I even used to experiment around with mapping for Legacy and Doomsday Engine years ago. Advanced sourceports are perfectly fine, but when their developers start infringing on all the other ports' territory with the 'why would you use their crappy worthless feature that everyone supports when you could instead use our feature-equivalent one that no one else can read', regardless of whether or not some other ports would be interested in eventually supporting that format (as I know some are), I find that problematic.

In other news, I can't exactly name any specific features that have been changed in a non-compatible way (other than the tranmap and colormap stuff that you already know about and aren't going to change), but ZDoom's differences in line walk-triggering behavior (triggering when the player is in the middle of the line, I think, instead of as soon as they touch it), does affect some voodoo-doll scripts in unwanted ways. As a result of that difference (and the lack of a compatibility flag for it that I know of), I recently had to make a bunch of ugly compromises to get a Boom spinning ceiling fan (sectors, not midtex) to work properly in both ZDoom and Boom-compatible ports. :\

Meh.

Share this post


Link to post
esselfortium said:

but ZDoom's differences in line walk-triggering behavior (triggering when the player is in the middle of the line, I think, instead of as soon as they touch it), does affect some voodoo-doll scripts in unwanted ways. As a result of that difference (and the lack of a compatibility flag for it that I know of), I recently had to make a bunch of ugly compromises to get a Boom spinning ceiling fan (sectors, not midtex) to work properly in both ZDoom and Boom-compatible ports. :\


What makes you think that? The trigger mechanism is precisely the same! Otherwise nothing would work properly - (and frankly it'd become unplayable.)

What may affect Voodoo scripts is the way scrollers are handled - but there's a compatibility option to revert that to Boom's way of doing things.

You even can add a MAPINFO that automatically sets it for your map (compat_boomscroll)

Share this post


Link to post
Graf Zahl said:

What makes you think that? The trigger mechanism is precisely the same! Otherwise nothing would work properly - (and frankly it'd become unplayable.)

What may affect Voodoo scripts is the way scrollers are handled - but there's a compatibility option to revert that to Boom's way of doing things.

You even can add a MAPINFO that automatically sets it for your map (compat_boomscroll)

Hmm... There is *some* sort of difference in trigger behavior, though I'm not sure what it is. When Nuxius was testing the barrel-triggered voodoo scripts that are now used in KDiKDiZD, he discovered that, to get the same result in ZDoom, either the lines or the player or something had to be moved slightly. So, I dunno, maybe it's an issue with barrel damage being changed, and/or the player's movement in response to that damage, and not with the triggers themselves. I don't understand all the technical aspects of it, only what I've been able to observe.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×