Pthalicus

Members
  • Content count

    132
  • Joined

  • Last visited

Community Reputation

738 Good

About Pthalicus

  • Rank
    Member

Personal Information

  1. World, view & projection spaces

    ID3D10Blob* pVertexShaderBytecode = NULL; ID3D10Blob* pCompileErrors = NULL; if( pCompileErrors != NULL ) { OutputDebugStringA( (CHAR*)pCompileErrors->GetBufferPointer() ); pCompileErrors->Release(); return 0; } D3DCompile(pVertexShaderCode, lstrlenA( pVertexShaderCode ) + 1, "vertex shader", NULL, NULL, "vertex_shader", "vs_4_0", NULL, 0, &pVertexShaderBytecode, &pCompileErrors ); Here you're checking if the shader compiled succesfully, before actually compiling the shader. If you try compiling the shader before checking the compile succeeded, this should fix this issue. Side note: You're compiling the shader each time you call DrawSquare() (perhaps this could use a better name?). It's much more efficient to compile the shader once, and then binding this compiled shader before drawing the triangle.
  2. Merge tools

    Another vote for P4Merge from me. Though I've only ever used one other merge tool, this has the advantage of being free (within requirements). :)   You can view the original file(base), and branched versions(yours and your partners changes) for resolving conflicts - and specify which change should be used(or both), and also, if necessary, modify the result by hand in the merge window below.   (It also works for images too, and can highlight the differences.)
  3. How do you pronounce your image formats

    Apparently, the Whitehouse declares .gif as Gif with a hard G, not Jif.    http://news.cnet.com/8301-17938_105-57581656-1/breaking-white-house-tumblr-says-its-gif-with-a-hard-g/   It's nice to know they're on the same wavelength... even if that's in another country.      I used to pronounce it like this too, but I've since changed to "jay-pee-gee".
  4. geometry shader sampling problem?

    I'm unsure of how the D3D shader compiler / effect system works when specifying just one address mode in the sampler state.   Here, you're just applying the CLAMP state to AddressU without setting AddressV or AddressW.  Does the effect compiler output any warnings/errors?   Searching through MSDN I found this: http://msdn.microsoft.com/en-us/library/windows/desktop/bb509644(v=vs.85).aspx Though this doesn't really answer that question, it does give an example in "MeshTextureSampler" for trilinear sampling.   (Also, I assume the duplicated "gPointSample" is a copy/paste error?)   Hope this helps     Additionally, since you're sampling in the geometry shader, ensure you're using the correct texture access method: http://msdn.microsoft.com/en-us/library/bb509700%28v=VS.85%29.aspx. I.e Load(), SampleGrad() or SampleLevel()
  5. Stereo when using an infinity projection matrix

    I haven't tested this with your "infinity matrix", however, this works fine with a regular good'ol non-orthograpic projection matrix:   void buildProjectionMatrixInfinityPerspectiveFovLH(f32 aspectRatio, f32 parallax) { const f64 yScale = 1.0f / tan(45.0f / 2.0f); const T xScale = (T)(yScale / aspectRatio); const T Epsilon = 0.000001f; M[0] = xScale; M[1] = 0; M[2] = 0; M[3] = 0; M[4] = 0; M[5] = (T)yScale; M[6] = 0; M[7] = 0; M[8] = 0; M[9] = parallax; // Parallax shift M[10] = 1.0f+Epsilon; M[11] = 1.0f; M[12] = 0; M[13] = 0; M[14] = -1.0f; M[15] = 0; definitelyIdentityMatrix=false; return *this; }     So you'd obviously want two projection matrices:   f32 parallax = 0.033f; // Real-world value: dependant on screen SIZE (not dimensions), and user's viewing distance to screen. matrix left = buildProjectionMatrixInfinityPerspectiveFovLH(aspectRatio, -parallax); matrix right = buildProjectionMatrixInfinityPerspectiveFovLH(aspectRatio, parallax);       Note: The parallax should match the viewer's eye seperation from their viewing distance, take into account the real-world dimensions of the screen, and account for the viewer's distance to the screen - if you want a realistic experience. However, this is largely impossible unless you're using a head mounted display - where the viewing distance is constant.   You could just tweak the parallax value to see what feels best. :)
  6. OpenGL Deferred Lighting for OpenGL ES

      This can be solved with the Light-Pre-Pass technique. Granted, you'll be rendering the scene twice - once for pre lighting, and once for post lighting - you won't require a "fat G-Buffer" as with regular deferred. Here's a proof of concept already implementing Light-Pre-Pass on an iPhone: http://www.altdevblogaday.com/2012/03/01/light-pre-pass-renderer-on-iphone/ 
  7. Micro-Job sites

    I'd never heard of this site (www.fiverr.com) before you posted it. There's a programmer section; a C++ programmer section.  "I will write any kind of c++,java,c program within 2 days for $5"  I wonder if they could code me a new modelling tool in 2 days? $5 seems pretty cheap. On the serious side, these sites always seem suspicious to me; since the cost is super low, the quality of what you purchase will likely be really bad. (Hopefully I'm wrong here)   I've personally never used a micro-job site for anything, instead, forming a network of contacts who specialise in certain fields (sound design/voice overs/animation) seems like a better approach. Additionally, agreeing on a contract for their services, and hiring the same people should ensure your assets are more coherent. Just a few thoughts, hope this is useful. :)
  8. Instead of looking for a tutorial that matches your exact requirements, you can gain a lot more by solving this yourself.     How do you think this could be achieved? If you know the maximum jump height and specify a jump speed, you can increment the characters height by the speed until they've reached the height limit - whilst the jump button is pressed. And when the jump button is released, the player falls. Once you've done this, you could improve the "feel" of the jump, by changing the characters jump height to increase by smaller and smaller amounts over time - rather than a constant speed. This will create a slightly floaty/hovery jump depending on the curve/falloff.     So you know the solution to the problem, but don't know where to put the code? You could place this code just after the input if you'd like. (Though I'd suggest you place the physics code in the same area)     You know when the jump button has been released, so you'll need to know when you've hit the ground. If you're using tiles/grid, check the tile below you is a floor/ground tile. If you're touching this tile, you've hit the ground. Reset the jump ability here.     At this stage, solve the problems one at a time.    Additionally, I'd like to add that it took a long time for them to get the movement mechanics right, with lots of tweaking. You would probably benefit from making a simpler jump system first, and then improving that once it's complete.     Looking forward to it 
  9. Your Worst "Gotchas" ever in programming

    Just a quick addition, since I have little time.   Symptom code: int i = 0; printf( "i = %d", i );   Output: "i = 1"   It took four senior coders to work out what was going wrong here. The issue was overflowing buffers -> memory corruption. Causing data to not be assigned the value it was assigned. That was a fun monday morning.
  10. No one uses raw directx anymore?

      In big companies, not everyone deals with the graphics code. For example, a gameplay programmer would benefit from scripting knowledge, but graphics programming wouldn't greatly benefit this role.
  11. Creotex Engine ~ Part 1

    Thanks for this post Jonathan You mentioned this in your post: [CODE] return ((Window*)GetWindow(hWnd, 0))->HandleEvents(hWnd, msg, wParam, lParam); [/CODE] The reason this doesn't crash is because in HandleEvents(), you're only calling the default window procedure and not modifying the data within the class object. If you were to modify the data members of the Window class inside HandleEvents(), you'd probably corrupt memory. This is because you're casting the HWND returned from GetWindow() to a pointer to your custom window class, but HWND != Window*. You could probably try breaking it, by setting the window title inside the HandleEvents() method. Hope this is useful, and I'm looking forward to your future posts!
  12. Structure of classes in good Game Engine?

    If it's used everywhere, make it global. Some people fight to the death to ensure there are no globals in the code... but sometimes, globals are necessary, and it keeps the code interface nice and tidy. (Don't use globals everywhere though, since they can be a pain to track when debugging) Using inheritance isn't "bad" all of the time, only when it's abused, like any other tool. At the moment, try focusing on implementing the game, and think less about the engine. You'll learn a lot about what you really need the engine to do from making a game. Hope this helps
  13. Particles with DOF

    Thanks guys ginkgo: Sorting [i]is [/i]possible[i], [/i]but a pain since the particles are generated on the GPU. Though I like the idea Promit and yourself mentioned about scaling the quads and varying the mip-sample. This might work nicely, and if it merges well with the scene DOF, I'll go with that - since it's relatively cheap. JimC1664: I'm not sure that will look right, something about it doesn't feel right - I could additively blend the depth, then use that to find centre of the particles for that pixel, but that feels wrong. CukyDoh: Looking at those images, it looks like they just completely ignored the particles depth, and applied the DOF using the scene depth after drawing the particles. I've seen inferred lighting, and if I were using it, then yes DOF using each layer's depth would be nice. DOF pass per render batch doesn't seem feasible in this case; the individual particle systems can merge together, so this might introduce "popping" artefacts. Also, there are many systems visible at once - meaning many DOF passes, which is extremely expensive in this case. I'll go ahead with applying the DoF manually, scaling the particles, and varying the mip level and see how it looks. Cheers guys.