Jump to content
  • Advertisement

_Sauce_

Member
  • Content Count

    246
  • Joined

  • Last visited

Community Reputation

116 Neutral

About _Sauce_

  • Rank
    Member
  1. Technically this would be recursion, and you would overflow the stack long before you run out of memory allocating [font=courier new,courier,monospace]Menu[/font] objects, unless [font=courier new,courier,monospace]Menu[/font] allocates hundreds of megabytes of data in addition to each child [font=courier new,courier,monospace]Menu[/font].
  2. Thanks MJP, that helps a lot.
  3. I held off for 4 days on creating this thread, exhausting every option I could think of, and not even 10 minutes after I posted did I find the solution. [source lang="cpp"]const int windowWidth = 800, windowHeight = 600; D3D11_VIEWPORT vp; ZeroMemory(&vp, sizeof(vp)); vp.TopLeftX = 0; //Change these two lines vp.TopLeftY = 0; // vp.Width = (float)windowWidth; vp.Height = (float)windowHeight; vp.MinDepth = 0.0f; vp.MaxDepth = 1.0f; g_pImmediateDeviceContext->RSSetViewports(1, &vp);[/source] MSDN says what the possible values for the D3D11_VIEWPORT structure are but it doesn't clearly explain what those values mean. I wrongly assumed the top left corner would be the minimum possible value given the conventions used for texture addressing and window layouts. Can anyone offer an in-depth explanation of the interpretation of these values?
  4. I'm learning DirectX 11 and I'm having trouble with the perspective divide. Specifically, the perspective transform is resulting in all my vertices getting clipped before rasterisation. I'm testing with a 200x200 cube centered at the origin. You can see an image of the problem in PIX below After the the w-divide my vertices lie wholly outside of clip space, but I can't see anything wrong with the matrices I'm passing to my shaders. Setting up the viewport [source lang="cpp"]const int windowWidth = 800, windowHeight = 600; D3D11_VIEWPORT vp; ZeroMemory(&vp, sizeof(vp)); vp.TopLeftX = D3D11_VIEWPORT_BOUNDS_MIN; vp.TopLeftY = D3D11_VIEWPORT_BOUNDS_MIN; vp.Width = (float)windowWidth; vp.Height = (float)windowHeight; vp.MinDepth = 0.0f; vp.MaxDepth = 1.0f; g_pImmediateDeviceContext->RSSetViewports(1, &vp);[/source] Building the matrices [source lang="cpp"] VSConstants VSConstData; D3DXMatrixIdentity(&VSConstData.world); D3DXMatrixLookAtLH(&VSConstData.view, &eye, &lookAt, &up); D3DXMatrixPerspectiveFovLH(&VSConstData.projection, toRadians(90.0f), (float)windowWidth / (float)windowHeight, 0.01f, 1000.0f); VSConstData.worldViewProjection = VSConstData.world * VSConstData.view * VSConstData.projection; D3DXMatrixInverse(&VSConstData.invWorldViewProjection, 0, &VSConstData.worldViewProjection); g_pImmediateDeviceContext->UpdateSubresource(g_pVSConstants, 0, 0, &VSConstData, 0, 0);[/source] and here is the contents of the constants buffer as reported by PIX Vertex & pixel shaders [source lang="cpp"]float4x4 world; float4x4 view; float4x4 projection; float4x4 worldViewProjection; float4x4 invWorldViewProjection; Texture2D g_texture; SamplerState defaultSampler { MipFilter = LINEAR; MinFilter = LINEAR; MagFilter = LINEAR; }; struct VSInput { float4 position : POSITION; float3 normal : NORMAL; float2 texcoord : TEXCOORD0; }; struct PSInput { float4 position : SV_POSITION; float3 normal : NORMAL; float2 texcoord : TEXCOORD0; }; PSInput VSDefault(VSInput input) { PSInput result; result.position = mul(input.position, world); result.position = mul(result.position, view); result.position = mul(result.position, projection); result.normal = input.normal;//mul(input.normal, invWorldViewProjection); result.texcoord = input.texcoord; return result; } float4 PSDefault(PSInput input) : SV_TARGET { return g_texture.Sample(defaultSampler, input.texcoord); }[/source] I have a feeling the problem is to do with my viewport settings as the post-vs output looks fine. It is only after clipping that I lose everything. Unfortunately I can't find much information on the appropriate values for the D3D11_VIEWPORT structure and trial and error has proven unsuccessful. Any idea what I'm doing wrong?
  5. _Sauce_

    Strange C++ Problem

    Habit... It stops being doing things like: big_integer a, b, c; (a + b) = c; By accident. [/quote] I've never seen const used this way but that's a fair point. I still feel like I'm not seeing the actual code responsible for your crash so I'm afraid I have no further suggestions. I'll be interested to hear what the cause was if you figure it out.
  6. _Sauce_

    Strange C++ Problem

    [font="Courier New"]return ...[/font] will call the copy constructor again because you are passing the result by value. This is the expected order of execution, which VC9 demonstrates. [font="Courier New"]operator - copy constructor operator -= copy constructor [/font]I couldn't reproduce the crash, so either you're doing something funky in operator -= that you're not showing us, or the problem lies in your driver program. FYI, returning a const [font="Courier New"]big_integer[/font] by value is technically meaningless. If it were a reference or pointer then it would make sense.
  7. _Sauce_

    Monte carlo path tracing

    I've never implemented refraction in a raytracer before, but i'll take a stab in the dark and pose the question anyway; have you offset the position of the refracted rays by epsilon to prevent self-intersection at the ray's origin?
  8. _Sauce_

    Adaptive music in RTS games

    Many of the command & conquer games have this feature. I know for certain that C&C Generals and C&C3: Tiberium Wars do. Company of Heroes is another RTS game that does this extremely well and in my opinion it adds a lot to the atmosphere of the game - company of heroes is the most atmospheric RTS I know and it has a great cinematic feel
  9. If you don't like the idea of indexing into a 1D texture that sweeps over the spectrum (why not?) then you can first map your float value into the HSV colour space, with a saturation and value of 1, and hue of 60..360 (you'll want to ignore the first 60 degrees otherwise you'll end up with red at both the low and high end of the scale). Then you simply convert HSV to RGB. There are plenty of resources on this so I won't go into details. There's really nothing wrong with the texture lookup approach - it will be much simpler in a shader (only severaly lines of your chosen shader language), though you might find the HSV->RGB approach better suited if you're doing this on the CPU.
  10. _Sauce_

    PIX Error on experiment startup

    The reason you get these two warnings is because the MY_SOLUTIONDIR expands to a path with backslashes (\) instead of forward slashes (/). Backslashes will be treated as the beginning of an escape sequence and, depending on the character following it, may be interpreted as some other random character (\\, \t, \r, \n are common ones) Solution: #define MY_SOLUTIONDIR "C:\\Users\\***\\Desktop\\***\\TestProject\\Debug\\" or... #define MY_SOLUTIONDIR "C:/Users/**/Desktop/***/TestProject/Debug/" or you can do what MJP said Neither of these are great solutions to the problem though. Your application should be capable of finding its resources regardless of the location it is run from. You can set the current working directory (on windows) to the executable directory using GetModuleFileName() and SetCurrentDirectory() so that your relative paths function correctly. If you're targetting the 360 (XNA) then obviously you don't have to worry about any of this, and you can use one of the previous suggestions.
  11. _Sauce_

    point cloud to triangular mesh

    If you're looking for an existing implementation then you can try meshlab. It has several surface reconstruction filters you can choose from and it supports the .ply format (among many others).
  12. _Sauce_

    Rendering and interacting with an UI

    There are GUI libraries out there that can do most of the work for you if you don't want to reinvent the wheel. CEGUI comes to mind (Personally, I'm not a huge fan - the current default skins are ghastly, but there is work being done on modern skins which look very nice)
  13. Have you called AnimatedSprite::Load() before calling AnimatedSprite::Update()? The most likely problem is that sprite is NULL. It wouldn't hurt to modify AnimatedSprite::Update() as follows; #include <cassert> void Update(float DeltaTime) { assert(sprite); //... }
  14. _Sauce_

    Regarding Legality

    Men at Work were sued 28 years after the release of "Down Under" for copyright infringement. I think it makes a good example in this situation. The flute part of the recording of the song is allegedly based on the children's rhyme "Kookaburra", written by Marion Sinclair for a Girl Guides competition in 1935. Sinclair died in 1988[sup][2][/sup] and the rights to the Kookaburra song were deemed to have been transferred to publisher Larrikin Music on 21 March 1990.[sup][16][/sup] In the United States, the rights are administered by Music Sales Corporation in New York City. In June 2009, 28 years after the release of the recording, Larrikin Music sued Men At Work for copyright infringement, alleging that part of the flute riff of "Down Under" was copied from "Kookaburra". The counsel for the band's record label and publishing company (Sony BMG Music Entertainment and EMI Songs Australia) claimed that, based on the agreement under which the song was written, the copyright was actually held by the Girl Guides Association.[sup][17][/sup][sup][18][/sup] On 30 July, Justice Peter Jacobson of the Federal Court of Australia made a preliminary ruling that Larrikin did own copyright on the song, but the issue of whether or not Hay and Strykert had plagiarised the riff was set aside to be determined at a later date.[sup][19][/sup] On 4 February 2010, Justice Jacobson ruled that Larrikin's copyright had been infringed because "Down Under" reproduced "a substantial part of Kookaburra".[sup][20][/sup] When asked how much Larrikin would be seeking in damages, Larrikin's lawyer Adam Simpson replied: "anything from what we've claimed, which is between 40 and 60 per cent, and what they suggest, which is considerably less."[sup][21][/sup][sup][22][/sup][sup][23][/sup] In court, Larrikin's principal Norman Lurie gave the opinion that, had the parties negotiated a licence at the outset as willing parties, the royalties would have been between 25 and 50 per cent.[sup][24][/sup] On 6 July 2010, Justice Jacobson handed down a decision that Larrikin receive 5% of royalties from 2002.[sup][24][/sup][sup][25][/sup] Until this high-profile case, "Kookaburra"'s standing as a traditional song combined with the lack of visible policing of the song's rights by its composer had led to the general public perception that the song was within the public domain.[sup][26][/sup][sup][27][/sup] The revelation of "Kookaburra"'s copyright status, and more-so the pursuit of royalties from it, has generated a negative response among sections of the Australian public.[sup][28][/sup][sup][29][/sup][sup][30][/sup][sup][31][/sup] In response to unsourced speculation of a Welsh connection, Dr Rhidian Griffiths pointed out that the Welsh words to the tune were published in 1989 and musicologist Phyllis Kinney stated neither the song's metre nor its lines were typical Welsh.[sup][27][/sup][/quote] Source: Wikipedia [media][/media] Personally, I don't even see the resemblance of the flute section of the song with the children's rhyme
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!