selliott4

Members
  • Content count

    27
  • Joined

  • Last visited

About selliott4

  • Rank
    Warming Up
  1. 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.
  2. I've submitted pull request 481 for this.
  3. 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?
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. I think so if by layout you mean two 2D floor plans. It does not create anything like 3D images from inside the map.
  12. I know this in an old thread, but I wanted to let everyone know that I just created a utility for converting maps in WADs to images named 'wad2image" that's much nicer than the Yadex screenshot approach in my pull request. There are many options to control how the images are created. wad2image can select multiple maps from multiple WAD files and create images for those maps. wad2image can create animated GIFs to illustrate the differences between revisions of a map. I made a web page for it as well as a github page. Anyway, I don't know if there is still any interest in being able to see differences in revisions of maps, but if so maybe I can work on a new pull request. Linguica, You're in the credits file because as far as I know you came up with the idea of using animated GIFs to illustrate the difference between revisions of a map. Thanks for that.
  13. I recently created an open source command line utility named "wad2image" that converts maps in WAD files to images. There are many options to control how the images are created. wad2image can select multiple maps from multiple WAD files and create images for those maps. wad2image can create animated GIFs to illustrate the differences between revisions of a map. I made a web page for it as well as a github page. I hope it's helpful. Feedback would be great.
  14. I've downloaded devinacker's fork (seems to be the preferred one) of OMGIFOL. It looks like you used the included drawmaps.py to draw those images, which doesn't render things as is. I've enhanced OMGIFOL's drawmaps.py so that it renders things as little circles with random but consistent colors which I've submitted to devinacker as a pull request. Here's what MAP05 (the MAP used in the OP) looks like with my enhancement: The tree in question is a little purple dot, but this is not a diff, it's just the latest version of MAP05. Incidentally I was curious what OMGIFOL stands for. It's "Oh My God! It's Full Of Lumps!". So they get credit for humor :-) So this has potential to be a replacement for the screen capture of Yadex approach used by my wad-to-image script, but it will take more work to get the thing colors to resemble the things they represent, and even more work for them to be the right shape. Given that do you guys think you'll merge my pull request? It should be pretty safe in that the only code change it makes to an existing file is to add a few targets to Makefile that people don't have to use if they don't want to. And people can rework wad-to-image to instead use OMGIFOL in the future when and if they overcome the thing limitations mention above.
  15. Oops. Normally I'm pretty good at reviewing the files in my commits, but I was doing some last minute testing with map07.wad, and that change snuck by. I've create pull request #432 that is just like #430, but without map07.wad.