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

Bauul

Members
  • Content count

    1543
  • Joined

  • Last visited

About Bauul

  • Rank
    Senior Member

Recent Profile Visitors

2516 profile views
  1. Unless anyone recognizes that error message, we'll need more info than tha if you're able: what format is the map (Doom, Hexen or UDMF) and what source port is it targeting? Based purely on the error message (that PRBoom+ can't find an expected lump file) I might guess you made it in UDMF?
  2. There was a discussion on this pretty recently actually: Personally for me, Sunder takes the cake as the best looking wad out there, with Viggles' maps (specifically Brigandine) also getting a massive shout-out, but a lot comes down to personal taste.
  3. Originally, Dehacked was a program that directly altered the game's executable. It wasn't merely a file you loaded, you used the program to literally change the makeup of Doom.exe/Doom2.exe to adjust how the game worked. The .deh file was bundled separately because you had to load the file in Dehacked, make the changes to the executable, and then run the game. Then when you were done with the wad, you needed to reload Dehacked and restore the .exe to its original form. Over time, source ports became advanced enough that you could merely specify the .deh file in the load order and it would apply the changes on the fly, temporarily applying them to the game. And then even as even more time went on, source ports became so advanced you could actually bundle the .deh file into the wad itself, and it would automatically load it. As a result, you very rarely see a separate .deh file any more. Alien Vendetta predates all of that though, so the .deh file still exists separately to rest of the files. This is a good example of how Doom mapping is not a single point in time, but a tapestry of changing customs, technology and protocols over a 25 year period. Somethings make no sense now, but make perfect sense in the context of when they were created.
  4. The other thing it's worth knowing about Chocolate Doom is it faithfully retains the 'limits' of the original Doom executable. Originally there were a bunch of hard limits on level complexity that would crash the game if a mapper made a level too detailed. One of the first things source port authors did was to remove many of those limits, allowing for bigger and more detailed maps, even without any advanced features present in later source-ports. These maps are described as "limit-removing", and most wads (even if they use no advanced features at all) tend to be at the very least limit-removing. True vanilla maps (i.e. maps that work within the original limits) are relatively rare in comparison. Chocolate Doom will crash if you try to run any of these limit-removing maps, but people still liked the authentic experience it provided. The solution came about in the form of Crispy Doom, an offshoot of Chocolate Doom that adds just a few quality of life improvements, most notably higher resolutions and the removal of those limits. Chocolate is an incredibly important source port, but if you find its authentic limits are a little too authentic for your liking, Crispy is the way to go.
  5. There's a scale. Playing a classic vanilla Doom wad with all of GZDoom's bells and whistles turned on is like watching a 1920's silent movie on an OLED TV. While yeah you're not viewing it how it was "meant to be experienced" (namely in a cinema with a live pianist surrounded by cigarette smoke), and there might be some minor things (like color and aspect ratio) that aren't quite the same as the true projected original, at the end of the day it's still the same movie, and the other modern quality-of-life improvements are often worth it. How much you choose to balance between the "authentic experience" and the ease of modern source ports is entirely a personal choice. Some people refuse to play anything other than Chocolate Doom (about the closest to the original DOS experience we have) while others insist on the latest version of GZDoom and a dozen graphical mods to make it look all fancy. Where you personally feel most comfortable is something you'll learn as you start to play the wads and try out the source ports. You'll start to get a sense of what feels "right" for you. The best thing to do is to try out as much as you can, because a: this gives you the widest selection of choices from which to pick your preferred approach, and b: having a good knowledge of the various source ports can be handy in the unlikely event your approach of choice doesn't work with a particular map. Generally though you're going the right way around it: play lots, try lots, and sooner rather than later you'll settle into your own personal groove.
  6. ^^^ This times a hundred. Change them to whatever you want. The simpler source ports have fewer options while the more advanced ones have absolutely loads. But they're all just graphics at the end of the day, set them to whatever you like the look of. That being said, one thing most people will agree on is to turn off Texture Filtering in GZDoom. Doom graphics are pixel art, and are generally considered to look best without the pixels being smushed together (although of course it's a personal choice and if you like Texture Filtering then all power to you!)
  7. Bauul

    Trouble with teleporting enemies in maps

    Also bear in mind in GZDoom UDMF (and other similar soureports) you don't even have to teleport the enemies, just spawn them. Something like this: Script "Ambush" (void) { SpawnSpotFacing([spawnspot tag], "Name of monster", 0); SpawnSpotFacing([spawnspot tag], "TeleportFog", 0); } Give every one of your spawnspots the same tag, and voila, easy spawning. They won't spawn if something is blocking the way, but as it's likely to be another enemy, is that an issue? Alternatively you can use SpawnSpotFacingForced to ensure they spawn no matter what.
  8. Just to provide an alternative, arguably simpler, viewpoint to all of the above: Don't worry too much about comp levels. 95% of vanilla/limit-removing/Boom wads will work fine with no comp level selected in prBoom+ at all. They exist primarily for demo playback (where a single microscopic change in the engine behavior can de-sync the demo) and those wads that utilized very specific engine hacks, features or effects. Just drag and drop the wad onto the .exe and off you go. For any wad that is described as "ZDoom" or "GZDoom" use GZDoom. GZDoom also runs pretty much any other wad too, albeit with some minor (and they really are minor) gameplay differences. Personally I use GZDoom for every wad, unless I want that sweet hit of nostalgia, then I use Crispy. Finally if you want to record yourself, personally I just use Windows 10. If you have it, it has full video and voice recording built natively into the OS. Just hit Win-G on the keyboard once the game has loaded, click "yes this is a game" and the rest is self-explanatory.
  9. Bauul

    Doombuilder 2 visual mode "laggy" movement

    Aside from the above (very sound) advice, it could just require lowering the draw distance (in the Preferences menu). Visual mode in DB is pretty taxing as there's nothing like a BSP to only draw the things you can actually see. Unlike a game, it draws everything. If you have a lot of custom textures, streaming those in and out of memory (especially if you have limited RAM) can cause slow down too.
  10. Bauul

    [v 0 .9] Doom Neural Upscale 2X

    Looking excellent guys! I do agree that the zombieman's face needs some work to get the feel back to the original, in testing this it was one of the only things that stood out as looking overtly different to the original. @Gifty That chaingunner touch-up looks perfect. One quick question: do the new sprites here have their offsets fixed (as found in the minor sprite fixing project), or are they matched to the IWADs exactly?
  11. Bauul

    Doom with PBR materials

    Amazingly no. From what I understand (and I'm really no expert) it's all done through a shader, basically a graphical effect that utilizes native OpenGL rendering methods. As long as you have a modern enough GPU to support it, the process is a breeze for your GPU to understand and render. It's pretty damn efficient.
  12. Bauul

    Doom with PBR materials

    They actually are 3D. Those specific shots have Parallax Mapping applied, a technique where the game "sinks" elements of the texture into the wall based on a 2D imagine denoting height (the heightmap). It's a purely graphical effect (no modeling or anything) but it's not entirely 2D any more.
  13. According to the Internet Archive, the earliest printed example I could find was from an Electronic Entertainment magazine dated May 1995. In describing Dark Forces, it said: There was supposedly a mention in a PC Gamer magazine dates January 1995 too, but the search engine couldn't find the exact words. So 1995 seems like a pretty solid guess for it becoming the accepted name of the character.
  14. ^^^ What Hak3180 said. Find and replace (F3) is your friend here.
  15. Tricky problem! But there are some alternative approaches that could work: Write a script that, presuming the player has passed under the door, deactivates the dyn light once the door closes (you can use Tag_Wait for that). Then reactivate it when the door is opened. From the player's point of view it'll look the door blocked the light, not that the light was just turned off. On the dark side of the door, place a subtractive light. You could even use a spotlight to control the exact angle. Subtractive lights reduce light, so you can use them to counteract a dyn light. Either just have a subtractive light the whole time, or turn one on as the door closes. Don't fight it: place a light texture on both sides of the door, and place dyn lights on both sides. One thing to bare in mind: Shadowmaps require a relatively modern PC to render, so they won't always be visible to everyone playing your map. When you release your map, make sure to call them out specifically. Many people don't play with them turned on.
×