Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] interlevel blood splats do not persist across map exits #2031

Open
elf-alchemist opened this issue Nov 18, 2024 · 34 comments · May be fixed by #2036
Open

[bug] interlevel blood splats do not persist across map exits #2031

elf-alchemist opened this issue Nov 18, 2024 · 34 comments · May be fixed by #2036

Comments

@elf-alchemist
Copy link

I have been trying to recreate the intermission screens from Doom 1 and I have noticed that the map completion splats are not persisting across map completion, which is not present in KEX. Both are using the same definition, extracted from LoR's id1.wad and having it's coordinates and graphics adapted to E1. The same behavior is also observed on Legacy of Rust, itself.

The lump in question:
https://gist.github.com/elf-alchemist/8a3f6e09afc037aa7aa9e3f4266dd737

Currently on Woof:
woof0099

Currently on KEX:
2280_20241118102733_1

@rfomin
Copy link
Collaborator

rfomin commented Nov 18, 2024

I can't replicate it yet. How do you test it, do you use -warp command? Woof stores the player path in save files. What is your UMAPINFO file?

I've made intermission screens for Sigil using this recources:
sigilint.zip

@elf-alchemist
Copy link
Author

elf-alchemist commented Nov 18, 2024

My testing is to idclip, iddqd and idkfa my way to the exits. This particular test of mine was done on my custom IWAD, again. Plainly using EnterAnim and ExitAnim:
https://gist.github.com/elf-alchemist/7b519bd333edeb874d2132dbc7ac96f8

I was actually planning to port all of the intermaps by DevilMyEyes myself, once I'd grokked the format well enough with D1.

I've just tested your compilation and it still happening. This one being done on plain doom.wad with KEX's sigil.wad. As I keyboard-cheated my way to exits of Sigil M1, M2 and M3, the blood splat on M1 did not persist:

woof0101

EDIT: I should note, all other animations are working fine, it is just the blood splat itself that is not persisting.

@OpenRift412
Copy link

I don't know if this was something that was added to Woof but I believe the interlevel format takes level warping into account.

For example, completing the levels sequentially will show blood splatter sprites for all completed levels. But if you IDCLEV to a level and then complete it, the map will only show a splatter for the level you just completed. This is just my observation. If I'm missing anything, let me know.

@elf-alchemist
Copy link
Author

elf-alchemist commented Nov 18, 2024

Aaaaaaaand even weirder, when just running this PWAD on doom.wad the blood splats now work, but the 0.667/0.333 "You are here" graphic timing is displaying incorrectly, looks more like 0.9/0.1?

EDIT: Forgot to be explicit, but yes this is the exact same set of interlevels.
EDIT2: Just tested with KEX and it works properly.

d1_interlevel_splats_arrow.zip

@rfomin
Copy link
Collaborator

rfomin commented Nov 19, 2024

For example, completing the levels sequentially will show blood splatter sprites for all completed levels. But if you IDCLEV to a level and then complete it, the map will only show a splatter for the level you just completed. This is just my observation. If I'm missing anything, let me know.

Yes, this is intended. With UMAPINFO it's not always possible to determine the player's path (there can be forks in the road), so Woof stores completed levels in save files. Does the KEX port behave differently? Anyway, I don't think this is a problem.

Aaaaaaaand even weirder, when just running this PWAD on doom.wad the blood splats now work, but the 0.667/0.333 "You are here" graphic timing is displaying incorrectly

There is only 0.333 duration in this file? Looks correct to me.

EDIT2: Just tested with KEX and it works properly.

d1_interlevel_splats_arrow.zip

KEX port crashes with this WAD for me with this error message: "Victory lump ExINTER is malformed."
I run it this way: doom -iwad doom.wad -file d1_interlevel_splats_arrow.wad

@elf-alchemist
Copy link
Author

Sorry, I accidentally sent the wrong version. This is the one I actually ran:
d1_interlevel_splats_arrow.zip

@rfomin
Copy link
Collaborator

rfomin commented Nov 19, 2024

Duration issue should be fixed here: #2036

I still can't replicate the splats problem, it always works for me.

@Ethel486
Copy link

I have been trying to recreate the intermission screens from Doom 1 and I have noticed that the map completion splats are not persisting across map completion, which is not present in KEX. Both are using the same definition, extracted from LoR's id1.wad and having it's coordinates and graphics adapted to E1. The same behavior is also observed on Legacy of Rust, itself.

