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

dpJudas

Members
  • Content count

    207
  • Joined

  • Last visited

4 Followers

About dpJudas

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. Making the check is easy enough (just lock it to a specific OpenGL version supported by the driver or make it an option). Writing and maintaining support for it is not. It literally doubled the development time for the post-process pull request. To illustrate, Direct3D 10+ and Vulkan does not even have the concept of render and frame buffers. In a modern graphics engine the concept of a 'frame buffer', as originally understood as a back and front buffer, barely exists anymore. It is nowadays called the swap chain and only functions as the final output destination. The swap chain is a list of textures. Everything else is done in other textures allocated by the engine itself. In contrast, 15 years ago there were hardware differences between textures and the back buffer. There is virtually no code sharing going on between two such implementations. It has to be written twice. For a render buffer implementation you have to call glGetTexImage2D and capture data out of the back buffer - in newer systems you simply bind the "back buffer" texture to a GLSL texture sampler. Stuff like that. If we go even further back to OpenGL 2 we now enter the domain of the fixed-function pipeline. Now you don't even draw the same way anymore. Before you could share at least the scene drawing code, but now there's nothing to share at all. Shaders are so limited and slow on this generation of GPU's that you can't really use them. Any GZDoom version that supported both OpenGL 2 and 3+ simultaneously effectively had two independent renderers. Anyhow, my point here isn't really that something can't technically be done. It is that development resources, code base history and politics all play a role in why things look the way they do. I don't want to be rude to Gooberman, but he seemed to imply I don't understand that doing a branch in a shader does have some impact on performance. I'm perfectly aware of that. When I do the branching anyway it is a performance/maintenance trade-off as not doing the branch have entirely different consequences: drop the feature or drop support for older GPU's (disappoint users with old hardware). There is no room in the "budget" (no volunteers) for writing a brand new shader manager that also targets OpenGL 2 and 3.
  2. No offense meant, but this kind of hindsight analysis of any existing codebase is the easiest thing in the world to do. Pick any codebase on the planet and I'll mention something in it that can be done better and state they have a "unprofessional" product. Furthermore, the Doom community is an odd bunch that created countless hacks for quick victory points, some that even John Carmack started, which complicates any source port trying to support 25 years of Doom modding. Add on top that a vocal minority that think we still have to support OpenGL 2.0 because "Doom is a game from 1993". What all this means is that the main.fp you've spent time studying wasn't initially written in its current from. It was slowly grown over the years. One of the first things I added to GZDoom was a basic post processing pipeline. The kind of thing that's been common in commercial games for over a decade. What was the first complaint that blocked the pull request from being merged in? It used textures instead of render buffers and that caused a measurable performance drop if you had some ancient 10+ year old computer with the lowest end non-gaming GPU available at the time. Any professional game released the last ten years would instead have accepted this old hardware shouldn't be optimized for, but no, in this community I had to double the development time to support it. What does that have to do with the optimization opportunities you mention? With any large and popular codebase there comes a complex set of politics and requirements that you don't have to pay attention to when designing something from scratch. The shader manager in GZDoom has grown into its current monstrosity due to its extremely long OpenGL support period. Some of the shaders it manages are distinctively post process and should be handled by the pipeline I added, but they were written before that pipeline and changing this design means you step up as the volunteer to deal with any problems that arise for old hardware and drivers. The truth is that as long as I'm not paid to care about 15 year old computers I'm going to be as selfish as anyone else in the community and cater to my own interests. On my card, currently the Nvidia 2080 RTX, the oh so expensive branching you keep mentioning still runs the whole thing at over 2000 fps. So why should I spent my leisure time on the overhead of something that's clearly less than 0.5 ms of the total render costs?
  3. Ah so they are more fancy than I thought. That's pretty cool. :) You don't have worry much - you'll have the engine with proper lightmaps for some quite still, maybe longer. :) The branch I did has some outstanding issues mixed with Graf wanting it to also fully support portals and stuff. Even if it is finished your port will still be the only one with realtime lightmaps as the GZDoom version requires an external tool to generate the maps. Yes, but are its lightmaps then "ambient" or "diffuse" light? If you declare they are are to be evaluated after then they match closer math-wise, but on the other hand if you consider lightmaps to be more advanced sector light then they should be evaluated prior. One of the outstanding issues with the lightmap branch is that Nash discovered Doom "fog" (altered fade table) doesn't work with them (as currently implemented). The fog is a property of the sector light, which indicates that at least he expected the lightmap to behave as sector light and not the dynamic light added on top. Branches only pause if they deviate. When all threads branch the same way the branch operation is actually pretty cheap. Of course not having the check at all is cheaper. Keep in mind though that GZDoom is a CPU-bound process for most maps. If the check was made compile time it would mean another shader and possibly use more glUseProgram calls when rendering a scene. If you decide this if statement is too expensive then what about the dynamic lights done too? If there are no dynamic lights those checks are also wasteful. Before you know it there's 50 new shader permutations that needs to be managed. That in turn means the already crazy long boot time on Intel GPU's will increase even more. Now you're faced with the problem that you have to add a loading screen saying it is compiling shaders. And so on. In short: it is a balancing act how much you branch in the shader versus how many shader variants you want to have. You can argue GZDoom does too many checks in the shader - maybe on low end, my card is bored to tears over GZDoom's fragment shader. But you can't look isolated on that one line I pasted and decide it was wrong. Things are more complex than this.
  4. The difference between a brightmap and a lightmap is exactly the part of the equation you removed by lowering the light level to zero. But that doesn't make them the same because it only applies at light level zero. Once you bring up the light level their behavior is different and that's why they have different names. It is essentially the same as saying imaginary numbers are the same as normal ones because they behave the same in the range that they are the same. As for the inefficiency, even if brightmaps used lightmap compatible math, you can't control the shape of the sector. You can't specify different brightmap textures in GZDoom on the subsector level. That's actually what the most of the code on the lightmaps branch is doing - generating second texture coordinates and picking the lightmap texture for the specific subsector. The extra code in the shader itself is actually just one line: if (vLightmap.z >= 0.0) color.rgb += texture(LightMap, vLightmap).rgb; Note that I'm only talking in the context of GZDoom here. If its for your own engine none of this applies, naturally. :) I'm not sure which port I was looking at, but I don't think the lightmap generation code I saw did any light source visibility tracing at all. It was only a very quick glance though so maybe I'm wrong. In any case, if you're happy with the lightmaps there's of course no reason to do anything. :)
  5. Well aside from the fact that you can't apply a brightmap to a level with your "lightmaps". And aside a U shaped sector floor/ceiling will be horribly inefficient (both for texture data AND lightmap data). You also pretty much forced the mapper to set a zero light level for all sectors hit by a lightmap light source. Let's just say that whatever you are describing here would never survive a pull request review because brightmaps aren't lightmaps. Try it. Go on. See if it will pass. ;)
  6. And yet now they can't be used as brightmaps. Fact.
  7. Yes lets be pedantic and agree that it is NOT a fact. If they were lightmaps you wouldn't have had to change the shader math.. and no, it doesn't just gray color it - the whole purpose there is to create minimum light at the art pixel level, which is quite different from what a lightmap is trying to do.
  8. You can beat me to it by adding something that allows k8Vavoom to load its lightmap data directly from a wav lump. Then update ZDRay to output a lump in that format (or use the lump format it already outputs). :)
  9. No, brightmaps are not lightmaps. If they were they'd be named lightmaps. Yes, they both add light to a scene but that doesn't make them the same. Removing the illumination checks in itself isn't really enough to convert them as lightmaps need their own texture coordinates or you'll end up with an extremely inefficient set of lightmap textures. If you want to be really pedantic you can of course argue that it meets the definition of a lightmap texture without the texture unwrapping part. However, you don't really have a working solution if it doesn't scale. The asset pipeline and the performance of the renderer are the hard parts.
  10. dpJudas

    something is very wrong with my GZDoom

    You didn't specify which graphics card being used so I speculated it might have been an Intel GPU. The shadercache.zdsc file contains pre-compiled shader binaries for Intel to speed up application launch. It is a relatively new feature and I wondered if it had gotten corrupted. It is also only used for Intel as the other vendors implement their own caches. The errors in your initial dialog comes from your graphics card OpenGL driver. Essentially it is saying that it can't link the shader because of an "unspecified error". Note that it is the driver itself that uses the phrase "unspecified error" and not GZDoom. There is a good chance your graphics driver got corrupted somehow - maybe you can fix the problem by reinstalling the display driver. If you are really unlucky the driver has a bug in it and may require a newer version of the driver.
  11. dpJudas

    something is very wrong with my GZDoom

    Try delete the shadercache.zdsc file in %localappdata%\zdoom\cache (the "C:\Users\<username>\AppData\Local\zdoom\cache" folder on your disk where <username> is the name of your Windows user). If this works, please let me know the name of your graphics card.
  12. That was the original plan. Unfortunately the code that selects the colormap in the ZDoom software renderer is quite scattered, which means it requires some cleanup of that before it will be possible. I don't want to remove the ZDoom light mode entirely as some may prefer it. Randi clearly did or she wouldn't have altered the light in the first place.
  13. Just wanted to add that in GZDoom 3.7.0 (released today) there's a new light mode: Vanilla. The 'software' light mode uses ZDoom's software renderer light math, while 'vanilla' more approximates original Doom (assuming I read the Chocolate Doom source code right). There are still minor differences to the original, but I recommend you give it a try to see which you prefer.
  14. dpJudas

    Cacowards 2018 - 25 Years of Doom

    Not sure if it is intended, but that link produces a permission denied unless you're logged in.
  15. 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.
×