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

GooberMan

Members
  • Content count

    1515
  • Joined

  • Last visited

About GooberMan

  • Rank
    Scripting Nut

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. GooberMan

    [Wolfenstein: Blade of Agony] Achievement Ideas? (p13)

    So the response to content that's deemed anti-Semetic and transphobic is to, uh, go Soviet? That's a weird flex.
  2. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    Update on this: There is no update. Why? So I stepped up to Technical Director a few months ago at Housemarque. My focus right now is on shipping the game. I don't expect to get back to R&R Doom until late May at the earliest.
  3. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    Well, it was inevitable. But real life has gotten in the way of progress over the last couple of weeks. Next thing to come will be an article on the threading. And before I go any further with features, I think I'll need to re-architect a few things so that I don't lose some vanilla compatibility I want to keep.
  4. GooberMan

    dsda-doom source port [v0.21.3]

    I started programming a "suicide if pacifist" feature in to Rum and Raisin. And also Tyson functionality. My approach is more player-focused than demo-authentication though, so :+1:.
  5. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    https://github.com/GooberMan/rum-and-raisin-doom/wiki/Rendering-Visplanes-by-Column New article. Attempts to give a ground up understanding of all the concepts involved with rendering visplanes by column.
  6. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    Just leaving some 21:9 shots. And also: I'll use this scene as a guidepost to see if my visplane lookup code is working as intended. At 21:9 and 4 render contexts, the middle 2 overlap the normal HUD. And the other two hit blocking walls fairly quickly, hence their disproportionately small times. Fixing the render load balancing code to not be a colossal fustercluck will also help spread the cost, but as I always say in a professional environment: Threading is not a silver bullet, your slow code is still slow on another thread.
  7. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    Oh, nah, sorry mate. Context, I guess. Short story is that I am bipolar, so sooner or later I'll just flat out lose interest in this. The fact that people like Altazimuth are waiting on my results and that it will subsequently benefit a large part of the community means that my focus will stay for far longer than it did for, say, BSP2DOOM. Which I couldn't get enough people proper interested in. Code still exists, theory is still about the same even after digging deep in to the renderer, but no real incentive to continue the work. And also my Demon Workers Unite! mapset, which I had grand plans of being an industry-wide relaxation effort but no one (outside of Kaiser for an intro map) seemed interested in. A bunch of other things, including professional concerns, would need to go a certain way before I commit to a full blown source port effort with users and all that. I do know that my kind of attitude and experience would be a good thing in general for source ports. See the bottom of my first post, and the nochicken reference a few posts above? This work is also, in part, my response to that kind of insanity. I can describe theory until the cows come home, but now for the first time thanks to very favorable professional conditions I can also supply code which is a very effective STFU mechanism. But actually committing? I've got a Playstation 5 game that needs my attention, and when I get to the point where relaxing doesn't mean "thinking about code 24/7" any dedicated source port efforts I make will take the hit.
  8. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    Being a real source port means I'd isolate the playsims in to their own dynamic library. Vanilla. Boom. Even ZDoom if you wanted would go right in to a switchable-at-runtime library. All dependent on render support of course. Whatever, playsim features can be their own thing. Even up to MBF level you don't need to do a whole lot different from a rendering level to support the advanced features. Again, I really want profiles from Eviternity. Since that's a gold standard mapset and a first-stop for many people new to the Doom modding community. It's not an unusual idea. Pretty sure Ling wants to do the same thing with his dream port.
  9. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    Well, this is the thing. If it's a real source port, I have to provide support to users. And if it's a real source port, it's harder for any other source port maintainers to see the ideas I'm employing and pull them in to their own ports. This is ultimately the point of the articles I write. I want everyone to understand what I'm doing. Seriously, redefining visplanes is a big thing. This is something that hasn't changed since 1993, but this work has allowed a new understanding of what they actually are. And if I can put that in a format that anyone can understand from the ground-up and employ in whatever source port they're developing, then that's far more valuable than a reference implementation in my opinion - for example, Linux Doom is a reference implementation and yet everyone's still using spans for software rendering. And it's already giving results - just from my articles and questions on Discord, Altazimuth has implemented the backbuffer transpose in Eternity. I really want to see some results with Eviternity, get an idea of what else is deficient. This is a resource for all Doomers. Being a real source port does diminish from that.
  10. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    I honestly need to tread lightly around jailbroken/modded devices. I mean, back in the day we used modded Xboxes as devkits and I did work on our PSP engine with my own hacked PSP. But it's a different industry these days. Doing it on a Raspberry Pi is the closest I'll get without professional concerns coming in. Back-and-forth development on someone else's Switch with them reporting results is not something I want to do either. It's already a ballache trying to get ImGui playing nice with GL3 on Ling's mac (and I've given up for now and just #if 0 the offending code out). Subsequently, I'm hunting for a cheap Mac that I will literally only be using to compile and test on, so it can be an i3 for all I care it just needs to compile and run code.
  11. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    I keep saying that I don't want this to become a real source port, that I'm happy to have this as an academic project and provide articles and explanations for what I'm doing so that anyone else interested in what I'm doing can grok it and try it out themselves. But it is dangerously close to becoming a real source port after all. Implementing widescreen support, and I'm all "It's 2020, I expect to drag my window out to 42:9 and have it work". The reality of the Doom renderer is that the trig calculations start breaking down after a horizontal FOV of 165 degrees, so I probably can't get it to go that far without rewriting the projection functions entirely. First time I tried Doom in 21:9 though, and ooh yeah. Lean in close to my monitor (27") so that it fills my peripheral vision. It's gooooooooooood. But widescreen though, there's a thing I wanted to profile here. 3 cores, pixel density just a tiny bit more than a proper 1080p render buffer. Three threads. Raspberry Pi 4. Clean out the spikes, and this is basically "If I had a Switch I could make Doom render at 60FPS on it" territory right here (ignore that bit about being a debug build, that's just me getting the defines wrong on not-Windows). I've shipped games on 11 platforms. 12 when Returnal releases. Worked on several others platforms. So yeah, making it work well across multiple platforms is one of my things - and being an engine programmer, gaming hardware especially interests me. Maybe I'll finally do something about visplane merging when I'm done fixing all the widescreen bugs. Although "use a hash map" for what's there like every other port is probably the best I'll do, short of actually doing what I said and dealing exclusively in rasterlines instead of visplanes and walls.
  12. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    I think you'll find literally every post I've made in this thread emphasises that you did not need to say this.
  13. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    Yeah mate, the full context is "ditching the original function at high resolutions is just plain necessary" - which it sounds like basically every high res source port either does, or fixes the problem another way. All good. This reminds me, it was glitchy with the original code and I haven't checked with the new code. Chocolate Doom, so entirely untainted by my code: Original code, 32-bit sample indexing at 2560x1600: And my new renderer: I can spot a bad pixel, but that line down the centre of the Icon's visage is otherwise eliminated. The pixel artefact also appears more at lower Log2 samples. So clearly there's more work to be done.
  14. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    Can the community at large say offhand what exactly the precision issue is? Or do you really mean source port authors at large? The average person around here doesn't know how or why. The Doom wiki won't tell you. Even reading the Doom black book won't tell you. A video like that, I'll use later when documenting everything to illustrate the example. Note that I describe visually what transposed means in the first article I list on the github wiki - something that anyone who's ever looked at how Doom texture data is stored knows, but that most people don't need to know how or why it's like that. But I'll give a ground up understanding for whoever wants to know. (Short story, since it's now a Thing: That original sampler recorded in that video actually isn't purely the original. I modified the span function to use the full 32-bit values to sample the texture. The issue comes from a precalculated scale value based on the centre column that is used to adjust the X and Y integration values for span rendering. These values become more and more inaccurate the further away from the centre of the screen you get. And it's entirely avoided with my function going vertically along the screen and self-correcting after N pixels depending on the backbuffer resolution.) Needless to say, this next bit should be addressed as a separate thing: No, and I have no intention to. Again, this is a way for me to relax. More pragmatically as a wider community, this is also a way for anyone that's interested to see what someone with my knowledge and experience would do when given a blank slate. Using ZDoom's headers as an example, the flat plane still wants to draw by span instead of by visplane column. I would gain nothing from that, since transposing the backbuffer means that's not a good idea. So I had to look at exactly what a visplane is, going in knowing that it stores top and bottom pixel values for screen columns. Which led to the realisation that these are exactly rasterlines for a texture mapper, and that the span translation is really quite unnecessary. Which leads to a further realisation: Every piece of render data in Rum and Raisin Doom is now actually a rasterline for a texture mapper. I'm seriously considering the benefit of deleting visplanes, deleting the column renderer, and generating and sorting raster fragments in a list for absolutely everything. Sprites, walls, whatever. They're all exactly rasterlines now. At which point, I'll basically have accidentally converted vanilla Doom in to a full 3D renderer - and be more efficient while I'm at it. And keep slime trails too. Where exactly am I going to get those kind of realisations by reading another port's code? Maybe Vavoom? Except that started life as porting the Quake renderer to Doom, and I've already separately dug in to Quake's renderer. With visplanes rendering faster, I'm approaching the limits of what I can do at a raw pixel level. Once SIMD is up and running properly, it's all algorithmic from here. And I'm going to get more speed wins by similarly abandoning conventional wisdom.
  15. GooberMan

    Rum and Raisin Doom - haha software render go BRRRRR

    So here's a bit of fun. You can actually very easily break my new code by using it at low resolutions. So I auto select the right function dependent on resolution. But you can just plain override it anyway for strange visuals. Also, ditching the original function at high resolutions is just plain necessary. This version of the original function even upgrades the sampling coordinates to the full 32-bit and it's still plain awful. But unnoticable at the original 320x200.
×