So I’m currently looking for a job in the game industry, location and salary are secondary to the work at this point. I kinda just want to get out of South Africa and work on something cool. I’m still young enough not have to worry about supporting a family, stability or dealing with crunch time, I kinda just need a chance. I’ve spent the last few weeks sending applications, writing programming tests and interviewing. And to be dead honest, I’m kinda starting to lose a bit of faith in myself and my chances of landing an entry level game dev job without any game experience.
Now before I carry on with this post, I need to just say that I, in no way regret any of the interviews I’ve had, I’ve learned something from each and every one of them. It’s actually been kinda fun even though I felt like a complete idiot a couple of times (I tend to be really hard on myself). The programming tests were a lot of fun and one plus is that I’ve passed all the tests I’ve written. Continue reading “Experiences with Interviewing So Far”→
So I’ve recently completed my MSc thesis on video game pathfinding and I guess it’s a little weird for someone who spent the last year focusing on game AI and pathfinding to not actually spend much time blogging about it. I figured that I spent the time today and write a short post on optimizing the A* algorithm. The A* algorithm pretty much sums up video game pathfinding as a whole. Even advanced techniques like hierarchical pathfinding algorithm make use of A* in searching the various abstraction levels. So today I’m going to just discuss optimizing the algorithm, not a low level implementation but rather the some of the high level issues. I’m assuming that readers will have some degree of familiarity with the A* algorithm so I’m not going to waste time explaining it.
These slides cover the entire graphical pipeline from start to finish in detail. They are intended for a modern computer graphics course using the D3D10 API and HLSL. The amount of information contained within the slides is quite significant and to my knowledge there isn’t a single other place online with a more comprhensive coverage of computer graphics theory.
So whats the point of putting up these slides, well they are catering for two types of people:
Lecturers – if you wish to modernize your undergraduate computer graphics course or are tasked with presenting such course, these slides are a great starting point. Hell, if you want just rip them off completely. 😉
Hobbyist Graphics Programmers – if you want to learn more about how computer graphics are programmed, GPU architectures or the basics of texturing and lighting.
Anyways, I hope you find the slide useful. This is my last semester as a computer graphics lecturer nd so I figured that there is no point letting all my work go to waste when someone can still get some sort of benefit from them.
A lot of guys have asked me for advice on developing and debugging shader programs. Well, it’s a tricky topic to deal with. Tto be able to fully debug shader programs you will need either a shader IDE like FXComposer or a GPU debugging tool like Nvidia Nsight. These are both complex tools and beyond the scope of a quick tutorial but what I can do if provide you a quick guide to aid you in writing shaders directly within Visual Studio. You will not be able to perform any sort of in-depth debugging, but it will help you deal with silly syntax errors. The first thing need is NShader. NShader is a shader syntax highlighting plugin for visual studio and helps with clarity when editing and writing shader programs.
The second thing is to create a custom build step within Visual Studio for your shader programs. This custom build step will use the MS shader compiler to compile your shader programs and notify you of any errors as well as tell you on which lines the errors can be found. To do this, we first select our shader file and right-click then select properties (see figure 1 below).
Doing so will bring up the properties windows, the first step is to ensure that the configuration drop down is set to “all configurations”. The select Item Type and choose “Custom Build Tool” from the drop down (see figure 2).
Click Apply, this will then show the custom build menu tab on the left hand side. Select the tab and you be presented with the following dialog window:
Under the general heading, set the command line value to the following:
This will mean that every time the shader file is modified and the solution is compiled, the shader file will be compiled using the microsoft FX compiler (FXC). The /T flag specifies the type of shader file being compile (i.e. the HLSL version). the /Fo flag refers to the compiled output file and the %(FullPath) macro refers to the full path of the current shader file.
Also set the Custom Build Tool outputs to: $(filename).fxo , this is the same as specified in the FXC commandline. Click OK, and you are done.
The results of the this process is shown below, all HLSL errors will pop up in the Visual Studio Error Dialog, double clicking on the error will take you to the line of code that caused the error.
I’ve wasted a ton of time attempting to find silly syntax errors when developing shader programs, and this little custom build step has been a great help. I hope it helps you in some way as well…
Attending the GDC has been a huge dream of mine for the last few years, as you can see from the banner on the right hand side, financial restrictions have prevented me from attending in the past. In addition to attending the conference, I get to be introduced to various industry VIPs and shown around at the conference by seasoned industry professionals. This is the single biggest opportunity I’ve had to get into the game industry and I am sooo excited!!!
The GDC scholarship provides me with a all access pass to the GDC, so I can attend the talks as well as the expo and career seminars. The “Eric Dybsand” scholarship is an AI specific scholarship which afford me the chance to network and meet a lot of game AI programmers and an opportunity to attend the AI game programmers guild dinner! I’m crazy excited about being able to attend the AI summit especially since the list of speakers is practically the bibliography of my thesis, and as weird as it sounds these guys are like rockstars to me. I’m quite intimidated by the thought of actually meeting them in person. I really hope that I dont make a fool out of myself haha…
I’d just like to thank Neil Kirby from the IGDA foundation as well as Gordan Bellemy and Jack Bodgan from the IGDA for giving me this chance! I really really appreciate it!!!
So whats happening at the GDC this year:
The AI summit – 2 days of discussions regarding the key issues in game AI
25 Post-mortems on classic games by the developers (games include Pac-Man, Prince of Persia, Bejeweled, Populous, Doom, Pitfall, Maniac Mansion and more)
A game design talk by Cliff Bleszinski of Gear of War Fame
Battlefield 3 Unveil (OMG!!!)
Keynote address by the president of Nintendo – Satoru Iwata!!!
and sooo much more!!
I really cant wait!!!! This has made my year!!!!
PS. I am responsible for all my accomodation and food expenses so if anyone feels like they wanna help me out by donating please feel free to do so.
Currently the total for donations I’ve received over the last ~3 years is $1…
This tutorial is going to cover the basics of using the geometry shader stage present in DX10+. The geometry stage is extremely useful for rendering sprites, billboards and particles systems. This is the first part of a three part series which will cover geometry shaders, billboards and particles systems.
The Geometry Shader
The geometry shader stage was introduced in DX10 and people initially assumed that it would be useful for tessellation purpose (which is true) but it’s more useful for use with particles systems and sprite rendering. The geometry stage sits between the vertex and pixel shader stages and its primary use is creating new primitives from existing ones.
Just to recap, vertices are sent to the vertex shader within a vertex buffer that is stored on the GPU. A draw call issued to the API, sends a vertex buffer down the pipeline. Each vertex first enters the vertex shader where it is transformed as necessary, and its vertex data is modified (if necessary). Once vertices have been processed and outputted by the vertex shader, they get combined into primitives during the primitive setup stage of the API. The type of primitive created from the vertices sent through the vertex buffer depends on the primitive topology set (points, lines and triangles). Normally, once a primitive is constructed, it moves on to the screen mapping and fragment generation (convert triangle to pixels) stages before reaching the pixel shader stage and finally being drawn to the screen. Continue reading “DirectX10 Tutorial 9: The Geometry Shader”→
I recently played through Fallout: New Vegas and couldn’t help but feel that while the whole weapon modification system was a nice addition, it was a pointless one. I, as much as anyone, love some good gun porn and being able to modify my weapon is a welcome addition to any game but in fallout:new vegas there really wasnt any reason to bother with it.
So what did I find so wrong with the weapon modification system in new vegas? Well two things, the first being that unique weapons exist in the game world. These unique weapons are far superior to their fully upgraded standard counterparts which makes you wonder why should I bother with the upgrades? You’ll spent a ton of cash buying the upgrades just to end up with an inferior weapon. Honestly, if designers want unique weapons, I think they need to either remove the entire modification system (and offer more unique weapons) or make the unique weapons upgradeable as well. Hell, make unique weapons unique by adding smaller perks like offering increased criticals or accuracy due to improved internals or improved reliability or something along those lines. That way the the player still has the option of modifying the unique weapons as well and not lose any of the unique features. Basically what you’d be doing is offering the player an improved base platform for the weapon modifications.
Introduction to Game Development is a book in the vein of the Game Programming Gems series, it consists of a collection of articles written by game industry veterans (Steve Rabin, Noel Llopis, Eric Lengyel, etc.) with the aim of providing a solid overall introduction to the game development industry from all its various aspects, be they engineering, art or business based. Calling this a book is a bit misleading, it is more of a tome, this hardcover 1000 page monster is extremely detailed and comprehensive for what you would expect just looking at the cover.
This tutorial will deal with the basic scene lighting. It will cover the basic Phong and Blinn-Phong reflection models and the per-vertex (Gouraud) and per-pixel shading models (Phong). The Blinn-Phong reflection model is used in the openGL fixed-function pipeline (and as far as I know also used in DX9 but I’m not 100% sure). Modern games don’t really used these shading models any more as they are very expensive especially when there are numerous objects and light sources in a scene and much more efficient techniques such as deferred shading are pretty much the industry standard at the moment in regards to scene lighting and shadowing. Even though the shading models may have changed and aren’t really all that relevant, the reflection models explained here are still in use. Continue reading “DirectX10 Tutorial 8: Lighting Theory and HLSL”→
Video game optimization by Eric Preisz and Ben Garney is a book that is focused on highlighting and addressing performance concerns found in modern video games. This is probably the best code optimization book that I have ever read. It is also the only book on the market that covers the entire game development programming pipeline from start to finish and is the only book I know of with a heavy focus on GPU and Shader optimization. In brief this this book fills an important gap in any game dev’s library and is an absolute gem. Continue reading “Video Game Optimization Review”→