Rachael

Members
  • Content count

    197
  • Joined

  • Last visited

Community Reputation

34 Neutral

1 Follower

About Rachael

  • Rank
    Junior Member
  1. Yeah, that's really oddly specific for a bug like that.
  2. This problem is fully solved now. All I had to do was disable the fog boundaries after they were redrawn once in the "renew" pass. (In the unlikely event anyone is actually curious - it was done here -> https://github.com/coelckers/gzdoom/commit/e290274fb769a6059656842c8cf8d8398436a0c5)
  3. https://github.com/raa-eruanna/qzdoom/blob/8af9f56895629f4d35f09df80dff49480b857f7d/src/r_main.cpp#L650-L681 This is really old render code from ZDoom, but it comes from a time when I managed to fix a minor bug in it. The calculations for "mirror flipping" are here. I don't know if this helps you or not, but I hope it does. (I think this highlighted code block was written by ZZYZX, if you need to contact him for anything) Of course, you still have to render it backwards, but once you get this part down I think the rest will come a little easier. ;)
  4. So - here's my white whale. I've been trying to tackle this for months, and figured I might as well give this forum a try - there might be someone (well, honestly, a lot of people) who knows the software renderer better than I do - particularly ZDoom's, and in this case, hopefully, particularly ZDoom's 3D floor code. As a lot of you might know, there has been a bug in ZDoom's 3D floor code that if fog is present, it overdraws the fog boundary which causes it to not be properly clipped to the walls. If you attempt to run Unloved in the GZDoom software renderer, there are a few places you can see this bug very prominently. Here's a screenshot of the bug in action: So - yeah, I've been trying to tackle this one for months, and may have managed to make a break-through with this commit: https://github.com/raa-eruanna/qzdoom/commit/add0acc0c6c1c97a9998d568c070475735be2344 Here's a screenshot of the same scene after this commit is applied: That should be all she wrote, right? Not only that, it fixes the fog boundaries appearing way too dark, as well. Bonus! So - off we go packing, problem solved and everything, right? Not quite.... There's still some overdraw occurring, and I think it might help to have a fresh pair of eyes look at the code to see what I could be missing - or if there's a better way than this admittedly gross hack (which pales in comparison to what it originally took to get 3D floors working in the first place, in this case, to be honest) to fixing the problem. Any help would be appreciated. The room where I am primarily testing this is the room that leads to MAP04 inside MAP01, though MAP04 right at the very start works, too.
  5. I think both Eternity and 3DGE can use the same set of DDF files for that purpose. But I don't think such functionality is available in a lot of other ports - what would you do, for example, for PrBoom+, Chocolate Doom, Retro/Crispy/etc/whatever other fork of Chocolate there is?
  6. Being a bit of an outsider with regards to Freedoom development, I've always found myself wondering if Freedoom really needed those strings. I get the whole effort to gear towards uniqueness and stuff, but I think the DEHACKED thing should be restricted to using actual Dehacked on the vanilla executable, and let the source ports import the strings themselves. This should be done, obviously, after they've been finalized because it would be very difficult to change them later on after everyone's brought in their own copies. But I still am a bit iffy on whether the string changes are even needed.
  7. With QZDoom (now GZDoom) - no, that's not how it works. Actually, the screen is divided into rows based on how many threads are available. Every column that gets drawn batches its data into individual threads and each thread does 1/Xth of the total column (where X is the number of virtual cores your CPU provides), and each worker thread does every 1 in X rows on its own after the setup stage when the drawer queue gets called. I am not exactly sure how it works beyond that like how it makes decisions about what to render when on each thread, but that's basically the whole gist of it, right now. There is, in an experimental stage, a software renderer in GZDoom that does slice the screen vertically by how many cores are available (if I understand it correctly) - but it's highly unstable at the moment and is prone to crashing. Render performance is drastically improved when this is enabled, though, to the point where the bridge scene on Frozen Time is actually playable.
  8. Ugh. Yeah I never thought about that with people running 4k and 16k. Those are big-time CPU blockers, especially for Eternity. That won't be a problem if Eternity picks up a multi-threaded renderer, at the very least, but it would have to split the entire screen and batch the rendering into vertical slices if it did it that way - not the way Q/GZDoom does it. That's the only way that renderer will survive being future proof - because as I see it, CPU's are getting more cores, but not more clock speed, but taking advantage of the new cores will at least somewhat make up for ever-growing display sizes, which if they keep expanding at this rate will still be unmanageable regardless, eventually, but at least it'll take a decade or two for that to happen. Much as I love Eternity's software renderer - HWPoly is the only real future-proof solution to that problem. :(
  9. I would say this is true, and my interest in creating a true-color renderer for Eternity extended mainly to software truecolor. Would it be nice for Eternity to have a true OpenGL (polygonal) renderer? Sure it would. But we already see just with GZDoom that there are issues with it - and while GZDoom may definitely be one of the more developed ones it still does expose a few problems with transitioning a 2.5D system into a true 3D world - and even has to have some compatibility patches, or in some cases even gross hacks, to try and make them a little less obvious. Plus - and this is purely my opinion - Eternity has one of the best paletted software renderers out there. It's definitely slower than ZDoom's, but for that price it's more accurate and definitely has vastly improved portal support. In my view, if Eternity does go true-color it should definitely do it in software, first, before attempting the polygonal hardware version - because it would be a real shame to see people abandon that renderer. (Yes, I am actually jealous of it)
  10. I couldn't find that on the package manager. Is it someplace else?
  11. Alright - so far - I've discovered that Haiku does not include SDL source files in the package manager. That presents a huge problem - one that we might be able to overcome simply by directing prospective users to download SDL from elsewhere, or simply 'link' it directly from the GZDoom repository and let CMake find it, but it may still require the OS packages to be installed. I'm hoping that dev packages start becoming more common in Haiku's repos - they're really needed. Luckily CMake is easy to install, so that's one big hurdle out of the way.
  12. I'm actually going ahead and downloading a copy of Haiku now (a dev build). I'm hoping that getting both 3DGE and GZDoom working on it will be as simple as building it - if there's any compile errors I'll do what I can to fix them. This comes with the assumption that the API code is largely unchanged from Linux for both ports - but if not, hopefully it won't be too much trouble to figure out what's wrong and tweak/adjust libraries and dependencies as needed. Unfortunately, this OS will obviously suffer the same weaknesses as Linux does - including dependency hell. Seeing only a 400 mb download is not hugely encouraging - but I hope that's enough to present the needed packages for this whole thing.
  13. Actually - no - I made a point to avoid that. And I got teased a lot for it. :P
  14. When I was in Sweden, I always had someone with me who could speak Swedish. It really helps if you have someone who can speak the native tongue - because while Sweden is famous for being the #1 non-English speaking country that knows English, not everyone there does. And that fact applies elsewhere, too. I will say though - you are right about getting down and dirty with it. Try everything. You only live once, and there's so much to live for. I tried more Swedish cuisine and tradition in 3 months than I ever did American anything the entire time I was alive. And I enjoyed myself. Made a lot of great friends there, too.
  15. The reason why it's slower is because it's still doing more pixels. And obviously 3d acceleration is not turned on. Using NEON intrinsics has been on my to-do list but that will really only improve performance for truecolor mode. At this point I think getting a decent framebuffer working at all on the Pi is a higher priority so that you're not stuck at such terribly low resolutions. That will all come in due time, when I feel like tearing into it and actually seeing what I can pull off.