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


  • Content count

  • Joined

  • Last visited


About Blzut3

Recent Profile Visitors

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

  1. My notes if you're curious which maps correspond to what. Could be more, but I did make this list after a fairly recent fresh playthrough of the PC game so hopefully I didn't miss too much.
  2. I too would like to see the N64 mission ported to PC since if nothing else it plays so differently. If I could be a pedant, 4 of the maps are modified PC maps (4, 7, 11, and 14) and at least another 4 (2, 12, 15, and 16) use components from the PC maps so not sure "entirely" is the right word. Still leaves like 12 maps that I don't think come from the PC in any capacity.
  3. Blzut3

    What was the best hardware available for Doom in 1994?

    Very few people had them at the time, but the Socket 4 Pentium 60 and 66 was out. When checking my memory I found a blog where someone did build such a period accurate machine: https://ancientelectronics.wordpress.com/2015/02/25/socket-4-the-cutting-edge-of-1993/ Since you're looking at 1994 that would open up Socket 5.
  4. Blzut3

    How to run wads on Mac and Linux builds of GZDoom?

    For your batch file: For Linux it's mostly the same. If you're not using ".exe" in your command it's probably literally the same except needing the first line needs to be #!/bin/sh. It is possible to make a polyglot batch and shell script, but Linux users would probably be confused by executing a .bat file even if it works fine. This is assuming the user has GZDoom installed system wide. For Mac you'd have to use the "open" command (don't have exact syntax on hand for passing command line arguments) or assume the user has GZDoom installed to "/Applications/GZDoom.app/Contents/MacOS/gzdoom". For drag and drop: macOS supports this just fine. For Linux support may vary by desktop environment. For KDE it does work, but it's somewhat clumsy to use since you have to drag and drop onto a .desktop file not the binary itself. This file is likely in a place the user usually isn't concerned about, or it needs to be pinned in a location where drag and drop is possible (i.e. taskbar). Which if one isn't a Doom regular that can launch your mod no problem, probably isn't something they've done. Right click "open with" does work well. I can't speak for other desktop environments but I expect that the big name ones should all have these features. My advice though: Since you say you have no means of testing, you probably shouldn't bother trying to provide anything beyond mentioning that it can be run on any platform GZDoom supports.
  5. Blzut3

    [v2] Maximum doom in one

    Minor nitpicky detail, but this probably results in a very minor quality reduction with next to no benefit. PNG's compression is mostly the same as that provided by zip, so since you're using a pk3 you're probably barely saving any space by doing this (if you're saving anything at all, but there's probably enough textures that benefit from the other technique PNG offers for saving space that you might be saving something). The downside is that in software rendering the palette may go through a 6-bit matching process and come out with slightly different colors. In practice this is barely noticeable, and perhaps more time than it's worth to revert, but thought you should know there is an advantage to just leaving them in doom's graphics format.
  6. Blzut3

    How can i compress a GIF Image?

    As the website says it uses Gifsicle https://www.lcdf.org/gifsicle/ (and LossyGIF although that has been merged into Gifsicle). So if you want the tool to do that locally that's where to find it. I have used Gifsicle before and it's amazing how much waste it can throw out of most gifs even without the lossy option turned on.
  7. Blzut3

    ssd size

    I think the biggest problem is that 250GB drives aren't that much cheaper than 500GB ones. For example a 250GB drive might cost $40 and a 500GB $45. They're also typically slower since they won't have as many NAND chips to parallelize over. Unless you're on a very tight budget, or you only use the computer for web browsing and would never fill it up anyway, there's no reason to go lower than 500GB.
  8. I wouldn't be so sure. Besides the Dreamcast port, the other Quake 3 ports weren't straight ports. Particularly the PS2 version. Odds are it would have had some kind of alterations, granted you're probably right it wouldn't be to the level of Doom 64 or Quake II 64. Although given it was announced at the same time, it may have been id was overly hopeful for the DS's online play and it was just a port of the 360's Quake Arena Arcade.
  9. They did at one point announced Quake Arena DS, but silently cancelled it. Kind of wonder if any prototypes of that are floating around.
  10. Glad to see you did this! Might encourage me to finally getting around to trying my Hercules card in various 386/486 systems I have to see if I can get dual display working. Wasn't able to do it with my K6 (AGP card would just take over monochrome functions), but I don't think that was entirely unexpected either.
  11. Haven't been seeking out the developments here, but did a nodebuilder add support for them or something? The main problem with them initially is that since they only existed in the classic nodes even something as simple as desiring a textured automap would break them. I know there was suggestions for coming up with ways to mark up a map so that a nodebuilder could generate portals, but I don't recall that getting anywhere. If the map data itself has the relevant info to create the portals it's possible that support for them can be added.
  12. So basically a return to late 90s/early 2000s ZDoom? :P OK, the in thing then was more doing fuax-Quake and we didn't have voxels, but I also feel like there was a lot of build influence in the early days.
  13. Widescreen assets aren't even all that new. It just used to be more targeted to fixing issues that widescreen exposes. For example there have definitely in the past been projects for wide screen status bars and fixing weapon sprites that were cut off in widescreen (particularly for Heretic, Hexen, and Strife since Doom doesn't have much to fix). WidePix (and I think some of the high res resource packs, but not certain) simply extended this to removing all the black bars. On that note, not everyone is bothered by black bars. Sometimes these things take waiting for someone to have a combination of being bothered enough by something and having the ability to do something about it.
  14. Blzut3


    I have no idea when I started playing Doom since that's behind childhood amnesia. Not entirely sure when I started making mods for the game, but I think it was around 1997 or 1998 so that would have made me 4 or 5. I was 10 when I started playing Doom online, and started contributing to ZDoom when I was 14. For some reason despite that, my mom thinks it's weird that my nephew is allowed to play Doom.
  15. Blzut3

    Comparison of Source Port Compatibility

    @Csonicgo I think your row for ZDoom might be wrong. The textured automap feature requires GL nodes and thus forces a node rebuild, but if you turn that off and restart the map ZDoom uses the original nodes which should improve edge case compatibility. Zandronum should work similarly at this time in software mode. So I think for those the answer for irregular nodes should be partial, since I never did complete the fix for linguortals. This does not apply to GZDoom since it always builds GL nodes to support fast switching between software and hardware renderers. Although doesn't GZDoom pass the colormap test in software mode? While I completely agree with the premise that people over react to vanilla compatibility assessments, after all most stuff will work with GZDoom and most people won't notice things that are changed. I think ultimately something like this could be an improvement over the subjective table that currently exists on the wiki which people already misinterpret. The reality is people need adequate descriptions of the way source ports are differentiated, it's just unfortunate that some of the differentiation comes in technical edge cases that are difficult for new comers to understand why/when they matter. But since not mentioning it at all isn't a realistic option the question really is if it's actually worse? Obviously definitely agreed on lumping renderer options together being problematic here though.