GDNet+ Pro
  • Content count

  • Joined

  • Last visited

Community Reputation

2527 Excellent

About iedoc

  • Rank
    Advanced Member

Personal Information

  1. So, the maximum number of active textures is not the same for every device, you'll need to check it using GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS: As for binding all those texture, do you really need to bind all of them if your not using all of them? As far as i know this *could* be a hit to performance, the drivers may move the resources to a more accessible location for the shader when they are bound. I don't think this is the right approach. I think your original method of tiling the textures is a better approach if you want to bind less often. Another way you can do it is to dynamically create these huge textures. basically each sprite you have can be their own resource, then you copy those resources into the larger texture that you will bind and use for that frame. you can keep them in that texture until you need more space for new sprites to be rendered in the frame, then just overwrite "tiles" in that texture that you are no longer using.
  2. ok, so in that case ,what did you set your render target description as? it should match your description of the texture2d you create in that function exactly as a side note, i would make that function take in a ID3D11Texture2D* rather than a void*
  3. what exactly are you passing in for "texture"? its just a void pointer, your not passing in the texture bytes are you? They source and destination of CopyResource must be the same type and description. i'm assuming this is your problem, if "texture" is already an ID3D11Texture2D. if "texture" is not an actual resource, and instead a byte array of the texture data, you will need to create a new ID3D11Texture2D with that data (not just cast it to a ID3D11Texture2D)
  4. OpenCL OpenGl and Cocoa

    i don't know what NSOpenGlView does, but i can tell you any api is going to render to a buffer, then present that buffer to the screen. presenting to the screen is usually just a simple change of a pointer, so its very fast. If you don't have a backbuffer, and your rendering directly to the front buffer (the buffer currently presenting to the screen), you'll usually end up seeing tears since you may be in the middle of rendering to the buffer while the screen is reading from it
  5. usually you'll just want to follow the logic of the shader, rather than copy paste, change a couple things and hope it works (although sometimes that works too). You know what the shader is doing, so just follow it through, and write a webgl shader as you go along. if you see a keyword that's unsupported in webgl, you can look up how to implement it in webgl. If you have more specific questions I'm sure you'll get more help Also, something i've found extremely useful when using webgl, download mozilla firefox if you don't have it already, open developer tools, go to settings, enable shader debugger, refresh the page, choose the shaders tab, and you will be able to view and debug the webgl vertex and pixel shaders Firefox is the only browser i know that does this right now
  6. DX11 HLSL NaN headache

    but what if gbPosition_tex.Sample(sampPointClamp, tc) returns (0, 0, 0, 1) or something (black)?
  7. DX11 HLSL NaN headache

    i just looked at the code a little closer: posVS = float4(0.0f, 0.0f, 0.0f, 1.0f); posVS == (0, 0, 0, 1) float3 v = normalize(; normalize: a = abs(sqrt(v.x * v.x + v.y * v.y + v.z * v.z)); a == 0; v.x = 0/0; v.y = 0/0; v.z = 0/0; v.x == NaN; v.y == NaN; v.z == NaN; IsNAN(v) == true basically, if posVS has 0 in all three x, y, and z before you try to normalize it, then you'll end up with nans
  8. DX11 HLSL NaN headache

    can you try: bool IsNAN(float n) { return n != n; }
  9. C++ Overloading Question

    The whole point of frameworks is so whoever is using it has less work to do. Nobody wants to learn a million tediously different functions if they do the exact same thing but are called with different parameters. There are a million ways to do the same thing, no right answer obviously, so just use your best judgement when doing things like overloading. If two functions are named the same, and do completely different things, maybe make the name a little more descriptive. I think the example in the OP was only a good example of a bad use of overloading, but not a great argument for why overloading in general is a bad idea. I don't mind the "Try" function naming, but i'd prefer it to return a boolean, and have an out parameter for the return anim, basically like how TryParse works in .net
  10. Billboarding a line

    can you try this? (if it works probably want to pull out the dot so you don't have to do it twice) if(dir1.z - dir2.z < 0 && dot(dir1, dir2) < 0) dir2 = -dir2; else if(dir2.z - dir1.z < 0 && dot(dir1, dir2) < 0) dir1 = -dir1;
  11. Billboarding a line

    oh yeah, your right, that does actually make sense. But since your z is bigger the further away from the camera, when you multiply by the projection matrix the width of your ribbon will get smaller the further away it is, if your using the same width all the way through. I'll have to think about your code a little longer to figure out why it appears to be twisting and turning so much. are seg.a and seg.b the left and right side of the ribbon?, and seg.dir1 and seg.dir2 are the direction the ribbon is flowing from the two points?
  12. Billboarding a line

    I'm not sure exactly what your doing in your geometry shader to get the final position, but it looks to me like your not taking the camera position into account. For the dot product, you should dot the normal of your segments with the camera-to-segment direction. something like this maybe: dot(segmentNormal, camPosition - segmentPosition) > 0) // reverse segment direction because segment is now facing away from camera
  13. Billboarding a line

    I'm probably still not understanding 100%, but orthographic projection would still get you depth. the only difference between orthographic projection and perspective projection is that in perspective projection, things further away appear smaller. depth is still written to the depth buffer in both of them.
  14. Billboarding a line

    this won't help the twist issue, but if you change gd_matProjection to be an orthographic projection, everything will appear the same size no matter how far away from the camera it is EDIT: I just realized what you are talking about with the twists. You want the direction to be reversed once it's facing away from the camera, so once it reaches the point where its about to face away from the camera, the direction is reversed
  15. Billboarding a line

    Ah OK, what about that twist? You don't want the twist?