The lump in question: https://gist.github.com/elf-alchemist/8a3f6e09afc037aa7aa9e3f4266dd737

Currently on Woof: woof0099

Currently on KEX: 2280_20241118102733_1

I think it may be the fact that they are all condition: 3 which states in the Interlevel specification that the map corresponding to the param value has been visited.

I think condition: 1 may work? But im not sure so give it a try first

@elf-alchemist
Copy link
Author

I've tested this branch with my usual local building process cd build && rm -rf * && cmake .. && sudo make install and the issue persists, even on id1.wad.

https://github.com/rfomin/woof/tree/fix_doom1_anim

On my end, the only other issue I see right now is that Cmake complains to me that it can't find yyjson, but all other JSON lumps work fine, so I doubt that's related.

CMake Warning at CMakeLists.txt:110 (find_package):
  By not providing "Findyyjson.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "yyjson", but
  CMake did not find one.

  Could not find a package configuration file provided by "yyjson" with any
  of the following names:

    yyjsonConfig.cmake
    yyjson-config.cmake

  Add the installation prefix of "yyjson" to CMAKE_PREFIX_PATH or set
  "yyjson_DIR" to a directory containing one of the above files.  If "yyjson"
  provides a separate development package or SDK, be sure it has been
  installed.

@rfomin
Copy link
Collaborator

rfomin commented Nov 19, 2024

I've tested this branch with my usual local building process cd build && rm -rf * && cmake .. && sudo make install and the issue persists, even on id1.wad.

I doubt it will help, but can you try AppImage artifact: https://github.com/fabiangreffrath/woof/actions/runs/11914116472/artifacts/2207403010

Are you aware that id1.wad was updated in the last major KEX port patch? The "level number" logic was changed. Otherwise I'm not sure what's wrong. Could you please make a minimal example with the bug? d1_interlevel_splats_arrow.zip works, right?

@elf-alchemist
Copy link
Author

Are you aware that id1.wad was updated in the last major KEX port patch? The "level number" logic was changed.

Yes, I updated my $DOOMWADDIR as soon as the update hit.

Otherwise I'm not sure what's wrong. Could you please make a minimal example with the bug? d1_interlevel_splats_arrow.zip works, right?

Yes it is still having issues to me on the branch from the PR.

I doubt it will help, but can you try AppImage artifact: https://github.com/fabiangreffrath/woof/actions/runs/11914116472/artifacts/2207403010

Aaaaaaand wouldn't you know it, the AppImage works with the blood splats in id1.wad and d1_interlevel_splats_arrow.wad.

But now neither the AppImage or the local build of the PR branch are rendering the "Entering" and levelpic graphics.

I don't know if it'll help but my local woof.cfg config is here, as always:
https://github.com/elf-alchemist/dotfiles/blob/main/local/share/woof/woof.cfg

@rfomin
Copy link
Collaborator

rfomin commented Nov 20, 2024

Aaaaaaand wouldn't you know it, the AppImage works with the blood splats in id1.wad and d1_interlevel_splats_arrow.wad.

I suspect there is something wrong with the git merge. For example, my fork of Woof is out of sync, I only use it for PRs and experiments. What is the output of the git remote -v command?

But now neither the AppImage or the local build of the PR branch are rendering the "Entering" and levelpic graphics.

Should be fixed now. I recommend using AppImages so you don't have to deal with the build process: https://github.com/fabiangreffrath/woof/actions/runs/11924808188?pr=2036

@elf-alchemist
Copy link
Author

Okay, Ive tested with the newest commit. Here's my setup right now:

  1. My local git clone of the fabiangreffrath/woof's master branch, for build from source

  2. My local git clone of rfomin/woof, currently checking out fix_doom1_anim, for building as well

  3. The downloaded AppImage from Actions' rfomin/woof:fix_doom1_anim

My current testing is to load -file id1.wad enter the first map of the first episode normally, then keyboard-cheat idclip, iddqd and lastly, twice iddt. I navigate through E1M1, enter E1M2, exit to E1M0.

Both 1 and 2 exhibit the non-persistent blood splats on id1.wad. The third shows blood splats normally.

Both 2 and 3 now show the "Entering" and levelpic graphics for a split-second before disappearing, while 1 is still missing the blood splat but showing the "Entering" graphics normally.

