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


  • Content count

  • Joined

  • Last visited

Community Reputation

141 Neutral

About thurber

  • Rank
  1. Hi,   I thought I'd respond to this thread in case it helps anyone solve the same issue that I was encountering. I finally worked out that if I rendered in wireframe mode, the edge pixels would always get drawn. When combined with solid rendering this results in the entire UV area being covered, so when sampling the texture it looks correct.   In case you're interested, my aim was to bake ambient occlusion fields to textures. I've written this up in a blog-post here: http://blog.mattdev.com/baked-ambient-occlusion-fields-in-cloud-racer/.   Thanks again for the useful discussion, it helped set me on the right path to work this out. Finally, some pictures...   Here is just solid rendering:     Here is the wireframe rendering:   When combined, you get this:
  2. Thanks for the replies, Hodgman & Jason Z!     Yes. I've also got the results rendering in my game (and looking the same), but I found the texture coordinate view in Softimage useful - and obviously it's safer to use their rendering code, in case something is wrong in another part of my setup :).   Your comments about differences in rasterization versus texture sampling have given me some ideas. I'll do some more research into that, and post again once I've got some results.   Cheers
  3. Hi there,   I'm trying to render out to a texture based on a mesh's UV coordinates, with the intention that I can then use this texture on the mesh. I've run into a problem which has had me stumped for ages... so *any* help would be gratefully received!   Here's my vertex shader (I'm using D3D9 btw):     VertexToPixel VertShader(VertexInput input) {     VertexToPixel Output = (VertexToPixel)0;     // Output position of the vertex is the same as the UV coordinate of the vertex     Output.Position.xy = input.TexCoord.xy;     // Half-pixel offset; not sure if required...?     // Output.Position.xy -= float2(1.0/fTextureResolution,1.0/fTextureResolution) * 0.5;     // Transform to clip-space Output.Position.y = 1.0-Output.Position.y;      Output.Position.xy = (Output.Position.xy) * 2.0 - 1.0; Output.Position.zw = float2(1.0, 1.0); return Output; }       The pixel shader is set to just output red for testing, and the clear colour is black. My test mesh is two triangles, as seen below. You can see that the output *almost* matches up with the mesh UVs, but there are slight black fringes around some edges (left panel is the texture editor, with UV outlines shown in yellow).     My initial thought here was that it needed a half-pixel offset (see http://drilian.com/2008/11/25/understanding-half-pixel-and-half-texel-offsets/); I'm outputting to a texture from clip-space, so it kinda makes sense that I'd need that translation... but please tell me if I'm wrong on that.   However, I've tried it with half-pixel offsets in all directions, and there's always at least one edge which has fringes:     Zoomed in:   At this point, I'm quite confused. I've generated these UVs in Softimage (using "Unique UVs (polymesh)") for a "target resolution" of 256x256, and I've output a texture of 256x256 using a *very* simple vertex/pixel shader... and it seems like no amount of offsetting can get it to line up correctly - there's always a fringe of black pixels in the mesh.   This happens with any mesh I throw at it, btw. Here's a torus that I tried:     My only other thought has been to try to use Direct3D's "D3DXCreateTextureGutterHelper" group of functions to try to add gutters, and I've had very limited success with that too; but I suspect the main problem is with something I've outlined above. As I understand it, gutters shouldn't be necessary at all unless I'm using bilinear filtering, which I'm not doing in these tests.   Can anyone see what's going wrong? Any thoughts would be greatly appreciated, and please let me know if any more details are required.   Cheers, Thurber