• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

smasherprog

Members
  • Content count

    550
  • Joined

  • Last visited

Community Reputation

568 Good

About smasherprog

  • Rank
    Advanced Member

Personal Information

  1. 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. try removing the transpose from this line   XMStoreFloat4x4(&pTransformData->WorldViewProjection, XMMatrixTranspose(worldViewProj));   making it   XMStoreFloat4x4(&pTransformData->WorldViewProjection, worldViewProj);
  3. 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. 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. 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. 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. 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. 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 [code] 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)); [/code]
  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. I havent used SlimDX before, but you can compile an effect in Directx. http://msdn.microsoft.com/en-us/library/windows/desktop/bb205078%28v=vs.85%29.aspx Maybe that will help you in your search in slimdx
  15. 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 [i]paradigms [/i]as a way to program a c++ application. The two might be somewhat related, but in general they are not.