Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Aug 2005
Offline Last Active Oct 21 2016 06:34 PM

#5314195 Self Referencing Template as a Base Type

Posted by on 06 October 2016 - 08:19 PM

Good point, I ammended my examples to add the public, but my actual implementation already did that.  In my second (working) example, making Data in the Derived class private does actually result in an error about accessing the private struct.  The second example was working with public though, so making it private makes sense that I would get the error.


I found an interesting question about this here: http://stackoverflow.com/questions/17478621/when-instantiating-a-template-should-members-of-its-incomplete-argument-types-b


The part about dependencies in the template would make sense, especially "In resolving dependent names, names from the following sources are considered: Declarations that are visible at the point of definition of the template."  Since the Data struct isn't visible when I inherit from the mixin template, it can't resolve the dependent type.  That wouldn't explain why my second method works though, as that should still be subject to the same restrictions on resolving the dependency?

#5314168 Self Referencing Template as a Base Type

Posted by on 06 October 2016 - 02:33 PM

I am trying to setup something that I don't think works, but I want to know for sure.  I am basically trying to setup a base mixin class, that can use a struct from the derived class.

template <class CLASS>
class BaseMixin
    std::map<string, CLASS::Data> dataMap;

    // Do stuff with the map of data;

class Derived
    : public BaseMixin<Derived>
    struct Data

So far, I don't think this is possible because when deriving from BaseMixin, the Data structure inside Derived isn't yet known, is this correct?  Basically I want a way of dropping in a mixin for certain classes to handle the management of the data, but I want the derived class to actually define the data.  As is, this gives a compiler error that Data is not a member of Derived.  If I try to just use Derived::Data as the template parameter (and change BaseMixin to just use that as is), I get an incomplete type is not allowed compiler error.


So can this be done?

#5309310 Noise Recalculation for Ambient Occlusion

Posted by on 03 September 2016 - 10:56 AM

I found that changing the random vector per frame ended up being too noisy, unless you have a strong blur implemented.  Even with a static camera/scene, you'll still see the ao bouncing around because the random value changes.  If you use the same random value, then in a static scene, the ao will also be static.

#5306554 FXAA and deferred rendering?

Posted by on 18 August 2016 - 09:02 AM

FXAA is a post processing effect, you take the final image, plus additional depth information (from your g-buffers or actual depth buffer, depending on your setup), calculate the edges from the depth discontinuities, then blur the final image based on how much depth discontinuities there are at each pixel.  With your steps, I'm not sure what you need to blit into another buffer for the second step.  You should actually be able to calculate the depth discontinuities and blur the final image all in a single pass, so you wouldn't need to blit to an additional buffer.  Just bind the final lit image, plus the depth buffer, as input, process and blur, then output the pixel to the screen.

#5304747 Text Rendering In D3D11/12

Posted by on 08 August 2016 - 03:19 PM

I've been trying out Sciter myself for a little while too.  If you just want to do basic stuff then it can work fine, it handles plain HTML/CSS without customizations.  If you want to do advanced UI though, trying to figure out how to get standard things to work in TIScript can be rather frustrating.  For the most part, anything you can do in (standard?) JS you can do in TIScript, but the syntax or objects or methods will (almost always) be different.  It also has a rendering path to use D2D directly, which has improved rendering performance over the regular path.  I've used Awesomium in the past for HTML as a UI, but Sciter is a lot easier and mostly cleaner to integrate than Awesomium was, at least for a smaller project.

#5304677 Problem With Cs:go Sensitivity C++

Posted by on 08 August 2016 - 09:13 AM

"Solving" this issue definitely won't result in any type of contract by Valve, especially since there doesn't even seem to be an issue to begin with.  They definitely have bigger fish to fry, like what to do with all the money they are raking in off Steam (which is obviously much more important than game development).  :)


In expansion to what I said before, it might not be padding extra zeros, but instead clipping off the last digits when converting from float to text to display in the console.  Most likely the engine doesn't store the value in plain text during runtime, it loads from the config, uses a float at runtime, then converts back to float when displayed in the console.  If the value is 0.0220009 but it's only showing 6 digits after the decimal, then it will only show 0.022000.




Looking at that page, the default precision is indeed 6, which means it will only show 6 digits after the decimal.  As has been pointed out, floats can store more places after the decimal than that, but when converting to string sometimes it's not useful to calculate more than a few.  Especially in this case, when it's just outputting to the console for display purposes and has no functional implication.  If that is the case then it might actually be a string to float conversion issue, or it might be intentional on their part to balance competitive gameplay issues, or just an accident, or an easter egg?


Ultimately, you will need to view the memory to actually see what value is being used.  0x3cb43958 is 0.022, extra zeros don't mean anything, they are quite literally nothing in the case of a floating point number.  If the value in memory is 0x3cb43958, then the value is 0.022 (regardless of padded zeros on the console).  If the value is different, then it might have some extra decimal that is getting clipped when displaying in the console.  You'd need to track down the value in memory then see.




