• Content count

  • Joined

  • Last visited

Community Reputation

1906 Excellent


About GuyWithBeard

Personal Information

  • Interests

Recent Profile Visitors

11408 profile views
  1. DX11 My renderer stopped working

    Allright then, glad you figured it out! Still, I would recommend enabling the debug layers. They have helped me many times in the past.
  2. DX11 My renderer stopped working

    Okay, first of all you haven't told how is it "isn't working". What's the expected output? What's the actual output? Does it crash? Does it render incorrectly? Does it render at all? Try enabling the debug layers and make them output any DX11 warnings/errors. That might help you narrow down the problem. Looky here: I haven't look through all your code (because c'mon), but one thing I noticed is that your DX pixel shader always outputs a constant color value while your GLSL fragment shader outputs whatever color is passed into it. Not sure if this is by design or not.
  3. AngelScript 2.32.0 is out

    Thanks for your hard work!
  4. C++ C++ Custom Memory Allocation

    It's a pointer to a u8 value, not the actual value itself. The pointer is still going to be 32 or 64 bits, depending on the architecture. You need to cast it to a u8 pointer to have the pointer arithmetic treat it as a byte array, which is obviously what you want when allocating memory.
  5. DX12 PSO Management in practice

    Not sure if this is something within your reach, but if possible I would suggest going the other way, ie. have your API expose a DX12-style PSO and emulate that on DX11. You can easily hash the DX11 rasterizer state, depth stencil state and blend state and only set them if they actually change. In my engine I always set the shaders and input layout on DX11 when switching PSO and it hasn't bitten me performance-wise yet at least. I would assume you could hash those too if you want, and only set them if they change. On DX12, setting the PSO is straightforward and Vulkan is pretty much the same if you want to go that route at some point.
  6. Gamma correction - sanity check

    Yep. I missed that exact flag. However, texconv seems to do linear-to-SRGB conversion even if you leave it out as long as you specify an SRGB format as output format. So, what I assume happened was that my input texture, already in SRGB, was treated as linear and was converted to SRGB a second time. This caused the texture to come out very bright.
  7. Gamma correction - sanity check

    Well, I managed to get the textures to look correct. I incorrectly assumed that texconv (of DX SDK fame) would be able to detect if an image was already in sRGB format or not. Turns out my images lacked the necessary metadata, so now my texture converter assumes a texture is in sRGB if it is set to output into sRGB, and that took care of the overly bright textures.
  8. Gamma correction - sanity check

    No need to apologize, this is very helpful. Some of my confusion came from the fact that I tried to do the same sanity check in Unity, by setting the project to use linear color space and clearing the screen to [128,128,128,1] and it actually comes out as 128 when color picked in GIMP, while my render window is cleared to 186. Although I realize I have no idea what Unity is doing behind the scenes so this probably is not helpful at all. Anyway, I realized that I have been converting my textures incorrectly to sRGB which probably explains why they are showing up brighter than they should. I'll fix that and output one of them on screen and see how they look...
  9. Gamma correction - sanity check

    I feel like you are dodging my actual question Anyway, thanks thus far. I will have to read up on this a bit I feel... EDIT: For the record, Matt77hias, edited his previous posts to provide more info. Thanks dude!
  10. Gamma correction - sanity check

    Yes, but in this case I render the color instead of sampling it. Would rendering the color to screen and doing a print-screen of that equate to your third sampling step? Ie. should I expect 128 or 186? (actually it came out as 188).
  11. Gamma correction - sanity check

    Yes, I know that. But if the pipeline was configured correctly, shouldn't a clear color of 128 come out as 128?
  12. Gamma correction - sanity check

    To be honest I don't quite have a use for Forward+ at the moment. That's why I put it in parentheses. I just happened to stumble upon this fine article and figured it looked interesting: Anyway, I might get to HDR at some point but rendering is only a small part of the development I am doing so I simply haven't gotten to it yet. I am by no means a graphics programmer per se. And speaking of, I have moved over to using sRGB textures and an sRGB back buffer now on both Vulkan and DX12 and I would like to do some more sanity checking if you don't mind. The image output is a lot brighter, as you would expect. However, simply clearing the window to a solid color (ie. not doing any real drawing) is also a lot brighter and I am unsure if that is correct. I made my clear color [128, 128, 128] and it seems to come out as [188, 188, 188] (checked by doing a print-screen and looking up the color in GIMP). Since I should now be working in linear space which is then converted to gamma space before being presented to the screen I would expect the color to come out the same. Black comes out as black and white comes out as white, so it seems to be allright. However, I thought the whole point of working in linear was that half-way between black and white would come out as that. Where did I go wrong? (and thanks in advance for explaining these fundamental things) EDIT: Textures also seem to come out a lot brighter, so there's clearly something wrong. I will have to investigate.
  13. Gamma correction - sanity check

    Yeah, I guess the alpha channel is practically unused in the backbuffer. On a related note, it seems that would only be possible for the "work back buffer" or whatever it should be called, as my Vulkan driver reports that the only two formats supported for the actual back buffer are VK_FORMAT_B8G8R8A8_UNORM and VK_FORMAT_B8G8R8A8_SRGB.
  14. Gamma correction - sanity check

    Cool, thank you @knarkowicz, I should be good to go then.
  15. Gamma correction - sanity check

    I was going by the GPU gems3 article I linked above where they suggested you use an sRGB format to get efficient linear-to-gamma conversion. As for the rest, my renderer is forward (+) so there is no G-buffer and I don't plan to do HDR any time soon. EDIT: ...but as I read your comments it seems like I should perhaps go the HDR route, so feel free to throw any good articles at an HDR-virgin like me.