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

GooberMan

Members
  • Content count

    1621
  • Joined

  • Last visited

Everything posted by GooberMan

  1. I've been working on a little something in my spare time over the last few weeks. Many years ago, when I was doing 3D floor layouts in Prime Directive, it was really annoying me that the tools were so obtuse. It required essentially a hacker's knowledge of exactly how the feature works to place them. Draw a 2D sector, draw a control sector, set up the lines. Doing anything reasonably complicated with them required thinking in full 3D in a 2D space. The community has long used a baked binary format - the WAD - as both its source and target data, and it annoyed me that GZDoom Builder didn't support a custom source data, allow arbitrary placement of 3D floors, and bake that data down to a WAD during the save operation. Of course, adapting GZDoom Builder or even writing a new editor is a big task. There's a bit of a different solution out there. Enter BSP2Doom. Quake has existed for a while now. There's full 3D editors and everything. And Doom engines have supported 3D floors for a while now. Translating Quake maps to Doom isn't the impossible task it used to be. Honestly, I know community loves building these big sprawling vista maps at the moment, but it really felt like overkill looking at last year's Cacoward winners and every one had a vista screenshot. So let's see what kind of gameplay we can get out of Doom if we start thinking about it with verticality as an actual thing. Besides. I spend my work day knee-deep in Unreal Engine doing everything from bug fixes and optimisations; to finishing half-implemented features the UE team left about. This is relaxing and far less insane in comparison. The workflow goes something like the following: Use another tool in this package - Doom2QWad - to create a texture WAD that Quake editors can read This will also spit out configurations for Quake editors in the future Load up an editor like Trenchbroom Create a Quake level using Doom assets Compile your map. EricW's tools are the gold-standard in the Quake community at the moment. Do the following: Run qbsp. You don't get geometry otherwise. Run light. Your map will be fullbright otherwise. Don't build vis data. This is normally where you'd do such a thing for a Quake map. It's 100% unnecessary here Run BSP2Doom. This will spit out Doom-compatible data from your newly compiled Quake map. Run your normal node builder on the new map WAD. Run your map. The resulting map is not meant to be edited in a Doom editor. Depending on the options given to the BSP2Doom utility, the map could look anywhere between normal and nightmarish when loaded in a Doom editor. The WAD here is exactly a cooked data format. Only ever edit the source format. The code isn't ready for public release. It does already live on Github in a private repository though, so all I'll need to do is flick a switch when it's ready. Regardless, I plan on releasing it with a mapset rather than just dumping it on the community. I have a couple of maps in mind, but I'll also be on the look-out for experienced mappers who want to explore what Doom can do when properly exploiting a 3D playspace. No slaughter, no everything-is-a-trap, no epic vistas. Drop the cliches and let's see what else can be squeezed out of Doom. Also of note: I'm resurrecting Calamity with this tool. The old code I wrote will basically be ignored. Much of the code I'm writing now will make it in to Calamity with an optimisation pass or ten. It's all being written ground-up in D, which is resulting in some really clean code (the UDMF parser is ultra clean; the BSP parser reasonably clean; the WAD parser less so because it's an insane format wholly reliant on the original implementation). Progress Quake BSPs - Geometry shell done. 3D floors about 80% done. Doors and platforms TBD. Lightmaps working but constantly being tweaked. Coloured lighting (ie .lit files) supported. Quake overbrights supported. GoldSrc (Half-Life, Counterstrike) BSPs - Preliminary. Data structures almost identical to Quake BSPs, just need to build some test maps. Quake 3 BSPs - Preliminary. Data structures defined, but need to handle bezier patches before I can attempt to support it. A big question I have is how to support doors and platforms. I haven't decided if I want to bake them in to the map geometry, or use all the polyobject tricks I whipped up a few years back. I will likely try both approaches. Engines supported GZDoom - Working off 3.6.0 as a base, probably works fine on earlier builds Eternity - The UDMF namespace is fully supported at the least, but since the GZDoom implementation heavily relies on shaders this will probably need the software fallbacks I'm coding k8vavoom - Same deal with the shaders. A way to hook in to its own lightmap system with my pre-baked lightmaps will be fab and mostly eliminate the need for shader work. Output formats Map UDMF Textures PNG Doom lumps Packaging Doom WAD ZDoom folder structure Run 7zip or equivalent in your build pipeline if you need a PK3, this is designed to be a scriptable tool and not an all-in-one solution The theory behind translating geometry Things? Entities? Quake style lighting is quite different - how do you handle it? Lighting system implementation details Screenshots
  2. Remember when id found the Quake 2 modding community so strong that they made a commercial release of it?
  3. GooberMan

    Do You Own a Device Capable of Playing Audio CDs?

    I buy CDs for archival/artwork/support purposes, and listen to that very music on streaming services. I own several devices capable of playing CDA, but they basically never get used anymore.
  4. Ah yeah, I don't think I got around to compiling again on Linux/Raspberry Pi after I made that change due to ImGui shenanigans that I hadn't sorted out. That's just #include bullshit. Follow its instructions and jam the following up the top of the file after the last line to start with #include: #include <string.h> That'll get ya going until I do the change myself and push to github.
  5. https://github.com/GooberMan/rum-and-raisin-doom Rum and Raisin Doom is a limit-removing port focusing on both vanilla accuracy by default; and performance on modern systems. Features include: Startup screen that looks like ye olde DOS Doom's text startup Complete integrated launcher, allowing free IWAD downloads, idgames browsing, and more Limit removing when using the -removelimits command line parameter A multithreaded renderer 64-bit software rendering Dynamic resolution scaling Frame interpolation Widescreen assets support Support for unsigned values in map formats, as well as DeepBSP and ZDoom nodes UMAPINFO and DMAPINFO support Flats and wall textures can be used anywhere Dashboard functionality implemented with Dear ImGui Full support for Raspberry Pi on Debian-based operating systems Latest pre-release: 0.3.1-pre.4 for Windows https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.4 BEX support added, INCLUDE directive unsupported Latest release: 0.3.0 https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.0 This one's a big release, because it comes with official support. Got a bug? Let me know! New Features: Complete launcher frontend is now brought up if you launch without an -iwad parameter. This is designed for a good first-time-user experience. If no IWADs are detected, you can download some. Want some new maps? There's a fully integrated idgames browser. More features and polish to come in the future. Dynamic Resolution Scaling is now included in an initial format. It scales both horizontally and vertically. This is currently in a preview stage, as I need to work on a few other things before this works as intended DMAPINFO and UMAPINFO is supported. Tested on Unity IWADs, Sigil, and Knee-Deep in Knee-Deep in ZDoom. This involved a complete reworking of how maps are referred to, with vanilla-exact matching of functionality retained. Futher map info format support will come down to writing the handler. Also required rewriting intermission screens, so that's waiting for some kind of format to exploit that. Multiple software backbuffers. DOS Doom had three backbuffers, giving noclip/HoM effects are very noticable forward velocity. You can now replicate that effect by increasing the number of software backbuffers. Stats overlay. Currently very spartan, but only because the default layout is like that. The system implements way more functionality, which I will expose in the future to users via an options window panel. Sound and detail shortcuts, as well as Options from the main menu, now bring you to the relevant section of the dashboard. Backbuffer resolution can now match window sizes; and the drop-down box for selecting backbuffer sizes is categorised as well as having named shortcuts (such as Vanilla, Crispy, and Unity style resolutions). Every platform now saves data to the user's home folder. You can make a portable install by placing an empty file called rnr_portable.dat next to the executable. Additional lighting slider added to the "View" tab in the options window Bug Fixes: 0 or less column rendering bug in balance loading no longer occurs Rendering interpolates while the menu is active Distance lighting is way more accurate for resolution heights that don't cleanly divide by 200 Previous contents of this post:
  6. GooberMan

    Rise of the Triad: Ludicrous Edition

    Maybe it's time to confess about the secret 160x100 mode that activates when it detects signs of DK-enabled users at the keyboard?
  7. GooberMan

    Rise of the Triad: Ludicrous Edition

    It's not broken in DOSBox. You're just plain not running it with a VGA card on a CRT. The short story is that the effect changes the colour of the "overscan" region of an analog monitor. Modern monitors do not have this region available to them. Shrinking the gameplay area in a window (fullscreen or not) to have this border visible in a meaningful manner is the definition of a bad idea. Everyone except the five people who remember that effect will think it's a bug. As a remaster, the current effect of flashing the screen red a little bit is the far better way to go.
  8. GooberMan

    Rise of the Triad: Ludicrous Edition

    I have in fact personally fixed that bug. It'll be in the first patch.
  9. Oh nice, I haven't had to deal with PowerPC since the 360/PS3/Wii days so I completely missed that. In that case, assuming GL3 support is good then it "should" run.
  10. It requires OpenGL3 support (the Dashboard is hardware rendered, and the palette decompression for final display is done on the GPU), so if that actually exists for your hardware then cool. However, I've made next to no effort to maintain big endian support. Confidence isn't high.
  11. GooberMan

    Rise of the Triad: Ludicrous Edition

    Some people just want to listen to everything on 8-track I guess.
  12. GooberMan

    Rise of the Triad: Ludicrous Edition

    (My rendering code is in the game, as are a few of my maps in the HUNT Continues campaign)
  13. Where have I been? Well, I've been focused on Rise of the Triad: Ludicrous Edition. I was tapped to help the team optimise the renderer. It uses code I wrote for Rum and Raisin Doom, specifically the floor renderer. And then because I could, I implemented the idea I had for lightmapping. Knocked out the initial implementation in about an hour, spent about five or six more polishing and refining it. The image quality of the game is immensely improved as a result, I'm fairly pleased with how it turned out. I've also got seven levels in the new campaign, The HUNT Continues. That was a creative outlet I didn't know I needed at the time, but it turns out ROTT still has a ton of design space to explore. It was a blast working out which way the game would bend and still be a cohesive experience. Now that it's out and my work will naturally be winding down, Rum and Raisin is in my sights again.
  14. Quick update. I'm still settling in to my new job at World's Edge. Yeah, I've switched from shooters to the other genre that was big in my teens - RTS. Wait until I'm 50 and I decide to get in to making adventure games. It does mean that I've ignored Rum and Raisin for a few weeks now. The next version I push out will be 0.3.2, which is basically pending getting Raspberry Pi back up and running. Dear Imgui decided to change how they handle OpenGL, and because version reporting is broken on Pi 4 its own internal loader decides that the version isn't high enough and quits. Works just fine if you remove that version check, but as I'm directly linking to the relevant versions of cimgui/Dear Imgui and not copying and maintaining my own branch then that basically leaves me with statically linking GL libraries on Raspberry Pi only. Some annoying fiddly config stuff needs to be done there, and I just couldn't be fucked over the last few weeks. Either way, if there's any small requests or annoying bugs you've seen. Now's the time to let me know. Once 0.3.2 comes out, there will be very little public progress on this port for a few months as I'll be going in to silent mode for a feature or two.
  15. https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.4 And there's that BEX support. The INCLUDE directive is unsupported, but everything else is working with the limited set of WADs I've tested with. Unsure how to handle adding -deh files on the command line in cases like D2TWID, since multiple DeHackEd files is perfectly kromulent and you'd basically need to parse every file to detect multiple files modifying the same bit of data to highlight potential errors. For ease of use/convenience, the idgames browser will straight up not add .deh files to the selected files list if there is a DEHACKED lump inside any WADs found in the archive. I don't believe any WAD will break because of this, but note that you'll find the .deh inside the "Change selected files" dialogue anyway if you want to manually add it.
  16. GooberMan

    Helion - C# (0.9.2.7 2/9/23 - Goodbye BSP tree rendering)

    Slightly different to the approach I was going to take. There's a bit of a misconception about Doom, in that there's not enough static data to create static buffers and just roll with it. But the reality is that there's exactly four dynamic elements of a Doom world: Floor height Ceiling height Light level Scrolling textures The last two are exclusively visual effects and have no relevance to anything but the end user; the first two are both a visual effect and required for culling objects. The approach I was going to take was to bake that static mesh, but never update subregions. I was going to use constant buffers for each sector (and for scrollers) and only update those four values listed. Less to go up to the GPU that way. Then reconstruct what is required on the GPU from those constant buffers. Honestly, Doom's rendering is so simple that you're probably wasting wavefronts. There's likely a ton of processing power to spare in each wavefront, but I won't know exactly what the cost differential is until I try each method and see what the results are. It's funny though, since that could sound like the opposite approach I take to bring Rum and Raisin's times down further. Sprite clipping is a nightmare, and there's going to be more efficient ways to do it. But a large chunk of time you see in my screenshot is the renderer preparing walls. Setting up the values for the column renderer to just go for it. This can all be computed at map load time. Adding a scroll offset and projecting the required UVs for the renderer is the smallest cost, there's milliseconds in that screenshot that can be saved just from checking flags if it's upper/lower pegged etc and adjusting offsets according. On the other hand, it's virtually equivalent to setting up those static buffers with constant buffers used to update select values.
  17. GooberMan

    Helion - C# (0.9.2.7 2/9/23 - Goodbye BSP tree rendering)

    i7-6700HQ 2.6GHz software rendering at 1920x900. No Boom functionality in Rum and Raisin yet, so unplayable. Throwing some Ryzen cores at it should bring that render time down from my ageing machine. Ran it on my profiling build to get an idea of where the time is actually going, and yeah good ol' fashioned setup/clipping stuff. Which I have solid plans to tackle, so expect better performance in R&R in the future on this scene. Won't be a concern with a hardware renderer, basic Z clipping will handle everything that these software routines do. I should also say, this port is basically doing what I was going to do with Calamity. So it pleases me to see it doing as well as I expected. There have been better ways to render Doom scenes for a very long time, and no one should be discouraged from going down those paths to see what shakes out. There's some reference maps in that thread I linked in fact that will help with flat rendering issues.
  18. Aha, exactly the kind of bug I've been looking for to test with. Thank you. Short story: The DEHACKED lump masquerades as a valid DeHackEd 3 file but looks like it has some BEX elements. I've set R&R to always look for lumps and the only way to short circuit that right now is to go in to non-limit-removing mode. Relying on just the lump with D2TWID results in a stack overflow on MAP31; and adding the (correctly formed) external DEH on top results in the no collision being observed. I think I'll just have to go ahead and make BEX support a thing for the next version.
  19. Wow, that's bad. It used to tell you a DLL is missing, not give you an error saying it can't resolve a function from a library. I consider that a regression from Windows there. Aaaaaaaaaand it could also explain why there's unexplained errors popping up in the frontend. Either the MSVC runtime or the UCRT not having correct versions installed and resolving functions from those libraries would bring up those kinds of errors. If you're not running Windows 10, UCRT needs to be installed. You'll also need the MSVC runtime regardless of Windows version.
  20. It's more like this source port is encountering a WAD that gives it unexpected data, and I have zero information on what WAD it is so it keeps crashing. It's probably some ZDoom targeted WAD though, I did find some issues trying to load NUTS3.WAD (which is completely playable in Rum and Raisin). To that end though, there's a new pre-release version that has extra error checking in where I think the crash might be. If this gives good information, then copy/paste the error. Screenshot or follow the CTRL+C to copy instructions, either way will give me the information I need. Also "fixed" in the new pre-release. And the quote marks there need some explaining. Rum and Raisin Doom's saved games are 100% vanilla compatible. You can load them up in Chocolate or DOS Doom and they'll work. Now, this is a minor problem for stat trackers. Doom's gamesim operates destructively on sectors - walk in to a secret sector and it unsets the secret special. And it's that special type that gets pushed in to save games. Load a game, the only way you'd know if it was ever a secret is to keep track of that in between loading the map and loading the savegame. I've taken the approach of just dumping extended information at the end of the save game file. There's more than just sector secret states that I track - I also dump monster resurrection counts. This is important for when the stat readout designer gets implemented, allowing people to customise the readout if they just want to know how many monsters count towards the killcount. The extended savegame lump has had versioning since the start, so you can load old save games and they'll work but they'll still have bad stats. New save games will have the correct stats.
  21. GooberMan

    Helion - C# (0.9.2.7 2/9/23 - Goodbye BSP tree rendering)

    I had to deal with this recently myself. If the drivers can resolve some exported integers from your program, then they'll always choose the discrete GPU over the integrated one. This is C/C++ code, I can half imagine how ugly it'll be to get it working in C#. #if defined( __cplusplus ) extern "C" { #endif // https://docs.nvidia.com/gameworks/content/technologies/desktop/optimus.htm _declspec(dllexport) DWORD NvOptimusEnablement = 1; // https://gpuopen.com/learn/amdpowerxpressrequesthighperformance/ _declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1; #if defined( __cplusplus ) } #endif
  22. If you use libsamplerate in Choco, you will get the same sounds. I'm in the middle of setting up the sound options so that you can change the resample quality on the fly. Right now, it's not using the highest quality resample because it significantly affects load time. I will also cache the results once you've selected them so that it's not necessary to recompute them every time you use them but it does mean working out the correct path to cache the results to, ie tracking which WAD it the sound sample comes from and caching based on that filename. I've got a callstack from someone else for the unhandled exception, so I should be closer to tracking that down.
  23. Yeah, but Heretic doesn't have the same treatment for example. So I decided on solving that problem before I got there.
  24. https://github.com/GooberMan/rum-and-raisin-doom/releases/tag/rum-and-raisin-doom-0.3.1-pre.2 The file browser is in. It's only accessible from the "Change Selected Files" plus signs. Need to work out how to handle IWAD adding correctly, but at least if you select one from there it will actually update the IWAD list and choose that IWAD. More importantly though: The error handler will try to catch every kind of exception and give you a callstack so I know where to go looking for the problem. For example: Oh, yeah, I bluescreen on error now too. You'll see this sitting beneath the callstack dialog box:
  25. I started noticing it when playing Call of Duty: Vanguard last year at 120Hz. It feels almost intangibly different to 60Hz, but I was noticing myself playing better than I had been. And yeah, it's just simple mathematics. CoD's multithreaded renderer means it takes one frame to simulate and one frame to render, ie you're seeing results two frames after input is read. At 60Hz, that's 33 milliseconds. And at 120Hz, that's 16 milliseconds. Rum and Raisin doesn't do that style of multithreaded rendering (yet - it will be an option) so that brings it down to 8 milliseconds at 120Hz. Or to put that in terms of the average human response time (150 milliseconds), it's gone from 22% of the time at 60Hz CoD, to 11% of the time at 120Hz CoD, to ~5% of the time in 120Hz R&R. It's way closer to real-life information delivery and response times, and it absolutely does make a difference. They don't call them "twitch shooters" for nothing. I've got word that DSDA-Doom already does do something like what I've described, so it'll be the built-in prBoom lag that's making that port feel off for me.
×