add support for colored blood and gibs #182
Conversation
Due to popular demand. 😉
|
On the speedrunning side, we actually don't allow any kind of sprite changes like this. Obviously prboom+ isn't constrained to dsda rules, which is why there's a separate port in the first place, but I felt like I should mention it anyway for posterity. |
prboom2/src/p_map.c
Outdated
| @@ -2008,6 +2009,7 @@ dboolean PIT_ChangeSector (mobj_t* thing) | |||
| mo = P_SpawnMobj (thing->x, | |||
| thing->y, | |||
| thing->z + thing->height/2, MT_BLOOD); | |||
| mo->target = thing; | |||
There was a problem hiding this comment.
With the way prboom+'s pointer cleanup works, you should use P_SetTarget instead of editing the target value directly. It probably wouldn't happen under normal constraints that a bleeding monster might be removed from memory, but I bet it's possible with dehacked, which could lead to some odd behaviour.
There was a problem hiding this comment.
Yes, it is indeed possible - and actually, doing this unconditionally may cause demo desyncs - not with the regular blood setup but if you add some code pointers that may work with the target pointer, all bets will be off.
I'd actually try to store the MT_ value somewhere instead of a target reference which may cause unforeseen issues
There was a problem hiding this comment.
Whoa, I wasn't even aware of P_SetTarget(), thanks!
I'd actually try to store the MT_ value somewhere instead of a target reference which may cause unforeseen issues
I'll see what I can do, but if I can't misuse an existing field in the mobj_t struct, then I'll have to introduce something new anywhere else. Stay tuned...
|
So, what do you guys say? |
If MF_COLOREDBLOOD is set and none of (MF_TRANSLATION1|MF_TRANSLATION2) this means green blood (Baron of Hell / Hell Knight) and if MF_TRANSLATION1 is additionally set this means blue blood (Cacodaemon). This allows for up to 4 different blood colors once MF_TRANSLATION2 is also taken into account. Let's see what we come up with...
Due to popular demand. 😉