Here's a free online converter, find the hex value in memory then plug it in and convert back to decimal.

#5304227 Quick Way To Invert Matrix

Posted by on 05 August 2016 - 10:59 AM


For advanced users: There are other ways in which the determinant is connected to the inverse. One I learned about recently is that the gradient of the determinant (as a function of n^2 variables) is the transpose of the inverse times the determinant squared, or something like that. It turns you can use that fact together with automatic differentiation to compute the inverse in a really whacky way.

If you transpose rotation matrix you get inverse rotation matrix. Ofc it cannot contain translation / scaling / etc.



Rather, the transpose of a matrix is equal to the inverse only if the matrix is orthogonal.

#5304213 Problem With Cs:go Sensitivity C++

Posted by on 05 August 2016 - 09:30 AM

Again, you are viewing the value in the console of the game after it has been loaded, right?  In the console, you are seeing 0.022 vs 0.022000?  The console is taking a floating point value in memory, then converting it to a string to display as text.  The conversion from float to text might be padding the zero's on the end just for display purposes.  As has been pointed out, a floating point value of 0.022 should be exactly equal to 0.022000, the trailing zero's aren't stored in the value because they are (quite literally) nothing.  If you use some type of debugger or memory viewer, getting the value of m_pitch for both games, you should be able to verify that the values are exactly equal.  The input value really seems like a red herring, the values both eventually end up as 0.022 in memory.


As for the changes in gameplay, you are comparing the same value used in two different games, right?  I've played CS in general, but I haven't played the different variations entirely or exhaustively.  I would assume that each version is different though, content was added/removed, and certain gameplay mechanics were tweaked?  If not, then what's the point of having a new version come out (I'm looking at you EA sports where the only thing that changes is the roster!!!).  Since they are two separate games, then it would make sense that they have tweaked different things to (hopefully) improve upon the game.  This means that they may use different methods to determine the camera movement, despite both using the same configuration value of m_pitch.


For example, there are many PBR lighting equations out there, and a lot of them use the same input values (for instance albedo, normal, roughness, metalness).  Despite all of them using the same input, the equations they use can be vastly different, resulting in a different look to the lighting.  The same is especially true player movement, there are soooo many different ways to respond to player input, I wouldn't be surprised if they tweaked that between versions of the game.  This would mean that the same input sensitivity value would lead to different responsiveness in game.


Ultimately what I am stating is that the difference in values (or perceived values) isn't the issue, it's that you are trying to compare two different games and expecting the movement to be the same between them.  The configuration value doesn't have anything to do with it, and the difference between 0.022 and 0.022000 just seems to be display padding, not actually a mathematical difference.

#5303994 Problem With Cs:go Sensitivity C++

Posted by on 04 August 2016 - 09:16 AM

To make sure I was not having a placebo effect, initially I told a friend the difference and told him which of the two was slightly faster / slower, and he confirmed that there was indeed a difference.
I kept telling other people, and they confirmed;
until I decided to change the way I say; might be putting some "pressure", and decided that they test them without any "track," I said, test m_pitch 0.022000 and m_pitch 0.022, and tell me if there is any difference.
They ended up saying 0.022000 was slightly faster than 0.022, and that they felt better with 0022 and "could not be true because they were the same numbers", so I decided to search more about these values ​​and found that they are floats and they work differently from casual mathematics ; so I decided to seek help to prove this, because i do not have the necessary knowledge

By telling your friend about the difference, you already affected the outcome of their response.
Also, are you sure the value itself, used in the engine, is actually different?  The conversion from string to float has been discussed, but what about from float to string when displaying it in the console?  I'm still a little confused where you actually got the numbers from, you said there's a config file but then talked about the source code?  Is the value in a plain text configuration file that gets loaded by the game, or are the values in code that get used by the game?  Are you just displaying the numbers after the fact (in the console?) to see that one is 0.022 and the other is 0.022000?  If you're just relying on the console to see the difference, then the console might just be padding extra zeros when converting the value to a float (for readability, spacing, etc).  This could mean that the sensitivity difference is something else, perhaps a mechanics or physics change in the core gameplay itself.  The same values would lead to different behavior because the core mechanics that use the value has changed.

#5300385 When you realize how dumb a bug is...

Posted by on 12 July 2016 - 08:54 AM

So I was switching over one of the libraries i use from a prebuilt dynamic DLL to a static library (that I was pulling and building/linking against directly).  Everything compiled and linked successfully, but whenever I ran it I would get crashes deep inside standard runtime libraries!  I was building and rebuilding and changing settings and trying to figure it out for a couple days, frustratingly to no avail.  Finally (I should have done this sooner), I started following the include links in the IDE and noticed that it was still including the old precompiled headers.  The functions all existed so I didn't get any errors during build, but a lot of the signatures and parameters had changed so it wasn't calling things correctly!


Grr, note to self, when changing library versions, just rename the old directory (or delete it entirely) to make sure it's not getting included by accident.  XD

#5297695 Retrieving World Position in Deferred Rendering

