• 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.

GeneralMeliante

Members
  • Content count

    11
  • Joined

  • Last visited

Community Reputation

149 Neutral

About GeneralMeliante

  • Rank
    Member
  1. Hi Jason Z!   I actually looked on the Hieroglyph 3 repository and managed to put the MFCwithD3D11 to compile (it needed to be made a solution that really had the .cpp and another configuration necessary) and made it open but it only creates the 3 windows wasn't it suppose to draw a cube in each one of those windows?   Thank you very much i did find the examples on the Hieroglyph 3 really interesting but by now i only need to learn how to get my already done D3D11 program go to the view window on MFC.   Thanks!
  2. Hi, thank you for your response but i actually did an extensive search on google e got nothing really helpful since i`m looking for MFC with D3D11, there is quite a lot on D9 and as i was told it is not adequate to use it.   Could you please provide me with any of your tutorials findings?   thank you very much!
  3. Hi everyone!   I need to integrate a program in DirectX11 already done with the view window on an MFC application, could you guys help me out somehow? Some examples any idea how I should tackle this situation because I'm pretty clueless here.   I did create the MFC application, I know that the .cpp I should focus is the one ending in view where there are kind of a start function for creating the object and OnDrawn and such but i have no idea how to get my already done program and add it to the MFC application.   Anything would help here, a simple example made (I was trying to make this integration with a simple draw the triangle from the D3D SDK), anything really!   Thanks very much in advance!
  4. I guess i forgot to make the question itself.   I would like to get the same effect as the one taking from a pre made base texture by providing in real time the range of colors.   Thank you guys very much for any input!
  5. Hi everyone!   I'm trying, through the PixelShader on the HLSL, to define the color of the pixel based on its height taken from the heightmap texture.   The program now takes the color from a texture sampling it linearly and I would like to change that to one defined by me based on the height of that pixel. It's a terrain so basically i get the heightmap, calculate and add to it a normal map on CPU. Since i need this to be really fast (the user must be allowed to change the colors on real time) this logic must be held on the shaders.   Below follows a cut of the function that gets the color for a given pixel considering all the lights and information from the texture with the color.   float4 ComputeIllumination( float2 texCoord, float3 vLightTS, float3 vViewTS ) { // Sample the normal from the normal map for the given texture sample: float3 vNormalTS = normalize( g_nmhTexture.Sample(g_samLinear, texCoord) * 2.0 - 1.0 ); // Sample base map float4 cBaseColor = g_baseTexture.Sample( g_samLinear, texCoord ); // Compute diffuse color component: float4 cDiffuse = saturate( dot( vNormalTS, vLightTS ) ) * g_materialDiffuseColor; // Compute the specular component if desired: float4 cSpecular = 0; // Composite the final color: float4 cFinalColor = ( g_materialAmbientColor + cDiffuse ) * cBaseColor + cSpecular; return cFinalColor; } When i try to change that logic by adding something like seen below it has no linear variation between pixels its flat that color and the normal map loses its effect for some reason.   float unit = 0.00390625; if((vHeight.w >= (0 * 63.75 + 1) * unit) && (vHeight.w < (1 * 63.75 + 1) * unit) //&& (vHeight.w > clipThreshold) ) { cBaseColor.rgb = uint3(0, 0, 255); //cBaseColor.a = 255; } else if((vHeight.w >= (1 * 63.75 + 1) * unit) && (vHeight.w < (2 * 63.75 + 1) * unit)) { cBaseColor.rgb = uint3(0, 255, 255); //cBaseColor.a = 255; } else if((vHeight.w >= (2 * 63.75 + 1) * unit) && (vHeight.w < (3 * 63.75 + 1) * unit)) { cBaseColor.rgb = uint3(0, 255, 0); //cBaseColor.a = 255; } else if((vHeight.w >= (3 * 63.75 + 1) * unit) &&(vHeight.w < (4 * 63.75 + 1) * unit)) { cBaseColor.rgb = uint3(255, 255, 0); } else if(vHeight.w == 1) { cBaseColor.rgb = uint3(255, 0, 0); }     Below first is how it looks using only the provided texture and second with the added logic AFTER relating it with the texture, meaning not taking of the:  float4 cBaseColor = g_baseTexture.Sample( g_samLinear, texCoord ); and adding: float4 vHeight = g_nmhTexture.Sample( g_samLinear, texCoord ); to get information from the heightmap.      
  6. Ok, keeping up with the idea of making less vertex and compensating it with tessellation there was the bug, but i managed to pin point the problem, it'`s something with the density based algorithm without it works perfectly, so by that i made the texture be something like a 72 x 83 and added a 20x tessellation and i get pretty good geometry except in regions of holes that the tessellation tries making more triangles based on the base text but a few parts of it are clipped after. so look at the little spikes that appeared is there a way to make this better? https://dl.dropbox.com/u/51198194/Trabalho/spikes.PNG
  7. Hi Nik02, well i did try to make but what happens now, after the modification to DWORD from WORD is that the tessellation bugs the visual creating little holes between triangles its very weird. So i couldn't make the variation of using less cpu by dividing it size and tessellation gpu because of the problem above. the image below demonstrate the issue: Using a 180 value for height and width with 8 tessellation only to see the bugged effect: solid: https://dl.dropbox.com/u/51198194/Trabalho/dividedby64solid.PNG wireframe: https://dl.dropbox.com/u/51198194/Trabalho/dividedby64wireframe.PNG And for a 1653x1440 without tessellation it takes a lot of time to load and gets a really bad fps, shouldn't it get higher values when not looking to all the cylinder? how can i improve on this two subjects, load time and fps rate? solid tube: https://dl.dropbox.com/u/51198194/Trabalho/Tubesolid.PNG wireframe: https://dl.dropbox.com/u/51198194/Trabalho/TubeWireframe.PNG Thanks, sorry for late response, thank you very much for your attention!
  8. [quote name='Nik02' timestamp='1350455482' post='4991024'] 1440*1653 (which equals 2380320) overflows the range of a WORD (typically 0...65535) by a great margin. Have you tried to use 32-bit indices, which would raise the range to 0...2[sup]32[/sup]-1? The indices would then be represented as DWORD as opposed to WORD. That said - independent of the above issue - it may be wise to spatially partition the mesh anyway, if the shading is complex enough. You probably don't see all the geometry at once, at any given moment? There is a fine balance here, though, in that the partitioning itself can use more time than you save by doing it. [/quote] Thank you very much! I did change the index buffer to be 32-bit and the WORD to DWORD on the grid creation, now i can get values bigger then 180 but, as you said, it gets a lot slower ( i'm using a 500 x 500 just as tryouts ). What would you recommend for a performance boost? creating partitions of the cylinder instead of trying to do it all? the thing is that i use a texture for heightmap i would have to cut it to keep the heights. The main point of my program is to keep the heightmap as perfect as the texture required. That is why i'm trying to keep the grid with the same amount of vertex of the heightmap texture.
  9. Hi guys! Well sorry for the weird topic title as i don't really get the concept i`m talking about as clearly as i should. So, i started my project on top of the sample "DetailTessellation11" from DirectxSDK and one of my intentions was to make it create a cylindrical terrain with a size of 1440 x 1653. I can use the image but it doesn't look as detailed as it should be. Then i found this variable: [source lang="cpp"]DWORD g_dwGridTessellation[/source] It is used in a few functions during the program but it's main use is for creating the grid ( in this case a square with the amount of vertex of the grid equal to g_dwGridTessellation*g_dwGridTessellation ). What i did get is that it determines the amount of vertex of the grid it's creating. The problem: Since I need to plot a 1440 x 1653 (or bigger) grid I changed the value of the variable and found out that it can't go over 180 and through breakpoints i have found out that this functions causes an Access violation probably because i`m overflowing a pointer or type of variable. [source lang="cpp"] // Allocate memory for buffer of indices in system memory WORD* pIndexBuffer = new WORD [nNumIndex]; WORD* pIndex = &pIndexBuffer[0]; // Fill index buffer for ( DWORD i=0; i < dwLength; ++i ) { for ( DWORD j=0; j < dwWidth; ++j ) { *pIndex++ = (WORD)( i * (dwWidth+1) + j ); *pIndex++ = (WORD)( i * (dwWidth+1) + j + 1 ); *pIndex++ = (WORD)( (i+1) * (dwWidth+1) + j ); *pIndex++ = (WORD)( (i+1) * (dwWidth+1) + j ); *pIndex++ = (WORD)( i * (dwWidth+1) + j + 1 ); *pIndex++ = (WORD)( (i+1) * (dwWidth+1) + j + 1 ); } }[/source] Since this variable is inside a grid creation function it's name has changed to dwLength and dwWidth. I did some researches and i thought that could be the change from DWORD ( unsigned long) to WORD ( unsigned short ) but couldn't change it in the program for some reason. So basically am i correct about anything? Is this a problem with this function or I simply cannot handle that many vertex? What can i do here? If no possible to handle that should i just make the program create several grids and stick then together? Thank you for you time!
  10. Well guys, first thank you very much for your input. Based on the overall answer it looks like this "move" on the VS is a very tricky one and not recommended if it is possible. And yes what i was doing is using a diffuse texture to get those holes transparent and what i was trying to fix was this weird lines trying to reach the regions of zero because from one vertex to the zero one there is a direct line connecting then and when i clip the zero vertex it keeps half the line. As sad on my first post i managed to fix this quite well by changing the zeros of the texture to a better suited value. In a way that the zero region would now have a value equal to its non-zero neighbor and the lines wouldn't go weirdly to the center so when i passed the diffuse texture the lines would, in theory, be pointing along the the cylinder terrain. What did happen is that i can hardly see the lines now, so great. Thanks very much, it was very informative (btw i loved the L4D2 thing)
  11. I'm currently working on a cylinder shaped terrain produced by a height map. What happens in the program is simple, there is a texture for the colors of the terrain that has the alpha value of regions in with i want it to be invisible and another texture ARGB with the A being the gray scale for the heights and RGB is the normal for the light. The texture is such that the A value goes from 1 to 255 and I'm reserving the 0 for the regions with holes, meaning i don't want then to exist. So in theory no problem, I'm making those regions invisible based on the first texture but on practice what's happening is that the program is considering the 0 as the minimum height and, even with the texture on top, is creating some lines towards this regions of 0, like trying to make its triangle but not getting there because i cut the next vertex by making it invisible. The image below is with a clip() function making the region invisible [img]http://i.stack.imgur.com/ZuEPk.png[/img] This next image is without the clip function: [img]http://i.stack.imgur.com/MyFmG.png[/img] Notice the lines going to the center of the cylinder This is how it gets when i stop making those vertex invisible So, just to say, i used the function Clip() on the pixel shader to make it invisible. My questions are: Is it possible, the same way i used clip() on the pixel shader i do something like that on the vertex shader and get rid of the unwanted vertex? Basically, is possible to just say to ignore value 0? Any ideas to fix this? Another thing is that we can see that the program is interpolating the values from one vertex to the next, that is why i cuts on halfway through to the invisible vertex. On a more technical point of view the domain shader is the one picking the heights from the texture and plotting it. I managed to fix this somehow by modifying the texture, through the program, by changing the 0 values of the heights to a more proper one, but i'd like to know if there's a possibility through the HLSL. I'm working with Directx11 API with C++ and the program uses Tessellation. Thank you for your time and will be very glad with any input on this!