Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

170 Neutral

About noVum

  • Rank
    Advanced Member
  1. That's not possible. You need to have an X11 server running to use OpenGL. The only thing you could use for that stuff is CUDA, but it doesn't work on GeForce 7 hardware and I don't know if it would need an X11 server too.
  2. noVum

    DirectX 10 timeline...

    Quote:Original post by Promit Oh, I forgot to mention one thing. DX8 apps run really slowlyon Vista. I mean really, really slowly. That's news to me. D3D8 uses the same emulation layer than any prior D3D version before D3D9 and runs on top of that. And it's not dead-slow. Especially D3D8 is very easy to map to D3D9.
  3. Quote:This should be done for all x and y also. Why?
  4. Quote:Not a problem, because clipping is done before the perspective division. That's what I was asking for... So I need to clip w<znear and w>zfar? Quote:Hm... not sure how to convince you of this. Try to think of a counterexample. Not important now. That was perhaps just a bad example... There are certainly triangles that are visible and have one vertex on the camera-plane.
  5. Then take (2,3,0) or something else. It doesn't matter as long as it lies on the camera plane. Besides that I'm not convinced that a triangle that has (0,0,0) as one of it vertices is always not visible. Makes no sense to me.
  6. No it does NOT (and I'm already using it). It does not, because the vertex coordinates go to infinity even before drawing the triangle itself if the vertex lies on the camera-plane.
  7. What do you mean by "discard" them. I can't just not draw the entire triangle if one of the vertices lies on e.g. (0,0,0) in camera-space.
  8. Hello guys, I'm currently writing a little software-based triangle rasterizer and everything is going alright, besides having a problem clipping polygons that are in front of the near plane. What's the correct method of doing this? Clipping Z in the homogenous clipspace is not working, because vertices will sometimes go to infinity-values if they lie on z=0 in camera space. Do I need to clip against the w-value? That would be much more complex, because w can't be interpolated linearly in screenspace.
  9. Say for example I have two faces which share 2 vertices and belong to the same "smoothing group" (that means the shared vertices have an interpolated normal) - so far so good. But now the textures on them are aligned totaly different and the texcoords in the shared vertices are therefore totally different as well. I think that means that I can't interpolate the binormal and tangent like the normal. Now there are 3 different ways you could handle that case a) Don't interpolate anything b) Only interpolate the normal c) Interpolate all three What's the "right" way? I could try it out, but the design of my exporter depends very much on this point so I would like to clear it out before I begin coding.
  10. noVum


    Quote:Original post by zedzeek Quote:Original post by noVum I fear both extensions are not supported on ATi-hardware atm and ARB_texture_non_power_of_two most likely never will. im pretty sure the latest ones do support NPOT (i think their support for tex_rect is not so hot though)Nope. NPOT would require Mipmapping support and only NV4x can support this. Look at the delphi3d.net extension registry. There is no Radeon that supports any of the extensions.
  11. noVum


    I fear both extensions are not supported on ATi-hardware atm and ARB_texture_non_power_of_two most likely never will.
  12. noVum

    float textures and GL_LINEAR

    nVIDIA HW is capable of doing even anisotropic filtering with FP16-textures, so this should not be the problem.
  13. Quote:Original post by remigius Well, considering the SM3.0 specs seem to be more of a joint venture between NVidia and Microsoft, I can't really blame ATI. When I was looking to buy an X850 I made a little comparative sheet between the SM3.0 specs and the X850 specs (SM2.0b?) and it all comes down to glossy terms ATI can't legally use. The only true feature the X850 missed was the seperate progammable specular & fog shader. And of course with the whopping 255 shaders instructions missing for full SM3.0 compliance, you're gonna have a hard time with the 65280 instructions available ;p Anyway, in case anyone's interested: This is a piece of bullshit. Shader length: The paper mixes Vertex- and Pixelshader-Length. Vertexshader-Length was not an issue on any Radeon Hardware. The Problem is the Pixelshader. Dynamic branching: ATi could very well expose static and dynamic branching through Shadermodel 2.x. They don't. The card doesn't even have static branching in the PixelShader. Back-Face Register: This is the only valid point. Interpolated Color Format: This is the precision of the Interpolator-Registers. And R300 and R420 only have 8bit precision there. MRT: ATi does expose 4 MRTs through Shader 2.x. This is no issue. FOG and Specular: Yes it could done with the shader anyway. Texture coordinate count: Texture coordinates have nothing to do with the maximum textures bound to samplers. Please inform yourself before posting.
  14. Quote:Original post by Leo_E_49 Yes, MFC does come in very handy for making tools. I can't imagine a better way to make Window-based map editors, for example.MFC comes directly out of hell. If you ever used it for larger projects you know what I mean. Qt or wxWidgets are much cleaner and powerful.
  15. noVum

    GPU as a processor

    The problem here is, that the command-buffer of the GPU is not unlimited (it can only render 3 frames ahead or so) and when it runs full your CPU has to wait anyway.
  • 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!