Not sure if it helps, but on a plain Debian Stable system with backports and proposed-updates repositories enabled. At this moment, the only thing I can think of is plain non-reproduced builds 🤷

OS: Debian GNU/Linux 12 (bookworm)
KERNEL: 6.1.0-22-amd64
CPU: Intel Core i5-8350U @ 1.70GHz
GPU: Intel Mesa Intel UHD 620 (KBL GT2)
GPU DRIVER: 4.6 Mesa 22.3.6
RAM: 8 GB

@rfomin
Copy link
Collaborator

rfomin commented Nov 20, 2024

2. My local git clone of rfomin/woof, currently checking out fix_doom1_anim, for building as well

Don't do that, my fork is very broken. I recommend using the GitHub CLI tool apt-get install gh.
Use only fabiangreffrath/woof repository, then run gh pr checkout 2036 it should merge correct version.

I recommend to delete your local copy of Woof repo and start over.

@elf-alchemist
Copy link
Author

I just did gh repo clone fabiangreffrath/woof and gh pr checkout 2036. The result remains the same, blood splats still don't persist and "Entering" graphics still disappear after a split-second.

@rfomin
Copy link
Collaborator

rfomin commented Nov 20, 2024

@elf-alchemist
Copy link
Author

Was about to log off when I saw b644b00 on my notifs. Rebuilt the local repo and tested with id1.wad, now "Entering" screen works -- same with the AppImage. Splat issue remaining 😕. Will have to take another look tomorrow.

@rfomin
Copy link
Collaborator

rfomin commented Nov 20, 2024

Splat issue remaining 😕.

Just did a walktrough of the first 3 levels of Doom 1 with d1_interlevel_splats_arrow.wad, everything works as expected:
woof0007

AppImage doesn't work either? My only theory is something in the autoload paths. Try running it with the -noautoload command line parameter.

@fabiangreffrath
Copy link
Owner

Could this have to do with the way we build and link yyjson? The AppImage embeds the Debian shared library, right? @elf-alchemist Could you try to install the libyyjson* packages from Debian testing (or backports if provided) and build Woof again?

@fabiangreffrath
Copy link
Owner

fabiangreffrath commented Nov 20, 2024

I can confirm that the arrow is blinking with a very strange rhythm in the fix_doom1_anim branch.

@rfomin
Copy link
Collaborator

rfomin commented Nov 20, 2024

The AppImage embeds the Debian shared library, right?

No, we build it on Ubuntu, which does not have yyjson.

I can confirm that the arrow is blinking with a very strange rhythm in the fix_doom1_anim branch.

Have you tested d1_interlevel_splats_arrow.zip? I thought the arrow was fixed now.

@fabiangreffrath
Copy link
Owner

No, we build it on Ubuntu, which does not have yyjson.

Right, it's in Debian just since May. Ubuntu hasn't caught up yet.

Have you tested d1_interlevel_splats_arrow.zip? I thought the arrow was fixed now.

Yes. The arrow is visible for about a second and then starts blinking.

@elf-alchemist
Copy link
Author

Could this have to do with the way we build and link yyjson? The AppImage embeds the Debian shared library, right? @elf-alchemist Could you try to install the libyyjson* packages from Debian testing (or backports if provided) and build Woof again?

I'm on Stable, It is not provided by backports yet, no. As far as I can understand, if I edit /etc/apt/sources.list to include testing but I do not apt upgrade my system packages should remain safe, correct? I won't try anything if it'll risk my install to revert to Stable.

Barring third-party repos, my sources.list looks like this:
image

@fabiangreffrath
Copy link
Owner

I'm on Stable, It is not provided by backports yet, no. As far as I can understand, if I edit /etc/apt/sources.list to include testing but I do not apt upgrade my system packages should remain safe, correct?

Please don't do that. What you could do is download the libyyjson0 and libyyjson-dev packages as deb files and install them manually with dpkg. But I don't want to push you into experiments.

@elf-alchemist
Copy link
Author

I've rebuilt using Testing's libyyjson0 and libyyjson-dev. This time no yyjson CMake error message (so I assume it is linking to the newly installed one) and splats remain bugged.

@elf-alchemist
Copy link
Author

Just did a walktrough of the first 3 levels of Doom 1 with d1_interlevel_splats_arrow.wad, everything works as expected:
AppImage doesn't work either? My only theory is something in the autoload paths. Try running it with the -noautoload command line parameter.

