Vanilla Doom smooth monsters? (split)

[unpleasantmarine]

[Mod note: Split from this thread]

 

Would a smooth monsters animations be possible too

[Spie812]

4 hours ago, unpleasantmarine said:

Would a smooth monsters animations be possible too

No. Vanilla Doom only has a certain number of images, or frames, that can be assigned to various monsters and items. Adding new frames means taking them away from somewhere else. Many small animations were sacrificed to make even the smooth weapons possible. There's simply no room to fit in any "smooth monsters." If you want smooth monsters, you'll have to turn to more advanced ports and mods, such as Smooth Doom for the Zdoom family. Under Vanilla Doom, it simply isn't possible.

[fraggle]

Monsters are out of scope for this project.

[Doomkid]

Until Ling makes his version of dehacked with 200 extra blank states, that is. He mentioned it offhand as a potential project one time years ago but I’m still keen!

[Spie812]

46 minutes ago, Doomkid said:

Until Ling makes his version of dehacked with 200 extra blank states, that is.

Oh, it's a Dehacked limit? I'd always just assumed that it was an engine limitation.

[Beezle]

19 hours ago, unpleasantmarine said:

Would a smooth monsters animations be possible too

There is this mod I downloaded about a month ago and it works really well with Crispy Doom, just add Fraggle's vsmooth.wad and you got Smooth Doom in Crispy:) https://www.doomworld.com/forum/topic/85991-smoothed-smooth-monsters-for-doom-retro-and-crispy-doom/

[kb1]

On 6/10/2019 at 9:56 PM, Doomkid said:

Until Ling makes his version of dehacked with 200 extra blank states, that is. He mentioned it offhand as a potential project one time years ago but I’m still keen!

