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

Revenant100

Members
  • Content count

    794
  • Joined

  • Last visited

Posts posted by Revenant100


  1. On 5/16/2022 at 1:08 AM, maxmanium said:

    I found a disappearing pixel (highlighted in cyan here) in frames M and N of the player sprite. Maybe the other way around, but not sure. Frame L on top for reference.

      Reveal hidden contents

    Untitled.png.e88eb3dbc0e6fbbb7eb39d321cb7d966.png

     

    The nice thing about this particular inconsistency is that we have two reference points to examine when it comes to determining how to address it. We have the final sprites (top row), the press release beta sprites (middle), and an alternate decapitation death from Romero's sprite sheets (bottom).

    hjrPRZo.png

     

    It looks like Doomguy's right shoulder was redrawn between the press release beta and the final game to match the size of his left shoulder. As for whether the pixel in question is disappearing or shouldn't be there to begin with, the answer lies in the decapitation frames which reveal more of the shoulders behind the head: the shoulder should create a straight contour on the upper edge. Hence, the pixel in the final sprite is incorrectly disappearing in the last two frames. I'll mark this as a new fix.

     

    On 5/19/2022 at 2:47 AM, NightFright said:

    I dunno if it qualifies for this project, but CELL has two green pixels at the bottom which will light up in ports like Crispy or Woof when you activate brightmaps. Replacing these with one of the surrounding colors would improve the result.

    Since this is a visual discrepancy created solely by the Crispy and Woof! ports, it doesn't warrant a fix in the sprite itself. Furthermore, the energy cell ammo appears to be made of metal, and this exact dark green in the color palette is used in other metal textures in the game (see the WALL47 family and WALL03_7 patches). Ergo, its presence in the energy cell sprite is intentional by the artists to depict this type of metal material. The two aforementioned source ports are making an incorrect assumption that this portion of the palette's green range can safely be made fullbright to create brightmaps.


  2. The TITLEPIC is another graphic that cannot be changed due to unavoidable IWAD conflicts. Again, this applies more to Doom 2 rather than Doom 1 (the TITLEPIC lump name being shared with Plutonia's and Evilution's TITLEPICs), but it's still not worth the potential future conflict to alter it. As for looking over it, the Cacodemon in the corner does have an erroneous transparent pixel at the corner of his mouth which is hard to spot because the red sky background blends in, but this was already identified and fixed for the normal sprite.

     

    It is worth noting that the Doom 1 TITLEPIC was updated in the shareware version after the initial 1.0 release (changed from this to this), and this update did some small touch ups to the art. Of relevance to the sprite fixes is that a few pixels on the Cacodemon's nose were tweaked. While I considered carrying this over to the main sprite since it was a new and deliberate adjustment, this art update was ultimately done in complete isolation from the rest of the sprites just for the TITLEPIC, hence they weren't necessarily thinking about how it'd look in-game as well.


  3. I quickly skimmed through numerous points over the hour+ long video, and I didn't see anything other than Doom Man fighting up a tiny sliver of vertical hallway at every moment. Are you sure you didn't loop the same 10 second snippit of gameplay hundreds of times in your upload by accident?


  4. A few green pixels also appear at the back of the left foot in POSSB7.

    cF8n9Z0.png

     

    Of note is that both of these frames are exclusively from the long lost rotations for the Zombieman, so this would never have been identified before. Most importantly, though, despite using the same shades of green from Doomguy's uniform, these green pixels in the Zombieman's sprites do not originate from the original Doomguy frames. The obvious immediate thought is that these green pixels could have been inadvertent leftovers when modifying the Doomguy artwork to become the Zombieman, but Doomguy's knee pads and boots do not use these greens at all. They're completely original to the Zombieman frames. In the absence of any other evidence, it appears the use of these shades of green to create darker shading was indeed a very deliberate decision by id's artists. An odd quirk, but hardly the only one of its kind among the game's art and evidently not an error, so it doesn't warrant any changes.


  5. The tan pixel between Doomguy's legs in PLAYB1 does look to be an oversight. This particular tan color is used for his helmet, boots, and other gear, but there's no reason why it would be sitting right at the corner of his pants like that. Oddly, this very same pixel exists in the Zombieman's equivalent POSSB1 frame where it actually fits fine there since this tan color is a part of his uniform. The pixel is appropriately recolored to black for the Shotgun Guy's black outfit, so I'll be recoloring it to an appropriate green on Doomguy for consistency between the three.

     

    As for PLAYB5, I'm not certain what you're pointing out here. If you mean to show that there appear to be some seemingly erroneous green pixels connecting between the legs which should be removed, I wouldn't agree to that. We can see the pants are somewhat baggy and do hang over the boots in several frames. This sufficiently accounts for the pixels you've highlighted here.


  6. But what's the complevel for the map?

     

    Edit: The readme states it's limit-removing, complevel 2. The WAD has an embedded MAPINFO lump and BEX patch (not plain DeHackEd) that only sets the map name and par time. The given "Map Name" in the readme provides a clear hint as to the origin of the level.

     

    Also,

    Spoiler

    there are, sadly, no Revenants.

     


  7. 6 hours ago, Hitboi said:

    I think Marphy Black's Doom 2 Minor Sprite Fixing Project fixes this? Here are the only 2 Evil Eye sprites from that project:
    CEYEB0.png.76696e91d9f1abde36445ca847cbc42b.pngCEYEC0.png.aaf982ac09dbc76a0f458581f2217276.png

     

    3 hours ago, maxmanium said:

    This is actually addressed in the Minor Sprite Fixing Project.

    The actual art for the Evil Eye was not touched in the sprite fixes. hence its appearance is unchanged. Rather, a small amount of padding was added to the sprite's dimensions in order to address a visible judder issue when the decoration animated. I don't have a visual example on hand specifically for the Evil Eye, but it's the same type of fix as demonstrated on these other animated decorations:

    ifQR2vF.gif


  8. 21 hours ago, Alaux said:

    I am totally aware about said method, and I agree on that it is much better by far. Problem is, it appears that SLADE doesn't allow me to add blank space to graphics easily, which means that, for many sprites, I'd have to export them, add the exact amount of blank space as to keep the offsets that I've made for them (Marphy's padding doesn't quite fit my offsets), and import them back, which would probably once again bring the issue of incorrect color indexes.

     

    SLADE now has a largely undocumented feature called "mirrorpad" which automatically performs the sprite mirroring padding task I manually did before in the sprite fixes. It's not accessible through any of the menus, so you need to bring up the console (View/Console) to enter it. The "mirrorpad" function also comes with the complementary "adjust" function to crop any already existing empty space in a sprite which you'd want to do before redoing the padding. There's one caveat here, though: "adjust" does not maintain the same relative offsets for the sprite after the function runs. You'll need to redo the offsets before running "mirrorpad".

     

    To summarize, the workflow to add proper mirroring padding to your set of sprites is as follows:

    1. Bring up the console, located under View/Console
    2. Select the sprite to be mirrored
    3. If the current sprite already has some empty space, crop it by entering "adjust" in the console's command prompt
    4. Re-center the sprite on the x-axis
    5. Enter the "mirrorpad" command in the console

    And repeat for all other relevant mirrored sprites. This is only necessary for sprites that are mirrored by the engine, however, and that doesn't apply to the current setup of your WAD as you've provided duplicates of the previously mirrored sprites but with their appropriate non-mirrored lump names. You'll have to undo that change to bring back the in-engine mirroring.


  9. I'm not sure how to best describe the particulars here, but based on my testing, I feel that there's some flaw in the Parallel Same-Sound Limit option that can prove unintentionally detrimental to gameplay. It's easiest to simply demonstrate the issue in-game, and I came up with two config setups to illustrate this:

    1. Sound channels = 8 (same max as the vanilla DOS executable), Parallel same-sound limit = 0
    2. Sound channels = 32, Parallel same-sound limit = 8

    I made a custom map to create a reproducible scenario in which the maximum limit for a single sound is consistently hit (in this case, the Revenant sight cry) with both the aforementioned settings. Under this very controlled test scenario, I'd imagine both configs would sound comparable. However, that doesn't turn out to be right. Here's a video with both cases recorded:

     

     

    Note the test map allows me to travel to both sides of this long room populated with Revenants along the whole way. In the first config setup that just has the 8 channel sound limit, I can hear a blaring cacophony of Revenants when I punch the air regardless of which side of the room I'm on. However, in the second config setup with the increased sound channels but an enforced Parallel Same-Sound Limit of 8, the side of the room I alert the Revenants on has a dramatic effect on what's audible. At the player start side with the happy face, I hear maybe a few very distant Revenant cries when I punch the air. If I go to the other side with the anguished face and shoot, I hear the expected eardrum-destroying Revenant explosion.

     

    I figure the engine is iterating through the monsters linearly when determining when the Parallel Same-Sound Limit is reached in a given time period. The issue here is that it seems the option can prioritize the sounds which are nearly inaudible, resulting in the possibility that a large group of alerted demons can be either near silent or utterly deafening.

     

    It's not just the alert cries that can be affected, however. As an extreme stress test, I also tried this experiment in 100,000 Revenants. This is, of course, far beyond a normal use case, but you can hear that the prioritization of the parallel sounds renders the Revenant horde completely silent in the second test case, and even their actions like rocket explosions, punches, and death crackles are mostly wiped out too.


  10. 1 hour ago, maxmanium said:

    This is more of an edge case, but some ports like Crispy Doom and Doom Retro have an option to randomly mirror corpses -- it might be worth it to consider adding padding to death animation sprites so that they mirror properly.

    If a source port is adding a feature as non-vanilla as arbitrary mirroring of non-mirrored sprites, it may as well also add proper mirroring logic for the sprites at the code level since that's actually a very vanilla-friendly feature that supports the original intentions.

     

    That said, what ports (aside from Chocolate Doom and the like) still haven't implemented correct mirroring? Last I checked, Crispy Doom was indeed one, but fabian chimed in in this very thread years ago and said he committed the fix. GLBoom+ is obsolete, I recall hearing that ZDaemon was supposed to add the fix (and it may have?), I don't think Odamex ever did, and I can't imagine Doom Retro not already having this.


  11. 15 hours ago, Alaux said:

    I noticed that the uppercase S from the big font graphics might be consistently missing two pixels of outline.

    The more I look over the font graphics, the more idiosyncrasies I come across. For reference, another independent review of the font artwork can be found in this thread. The takeaway is, I'm not sure the rules (at least the best we can surmise based on examination) for the font's appearance is as concrete or consistent as we'd like them to be. Ultimately, since I've already been including fixes for other identified font errors, I may as well commit to these as well, presuming the particular text graphics are safe to replace. I'll have to do some checking to ensure they're not likely to lead to conflicts.

     

    7 hours ago, Eggman07 said:

    Is a Chex Quest sprite fixing project possible or is it too difficult to tell what's an error or not.

    I think the question for any sprite fix project attempt is what its end value will be versus the time investment involved. The problem with games like Strife and Chex is that, quite unlike Doom, Heretic, and Hexen, the former don't have much ongoing replayability. The replayability in question here is essentially the endless modding the games receive. People get great use and functionality out of these current sprite fixes because they'll continue to take effect in the many WADs, mods, and so forth that are produced by the active modding community. Of course, there's already a massive gap in modding activity between Doom and the Raven games. Consider then just how virtually non-existent modding is for Strife and Chex. Any sprite fixes would just have far less value for these two. While ideally it would be great to create the sprite fixes simply for the sake of having them available, it's hard to justify the time and effort required, especially in the case of something massive like Strife.


  12. 3 hours ago, rzh said:

    Anyways, do you have any plans for updates for Heretic/ a Hexen Minor Sprite Fix?

    I remember reading one of your comments about Hexen being a headache though, and I'm also wondering what makes editing Hexen so much harder.

    Yes, there will be an update to the Heretic sprite fixes which will coincide with the eventual Hexen sprite fix release. The biggest hurdles for Hexen has been that it's not nearly as popular as Doom, hence there's little in the way of familiar or common knowledge errors to address, and that it contains about as many sprites as Doom and Heretic combined. Consider that we're now a decade removed from the start of the Doom sprite fixes and still identifying potential errors to fix here! Although it won't be nearly as active a project in the long term, the initial scrutinizing of Hexen's sprites is nonetheless going to be a long and tedious endeavor, and I no longer have the abundance of free time as I did back then.

     

    However, there has been one major recent development that indirectly supports sprite fixes for Hexen: the creation of Nash's WidePix. This alleviates the need for me to attempt my own widescreen sprites, and while widescreen-friendly sprites for Heretic and Hexen was always a secondary goal that only benefited the ZDoom family of ports at the time, there are now growing options where such sprites also make a difference.

     

    3 hours ago, HavoX said:

    To chime in, I'm more than willing to help you out if you do. I did some work on some sprite fixes for the monsters in both Heretic AND Hexen.

    I appreciate the offer for help. At the moment, I don't need any direct assistance with the fixes. However, if you happen to have one handy, a list of errors you've already identified in Hexen would be a great resource to keep in mind as I go over its sprites. The more eyes and more collaboration on such a project, the more thorough and encompassing it can be.


  13. On 2/5/2022 at 2:18 PM, UndeadRyker said:

    In this project you actually add multiple rotations for the Nazis which is a bigger fix/change than adding the missing sights back, IMO.

    The omission of firing and pain rotation frames for the SS monster was certainly not an error, oversight, or inconsistency on id's part, so the inclusion of the fanmade rotation sprites here is not meant to be within the stated scope of the sprite fixes. These community resources for Wolfenstein 3D actually have more use in Doom 2 than they do in the game they were originally created for, and there's really no other type of WAD that would ever incorporate them. Combined with the fact that the SS is a joke monster that appears in a total of two maps within all official IWADs (hence it is virtually never seen outside of deliberate joke WADs), the inclusion of the missing rotations was largely for fun. It's basically an Easter egg on an Easter egg, and it happened to be fully non-intrusive to boot. It's not representative of the project's aim as it's  the intentional sole exception of its kind.

     

    The SSG, on the other hand, falls within the realm of normal gameplay sprites, and without going into the nitty gritty, addressing the missing sight would require original art well beyond the "minor" ambition. Just drawing in the few pixels above to fix the Imp's missing knee spikes already constitutes one of the more extreme examples of introducing original art in any fixes, and that had numerous adjoining frames to use as reference points for that addition.


  14. 4 hours ago, yakfak said:

    - "IWAD" nothing but jargon, think up something intuitive or I'm calling them source files

    - community project as an acronym, please get some awareness

    I see a single simple solution to both of these problems: Any future Doom CP should be called an "USWAD".


  15. 8 hours ago, Alaux said:

     I kinda need to know exactly which sprites were changed between 1.9 and 2.0 Beta 1

    One way you could do this is to use SLADE's "Remove Entries Duplicated from IWAD" feature. It's under Archive/Maintenance. To use it for this purpose, load up D2SPFX20_FULL_beta1.wad, set the previous D2SPFX19_FULL.WAD as your current base resource, and then run the option. The remaining lumps will be all of the sprites modified between the two versions. Here's the list I generated using this feature:

    Spoiler

    sttnum2
    sttnum5
    sttnum8
    sttprcnt
    stftl00
    stftl10
    stftr10
    stfkill1
    stftr30
    stftr40
    stfgod0
    m_rough
    m_nmare
    chgfa0
    chgfb0
    manfa8a2
    manfa7a3
    manfa6a4
    manfb8b2
    manfb7b3
    manfb6b4
    misfa0
    misfb0
    misfc0
    misla6a4
    sht2e0
    sht2i0
    bfgfa0
    sarga2c8
    sargb4d6
    sargc2a8
    sargd4b6
    sarge2
    sarge6
    sarge8
    sargf1
    sargf2
    sargf6
    sargf8
    sargg3
    sargg7
    sargi0
    trooa1
    trooa2c8
    troob1
    troob2d8
    trooc1
    trooc2a8
    trood2b8
    trooe1
    trooe2
    trooe8
    troof1
    troof8
    troog2
    troog8
    trool0
    playu0
    playv0
    playw0
    possf7
    possf8
    possh0
    possn0
    posso0
    skulb8b2
    skulc8c2
    skulc6c4
    skuld8d2
    skuld6d4
    skule8e2
    skule7e3
    skule6e4
    heada2a8
    heada3a7
    heada4a6
    headb2b8
    headc2c8
    headd2d8
    headb3b7
    headc3c7
    headd3d7
    headb4b6
    headc4c6
    headd4d6
    heade2e8
    headf2f8
    heade3e7
    headf3f7
    heade4e6
    headf4f6
    headh0
    paina2a8
    painb2b8
    painc2c8
    paind2d8
    paine2e8
    paine3e7
    painf2f8
    painf3f7
    paing2g8
    bspia1d1
    bspia2d8
    bspia3d7
    bspia4d6
    bspia5d5
    bspib1e1
    bspib2e8
    bspib4e6
    bspib5e5
    bspic1f1
    bspic2f8
    bspic3f7
    bspic4f6
    bspic5f5
    bspid2a8
    bspid3a7
    bspid4a6
    bspie2b8
    bspie3b7
    bspie4b6
    bspif3c7
    bspif4c6
    bspig2g8
    bspig3g7
    bspig4g6
    bspih1
    bspih2h8
    bspih3h7
    bspih4h6
    bspii6
    bspii7
    bspil0
    skela5d5
    skela6d4
    skela8d2
    skelb3e7
    skelb4e6
    skelb8e2
    skelc1f1
    skelc2f8
    skelc3f7
    skelc4f6
    skelc6f4
    skelc7f3
    skelc8f2
    skeli6
    skeli7
    fatta1
    fattc3f7
    fattc4f6
    fattd1
    fatth2h8
    fatth3h7
    fatth4h6
    fatti4i6
    fattj4
    fattj6
    sswvn0
    cybra3
    cybra6
    cybrb2
    cybrg1
    cybrg3
    cybrh0
    cybri0
    cybrj0
    cybrk0
    cybrm0
    cybrn0
    cybro0
    cybrp0
    spida1d1
    spida2d8
    spida3d7
    spida4d6
    spida5d5
    spidb1e1
    spidb2e8
    spidb3e7
    spidb4e6
    spidb5e5
    spidc1f1
    spidc2f8
    spidc3f7
    spidc4f6
    spidc5f5
    spidd2a8
    spidd3a7
    spidd4a6
    spide2b8
    spide3b7
    spide4b6
    spidf2c8
    spidf3c7
    spidf4c6
    spidg2g8
    spidg3g7
    spidg4g6
    spidg5
    spidh2h8
    spidh3h7
    spidh4h6
    spidh5
    spidn0
    spido0
    spidp0
    spidq0
    pol5a0
    bexpe0
    bon1a0
    bon1b0
    pol6a0
    gor1a0
    gor1b0
    gor1c0
    gor2a0
    gor3a0
    gor4a0
    gor5a0
    smrtc0
    hdb1a0
    hdb2a0
    hdb3a0
    hdb4a0
    hdb5a0
    hdb6a0

    Note this includes everything updated for the v2.0 Beta 1 release, not just the sprites that received the duplicate color palette fix.


  16. 13 hours ago, NightFright said:

    Based on that changelog, I assume there are once again no new assets which would require adjustments of my spritefix brightmaps, correct?

    That's correct. The latest compatible version of the brightmaps doesn't need any modifications to accommodate this update.

     

    11 hours ago, maxmanium said:

    Glad to see the palette indexing has been fixed. Was my work of any help? :)

    Yes, indeedy. I independently performed my own complete pass on the duplicate palette colors, and I compared these results to your versions. Seeing as this is a thoroughly esoteric and intricate task that can't be automated, it was of great help and reassurance to essentially have a second pair of eyes look over everything.


  17. 7 hours ago, dotQLL said:

    I found some flaws in the Pinky Sprites.

    In some frames, the teeth are gray instead of yellow.

    Thanks for the report! It led to more than I was expecting. Comparing the final sprites to the Demon's alpha sprites when it still had white teeth, the error here is easy enough to pinpoint as being pixels they missed during the recoloring process. I fixed the four frames you've mentioned, and I was compelled to scrutinize the alpha Demon sprites further to work out the actual color palette translation used to recolor the teeth. This ended up revealing overlooked gray teeth pixels in 9 other frames (SARGA2C8, SARGC2A8, SARGE2, SARGE8, SARGF2, SARGF8, SARGG3, SARGG7, and SARGI0) which I've gone ahead and accurately recolored with my palette translation as well.


  18. These source Romero sounds are sourced from Bobby Prince's old site, specifically this page under Fact #4: https://web.archive.org/web/19970416090930fw_/http://bpmusic.com/frame_little.html

     

    Direct links to all of the relevant sounds:

    These audio files are at a 7,000 Hz sample rate which unfortunately makes them even lower quality than Doom's 11,025 Hz sound files.


  19. 23 hours ago, Alaux said:

    Based on this evidence, I believe that for SPFX's weapon sprites to actually be centered in-game, they should be offset one pixel to the left relative to their current offsets.

    I've just tested numerous versions and ports, both in DOS and out, and I can confirm your findings. However, there's a catch: Some source ports have already fixed this centering issue, namely the ZDoom family. Hence, I cannot adjust the centering of the weapon sprites from the graphics side to account for this erroneous pixel offset without introducing the same erroneous offset into engines that also fixed this problem from the code level. It's an unavoidable conflict.

     

    For this reason, I'm going to have to pass on this change. This issue should come down to a code fix on the engine side, and from my testing, a majority of source ports do exhibit this off-center behavior.


  20. 17 hours ago, Eggman07 said:

    I think I have asked this before, but is it possible to run this mod with dos?

    Yes, the sprite fixes are fully compatible and functional in the original DOS executable. However, due to the limitations of how the DOS version handles sprites, you can't load the sprite fix WAD like any other PWAD. You need to merge the sprite fix graphics into the main IWAD. This was how graphics (and other types of) mods were commonly installed back then, and we even have a dedicated DOS tool for this purpose: DeuSF.

     

    If you want to use the sprite fixes in DOS, you're going to be in a DOS environment anyway, so here's instructions on how to carry out the process there using Doom 2 as the example:

    1. Put D2SPFX19.WAD in your main Doom 2 game directory
    2. Download DeuTex/DeuSF 3.6
    3. Extract these files to your Doom 2 directory
    4. In DOS in your Doom 2 folder, run the program DeuSF with this parameter:
      deusf -merge D2SPFX20.WAD
    5. Run Doom 2 as normal

    The sprite fixes will now be in effect. The process for Doom 1 is essentially identical except with D1SPFX19.WAD instead. DeuSF also gives instructions on how to restore your IWAD if desired.


  21. 2 hours ago, Kinsie said:

    I mean, the wiki is a wiki. If something's missing, add it.

     

    4 hours ago, Gez said:

    The "neat stuff safari" being neither runners-up nor honorable mentions, they're not covered by the Doom Wiki articles.

     

    57 minutes ago, Dynamo said:

    Indeed. As I hadn't made it overtly clear enough in my previous post, the omission of sidebar content in the Doom Wiki articles is not merely an oversight. It is very much by design. Combined with the Cacowards' own lack of any available indexing or summary of this material each year, the sidebar content has always unquestionably been difficult to discover and search through, easy to miss, and ultimately destined to be overlooked and forgotten.

     

    You might even say it's doomed to obscurity!


  22. 3 hours ago, Gregor said:

    I beg to differ. The sidebar is clearly visible when you're reading the "Other Award" section. It's actually difficult to miss

    I beg to differ to differing. The sidebar is unquestionably where content goes to be lost and forgotten. As an example, earlier this year, I had reason to go over past Cacowards to check which recently released source ports had been formally acknowledged for whatever reason. This includes non-winners, aka sidebar content. One port I distinctly recall being mentioned in the past was Quasar's Calico port. However, finding it in the Cacowards was easier said than done. It's not mentioned in the port's DoomWiki article (suggesting the sidebar acknowledgement itself is not notable), it's not mentioned in any of the DoomWiki's individual Cacoward articles, and of course it's not mentioned in the front page indexes of any of the Cacowards proper. In the end, I had to go back through each year of the Cacowards and check every single page to see which sidebar Calico appeared in. After almost 30 pages, I eventually found it in the sidebar of 2017's Gameplay Mod Awards page. That's buried pretty deep among unrelated content for something that's "difficult to miss." Sure, I could have also just done an external search with a search engine for the page that had both the terms "cacowards" and "calico", but it'd only be this easy in cases where you have an inkling of what you're searching for. Imagine trying to find sidebar content you're not certain of!

     

    And that's not to say the sidebar can even be called consistent. 2021 is the first year in which, instead of being relegated to the sidebar, the runners-up are mixed in the same pages as the winners. In fact, I guarantee you readers casually ran through this year's Cacowards without realizing which ones were the winners and which ones were the runners-up as the only distinguishing mark between the two was this new icon, something which has never appeared in years prior and was not established for 2021. But I digress: To anyone who's been reading the Cacowards for years now, at a glance, you might think the sidebar was eliminated this time around, and to new readers, you'd have no idea there was supposed to be any content there at all.

     

    So of course, after browsing through four consecutive pages of the Cacowards with a no sidebar material in sight, I guarantee you many readers weren't even thinking to look out for it when it suddenly reappeared on the Special Features page, the sixth page in. This matter is immensely compounded on the mobile version of the site where the sidebar content is placed after the index, ensuring unsuspecting readers would go to the next pages without ever realizing said sidebar content even existed!

     

    Truly, the Cacowards sidebar is where Doom projects, achievements, and miscellanea go to wallow and languish in a miserable and prolonged decay by obscurity. Is there any crueler fate? No, there is not.

     

    And to illustrate all this, here's a fun challenge for you: Try to find the Cacowards sidebar that mentions my sprite fixes. I assure you it's there somewhere. Or maybe I'm just sending you on a wild goose chase. The truth is out there!

×