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

selliott4

Members
  • Content count

    32
  • Joined

  • Last visited

About selliott4

  • Rank
    Green Marine

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. selliott4

    Improving player front walk animation

    It looks more like actual walking with your change. I think before maybe there was a huge amount of perspective, like the viewer was close, and maybe close to his feet, but I'm not sure why that would be. I like what you did.
  2. selliott4

    Finishing up PR 481

    I just submitted PR 547 with what I proposed in my previous comment. I've also closed out PR 481 since PR 547 replaces it.
  3. selliott4

    Finishing up PR 481

    After thinking about it a bit more I think they way to go is to have a Python script, sort of like the one I just proposed, that can both fix the map names *and* test that if they are correct. So something like "scripts/fix-map-names" since I think there is a desire to keep scripts in "scripts". By default fix-map-names would iterate through the files in "levels" and print out a table of any incorrect WAD files, the map name it had, and the correct map name it was changed to. It could be run after replacing or reordering maps. To test if the maps names are correct the new "test-map-names" build target would call something like "fix-map-names -t" where the "-t" option would test, which would effectively make it a dry run. This way the concept of having a basic test scaffolding run by "make test" is maintained where people could add "test-*" build targets, anyone could easily fix or test the map names at any time, and redundancy between testing and fixing scripts would be avoided (my proposed fix-map-names script would obsolete the current test-map-names in my PR). How does that sound? I would probably submit such a script some evening this week, or the weekend.
  4. selliott4

    Finishing up PR 481

    That's a good question. I thought (hoped?) that things are settling down and that rearrangements or replacements are getting to be less common, but you know better than me. In any case I don't mind checking in again in a few months and fixing it again. True, that could be done, but it would make wad2image output even more confusing. It's also possible I should update wad2image to generate image files based on the filename passed to it. In any case, one question is if the map names have any value for anything else such as build error messages, making things less confusing for people editing the files, people consuming Freedoom resources, or whatever. I don't know the answer though. The map name is the name of the first lump, which has a zero byte value. I assume that lump is required, but what if it could be stripped out of the WAD files in the "levels" directory combined with something being passed to duetex, possibly with a duetex modification, telling it what map name each file was? That may be getting more ambitious than we want to talk about though. And finally, a script could be written that automates fixing the map names. Since the map name is just the first lump name it could be done with a Python script that decodes reads the WAD file directly without any dependencies, and then writes the correct name. It would have some regexs to map from Freedoom filename, to Doom map name. I don't think it would be too hard. I could possibly write such a script.
  5. selliott4

    Finishing up PR 481

    Since PR 481 has been open for over a year I thought I'd see if there's anything I can do to finish it up. PR 481 is about making sure that he nap name for the WAD files in the "levels" directory match the file names. My interest in this has to do with the fact that wad2image that I wrote, which has been integrated into Freedoom's "Makefile", generates images based on the map name, not the filename. This means that the output is confusing when the map name is incorrect. wad2image works this way since it can work with WAD files that contain multiple levels. PR 481 has two parts, the fix, which literally alters only a few bytes per effected WAD file, and a shell script that can report on the problem in the future including what the current incorrect names are, and what they should be changed to. For the script I thought it might be nice to add a basic test scaffolding. In this case a new target "test" depends on a "test-map-names" target which runs "tests/test-map-names". That way if someone wants to add a test in the future there's a pattern to follow. But if you don't like it I can change it. I can move the script to the "scripts" directory with a "test" prefix. I can get rid of the build targets, or whatever you want. PR 545 adds instructions on how to do enable binary diffing in git. If those instructions are followed here's what it looks like for one of the files that PR 481 changed: diff --git a/levels/map18.wad b/levels/map18.wad index b2ea036..1e9d1b6 100644 --- a/levels/map18.wad +++ b/levels/map18.wad @@ -15179,7 +15179,7 @@ 0003b4e0 00 b5 04 f8 04 02 05 0c 05 ff ff 00 00 b5 04 f8 |................| 0003b4f0 04 ff ff 00 00 b5 04 f8 04 f9 04 ff ff 00 00 b1 |................| 0003b500 01 b5 04 ff ff 0c 00 00 00 00 00 00 00 4d 41 50 |.............MAP| -0003b510 30 36 00 00 00 0c 00 00 00 34 17 00 00 54 48 49 |06.......4...THI| +0003b510 31 38 00 00 00 0c 00 00 00 34 17 00 00 54 48 49 |18.......4...THI| 0003b520 4e 47 53 00 00 40 17 00 00 d8 6b 00 00 4c 49 4e |NGS..@....k..LIN| 0003b530 45 44 45 46 53 18 83 00 00 d0 6a 01 00 53 49 44 |EDEFS.....j..SID| 0003b540 45 44 45 46 53 e8 ed 01 00 f8 1e 00 00 56 45 52 |EDEFS........VER| Since I can understand that a relative unknown (me) changing a bunch of WAD files might be concerning I thought PR 545 might be helpful in this case, and possibly future cases, to make it easier to see that there are no extraneous changes.
  6. It's a bit surprising to me that levels are still going to be replaced, not just edited, which I'm guessing is how this happens. In any case I could take that one liner and make it into a script, something like "scripts/test-map-names.sh". There would then be a build target like "test-map-names" that ran it. There could be a new "test" target that then depends on "test-map-name" so additional tests could be added easily in the future. Does that sound about right? I think fixing this problem in an automated manner is a harder problem than detecting it. I can just check again in a while and submit another CR if need be.
  7. I've submitted pull request 481 for this.
  8. I noticed that some of the WAD files in the "levels" directory contain maps that do not match the filename. For example, "map08.wad" contains MAP01. Here's a one liner to get a list of all WAD files that contain unexpected maps: cd levels; for w in c*.wad dm*.wad map*.wad; do l=${w%.wad}; l=${l^^}; l=${l/DM/MAP}; l=${l/C/E}; bad=$(yadex $w < /dev/null | grep " Levels:" | grep -v $l | awk '{print $2}'); if [[ -n $bad ]]; then echo -e "$w\t$bad"; fi; done And the output it produced: dm31.wad MAP01 dm32.wad MAP01 map06.wad MAP04 map08.wad MAP01 map13.wad MAP09 map14.wad MAP03 map18.wad MAP06 map19.wad MAP08 map24.wad MAP06 map32.wad MAP01 I realize that the build handles this correctly, that the filename drives what maps ends up as in the final "freedoom*.wad" files, but it's still a bit confusing. For example, wad2image, which I'm in the process of trying to get integrated into the build, generates images based on the map name, not the filename. Fortunately based on a quick experiment I did it's possible to change the map name within the WAD file with a hex editor without otherwise changing a map. In other words it's possible to edit the map names listed above by only changing one or two bytes in the containing WAD file. The build seems to still work correctly after the edit. Should I submit a pull request with the map names edited to match the WAD files?
  9. I've finally submitted a significantly overhauled pull request in part based on feedback I received. I hope it's helpful. Let me know what you guys think.
  10. I've looked at it more carefully and 0.9.1, which I mentioned in my previous comment, should fix the two bugs, but it's not as robust as I'd like it to be. It may fail if the IWAD is missing sprites. I just posted 0.9.2. The direct download link is here.
  11. Thanks for the feedback. I've added a sentence about ImageMagick to the requirements in wad2image's home page. You can control the animation speed with "--gif-duration". By default it's 500 milliseconds per frame. Try adding "--gif-duration 2000" to make it four times as slow with 2 seconds per frame. I've fixed the two bugs that you've found and I've released version 0.9.1. The direct download link is here. It should now render Hell Knights. Also it should also no longer have "animate: unable to open" error messages combined with a non-zero exit status. It does build the GIF files by loading the PNG files created where each PNG file is one animation frame. Generally "-d gif" is good if you don't care about keeping the static PNG images that went into building the GIF. The GIFs are valid in my testing. They appear animated in chromium, animate and gpicview. If you like I can try your "Feveswar*.wad" files.
  12. Sorry for the late response. I haven't logged in recently. I see what you mean about the Hell Knight. I just reproduced the red dot problem with Doom2's MAP06. Other Doom 2 monsters are rendered, but not the Hell Knight. wad2image is confused by the sprite name. The sprite prefix is "BOS2" so wad2image expects the sprite frame to be "BOS2A1" or "BOS2A1D1", but actually it's "BOS2A1C1". I don't quite understand how the sprite names work, but I'll see if I can get it working this weekend if not sooner. The error you got about wad2image not being able to find "animate" is because of "-s --show-cmd animate". "-s" tells wad2image to run an external command to show the images once it's done. "--show-cmd animate" changes the command from its default value of "display" to "animate", which supports GIF animation. Both "display" and "animate" are in the ImageMagick package. The good news is this is optional. wad2image probably created the images in the "images" directory, it just wasn't able to display them. Also, passing in "-v" (verbose) is handy - it gives you more information, such as the path to each image created.
  13. selliott4

    Wasn't there a tool that created an image of your map?

    The download on it's web page is a ZIP file that you expand wherever you want. By default it creates images in it's "images" directory". Its web page has a few examples. It's a Python program that requires Pillow, an image library for Python. Getting Pillow installed might be the tricky part if you don't have the "pip" utility as per the instructions on wad2image's web page, but there is probably a way. Then again it may already be installed on your OS. A few other approaches came up in this thread. There are advantages to each of them. One advantage of wad2image is that it can do multiple maps at once, and it can do it non-interactively based on command line arguments. So if you find yourself creating images a lot it may save you some time since you just have to scroll back in your history, or write a BAT file, or however you do it on your OS, rather than having to manually go through the same process each time. It's possible that Automapper does that, but I'm not familiar with it.
  14. selliott4

    Wasn't there a tool that created an image of your map?

    I'm the author of wad2image utility mentioned above and I just noticed this thread. I'm sorry to hear you guys are having trouble with it. Maybe I can help. What operating system are you using? Can you include the output of wad2image and maybe a link to the WAD you want an image of?
  15. I'm happy to have wad2image bundled, but it's GPLv2+. I gave it that license because it includes some Yadex files, which is GPLv2+. I'm not sure what GZDB's license is. Even if wad2image was not bundled installing it is pretty easy. And running it from another program shouldn't be hard.
×