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

TheFallenOne

Members
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

136 Neutral

About TheFallenOne

  • Rank
    Newbie
  1. Hey guys,   I'm having a bit of an issue with texture mipmaps.   I have a model that uses a diffuse texture that doesn't stretch to the edge of the image file. To clarify, the edges of the texture are padded with a solid black color, and the texture coordinates on the model never hit either 0 or 1, they use a smaller subset of the texture.   When I disable mipmaps, everything works great, but with mipmaps, the edge of the texture is showing a line from the black pixels bordering the texture, making it appear like the model has a seam in it.   My guess is either the mipmaps are sampling part of the black pixels, or the texture coordinates are coming out with a different result on the mipmap'd texture.   Does anyone have any suggestions on how to fix this?   I can post images and code if needed.
  2.     Yeah, that's the easy part.  Unfortunately, I can't precalculate values in this case.   The sprites can be rotated on the sheet, and will need to have extra transparent space added on to them, which means the calculations will have to be done in the shaders. It's not the calculations I'm worried about anyways, it's the extra data being sent down the pipeline.   For instance, my model shader takes 4 textures (for various lighting effects, etc).   That means that for every model drawn, just to use sprite sheets (and remember these are ONLY in use if the texture is animated, which is the exception rather than the rule) I have to include:   -8 extra float2's (a texture coord range for each texture, specifying where on the sprite sheet to take it from) -Another 16 float2's (final texture width/height and the texture offset, so transparent space can be added in the shader and the texture can be properly aligned) -8 boolean values (specifying if the texture is rotated on the sprite sheet)   Plus all the calculations to make those function. All done in the shader.     Feels like a huge chunk of data to be sending down the pipeline with every shader for functionality that's not going to be used in the majority of cases... Maybe I'm worrying over something that won't really be causing any serious issues. It likely won't cause any performance hit whatsoever, just feels like I'm adding a lot of bloat to the system.   Thanks for the input though guys.
  3. Hey guys, need some opinions/input on the best way to handle this.   Using DirectX 9, for reference.   I've recently started implementing animated textures into my engine, which included the addition of sprite sheets.   I've made it to the point that the resource hierarchy (texture management) will let me reference static textures and animated textures interchangeably, and the sprite sheet textures (plus separation data) are loaded properly.   Now I've come to a bit of a crossroads, and am hoping there's a better way to handle this.   So, I've got my sprite sheet loaded as a texture, and now need to split it off into individual frames.   I can setup a system that will modify texture coordinates and rotation properties to grab the proper image off of the sprite sheet, without cutting the texture up in memory at all. This, however, would add some overhead on per-frame calculations and increase the amount of data being sent down the shader pipeline a bit, especially considering I'll need to re-add transparent pixel data around the edges of most of the grabbed sections. Plus it'll be a decent bit of work coding wise.   The second option is to split the textures up when the sprite sheet is loaded, copying them to new texture resources, so I don't have to modify texture coordinates (et cetera) at all, I just have to pass a different texture pointer. This would add some additional memory overhead, though, and essentially eliminate 80% of the purpose of using sprite sheets in the first place.   So, I'm hoping there's a third option I'm missing. I was really hoping there was a way to simply set up a texture "reference" (that points to a specific subset of a texture) without having to physically make a new texture to store it, but I haven't seen anything of the sort.     Anyways, any input is greatly appreciated. Thanks in advance!
  4.   Awesome, this solved the issue! Thanks a million. :D   Sad, because I read that it uses a vector to determine texture coordinates in several different places... I guess it just never clicked.   Thanks to you other two as well!!
  5. Hey guys,   In the process of writing some code to render a cube mapped skybox, used to render a star map in space.   Running into some issues, the texture isn't cooperating, as you can see in the following screenshot:   http://img502.imageshack.us/img502/4474/skyboxbug.jpg     Top and right hand sides seem to be rendering okay, but the rest isn't.   I've looked over everything ten times, double checked all the vertex and index definitions, rewritten the shader... to no avail. So obviously I'm missing something.   It feels like a misplaced texture coordinate, but I've tried replacing the texCUBE in the pixel shader with a color determined by tex coords, and all of them come out how they're intended, so I'm going crazy here. Figured I'd get some outside help.     I'm only sending texture coordinates and building vertex coordinates in the vertex shader.     The following is my cube definition (note that my camera viewing vector is down the Y axis, instead of the usual Z axis, hence the comments on the position of the vertices may seem... misleading):   pPrim->LockVertices((void **)&pVertex); pPrim->LockIndices((void **)&pIndex); // 0 = Top far left pVertex[0].fU = 0.0f; pVertex[0].fV = 0.0f; pVertex[0].fW = 1.0f; // 1 = Bottom far left pVertex[1].fU = 0.0f; pVertex[1].fV = 0.0f; pVertex[1].fW = 0.0f; // 2 = Top close left pVertex[2].fU = 0.0f; pVertex[2].fV = 1.0f; pVertex[2].fW = 1.0f; // 3 = Bottom close left pVertex[3].fU = 0.0f; pVertex[3].fV = 1.0f; pVertex[3].fW = 0.0f; // 4 = Top far right pVertex[4].fU = 1.0f; pVertex[4].fV = 0.0f; pVertex[4].fW = 1.0f; // 5 = Bottom far right pVertex[5].fU = 1.0f; pVertex[5].fV = 0.0f; pVertex[5].fW = 0.0f; // 6 = Top close right pVertex[6].fU = 1.0f; pVertex[6].fV = 1.0f; pVertex[6].fW = 1.0f; // 7 = Bottom close right pVertex[7].fU = 1.0f; pVertex[7].fV = 1.0f; pVertex[7].fW = 0.0f; // 0 = Top far left // 1 = Bottom far left // 2 = Top close left // 3 = Bottom close left // 4 = Top far right // 5 = Bottom far right // 6 = Top close right // 7 = Bottom close right // Left Side pIndex[0] = 0; pIndex[1] = 1; pIndex[2] = 2; pIndex[3] = 1; pIndex[4] = 3; pIndex[5] = 2; // Right side pIndex[6] = 4; pIndex[7] = 6; pIndex[8] = 5; pIndex[9] = 5; pIndex[10] = 6; pIndex[11] = 7; // Top Side pIndex[12] = 0; pIndex[13] = 2; pIndex[14] = 4; pIndex[15] = 2; pIndex[16] = 6; pIndex[17] = 4; // Bottom Side pIndex[18] = 1; pIndex[19] = 5; pIndex[20] = 3; pIndex[21] = 3; pIndex[22] = 5; pIndex[23] = 7; // Far Side pIndex[24] = 0; pIndex[25] = 4; pIndex[26] = 1; pIndex[27] = 1; pIndex[28] = 4; pIndex[29] = 5; // Near Side pIndex[30] = 2; pIndex[31] = 3; pIndex[32] = 6; pIndex[33] = 3; pIndex[34] = 7; pIndex[35] = 6; pPrim->UnlockIndices(); pPrim->UnlockVertices();       And... My shader:     struct VertexOut { float4 Position : POSITION; float3 TexCoords : TEXCOORD0; }; float4x4 xProjection; float4x4 xView; float3 xCameraPos; Texture Texture; samplerCUBE TextureSampler = sampler_state{ texture = <Texture> ; magfilter = LINEAR; minfilter = LINEAR; mipfilter=LINEAR; AddressU = CLAMP; AddressV = CLAMP; AddressW = CLAMP;}; VertexOut CubeMapVS(float3 TexCoords : TEXCOORD0) { VertexOut Output = (VertexOut)0; float4x4 Final = (float4x4)0; Output.Position.x = (((TexCoords.x - 0.5f) * 2) * 50000.0f) + xCameraPos.x; Output.Position.y = (((TexCoords.y - 0.5f) * 2) * 50000.0f) + xCameraPos.y; Output.Position.z = (((TexCoords.z - 0.5f) * 2) * 50000.0f) + xCameraPos.z; Output.Position.w = 1.0f; Final = mul(xView, xProjection); Output.Position = mul(Output.Position, Final); Output.TexCoords = TexCoords; return Output; } float4 CubeMapPS(float3 TexCoords : TEXCOORD0) : COLOR0 { return texCUBE(TextureSampler, TexCoords); } technique CubeMapShader { pass Pass0 { VertexShader = compile vs_2_0 CubeMapVS(); PixelShader = compile ps_2_0 CubeMapPS(); } }       Any assistance would be greatly appreciated!!   Thanks in advance.
  6. Hey guys, I've recently written my own custom Wavefront OBJ model importer (in C++) that creates a DX9 mesh based on the OBJ/MTL information supplied. The only problem I'm having is with faces with more than 4 vertices (Ngons). I can handle quads just fine, but more than that I'm not 100% sure how I should handle it when creating a new mesh, and information seems to be pretty scarce on the web. Does anyone have any pointers on where to start?
  7. Quote:Original post by Wyrframe I'll assume you are aware that those 14 pixels are the ones taken up by your title bar, and past the question itself to some possible solutions. Yeah, I'm aware of that, thanks though. :) Quote:Option 1. Calculate your aspect ratio based on the client area of the window each time the window changes size (including when it is initially made visible). These days, with screen resolutions in not just 4:3, but also 5:4, 16:9, and 16:10, you either have to letterbox, or adapt to whatever you end up with. This sounds like a case of the latter. I've actually got a good system in place to deal with different aspect ratios, the only issue is that 1280x786 isn't, well... a traditional aspect ratio, to say the least, haha. I can make some adjustments in renderer to allow for this discrepancy between requested window size and received window size, but I would really rather not have a user get a smaller resolution (even if it is only 14 pixels smaller) than he requested simply because he wants to use windowed mode. Quote:Option 2. Ditch the Windows titlebar and draw your own minimize/close buttons in the top corner. Lets you utilize the rest of those rows of pixels. Actually not a bad idea at all, though a good portion of the reason the title bar is there is to allow the user to move the window. I suppose I could code a smaller little section alongside of those allowing them to move the window, but these buttons would not be visible in fullscreen mode, meaning that the top right hand corner of the screen would be unusable in fullscreen, since windowed users would not be able to see it. I don't really want to waste screen space unless absolutely necessary... Quote:Option 3. Go traditional fullscreen. The problem is that the user has complete control over resolution, fullscreen and windowed mode, and I'd like to keep it that way... I'm not going to force them into fullscreen mode just because of some differences in resolution between fullscreen and windowed. Thanks for the suggestions, I'll take them into account. :) I'll play around with a few ideas you gave me. However, if anyone else has any input on bypassing the issue directly, it'd still be greatly appreciated.
  8. Hey all, First post here, browsed the sections of the forums and this seemed like the appropriate one, I apologize if I dropped it into the wrong section by accident. Anyways, I'm currently working on a game engine and recently noticed an issue, have thus far been unable to solve it (with several hours of searching, nonetheless). The engine is written in C++ in conjunction with DirectX, for reference. So, here's the problem. When creating a window using CreateWindow or CreateWindowEx, I've discovered that you *cannot* create a window that extends past the edge of the screen. Normally this is a non-issue, however, I'll give a quick example of where I hit a snag. Say a user selects Windowed mode, and decides to use the same resolution as the desktop. Let's say... 1280x800. Since it's windowed mode, I'd like a title bar to be available, so I've included the following style flags: WS_CAPTION | WS_MINIMIZEBOX | WS_SYSMENU Now, using AdjustWindowRect gives me the proper size that I should pass in to get the desired client area just fine. However, when I pass it in, CreateWindow returns a window of size 1280x786, because the title bar increases the size of the window to the point that if the client area of the window was 1280x800, it would be offscreen. Even if I attempt to pass in something like 1280x9000 for size, it will still create a window of size 1280x786, so that it doesn't go offscreen. So, I'm missing 14 pixels. This causes some major texture issues when I go to render and present the backbuffer in DirectX, as the backbuffer has a height of 800, not 786. Obviously I could resize the backbuffer to match the client area, but I would rather not throw off the aspect ratio just because Windows decides it doesn't want to give me the client area I want. Is there ANY way to get Windows to give me the properly sized window? I've tried calculating the proper size myself (using GetClientRect and comparing pre and post-CreateWindow call sizes) and then modifying it after the CreateWindow call using SetWindowPos, but that still won't let me exceed the screen size. Any help is greatly appreciated! Thanks in advance, -Kyle