• 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

215 Neutral

About Drakonite

  • Rank
  1. By far the most commonly used IDE is Visual Studio. This is true for both game development and software development in general. Some platforms will necessitate using other IDEs. For example, iPhone development requires using XCode, Android developers primarily use Eclipse, Wii development is done in Codewarrior, developing for Linux systems might mean Code::Blocks or KDevelop. You should try to be comfortable using a range of IDEs, but Visual Studio is the most commonly used IDE in commercial development by far, and it is the one you really need to know how to use efficiently.
  2. IIRC the only event you won't see is a mouse move event when there is no button pressed. Otherwise all of the events should work the same as a normal mouse. It sounds like SDL may not be handling something correctly. I'd recommend adding code that logs every mouse event when they are received (with a timestamp) and see what events are occurring. Windows should be sending X/Y coords with the mouse down event, but it is entirely possible SDL (or maybe just your code) is ignoring them and using a previous value from a mouse move, which may not be getting updated until after the mouse down event.
  3. Sorry, without having the project in front of me I don't have any major ideas. The next things I'd check are if those bits of code are actually being compiled/called, and then whether anything conflicts with them. At a quick look it appears you are using DXUT, and it may be calling some of the crt debug stuff itself.
  4. If you open your project properties, go to C/C++, and then Code Generation, this is the option Runtime Library. IIRC leak tracking only works with the debug versions. Default project settings use a debug version for debug builds and release version for release builds, but it can be changed -- and I think requires changing to link certain external libraries that do not include debug versions.
  5. Are you sure you are linking against the debug version of the CRT? Are you sure you are doing a debug build and that _DEBUG is defined? Are you running inside of Visual Studio or launching the application directly?
  6. Spec'ing parts can be intimidating at first, but there are some good guidelines I follow that work well and make things much easier. Your CPU choice is fine. My rule for CPUs is to get something with a lot of cores (currently that means quad core, next summer it'll be all about 6 cores) with a good price/performance ratio. For both CPUs and Graphics cards there is a point where they quickly transition from having a big performance gain per cost to having a huge cost for minimal performance increase. For both I recommend picking something just to the cheaper side of that transition. I think all the CPUs mentioned in this thread are about in that area -- the i7-920 is. Most people dump most of their money on CPU/GFX card and it is a waste. Your CPU is not going to be your bottleneck and there are a lot more important things to put money in to. Buy a nice motherboard. Don't cheap out. A year from now you can buy a better CPU or better graphics card for your PC, but only if you have a good enough motherboard, and you can't so easily swap out the motherboard. Make sure to buy RAM that supports at least as high of speed as your CPU/Mobo combo supports for RAM. Buy a decent brand; it doesn't need to be a super high end enthusiast brand, but a major bottleneck is going to be RAM. I highly recommend buying enough to max out your motherboard and all at once of the same brand to make sure they are identical timings. You can't buy enough RAM; I currently run 8GB and it's starting to feel claustrophobic. As for the parts to focus on most, they aren't even in your list. Here is what I recommend worrying about most: A good monitor (or set of monitors). Try to buy something that has an IPS panel, or at least a VA panel. TN Film is cheap (and very common) and has a poor picture. I run dual 24" LCDs, both of which use IPS panels, and I will never buy a cheaper monitor again. A decent desk. A good chair (you're going to be sitting in it a lot right?). A good keyboard and a good mouse. Get a keyboard that works well and is comfortable to type on for long periods of time. Your mouse should be responsive and comfortable. You are going to spend far more time using the keyboard and mouse than you are going to be stressing the CPU.
  7. The blocks in your memory pool are contiguous and thus offset by the block size; therefore you can't guarantee alignment greater than your block size; more precisely, the most coarse alignment you can guarantee is the largest power of 2 that will evenly divide your block size (assuming your original buffer is aligned by that amount as well). In a general case, your memory pools should be created such that the block size is a multiple of the alignment required. Quite often memory pools are created with power of 2 block sizes, partially for alignment reasons, and non-power of 2 allocations are fulfilled with the next largest memory pool. For instance with 8, 16, 32, and 64 byte memory pools, a 12 byte allocation would come from the 16 byte pool. If you have enough allocations to warrant having a separate 12 byte pool (or any other odd size) you can have the odd sized pools, but treat the size of an allocation request as the greater of the allocation size and allocation alignment. For example, a 12 byte allocation with standard alignment would still come from a 12 byte pool, but a 12 byte allocation with alignment of 16 bytes would come from a 16 byte pool. Obviously this also depends upon your buffers being aligned by the correct amount as well. Before you do too much work in any direction, you should evaluate how often you are making small allocations with large alignments. In the case of my latest project, small allocations with large alignments are so rare that having logic to handle them in my pooled allocator is more expensive than having them handled by my non-pooled aligned allocation system.
  8. Yes. ...Oh sorry, did you need a more verbose reply than that? :) Game Engine Architecture is the best book on the topic. It is exactly what you'll want for 1, and OGRE happens to be one of the examples Jason Gregory uses throughout the book. I highly recommend. Programming Game AI by Example is definitely worth the read. I haven't read the Art of Multiprocessor Programming yet, but recently picked it up after a lot of research pointing it out as the best book on the topic. In other words... Yes. Go get them, read them, learn!
  9. The Shure SM58 is a great microphone and at $100 it is easily worth every penny. You'll find at least one in every decent studio. I know a few musicians that will only perform or record with a 58. You're audio interface is probably going to be the weak link for quality. The audio controllers that are built in to motherboards are horrible. You can get a decent quality external audio interface with built in preamp for $125 - $150 (I can't name a specific model off the top of my head, but I can find a link if you want one). Any less and the quality probably isn't worth it. You should expect to pay as much as $20 - $25 for a shielded mic cable. By using a good shielded cable and an external audio interface, you should be able to move far enough away to avoid the interference hum from your computer, and with some careful setup a lot of the fan noise as well. $250 - $275 may seem like a lot, but for audio equipment it is about the lowest you can expect for a decent quality basic recording setup; and for as long as you do audio work you'll have a good use for all of the equipment. If you're willing to go a bit higher to $300, you may want to consider getting a portable recorder like the Zoom H4n instead. I use one of these for person recording, and I've worked on commercial games that recorded voice overs using an H4n. The quality of the better portable recorders is amazing these days. The main benefit of a portable recorder is the ability to take it to a small room with good acoustics and no sources of background noise for a very clean recording. As for free audio software, you are going to want Audacity.
  10. In general, you really want to have both a debug and release build of the library and link to the correct one. Mixing crt libraries is not a good thing. However... It's been a while since I've dealt with this, but IIRC you can link your library with /MT (multi-threaded static) and your debug executable with /MTd (debug multi-threaded static) and work correctly as long as you are careful to never mix the two memory environments. For example, you cannot allocate inside the library and have the main executable free it. This may not be supported in later versions of Visual Studio, and it's never been recommended, however IIRC "it works". But really... you should compile both a release and debug version of your library. You'll save yourself tons of headaches and chances are you'll be wanting some extra debug info from debug builds anyways. If you are worried about the performance differences... Don't. Your debug builds are going to be slower either way, and the debug info from the libraries will be crucial to fixing many bugs. If it gets to be that much of a problem, you can always enable optimization for the debug build of your library.
  11. If _CrtDumpMemoryLeaks() is not reporting any memory blocks, are you sure you are building with the proper debug options to enable memory tracking? _CrtDumpMemoryLeaks() does not function in release builds. If you are getting no output from _CrtDumpMemoryLeaks() then something is odd... It's definition of a leak is simply an allocation that hasn't been freed yet, so ANY allocations you have made should be dumped, even if they haven't technically leaked yet. Also, are you sure there are no debugging features enabled that will cause the process to use more memory over time for crt debug memory blocks? Memory information shown with tools like Process Explorer are extremely coarse and inaccurate in some cases, particularly when using the debug crt. If you verify you are actually leaking memory and not just seeing a debugging anomaly, as well as verifying _CrtDumpMemoryLeaks() is functioning correctly, about your only option will be to identify which libraries could be leaking without your catching it and then selectively disable calls to each until the offending library is found.
  12. Shotguns are good for the quick kills when you need to defend yourself against a larger group, and are also quite effective as intimidation versus other non-zombie survivors. Some people might opt for a rifle or automatic weapon, however at the critical close to medium range a shotgun should deliver more stopping power. Shotguns are also fairly common due to the prevalence of small game hunting, so finding additional ammo is far easier than for more restricted weapons, such as an AR15. A melee weapon is also a necessity to conserve ammo however. Blunt objects are not very effective compared to cutting weapons; it is much easier to remove a head with a sharp object. Distance is also a key factor, making small bladed weapons such as a dagger a bad idea. Small weapons such a dagger, switch blade, or even larger but light weapons such as a foil lack the stopping power to make them effective. Most larger swords such as a broadsword, katana, long sword, etc, require training to be effective. A machete on the other hand, has decent reach, enough heft for stopping power, and is easy enough to use without real training, making it a very effective weapon. As great as big weapons such as a gatling gun, flame thrower, and various explosives may be for a short term defense (or offensive), a shotgun and machete as fallback weapons is a must. The ease and availability of the makeshift molotov cocktail makes them invaluable as well, just take care to not harm yourself with them.
  13. You'll have to give more info as to what your errors are. IIRC, the code generation option you are mentioning has 4 different settings (dependent upon version of VS I believe), and the trick is to be sure everything is built with the same setting.
  14. I highly recommend Game Engine Architecture by Jason Gregory. IMO it is by far the best book available on the topic and should probably be required reading for anyone learning to work on non-trivial game engines.
  15. With that type of design, you could use a semaphore for condition. When you add something to resource_queue you would increment the semaphore (usually called post or release, depending on the semaphore implementation) once for each item added, the loading thread would then block until at least one resource was waiting, and process one at a time. void loadingThreadMain() { while (true) { // wait until alerted condition.wait(); // Wait until we can remove 1 from semaphore count // lock, and copy lock_resource_queue(); resource = resource_queue.pop(); unlock_resource_queue(); load(resource); } } // and in the main thread: void loadResource() { // lock/add the resource lock_resource_queue(); resource_queue.push( resource ); unlock_resource_queue(); // notify the other thread condition.post(); // Add 1 to the semaphore count } The loading thread is processing resources serially, so you only pop one at a time and don't need a temp_queue. This also makes counting on the semaphore simpler and could let you have multiple loading threads processing the queue simultaneously.