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


  • Content count

  • Joined

  • Last visited


About dpJudas

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. One of the first things they teach at university in sorting class is that generic algorithms can lose out heavily against domain specific ones. In this case, specifically, sorting a single huge sector of unsorted objects is highly atypical to what you'll encounter in real maps. In real maps the general rule is that when you have a big open viewable space you will typically have many sectors, or at least many subsectors, and you will have many segments. Because if you didn't, the map would be plain and boring. Plain and boring fits Nuts well, by the way. Locking yourself into the mindset of finding the best generic sorting algorithm for something you will almost never encounter, including your multiplayer case, unless it is Nuts you're playing, you spent lots of time gaining very little while missing the obvious advantage that in most cases Doom's sprites are already generally well sorted. Your multiplayer example even further helps proving the point as any gibs and gore all over the map will be static and not moving - there's absolutely no reason to sort that frame after frame. If you look closer at jval's numbers for non-Nuts stuff, you'll see the total sorting time is very low. In the typical case you'll be shaving off maybe 0.3 milliseconds of a frame. With a 60 fps render deadline, we are optimizing 1.6% of the total time, in one of the worst non-joke examples from jval's test set. I'm sorry, but the ridiculous part here is to make an optimization clearly meant for Nuts and pretty much nothing else. If your general point is that faster is faster, then why not go all-in on fast and use the domain specific knowledge available and use the BSP. Even Carmack commented this is the right approach. Thread synchronization has a cost. For 0.3 milliseconds run time it will probably make it overall slower to use threads for this.
  2. The softpoly software renderer in GZDoom also renders its sprites by subsector, although it doesn't really deal with clipping the proper way. The Doom software renderer in GZDoom also sorts by subsector when models are present, although I left out clipping the sprites across subsector boundaries (can cause render order problems). The really tricky part is supporting all the render hacks and Boom extensions - I don't know how much of that had to be done for a Doom64 solution. But nice to hear other people, even Carmack himself, favors this approach. :)
  3. It depends, but in a scene like the infamous Frozen Time the sprite rendering takes a very significant part of the total - something in ballpark of 40% if I remember correctly. In general I have to agree with you that using nuts is probably not the best benchmark for sprite performance as its high sprite count in a single sector could easily lead to the wrong conclusions. The benchmark numbers here seem to indicate they are all based on the start location of the player in nuts, which is problematic as the modder that created the map may have placed all the monsters systemically in an array-like fashion in the wad file. What that means is the array to be sorted might not be typical and we are looking at it from a specific angle - the numbers might shift in other sort algorithms favor if you view the scene from a different direction. For example if we look at it from exactly the opposite direction it is very likely the arrays will be initially sorted exactly opposite to Fraggle's cautious "mostly sorted" assumption. I think it is also worth mentioning that partly what makes sprites rendering in Doom silly slow isn't so much the initial sorting of the sprites, but rather the way it applies sprite clipping with regard to segments. I can't say for sure if this was a problem in the original Doom version, but at least the version in ZDoom is horribly inefficient as it constantly seeks in the sorted sprite array for segments that may be in front of any given sprite. This problem won't at all be revealed by a nuts test as you basically have about 20 segments in total for the scene. In my opinion if you really want to improve sprite performance in general, as opposed for just nuts, you really should consider changing Doom into rendering sprites at the subsector level. Ideally by tracking which subsector a sprite belongs to instead of just which sector. This gives you two advantages. First, you only have to depth sort within a single subsector, the initial BSP front-to-back pass will already have sprites sorted across subsector boundaries. Secondly, it allows you to skip the segment search entirely. It no longer need to compare each sprite's location to all segments in front of it - subsectors guarantee that it will always be behind them all.
  4. dpJudas

    Has PBR for Doom been a disappointment so far?

    One of the unfortunate side effects of adding graphical features to any Doom engine is that there's always going to be people using it poorly and then other people in turn using that as evidence it is all shit. As a simple example, I could conclude the Unreal Engine 4 is utter garbage because I've seen youtube videos of Doom remakes in it that makes every single feature in the engine look terrible. When hardcore_gamer chooses to use something like his original video as "evidence" I think he's doing more or less the same - what looks bad there had nothing to do with the textures, but rather *everything* in the scene: model animation, post-processing, sprite choices, and the textures themselves. Yeah the video looks shit, but whose fault was that really? Seems a bit premature to blame the tool. My original goal with the feature wasn't to suddenly upgrade Doom 1993 to Doom 2016 visually - there's been plenty on comments here already explaining why that would never work. What I wanted originally was to add a bit more quality to dynamic lights and allow the careful modder to bring more detail into the world. Specifically, I wanted early 2000's game style specular textures to work. Hopefully over time some talented folks would be able to apply it at just the right spots. Like Enjay did with 3D models in Gene Tech and Waterlab. So far the screenshots from Elementalism are looking very cool. It is stuff like this I added it for. Then there are the actual PBR textures themselves. Once I had added the infrastructure in GZD required to switch between light shaders, there wasn't really anything preventing me from experimentally adding an UE4 level light model into the mix. Unlike specular maps, which is a basic extension to the original light model Doom was built on, PBR actually need environmental light input in a completely different way. What you see GZD is a test of what happens if you just take the modern PBR materials but leave out the environment. Short version here is that it doesn't look too good, because any material with reflection in it suffers badly and it blends poorly with the flat ambient light in Doom. It got pretty clear early on after release that I have to improve the environmental part of the equation for this to be truly useful. Doing this is tricky though, as Doom has no lightmaps and no other baking tooling in place beyond generating a BSP tree. I recommend that mappers stick to specular textures and not use the PBR feature. There are a few folks here on DW that are trying anyway with PBR textures and made stuff that sometimes looks great, sometimes reveal the problems with the light model as implemented. I want to add environmental light to it at some point, but I'm still trying to find a good solution here that doesn't require a complex baking tool. Until then, probably best modders stick to specular maps.
  5. dpJudas

    Zdoom Friendly mods, Something that is dead?

    That's really only one of the things improved GZDoom's software renderer after ZDoom stopped. Of other things worth mentioning: fixed pixel center math (no dancing sprites, no edge artifacts, higher quality texture mapping), multi-threaded rendering, dynamic lights, 3d floor fixes, non-power-of-two flats, better voxel depth sorting, skies that fade out, 6-bit blending tables (instead of 5 in zdoom), keep aspect ratio in windowed mode if the window is resized, resolution scaling. And in nightly builds you can enable 3D models (r_models 1) which will probably land as a fully supported feature in one of the next GZDoom releases. :)
  6. dpJudas

    Do any Doom ports support Ambient Occlusion?

    The SSAO pass in GZDoom is a HBAO variant (newer than original HBAO, can't recall the name of the paper it is based on right now). It is called SSAO since there's been so many variants of screen space AO since the original depth-only SSAO algorithm. As a result, most newer games don't try to name the specific algorithm. The near screen boundary artifact is an inherent limitation of screen space AO as it cannot sample depth information outside the rendered canvas. Theoretically, the effect could be reduced a bit by rendering more than just the visual screen, but that comes at a performance cost. By the way, the level complexity has no impact on the cost of a screen-space algorithm.
  7. dpJudas

    [Solved]GZDoom 3.2.5 options and performance?

    Disabling the render buffers is only really meaningful for ultra low end. The impact of using render buffers is extremely minimal for recent hardware. Even something as old as yours I don't think they will have any impact worth mentioning. Toggling render buffers off helped because vid_scalefactor stopped having any effect on the rendering at all. The scaling feature uses the render buffers to render into a smaller or larger buffer and then scale the result to the monitor resolution.
  8. dpJudas

    [Solved]GZDoom 3.2.5 options and performance?

    You changed the scale factor to 2 (vid_scalefactor). That causes it to do supersampled antialiasing - that is, it renders at twice the resolution and then scales it down. The scale factor allows you to render the game at a lower or higher resolution than the video mode you're rendering at. A mid-end card from 2010 will be way too slow for that. Change vid_scalefactor back to 1.0 and you should be getting the same performance as when you turned gl_renderbuffers off.
  9. dpJudas

    Which should I get?

    It would be more correct to say that it exploits bugs in a specific point version of ZDoom. Bugs that most likely would be fixed if Randi ever did another release of ZDoom. It doesn't work in GZDoom because there the bugs have been fixed.
  10. dpJudas

    Specific Things in Doom that annoy you

    I think you're focusing too much on conscious decision making. Think of it this way: imagine you're a mediocre player that isn't very good at the game. If all RNG elements are removed from a game, it will almost immediately become clear to you that you actually suck at the game and humans generally quit things they suck at. Now, if a dice is introduced in such a way that your poor play sometimes succeeds you get a rush from your good fortune. Heck, you might even think you're really good and the times the dice go against you that's just bad luck. Ask any fish in Poker and they'll tell you about the day where they were winning at the poker tables and what a magic night it was. I know you didn't say ALL RNG elements, just the weapon damage. But once you go down that rabbit hole your next complaint will be the huge spread on the shotgun or whatever next ruins your play. The thing that you're really complaining about is your bad fortune. It will always be there, until you've reduced all the RNG parts to be insignificant. Once it is insignificant, no poor player will want to play online (they will always lose every single game), and single player will be boring and predictive.
  11. dpJudas

    Specific Things in Doom that annoy you

    I think RNG weapon damage is an important factor in causing chaos in an encounter. A predictable encounter is a boring encounter. If you know you can take the hit of a Revenant every time it becomes strategy to simply eat the bullet once in a while. On the other hand, with its current damage level, the rule really is "do not ever get hit by a revenant" and the RNG part allows a weaker player to sometimes survive while still getting hit. In multiplayer high RNG values allows a lesser player to sometimes kill a better one. The war of attrition is unfortunately something mappers introduced. If you look at the original games, the general rule is that if you survive a pack of monsters there's plenty of health packs around to heal up with. Most mods on the other hand have greatly reduced the health pack to the degree that whether you got RNG'ed high or low by that Revenant now decides whether you have to load a save game or not.
  12. dpJudas

    How much do you care about Doom's plot?

    I like stories in shooters for the ambience as long as it stays as a backdrop. I think Doom 1 does it very well where the text between the episodes enhances the feeling that you're generally just screwed - going to hell and not coming back. The story in Doom 2 on the other hand just seems way too disconnected to the actual maps. I've seen porn movies with a better story than what Doom 2 had.
  13. The "software" light mode is literally ZDoom. If the GZDoom software renderer is set to 24-bit truecolor it will look exactly the same (100% same algorithm). However, when you use old ZDoom you have to take into account that it using a palette mode where it can't pick exactly the correct light - it snaps to the nearest colormap. The colormap itself also has the problem that it needs to snap to the closest color in the palette. This causes a minor difference in contrast. You might be able to get the contrast to match a little better if you turn on the palette tonemap. Although the error won't be exactly the same, at least it is still forced to snap to the closest color in the palette that way. Problem is, OpenGL doesn't have a "standard light model" that applies to light levels and diminishing light. The closest is the fixed-function fog mode, which has three settings and additional parameters to adjust them. IMO name is bad as it might make some think its the recommended light mode. Never really discussed it with the others why the default is what it is. Could be a preference of Graf or it could be simply historical. I know some people in the community really dislike diminishing light and prefer Dark. But yeah, I should probably ask one day on the ZDoom forums if we should change the default to something closer to vanilla Doom. :)
  14. That's actually what's so annoying thing about the GZDoom light modes. They are named in such confusing ways that a newcomer to Doom has no chance in hell knowing which one is closest to the original game. Doesn't exactly help it defaults to Dark, which doesn't even have diminishing light..
  15. You forgot the most important light mode of them all: Software! The only one that actually looks like Doom.