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


  • Content count

  • Joined

  • Last visited

Posts posted by GooberMan

  1. 10 minutes ago, NoXion said:

    The old "tHeY'rE nOt hOlDinG a gUn tO yOuR hEaD" nonsense is an irrelevant fallacy used to excuse all kinds of shitty practices. 

    "Ironic hyperbolic response gets serious hyperbolic response on internet forum. News at 11"

  2. 1 hour ago, Foebane72 said:

    I think what irks many, besides the implications of Denuvo Anti-Cheat, is that many have been forced to abandon the game they spent £50 or $60 on

    "Doomers held at gunpoint forced to stop playing their game"


    The only people actually forced to stop playing the game is the ones the publisher/Denuvo is considering (ie people playing through Proton on Linux, people getting crashes that might be unrelated since it's a whole new update, etc) and cheaters whose cheats are broken. Everyone else is just taking an ideological stand.

    Which, you know, is fine. It's your money. I just find it hilarious considering how many other bad drivers people install daily that an anti-cheat driver is the hill they've chosen.


    (Ask me about how soon encrypted-memory-by-default should be the hardware standard, since that'll make the need to out-cheat the cheaters much less relevant.)

  3. On 4/30/2020 at 7:28 AM, Nevander said:

    I wished there was a way to load custom limit-removing WADs with the XBLA releases when they were new.

    There was. But it involved getting hold of a pirate SDK and repackaging the game yourself.

  4. Quote

    The demons are unionising! Thanks to the Doom Slayer, working conditions have deteriorated and the common demon just won't tolerate it any more. Doing a spit-take while sipping on his blood mochaccino, the Doom Slayer decides that only Earth governments can make a mockery of unions in such a manner and sets about to clean up the problem.

    But first things first. That mochaccino won't refill itself. Where'd that barista go?


    DWU! is a planned 32-map megawad targeting vanilla Doom. I know, right? I feel so naked without typing in scripts.

    So, Finland locked down thanks to the coronas. Within a couple of days, I had a Doom level editor out. Decided to challenge myself by making a vanilla compatible map. And then got so inspired that I had a grand idea: What about if I got a bunch of game developers to join in and make it a megawad? Make it a bit of a present to the people who keep buying our games which keeps us employed; and besides, so many of us were inspired by Doom to get in to the industry so give something back to the game.

    The major restriction is that it will be vanilla compatible. I've spent so much time already in nodes view mode avoiding HOMs and visplane overflows. Even that hasn't been enough, and I've had to get creative with tactical map modification.

    Which brings up the next major feature: The intention is to abuse Mikoportals and voodoo dolls to make a vanilla megawad like no other. I really want to get away from slaughter style gameplay, so using ghetto scripting we can start enforcing interplay instead of infighting. Pacing when monsters spawn leads to some really interesting (to me) map designs, and can really surprise the player even with the stark limitations on display.

    (Yeah, turns out I can't avoid scripting at all. Sue me.)

    I'm going to start chasing up my own industry contacts, but short story: If you're interested in contributing and have either shipped a game or are currently/have been employed in the industry then shout out in this thread. Kaiser is conditionally interested in contributing an early-slot map (the main hurdle will be whether this becomes a project or just remains a forum thread) so join in and sip a blood mocha or two.

    Current progress on my MAP07 candidate is linked below. Outside of Mikoportals, I've found using crushers+barrels on hidden monsters to reset a room with non-alert monsters to be a really interesting design path that I'll be elaborating on as I continue in the project. I've got distances set up with everything so that each monster/voodoo doll only takes 2HP of damage, which seems to be the absolute bare minimum that you can get it to. It's also not really possible to go full Doom 64 with map transformations, the ceiling specials just aren't flexible enough. But there's still some cool shit you can get away with.

    (Oh the mouse lag, unbearable, had to god mode to get that footage in Doom II Classic Unity. I can beat it in one on Choco. And ZDoom, well, Mikoportals don't work so I use a Boom friction special on the hidden sectors to achieve the same frictionless effect that Mikoportals give you so this works flawlessly there too - just never set foot in those sectors in vanilla or you'll crash out. Hence why I've named the map "idspispopd" because you'll break it if you noclip.)

  5. Tangentially related.

    Finland in lockdown is getting to me.





    I wrote a .NET Remote Binary Format reader so I could work out what their metadata structures are. Then I wrote a metadata writer that will deploy WADs to your local install. Experimented a bit, worked out what one or two of the fields actually mean rather than just blindly copying them from examples (there's a field called "type" whose valid values are either "iwad" or the target game).

    I'll release it when it can read and parse a standard wad zip file and extract info from the text document. There's also a JSON format I'm creating that will let you define extended details. Also not sure how it will handle getting updated WADs from the server - but since their naming scheme is exclusively numbers and I'm recycling the actual WAD filename, I think we'll be fine here.

    Example is just Plutonia with added Chapelle Show JPEGs and references.

  6. The really annoying thing about Hexen's switch hunts is that they already had an in-game solution to make the results much clearer. Items.


    But instead they went for the more technically challenging (at the time) deferred script execution method and figured showing text rather than providing clear design was good enough.


    If someone were to make a map patch WAD that changes the switches to be items/puzzle pieces/etc it'll do a lot to clear up some of the game's more annoying design habits. Some people might even say "Metroidvania" over and over in the release thread too.

  7. 47 minutes ago, Mordeth said:

    No, you don't need to make tons of "cake layers". Details (like stairs) can be easier done with edge portals. Edge portals work on the lower/upper edges of a raised/lowered floor/ceiling. Like, apply to the sides of a raised platform to make a 3D looking table in an otherwise normal non-portal room.

    Does that affect collision as well, or is it just a visual effect?

  8. 10 hours ago, therektafire said:

    From what I can tell from participating in a few quake related discords for the past few months this is actually a pretty common trick to get higher presicion lightmaps but apparently a lot of people don't like it because it makes shadows too sharp or something like that

    My preference certainly goes in the opposite direction of the community then.


    I had to turn bounce lighting off for those most recent screenshots to illustrate the request. The scene looks entirely different with bouncing on. And then there's those massive blocks when you do get a hard edge. I'd rather have higher fidelity light maps - but the maps I want to make also make no attempt to preserve a Quake-, or even a Doom- aesthetic.

  9. 3 hours ago, Bauul said:

    I appreciate the example screenshots, but is there a chance you could quickly mock up say a light shining through horizontal bars to really give us a sense of how they look in practice?

    That's the first time I tried using such small bits of geometry, and I immediately found issues.


    I can give you a couple more screenshots of some limping-along version though to give you an idea:






    You can really see the low fidelity of Quake lightmaps here - each texel of the lightmap is equivalent to 16x16 texels of the texture it operates on.


    Quake 3 lightmaps can work better, but they also come with their own set of quirks.


    There are also ways to cheat Quake lightmaps, that I only realised after delving deep in to their implementation details. Quake lightmaps are generated entirely in texture space. The physical surface size matters not. So if you were to double the texel density of a surface - say, by scaling the texture - you also get higher resolution lightmaps.




    I might branch EricW's tools and work out a way to let you scale lightmap generation for BSP2Doom's purposes.

  10. 12 hours ago, Linguica said:

    Those modern game engines and editors are also several orders of magnitude more complex and have god knows how many person-years invested in their creation and debugging. To the extent that the Quake "editing pipeline" is more onerous and requires more tools and steps and editing knowhow, the number of people willing to make such tools for free, and make them work well, is going to decrease accordingly.

    Granted. I can certainly go in to plenty of detail here as to exactly where that complexity is, and why the fundamentals of item placement and object manipulation can be comparable between Quake and modern engine editors (and why that only takes a man-month to get a good quality implementation competitive with Unity and Unreal).


    But why do more people try to create tools for Doom instead of Quake? Doom is a far more obtuse from a data perspective than Quake, and Doom editing is only in the reasonably good state it's in right now because people looked at the tools and the pipeline and thought they could do better. What if we were still using XWE instead of SLADE? What if Doom Builder was never written?


    There's certainly still improvements that can be made to the Quake pipeline. Custom monsters are a big one - ZDoom has plenty of "drop in" custom monsters. That still need you to manually construct a DECORATE with all the combined entries, but it's still a reasonably smooth process. There's no particular reason a progs.dat manager that handles new monster definitions and generates appropriate support code can't be done, other than no one wants to do it. So people still have to invoke QC.


    Trenchbroom also really needs to ditch those CAD views and provide multiple 3D viewports. CAD view really does nothing to help a normal person look at a Quake editor and think "I can use this". Real time lighting preview is certainly quite achievable as well, either by using modern rendering techniques or going old-school and using surface caching similarly to how the original Quake software renderer operated.


    But here I am writing a tool to improve the Doom editing experience, with a tangential goal of improving the Quake experience by getting more people interested in Quake editing. Interesting aside: Dusk's levels are Quake[1] BSPs converted to Unity. Perhaps we're on the threshold of a Quake resurgence.


    Quake 2, though, is in an even worse place (and with only one source port worth talking about). Quake 3, well, Googling for various terms only shows me quake3world as a hub and that seems fairly barebones.


    [1] Well, honestly, I say Quake but I figure GoldSrc would be the better option since each embedded texture contains its own palette.

  11. 4 hours ago, printz said:

    @GooberMan: Are you going to place linked portals instead of 3D floors if the two overlapping areas are unrelated? I mean that if passage 1 is above passage 2 and they're only connected in a hub room, place a linked portal near the hub room. Possibly helped by the Quake map author placing a special "portal" brush to mark where the portal should appear.

    Purely to keep my sanity, I'm focusing on getting it working in GZDoom first without portal tomfoolery. That certainly sounds like a great suggestion though for optimisation purposes. It almost starts resembling Doom 3 editing in that respect, placing down sectors for the portal culler.


    To that end:

    3 hours ago, Edward850 said:

    Unfortunately that certainly kills my interest in this thread. It's not really any interesting if all this works on is the two least-doom ports we have. 

    This will be an open source project. I'd be open to the right pull request from the right programmer. Programming in D really isn't that hard, at least the part that will need modifying. The UDMF parser makes heavy use of compile-time introspection and code generation, but the code that actually builds Doom compatible geometry should be quite readable to anyone with a basic understanding of C#.


    I'm not sure I'll have the patience or interest myself to do all the portal tomfoolery, but we'll see how things go when it's getting closer to release time.

  12. 6 hours ago, Linguica said:

    Maybe these are related!!

    I know a number of people on these forums would agree with your suggestion, but I find it to have a degree of false equivalence. There's several orders of magnitude more people making content with modern engines and modern editors than the Doom and Quake communities combined.


    There's plenty of theories one could put forward as to why people are more drawn towards Doom rather than Quake editing. Certainly from a pure map-creation perspective, there's nowhere near the variety in Quake bestiary as there is in Doom's bestiary. I'm tempted to make a parody Quake map called "I'm a piece of shit that thinks placing Spawns, Vores and Shamblers everywhere is a good challenge" but the straight-up truth of the matter is that your only other alternative is four types of melee enemy (two with alternate ranged attacks), the Scrag, zombies, and a couple of grunts. E4 is fantastic because it acknowledges that and goes for environmental tomfoolery.


    Doom mapping is often called simple because it's just like drawing a map on a piece of paper. Quake mapping, on the other hand, is a lot like building with Lego.


    This reminds me too. I saw a commit go in to the Trenchbroom Github that finally fixes subtractive geometry operations to operate on the world instead of needing to select everything else and then selecting the single brush you want to subtract last. And a new version was released a few days ago. Time to download that.


    EDIT: Yep. That significantly increases the editing experience.

  13. The side-panel list of entity properties is certainly the better way to go than the DEU-style properties boxes that Doom Builder uses. Trenchbroom's panel however just feels so manual-labor compared to modern engine editors. It can definitely be improved, especially with some docking support so that I can have the panel floating wherever I want.


    But yes, everything else I basically agree with. Quake editing pipelines more closely resemble modern engines.

  14. 21 minutes ago, boris said:

    Look at DM4, the stairs that lead to the quad damage. You'd pretty much have to horizontally slice the map for every single step, and that'd also affect other parts of the map like the shotgun room.

    That also sounds like a good stress test for Eternity's portals, since a thing would overlap several portals fairly often.


    Still. Supporting Eternity is well on the backburner for now. Especially if that's true about its slopes.


    EDIT: Another implementation detail. I'm setting floor and ceiling planes instead of using slope line actions. Having to make a ton of control sectors to make basic slopes doesn't sound like my cup of tea. Something as simple as this would need a control sector:



  15. 8 hours ago, YukiRaven said:

    and give me a good editor in Linux.

    Actually, this reminds me. The Quake community's editors and documentation are in a far worse state than here in the Doom community. I'm hoping an influx of people interested in Quake mapping would help that out.


    I'm also not a complete fan of Trenchbroom. Its entity property editor is fairly barebones - anyone used to Doom Builder is in for a shock. And its insistence on not providing standard move/rotate/scale gizmos is frustrating. Doing fine grained movement with camera angles it doesn't expect (ie anything approaching horizontal) often results in my brushes moving out to the distance. I also think that brush/entity selection would benefit greatly from a hierarchy view, not just from an organisational standpoint but to allow simple mass selection and things like group movement by selecting a parent node.


    I'm half tempted to write a Quake editor myself from here. That's probably one side project too far for me right now.


    8 hours ago, YukiRaven said:

    Are liquids translated to swimmable 3d floors?

    That's the plan. Liquids are a little bit tricky in the BSP - no entity, capping surfaces only, name of the surface special-cased by qbsp and the engine. FWATER1 will be a solid wall by default. I need to double check the Quake source code for implementation details to see if there's anything I'm missing, but at the very least this is going to require user input to define liquid surfaces and my tool will generate Quake-compatible surface names from there.

  16. 8 hours ago, Edward850 said:

    While you might already know this, note that with Eternity it doesn't quite have 3D floors in the same way ZDoom does. Instead it has fully traversal portals, so instead of making a shape of a floor flagged from a control sector, you'd sort of make a map sandwich and a part of the floor/ceiling (or walls) is linked together. GZDoom does support these as well although I'm unsure of its compatibility level and naturally the line actions are different.

    I've never looked that deep in to Eternity, but that certainly kills the initiative I have to support it.


    It's not an impossible task. But it sounds like it means making a ton of horizontal map slices. Another implementation detail I neglected to mention is that I do all the heavy lifting in an intermediate format (hence why Quake 3 BSPs are on the cards), so sorting in to horizontal slices and running the code I already have on the results would be the obvious way to do it. Sounds fairly tedious to get up and running though.

  17. 25 minutes ago, YukiRaven said:

    How complex can the geometry be with this? Like, could it theoretically handle something like ad_sepulchre or Grendel's Blade?

    If you can build it in Quake, I can translate it.


    With some exceptions. One map I would like to make is something of a demolished building/ship crash kind of map. Which means doors would naturally want to be sloped. I can't translate dynamic objects to Doom like that. Certainly the portcullis style of doors would demand doors get implemented exclusively with 3D floors instead of polyobjects, but that also immediately rules out many Quake style doors.


    Moving platforms will work if I embed those ACS scripts I wrote, but there's also some changes I've long wanted to get in to polyobject collision resolution that would stop the desync bugs that are possible currently.

  18. I mean, I'd really like to not use that spotlight hack. The thing that'd make or break your suggestion is how Cacodemons floating across 3D floors will be affected by doing solely sector lighting.


    I've not seen a Quake poly inhabit anything larger than a 192x192 space, which sure is smaller than many DOOM.WAD/DOOM2.WAD sectors but also isn't really fine grained enough for subtle lighting. So I'd want to split in to further subsectors for an all-sector approach.