Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

642 Good

About reltham

  • Rank

Personal Information

  1. reltham

    My capacitor fell off.

    Most likely the card will work without the capacitor. It's probably a noise reducer put on to meet FCC. [Edited by - reltham on August 25, 2008 5:53:48 PM]
  2. reltham

    Pirate Dawn

    A board game he was "involved" with was Star Fleet Battles To see his "involvment", scroll to the bottom of this Link. I'm not sure how this fits with your earlier claims. I certainly don't consider SFB to be even in the top ten of board games of all time. Also, your posting implied actually working professionally (as in being on a payroll of a company for doing the work) on one of the most popular board games of all time. Being a volunteer design assistant via an online service doesn't really fit that bill. Perhaps you got hired to work on something else more popular after this work? Your ideas are not original, nor are they revolutionary. I'm glad no game company wasted the time or money to make your game. I'm equally happy that you have retired from game design because I would hate to think that anyone would have to actually work with you to make anything.
  3. reltham

    Great Game Soundtracks

    Quote:Original post by benryves Quake. Yes, Trent rocks.
  4. reltham


    Quote:Original post by Programmer101 Personally I like the elements from the older contests: Earth, Fire, Wind, Water. I'd like that.
  5. reltham

    Maximum Number of Devices?

    I opened all the D3D10 demos at ones on my G80 when I first got it running with hardware D3D10, and they all ran fine. However, all of the ones out of focus were running at much lower rates (intentionally I assume). only the one in focus ran at full rates. So it wasn't a very good stress test.
  6. Quote:Original post by Cypher19 Quote:Original post by Anonymous Poster A word of caution: the "linearized depth" trick will only give you a linearized depth buffer if you only render screen-aligned polygons. The problem is that the division is done on interpolated values. lerp( n0 * d0, n1 * d1, f ) / lerp ( d0, d1, f ) != lerp( n0, n1, f ). This will introduce a new type of depth buffer artifact which may be more objectionable than the standard ones. It will be similar to the sort of artifacts you get when using linear interpolation while rendering dual paraboloid shadow maps. It could still be a precision victory, but the article should've mentioned this pitfall. A little aside to Promit and reltham: Although, like you guys mentioned in IRC last night, a little more detail about this artifact would be nice. Where/how does it come up? How does it exhibit itself, etc? Looking at the dual parabloid shadow map problem discussing in this paper: http://portal.acm.org/citation.cfm?id=1183316.1183331&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184618 I think that as long as everything uses the linearized Z approach then it will all distort in the same way and work as desired for Z buffer usage. Since we aren't visualizing the Z, we are just using it for relative comparisons, I think it won't really matter. Of course, I could be wrong, we'll need to do some detailed testing.
  7. reltham

    December DirectX on Downloads

    For new titles, that still need to support SM1 (and FFP). I think it's unreasonable to expect us to stay on old SDK versions. Too much is enhanced and fixed. You are the second MVP type to say that, and it makes me wonder why you guys think it's ok to stay on old versions? I think it's terrible to stay on old versions. You know most really big games still do run on those old cards. While I do love all the new SM3 and SM4 stuff, I still have to be practical about market share. I think it's too early to stop supporting SM1 as a first class target with HLSL compiling. The new compiler (when finished) will be REALLY nice for SM2+ stuff, it should include SM1 in HLSL (not just ASM). And the flag to use the old compiler isn't very friendly since I'd have to maintain a seperate FX file with the SM1 techniques in the OLD fx format, while having SM2+ stuff being in the new format to gain the benefits of the new compiler and fx sharing between D3D9 and D3D10 (which should be possible and desirable since we already have to build 2 engines, sharing the fx files would make it a little less painful). Maybe I'm alone in making a renderer that supports SM1 thru SM3 on D3D9 and SM4 on D3D10. I guess it's two renderers really, but anyway. I'll likely even support FFP if I can. Not everyone is making a FPS that targets uber gamers only with high end gear.
  8. reltham

    December DirectX on Downloads

    This is rediculous: New HLSL Shader Compiler for Direct3D 9 Targets: No Support for 1.x Pixel Shader Targets The December 2006 SDK includes D3DX9_32.DLL. This DLL includes the Direct3D 10 HLSL compiler enabled for Direct3D 9 targets (shader models 2.0 and later). The new compiler has no support for 1.x pixel shader targets. This new compiler is the default for Direct3D 9. As a result, all developers are encouraged to author their shaders in HLSL and use shader models 2.0 and higher. The legacy compiler is available using the /LD switch. The new compiler exposed has the following issues: * Using asm_fragment blocks is not supported by the DLL. Compilation of shaders or effects containing these statements will fail. * Because only a subset of HLSL optimizations and new features are active in this release, generated shaders will not be fully optimized. Why are you doing this to us? Why is this the default when it's not ready? Why are you breaking a bunch of existing code?
  9. reltham


    Quote:Original post by Herbal Sauruman, Jpetrie. Please stop with this cold hearted crap. I don't know why people even bother posting just to be awkward. Its strange how every site I visit is 'crap' and every text I read is innacurate... 2%+ use Linux. Yes, that's tens of thousands, and OSX is becoming increasingly more popular. The magazine I read is not 'crap', I've met some of the writers, and we email from time to time. The lineup is not biased. Compare Xgl and Compiz to Vistas 'Aero' graphics. Guess who wins hands down? Thanks. My guess is Vista!!! Hands down!
  10. reltham

    Runtime effect creation

    D3DX is really solid these days, and definately usable in production code. I know we use it where I work. It's shipped in many titles across the industry. In fact, I would say that any title from this year or into the future that uses D3D9 will very likely use D3DX.
  11. reltham

    DrawIndexedPrimitive help

    Btw, my guess is that your indices are going over 65535 and you are using 16bit indices. Each patch in your terrain is 1089 vertices, how many patches are there? If there are more than 60 then you have more than you can index in a single IB that covers the whole terrain. If you use the approach I outline above, then you can have as many vertices as you want (up to memory limits) and still draw them with one small 16bit index buffer.
  12. reltham

    DrawIndexedPrimitive help

    Like jollyjeffers said, start out with a smaller case... Say you have a small terrain with only 16 quads and a patch is 4 quad (two triangles per quad). You'd have 9 vertices per patch, and to draw one patch via triangle_list, you'd need 24 indices. Assume that for a patch your vertices are arranged like this: 0,1,2, 3,4,5, 6,7,8 The patch's indices would be (2 tri's per line for each quad): 0,1,3, 3,1,4, 1,2,4, 4,2,5, 3,4,6, 6,4,7, 4,5,7, 7,5,8 The DIP would be: DrawIndexedPrimitive(triangle_list, 0, 0, 9, 0, 8); BaseVertexIndex is 0 (our first vertex is addressed by index 0) MinIndex is 0 (the first vertex) NumVertices is 9 StartIndex is 0 (start at the beginning of our index buffer) PrimitiveCount is 8 (4 quads, 8 tris) Say the next patch's vertices are this: 9,10,11, 12,13,14, 15,16,17 Using the same Index buffer we used for the first patch the DIP would be: DrawIndexedPrimitive(triangle_list, 9, 0, 9, 0, 8); Only the BaseVertexIndex changed here. This allows us to draw this new patch using the same index buffer, and assumes the vertices for your patches are arranged the same. The other parameters stay the same because we are drawing the same number of vertices (just offset into the VB by BaseVertexIndex), and the same index buffer. BaseIndexVertex is added to each index as it's used to access the vertex buffer. It's also added to MinIndex, which is why that parameter stayed at zero in the second call.
  13. I own all of the books in question here, and highly recommend all of them. I think you should get the Blinn books. They are like a good foundation of graphics information. When you can, get the ShaderX books, also. As for the whole ShaderX series, I still refer to the ShaderX2 books as well as X3 and X4, and feel that anyone doing serious shader programming should have ShaderX2-4. X1 was good for it's time, but the X2 books replace it.
  14. I personally feel that this book is going to be extremely valuable to any team in the industry. Tools are all too often ignored or reduced to the minimum needed. However, they often have a huge influence on the final product. I wish this book or something similar had been written long ago, and I wish I didn't have to wait until mid/late March to get my copy.
  • 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!