I overlooked this one ealier. I just tested id1.wad and d1_interlevels on my local build with -noautoload, the issue persists. And yeah the AppImage works with both, -noautoload or not.

Although I have just noticed, on my local build of fix_doom1_anim, that the old blood splats seem to "blink" for a very brief period before disappearing, while the just-visited map remains, maybe that could be a hint as to what is happening?

@rfomin
Copy link
Collaborator

rfomin commented Nov 21, 2024

Have you tested d1_interlevel_splats_arrow.zip? I thought the arrow was fixed now.

Yes. The arrow is visible for about a second and then starts blinking.

Should be fixed in 23a49b5

And yeah the AppImage works with both, -noautoload or not.

Where do you run AppImage? Maybe there is a different configuration of environment variables like DOOMWADDIR. For example, Woof automatically loads "extras.wad", maybe you have such a file somewhere with modifications. Could you paste a startup log of Woof here? For example:

W_Init: Init WADfiles.
 adding c:\develop\woof\build\src\woof.pk3
 adding C:\downloads\wads\doom2.wad
 - "DOOM II: Hell on Earth" version

M_LoadDefaults: Load system defaults.

@fabiangreffrath
Copy link
Owner

Should be fixed in 23a49b5

I'm glad you could fix this. I'll be able to check tomorrow.

@elf-alchemist
Copy link
Author

elf-alchemist commented Nov 21, 2024

Where do you run AppImage? Maybe there is a different configuration of environment variables like DOOMWADDIR. For example, Woof automatically loads "extras.wad", maybe you have such a file somewhere with modifications. Could you paste a startup log of Woof here?

I've had extras.wad removed from my $DOOMWADDIR since its autoloading was added. So unless I have -noautoload I only see the woof.pk3, the IWAD, the autoload dir and PWAD just as normal.

Locally built fix_doom1_anim with d1_interlevel, for example.

W_Init: Init WADfiles.
 adding /usr/local/bin/../share/woof/woof.pk3
 adding doom.wad
 - "The Ultimate DOOM" version
 adding /usr/local/bin/../share/woof/autoload/all-all/woofhud.lmp
 adding /usr/local/bin/../share/woof/autoload/doom-all/brghtmps.lmp
 adding /home/alchemist/Desktop/d1_interlevel_splats_arrow.wad

My doom-related dirs in my bashrc are only as follows:

export DOOMWADDIR="${HOME}/doom"
export DOOMWADPATH="${DOOMWADDIR}:/usr/local/share/games/doom:/usr/local/share/doom:/usr/share/games/doom:/usr/share/doom"

On another note, I've quickly tested both id1.wad and d1_interlevel using local fix_doom1_anim -warp and the issue persists there, as well. And still, the missing visited maps "blink" their blood splat for a fraction of a second before disappearing, while keeping only the map that was just visited.
woof0135

@rfomin
Copy link
Collaborator

rfomin commented Nov 21, 2024

On another note, I've quickly tested both id1.wad and d1_interlevel using local fix_doom1_anim -warp and the issue persists there, as well.

This is normal. Both IDCLEV and -warp do not show completed levels, because it's not always possible to determine from UMAPINFO (there could be many secret levels and two exits on each map).

@fabiangreffrath
Copy link
Owner

I can confirm that when using IDCLEV17 in E1M1 and hitting the switch that the blood splats for the former levels appear for a split second. This is on the fix_doom1_anim branch with d1_interlevel_splats_arrow.zip loaded.

@rfomin
Copy link
Collaborator

rfomin commented Nov 22, 2024

I can confirm that when using IDCLEV17 in E1M1 and hitting the switch that the blood splats for the former levels appear for a split second. This is on the fix_doom1_anim branch with d1_interlevel_splats_arrow.zip loaded.

Should be fixed in 587a383

@elf-alchemist
Copy link
Author

New, surprising development on my end.

I've started to add the actual map animations onto doom1_interlevel.wad, and by adding the WIA00* images, the locally built master now works with the blood splats, yet the fix_d1_anims branch breaks.

On branch master (the arrow presented the timing issue fixed on fix_d1_anims, otherwise they worked normally):
woof0146

On branch fix_d1_anims:
woof0147

@elf-alchemist
Copy link
Author

Dumb me should stop trying to write issues late at night :p
Here's the new WAD, only the E1 inter map anims are in, for now
doom1_interlevel.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants