• 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

738 Good

About Pthalicus

  • Rank

Personal Information

  1. ID3D10Blob* pVertexShaderBytecode = NULL; ID3D10Blob* pCompileErrors = NULL; if( pCompileErrors != NULL ) { OutputDebugStringA( (CHAR*)pCompileErrors->GetBufferPointer() ); pCompileErrors->Release(); return 0; } D3DCompile(pVertexShaderCode, lstrlenA( pVertexShaderCode ) + 1, "vertex shader", NULL, NULL, "vertex_shader", "vs_4_0", NULL, 0, &pVertexShaderBytecode, &pCompileErrors ); Here you're checking if the shader compiled succesfully, before actually compiling the shader. If you try compiling the shader before checking the compile succeeded, this should fix this issue. Side note: You're compiling the shader each time you call DrawSquare() (perhaps this could use a better name?). It's much more efficient to compile the shader once, and then binding this compiled shader before drawing the triangle.
  2. Another vote for P4Merge from me. Though I've only ever used one other merge tool, this has the advantage of being free (within requirements). :)   You can view the original file(base), and branched versions(yours and your partners changes) for resolving conflicts - and specify which change should be used(or both), and also, if necessary, modify the result by hand in the merge window below.   (It also works for images too, and can highlight the differences.)
  3. Apparently, the Whitehouse declares .gif as Gif with a hard G, not Jif.    http://news.cnet.com/8301-17938_105-57581656-1/breaking-white-house-tumblr-says-its-gif-with-a-hard-g/   It's nice to know they're on the same wavelength... even if that's in another country.      I used to pronounce it like this too, but I've since changed to "jay-pee-gee".
  4. I'm unsure of how the D3D shader compiler / effect system works when specifying just one address mode in the sampler state.   Here, you're just applying the CLAMP state to AddressU without setting AddressV or AddressW.  Does the effect compiler output any warnings/errors?   Searching through MSDN I found this: http://msdn.microsoft.com/en-us/library/windows/desktop/bb509644(v=vs.85).aspx Though this doesn't really answer that question, it does give an example in "MeshTextureSampler" for trilinear sampling.   (Also, I assume the duplicated "gPointSample" is a copy/paste error?)   Hope this helps     Additionally, since you're sampling in the geometry shader, ensure you're using the correct texture access method: http://msdn.microsoft.com/en-us/library/bb509700%28v=VS.85%29.aspx. I.e Load(), SampleGrad() or SampleLevel()
  5. I haven't tested this with your "infinity matrix", however, this works fine with a regular good'ol non-orthograpic projection matrix:   void buildProjectionMatrixInfinityPerspectiveFovLH(f32 aspectRatio, f32 parallax) { const f64 yScale = 1.0f / tan(45.0f / 2.0f); const T xScale = (T)(yScale / aspectRatio); const T Epsilon = 0.000001f; M[0] = xScale; M[1] = 0; M[2] = 0; M[3] = 0; M[4] = 0; M[5] = (T)yScale; M[6] = 0; M[7] = 0; M[8] = 0; M[9] = parallax; // Parallax shift M[10] = 1.0f+Epsilon; M[11] = 1.0f; M[12] = 0; M[13] = 0; M[14] = -1.0f; M[15] = 0; definitelyIdentityMatrix=false; return *this; }     So you'd obviously want two projection matrices:   f32 parallax = 0.033f; // Real-world value: dependant on screen SIZE (not dimensions), and user's viewing distance to screen. matrix left = buildProjectionMatrixInfinityPerspectiveFovLH(aspectRatio, -parallax); matrix right = buildProjectionMatrixInfinityPerspectiveFovLH(aspectRatio, parallax);       Note: The parallax should match the viewer's eye seperation from their viewing distance, take into account the real-world dimensions of the screen, and account for the viewer's distance to the screen - if you want a realistic experience. However, this is largely impossible unless you're using a head mounted display - where the viewing distance is constant.   You could just tweak the parallax value to see what feels best. :)
  6. OpenGL

      This can be solved with the Light-Pre-Pass technique. Granted, you'll be rendering the scene twice - once for pre lighting, and once for post lighting - you won't require a "fat G-Buffer" as with regular deferred. Here's a proof of concept already implementing Light-Pre-Pass on an iPhone: http://www.altdevblogaday.com/2012/03/01/light-pre-pass-renderer-on-iphone/ 
  7. I'd never heard of this site (www.fiverr.com) before you posted it. There's a programmer section; a C++ programmer section.  "I will write any kind of c++,java,c program within 2 days for $5"  I wonder if they could code me a new modelling tool in 2 days? $5 seems pretty cheap. On the serious side, these sites always seem suspicious to me; since the cost is super low, the quality of what you purchase will likely be really bad. (Hopefully I'm wrong here)   I've personally never used a micro-job site for anything, instead, forming a network of contacts who specialise in certain fields (sound design/voice overs/animation) seems like a better approach. Additionally, agreeing on a contract for their services, and hiring the same people should ensure your assets are more coherent. Just a few thoughts, hope this is useful. :)
  8. Instead of looking for a tutorial that matches your exact requirements, you can gain a lot more by solving this yourself.     How do you think this could be achieved? If you know the maximum jump height and specify a jump speed, you can increment the characters height by the speed until they've reached the height limit - whilst the jump button is pressed. And when the jump button is released, the player falls. Once you've done this, you could improve the "feel" of the jump, by changing the characters jump height to increase by smaller and smaller amounts over time - rather than a constant speed. This will create a slightly floaty/hovery jump depending on the curve/falloff.     So you know the solution to the problem, but don't know where to put the code? You could place this code just after the input if you'd like. (Though I'd suggest you place the physics code in the same area)     You know when the jump button has been released, so you'll need to know when you've hit the ground. If you're using tiles/grid, check the tile below you is a floor/ground tile. If you're touching this tile, you've hit the ground. Reset the jump ability here.     At this stage, solve the problems one at a time.    Additionally, I'd like to add that it took a long time for them to get the movement mechanics right, with lots of tweaking. You would probably benefit from making a simpler jump system first, and then improving that once it's complete.     Looking forward to it 
  9. Just a quick addition, since I have little time.   Symptom code: int i = 0; printf( "i = %d", i );   Output: "i = 1"   It took four senior coders to work out what was going wrong here. The issue was overflowing buffers -> memory corruption. Causing data to not be assigned the value it was assigned. That was a fun monday morning.
  10.   In big companies, not everyone deals with the graphics code. For example, a gameplay programmer would benefit from scripting knowledge, but graphics programming wouldn't greatly benefit this role.
  11. Thanks for this post Jonathan You mentioned this in your post: [CODE] return ((Window*)GetWindow(hWnd, 0))->HandleEvents(hWnd, msg, wParam, lParam); [/CODE] The reason this doesn't crash is because in HandleEvents(), you're only calling the default window procedure and not modifying the data within the class object. If you were to modify the data members of the Window class inside HandleEvents(), you'd probably corrupt memory. This is because you're casting the HWND returned from GetWindow() to a pointer to your custom window class, but HWND != Window*. You could probably try breaking it, by setting the window title inside the HandleEvents() method. Hope this is useful, and I'm looking forward to your future posts!
  12. If it's used everywhere, make it global. Some people fight to the death to ensure there are no globals in the code... but sometimes, globals are necessary, and it keeps the code interface nice and tidy. (Don't use globals everywhere though, since they can be a pain to track when debugging) Using inheritance isn't "bad" all of the time, only when it's abused, like any other tool. At the moment, try focusing on implementing the game, and think less about the engine. You'll learn a lot about what you really need the engine to do from making a game. Hope this helps
  13. Thanks guys ginkgo: Sorting [i]is [/i]possible[i], [/i]but a pain since the particles are generated on the GPU. Though I like the idea Promit and yourself mentioned about scaling the quads and varying the mip-sample. This might work nicely, and if it merges well with the scene DOF, I'll go with that - since it's relatively cheap. JimC1664: I'm not sure that will look right, something about it doesn't feel right - I could additively blend the depth, then use that to find centre of the particles for that pixel, but that feels wrong. CukyDoh: Looking at those images, it looks like they just completely ignored the particles depth, and applied the DOF using the scene depth after drawing the particles. I've seen inferred lighting, and if I were using it, then yes DOF using each layer's depth would be nice. DOF pass per render batch doesn't seem feasible in this case; the individual particle systems can merge together, so this might introduce "popping" artefacts. Also, there are many systems visible at once - meaning many DOF passes, which is extremely expensive in this case. I'll go ahead with applying the DoF manually, scaling the particles, and varying the mip level and see how it looks. Cheers guys.