selliott4

Members
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

11 Neutral

About selliott4

  • Rank
    Warming Up
  1. 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.
  2. 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?
  3. 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.
  4. I think so if by layout you mean two 2D floor plans. It does not create anything like 3D images from inside the map.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. But will it generate images with things? I'll look at OMGIFOL more tomorrow and possibly answer my own question.
  10. Nice. What tool did you use to generate those images? What I did is a bit of a hack (taking a screenshot of Yadex), so I'm open to using a better utility.
  11. Previously in the thread "Using wadlc and wadldc in the build" I asked if there are utilities that can be used display the difference between two WAD files as an image. This is my attempt at creating such a utility. I've created a script "wad-diff" that will do this. By default it generates a diff image for changed WAD files in the "levels" directory, but it can also be used to generate diff images for arbitrary git revisions. Here's one of my favorite examples: The above was generated for git commit 0c004ce which says "MAP05: Move tree aside to prevent the player from getting stuck". By diffing that revision we can see the tree that was moved. Unchanged pixels are white. Adds are blue and removes are red. You can generate this image with: As can be seen above I've added make targets that invoke the scripts. Target "wad-diff-display" displays the diff images produced via "display". By default the diff images are the size of the display, so normally you can see more detail, but I didn't want to post such a large image. It doesn't always work this well since sometimes Yadex displays different revisions of the WAD at different scales, but it works a lot of the time, especially for small changes. I've created pull request #430.
  12. Thanks for confirming that about the BFG. That's totally understandable. I kept wondering if I was overlooking something. I'm guessing at this point my "fake door" comment (my last image) is not a concern now that I've noticed them in other Freedoom 2 maps. Perhaps the idea is to give the user the illusion that the map is bigger than it actually is, that they are not trapped in a tiny enclosed universe. But while playing I still get curious what's behind that door, and if I overlooked a switch. Thanks for the explanation and the term "disjointed sectors" in particular. I kept searching for variations of "stuck door" and I could never find anything relevant. I ended up debugging PrBoom+ to see what was going on.
  13. Good stuff. Thanks for sharing that. With regard to diffing the IDs getting renumbered what if they IDs were stripped out before the diff? Of course you then have less information. If only each item had some ID that never got changed once set. Also, this probably means that my original goal of having maps be git mergeable won't work in most cases :-/
  14. Thanks for the feedback, but just to clarify - I was assuming that people would continue using the same WAD editors they are currently using, that part of the process would be the same. I wasn't assuming that anyone would want to update WADs by editing the text files. Only the build would handle the conversion either direction. As to people not familiar with GitHub - my post was geared toward that because I assumed that you want people to do use that process, but indeed all the current ways need to be accommodated: People doing the full GitHub pull request approach. They would just do "make submit" after their normal process when done with their edits to the levels, but before the pull request. People with commit access pushing directly to GitHub. They would just do "make submit" after their normal process when done with their edits to the levels, but before the git push. People who have the build setup, but don't use GitHub and who currently post their WADs somewhere on the internet. They would just do "make submit" after their normal process and then post the text files somewhere on the internet instead of the WAD files. People who don't have the build setup, but edit the levels anyway. This is a trickier. They'll have to get the build working, or work with wadlc and wadldc directly. That's my understanding of what people are doing. EDIT: Possibly for steps 3 and 4 the submitter would just submit the WAD files and the maintainer would put them in a build tree and do "make submit" before committing the changes. I'd totally understand if this seems too odd, but I thought I'd suggest it in case it's helpful. I agree that "Use Wadspy to output level stats" thread is a good idea regardless. By the way, do you have some way of comparing to versions of a level WAD graphically, like something that displays the changes made on a 2D image, so you can see what was done? I was assuming that was not common when I posted this. I guess that's another topic, but I have some ideas on that as well.
  15. The recent the "Wadspy output with Daily Builds" thread having to do with summarizing levels with a text file made me curious if it's possible to take the concept one step further where the level WADs could be entirely converted to and from text format. The "wadlc" and "wadldc" CLIs from xwadtools, the same GitHub Doom-Utils organization Freedoom gets its "deutex" from, are such tools. This would make it possible for the actual checked in Git resource in to be a text file, so something like "levels/map11.txt" instead of "levels/map11.wad". The build would then produce all of the "levels/*.wad" files based on the "levels/*.txt" files. There would be some other build target, maybe "submit", to go the other way to update "levels/*.txt" files based on modified "levels/*.wad" files. This would be done after editing "levels/*.wad" files. Why the additional abstraction? The levels would then be diffable and mergeable. When viewing pull requests for levels you'd be able to actually see a summary of the changes in GitHub, although cryptic. More importantly if ongoing work from multiple authors made changes to different parts of the level they could be merged by Git automatically. Diffs could be done locally as well to make sure no unintended changes were made before submitting a pull request. What do you guys think? Maybe I could look into modifying the build if there is any interest.