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

GooberMan

Members
  • Content count

    1621
  • Joined

  • Last visited

About GooberMan

  • Rank
    Scripting Nut

Recent Profile Visitors

5543 profile views
  1. Remember when id found the Quake 2 modding community so strong that they made a commercial release of it?
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. GooberMan

    Rise of the Triad: Ludicrous Edition

    I have in fact personally fixed that bug. It'll be in the first patch.
  7. 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.
  8. 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.
  9. GooberMan

    Rise of the Triad: Ludicrous Edition

    Some people just want to listen to everything on 8-track I guess.
  10. 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)
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
×