I thought that was first my idea...(not that there's much to the idea, of course)

 

On 6/10/2019 at 10:43 PM, Spie812 said:

Oh, it's a Dehacked limit? I'd always just assumed that it was an engine limitation.

It's a Dehacked limit because it's an engine limit. There are only so many frames that can be changed. The number of frames available is the limit. Sprite animation is achieved when the monster, or shield, or candelabra switches to a different frame, causing a different image to show. Each monster step is a frame. Monsters also have attack, pain, and death frames, and sometimes a few others.

 

Dehacked lets you re-purpose one or more of these frames. The Smooth Weapons project re-purposes a small number of rarely-used, less-important frames to add additional frames to the weapons. A Smooth Monsters mod would require many new frames...but DeHacked cannot provide more frames than are there originally.

[Doomkid]

So does Doom itself just have a limited range of states it can call? That would make sense, I was hoping the change to allow extra frames would be trivial but I guess even trivial changes put it beyond the scope of vanilla - at which point you may as well just use one of the many source ports with extended dehacked or decorate support.. (damn, this killed a little half dream I’ve had about vanilla compat mods with significantly more animation frames!)

[kb1]

There is a specific space in the executable allocated for the states that were hard-coded in the info.c source file. On both sides of this table are other data structures and/or executable code.

 

Now, in a source port, you can add as many states as you want to this structure. But DeHacked can only modify the original executables.

 

*However*, if you're really good at machine language, it might be possible to relocate the table, either by hacking the DOS .exe file format, or by inserting a small bit of code that would copy the table elsewhere. Also, you'd have to update all pointers to the table, to allow the executable to find the data in the new location. If you could accomplish all that, you could then extend the table with new states. You'd also have to modify DeHacked to allow it to edit the data in it's new location, and to be ok with there being more states than usual. But, there's more than just frames. For completely new content, you'd want new space for frames, thingdefs, spritedefs, sounddefs, etc. It's a ton of work.

 

It was reasonable to make a tool like DeHacked, to provide a way to edit these preexisting tables. DeHacked simply needs to know where the table starts in the executable, how big the table is, how big each variable in a frame is, and what its purpose is. DeHacked simply provides a GUI for editing this table (which involves simply changing the numbers in the table in a meaningful way.) But adding new space to the table would require everything after the table to be pushed to a new location, which messes up thousands of pointers that expect everything to be in its original place.

 

Practically speaking, it's the job of a source port. Many ports have removed the hard-coded data table, and they read it in at run-time as data. Because the source code is aware of this, moving that table around in memory is not a problem. My home port, KBDoom reads the state data from KBDoom.WAD, for example. Other examples include Eternity and ZDoom, to name a few. ZDoom reads and parses Decorate lumps to build the frame table dynamically. These ports can add new frames at will.

 

But, even if the source port retains the hard-coded data table, it's easy to simply add some new states to the end of the list. DeHacked was originally designed to make changes to Doom(2).exe. But, since the release of the source code, many source ports can read DeHacked data, and, instead of modify their executable files, they modify their in-memory copy of the frame data at run-time. These source ports could add a chunk of empty frame data at the end of their in-memory frame table, and then modify their DeHacked parsers to support higher frame numbers than usual, to access the additional frames.

 

Of course, the question becomes "How many frames should be added?". If the port is not loading the frame table at runtime, it must hard-code a *reasonable* number of frames (and hopefully also thingdefs, spritedefs, sounddefs, etc). And, adding empty space does consume memory, so there's a bit of a conflict of interest.

 

I think Doom II's frame table has about 1,000 frames. Monsters need somewhere around 25 frames for walking, fighting, pain, death, and xdeath frames. So, by adding 1,000 blank frames, you might have enough space for 40 new monsters or so. Of course, you also need 40 new thingdefs, 40 new spritedefs, a few dozen new sounddefs, etc.

 

I was discussing this while considering CDEX (Compatible Doom EXtensions) - a protocol where port devs agree on a compatible way to extend Doom past Boom/MBF standards. Part of this was to consider a compatible way to define things/frames/sounds. Then I got bogged down, and I still have a nearly completed draft that I haven't been able to find the time to finish. But, I'm still convinced that the best way to extend the frame table is for source ports to build their frame tables dynamically, using a frame/thing definition language. I vote for a generalized Decorate-like syntax. Decorate has seen the most success of any thing/frame language in Doom.

 

At one time, I too wanted to have ports add blank frames. But, since it won't work in vanilla, it seems like a half effort. Why not go all the way, and actually be able to define all the frames needed?

 

[fraggle]

On 6/10/2019 at 9:56 PM, Doomkid said:

Until Ling makes his version of dehacked with 200 extra blank states, that is.

No, when I say that it's out of scope for my project, I mean it.

 

Splitting out this derail so that the original thread can stay on topic.

[kb1]

1 hour ago, fraggle said:

No, when I say that it's out of scope for my project, I mean it.

 

Splitting out this derail so that the original thread can stay on topic.

Sorry Fraggle. I wouldn't have answered so completely, except that the fact that your smooth weapons mod works within a demo-compatible vanilla-compatible way, without requiring new frames, seems relevant. Knowing what it took for you to get it to work makes it that much more appreciated and interesting.

 

Translation: Fraggle carefully scoured Doom's frame table, looking for the frames that were least likely to be missed, and re-purposed them as extra weapon frames, thereby providing smoother animations. Frame timings were also very carefully adjusted, so vanilla demos would stay in sync while also showing the smoother weapon frames. Finding these extra frames is non-trivial, and Fraggle also made a tool that can be used to make finding these frames easier.

 

I'm not 100% sure, but I believe that the Smooth Weapons mod demonstrates the upper limit of what can be done with frames, while remaining in perfect demo sync. Nice job!

 

[Doomkid]

Yeah I’m sorry for causing a derail - I genuinely thought there would be a possibility for smooth Doom monsters in vanilla if the frame limitation could be overcome, but now that I know it’s not I’ll put it out of my mind. I was also slightly joking with my comment in the first place, it was more wishful thinking than anything else.