Posted by on 23 June 2016 - 08:16 AM

Are you sure you need the world position?  If you store the linear depth, then this is the view space depth (the distance from the camera).  When rendering your lights, if you render a quad (or an extra large triangle) and use the corners as the view vectors, you can then multiply the view vector per pixel by the depth to get the view space position.  With this, you can do all your lighting in view space, just transform your lights from world space to view space, then the lighting equation remains the same.


Here's the code code to calculate the linear depth in the pixel shader, this is the first shader that stores all the info into my g-buffers:

outputPixel.depthBuffer = (inputPixel.viewPosition.z / Camera::maximumDistance);

This just takes the view space position, takes the depth of it, then converts it to the [0,1] range.


Here's code to use that depth to get the view space position:

float3 getViewPosition(float2 texCoord, float depth)
    float2 adjustedCoord = texCoord;
    adjustedCoord.y = (1.0 - adjustedCoord.y);
    adjustedCoord.xy = (adjustedCoord.xy * 2.0 - 1.0);
    return (float3((adjustedCoord * Camera::fieldOfView), 1.0) * depth * Camera::maximumDistance);

float surfaceDepth = Resources::depthBuffer.Sample(Global::pointSampler, inputPixel.texCoord);
float3 surfacePosition = getViewPosition(inputPixel.texCoord, surfaceDepth);

This uses the texture coordinate, remaps it from [0,1] to [-1,1], then treats that as a vector away from the camera.


Just to finish it off, here's the code that renders a large triangle over the screen.  This is from Bill Bilodeau's vertex shader tricks presentation:


Pixel mainVertexProgram(in uint vertexID : SV_VertexID)
    Pixel pixel;
    pixel.texCoord = float2((vertexID << 1) & 2, vertexID & 2);
    pixel.position = float4(pixel.texCoord * float2(2.0f, -2.0f)
                                           + float2(-1.0f, 1.0f), 0.0f, 1.0f);
    return pixel;

You can just draw a simple 3 vertex primitive with this shader, no vertex or index buffers required since it uses the vertex ID.

#5293264 About resouce files

Posted by on 24 May 2016 - 03:48 PM

A type of ico in the RC file, and "ico" in FindResource call, should result in a custom resource type.  "ico" is not an existing resource type (https://msdn.microsoft.com/en-us/library/ms648009(v=vs.85).aspx), which means it's being imported and compiled in as a regular blob in the resources.  This is why it gets found when finding it, there's no special handling going on and you're matching the RC type when finding it.


ICON and RT_ICON will do it's own special handling, and I've found that icons can be pretty tricky when used as resources.  Have you made sure that the icon is valid and supported (no odd sizes/laters/color depths/etc)?  Open the icon in Visual Studio and make sure it loads/looks correct, and try actually saving it there as well.  Make sure you save it explicitly (Save As and overwrite, or save to a new name), otherwise it might not think it needs to save.

#5293116 About resouce files

Posted by on 23 May 2016 - 03:49 PM

Look up Image on MSDN, you'll see a list of functions that you can use from it.  In particular, you should be able to use GetRawFormat to get the GUID of the image format that was loaded.


GetRawFormat: https://msdn.microsoft.com/en-us/library/windows/desktop/ms535393(v=vs.85).aspx

Image formats: https://msdn.microsoft.com/en-us/library/windows/desktop/ms534410(v=vs.85).aspx

#5285063 Create holes in plane dynamically

Posted by on 04 April 2016 - 12:54 PM

Try searching for information about Constructive Solid Geometry.  That lets you do boolean operations of shapes, so you could setup a ground mesh then subtract the spheres from it.  You could also look into voxels, setup a big array of voxels for the terrain, then just start removing the voxels as the user digs.  With voxels, you'd still need to look into some way of calculating the mesh from the voxels though, but there should be a lot of information about that online as well.

#5284663 SpriteFont render Umlaute

Posted by on 01 April 2016 - 03:51 PM

It looks like it's auto converting to utf-8, but doing straight character comparisons.  There's a lot going on under the hood when working with STL and regex and etc, including dealing with locale.  Here's a good example of setting the locale to support utf-8:  http://stackoverflow.com/questions/11254232/do-c11-regular-expressions-work-with-utf-8-strings


char strings typically are simple strings, but utf-8 is a type of encoding.  You can store a utf-8 string in a std:string, but at that point it's really not human readable anymore.  A lot of editors know that the string is utf-8 and auto convert when displaying the value, but if you look at the raw memory then you'll see that it's actually a buffer of utf-8 data under the hood.  That's what's happening with äüöß to Ã¤Ã¼Ã¶ÃŸ, Ã¤Ã¼Ã¶ÃŸ doesn't make any sense when reading, but the values in it are the utf-8 encoded data for äüöß.


EDIT: This is why your solution works, you're extending the regex to check the encoded utf-8 values.  You won't need to do that if you set the locale ala the SO link, or if you switched to using wchar_t types (wregex/wstring).