Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

568 Good

About smasherprog

  • Rank
    Advanced Member

Personal Information

  1. smasherprog

    Common Shading Language

    Just a suggestion, but instead of making a new language, why not use GLSL as "your" language --or HLSL. Then, write code to export the GLSL to HSLS/someotherlanguage?  In this way, you do not need to write an extra language, but work with what already exists -- it might be easier this way as well?
  2. smasherprog

    Camera axis always inverted somehow

    try removing the transpose from this line   XMStoreFloat4x4(&pTransformData->WorldViewProjection, XMMatrixTranspose(worldViewProj));   making it   XMStoreFloat4x4(&pTransformData->WorldViewProjection, worldViewProj);
  3. smasherprog

    Increasing Line Length

    to make any ray longer, you just multiply if by a scalar.   Meaning, if you have a ray, and you multiply it by two, the ray is twice as long . . .
  4. I successfully ported his examples to directx and ran into the same issues. Unfortunately, there were several places where the y and z components needed to be flipped. Both in the vertex shader and the pixel shader. First, get your vertex shader to draw properly.   Swap your final output y and z components in the vertex shader( but before you transform the vertex so the transform is correct). This will mess up your pixel shader. So try swaping the z and y components back at the beginning of the pixel shader. Then, make sure to swap the z and y components of anything externally set and used in all of the shaders, i.e. cameraposition, sunnormal
  5. smasherprog

    Compile errors

    This just means that the function bool InitializeDirect3d11App(HINSTANCE__ *) that is used in your _WinMain function is never defined anywhere   It is called, but the compiler cannot find the actual function definition.
  6. smasherprog

    SSAO and skybox artifact

    When dealing with shaders, ALL code is executed, including ALL branches, all function calls, etc. The ONLY exception for this is if something is known at compile time that will allow the compiler to remove a particular piece of code. This is how all graphics cards work, AMD, NVIDIA, etc. So, your additional cost is of the if statement, and in your example, you are adding an extra if instruction. This is a zero cost on gpus. If you want to read on it, check out vectors processors and data hazards. If you somehow split our shader up and added an if statement to the middle thinking that it would speed up your code, you would get NO speedup. because ALL paths will be executed.
  7. smasherprog

    Question about glGenTextures

    All gentextures does it get you a valid Texture ID. It doesn't actually create a texture for you. So, you would Usually, GenTexture //get an ID BindTexture //sets the active texture for work Fillorcreate the texture stuff here GenTexture should only be called when you want a NEW texture ID. If you are just updating a texture, or want to bind it for work, use the ID that you got from your GenTexture call when you created the resource.
  8. Like Erik said, the drawing function changes states, so you can use the ID3DX10Sprite::begin(D3DX10_SPRITE_SAVE_STATE); draw text inside here ID3DX10Sprite::end(); This will make sure your states are changed back to what they were before the draw text call.
  9. smasherprog

    Allocating memory problem (terrain)

    You can also do away with most of the the position of the grid, as well as the texcoords. You can generate the actual position of the verts in the vertex shader by supplying an offset that you pass in for each chunk drawn. Create a stream of two floats( x and z) and make it go from (top left) 0, 0 to (1, 1) on the bottom right. Then when ypu draw it in the shader, you can compute the texcoords from it and you just scale the grid up its full size with a multiplication, then add the offset to each vertex and you have placed you4r grid correctly. To get the correct hights, you create a seperate highstream for each grid and pass that in for each drawing operating as well. In the end, you reuse the x,z grid mentioned above for all grid patches, since its always the same. Resuse the same index buffer for all grids since its also the same. The only differences will be your extra data. You will need a highstream for each grid, and your normals + tangets. This is very breif as I am heading off to work, but hopfully you get the idea on reducing a decent amount of vertex memory.
  10. smasherprog

    Sending data questions

    A pointer variable is really either a 32 bit or 64 bit number --depends on whether you build your application as a 32 bit or a 64 bit. So, when you send that structure --assuming a 32 bit build-- you are sending a total of 64 bits, 32 for m_data and 32 for m_id. The number that the pointer holds is a memory address. If you want to send a variable length array, you can, but you need to do your own packing. also , use unsigned shorts, which are 16 bits. You will likely not need 32 bit packet ids unsigned short int packetid = 45;// best to use an enum for packet ids so you can reference them with words std::string npcname = "big bad monster"; unsigned short int sizetosend = npcname.size() +sizeof(packetid) + sizeof(unsigned short int)*2;// 2 is for the size of the string 2 is for the m_id variable, 2 is for the size of the payload char* data = new char[sizetosend]; memcpy(data, &packetid, sizeof(packetid)); memcpy(data+sizeof(packetid), &sizetosend, sizeof(sizetosend));// size of the payload so on the other side, you can copy the data correctly memcpy(data + sizeof(packetid) +sizeof(sizetosend), npcname.c_str(), npcname.size());// there is no null terminator being copied in here to save a byte sendto(socket, data, sizetosend, 0, (sockaddr*)&address, sizeof(sockaddr));
  11. Use mipmaping. Create your heightmap as a texture on the gpu, and make sure the gpu generates mipmaps for it. Then, when you are sampling the heightmap, you have mipmaps to give you coarse or fine grained results.
  12. MJP, thanks for the reply, i had a buffer overrun in a part of my program that spilled over into the shader which was causing the error. I could'nt understand what was going on because I knew pre processor macros could be used..... Thanks for the response +1
  13. While working on my graphics engine, I have some shaders that never change and I want to keep them inside my compiled code so I have less files floating around, but compiling a shader from a string with pre processor macros causes an error to be thrown. Error CompileShaderFromMemory, Shader@0x03D5F140(1,76): error X3000: syntax error: unexpected token '#' E_FAIL An undetermined error occurred Are any pre procesor defines not allowed when compiling a shader from memory? I did a search and found nothing, so I am curious.
  14. smasherprog

    Precompile Effect

    I havent used SlimDX before, but you can compile an effect in Directx. Maybe that will help you in your search in slimdx
  15. smasherprog

    mvc and c++

    The model view controller works for web site design because thats all there is. In c++ programming, there are many more ways to seperate code than the MVC route because you are not just developing a web application. You can seperate code based on input, network, graphics, logic, threading... on and on Segregation of code is done in c++ to make compilation faster, reduce coupling between classes, keep cpp files as small as possible to make maintining easier, and to create logical relationships between child and parent classes. There are other reasons I am sure, but I would suggest to not think of web programming paradigms as a way to program a c++ application. The two might be somewhat related, but in general they are not.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!