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

MadKeithV

Moderators
  • Content count

    3331
  • Joined

  • Last visited

Community Reputation

992 Good

About MadKeithV

  • Rank
    Moderator

Personal Information

  • Location
    Northampton, UK
  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Programming

Recent Profile Visitors

5118 profile views
  1. Over the years I've become a lot more tolerant of different coding styles, I've changed my own style several times, and I've been involved in defining code styles a number of times. Currently, the client I'm working for has automatic code formatting inside the IDE for every save (something based on CLang-format), which I find really nice because there are no more discussions on style, it just happens.   In the past, where there's been contention, the decision process has been quite simple: Is there a rational argument against the style being introduced?  If I can't come up with a convincing one very quickly, then I dismiss my own reservations and just adhere to the new style. Is the change important enough to warrant me spending additional time building up a data-supported argument?  Often when balancing the cost of me doing so against the aggravation of having to follow the new style, the new style still wins out. So there's a rational argument and I care about it enough to dig deeper: I write down the argument in technical terms, with supporting data where possible.  I present this argument to the team responsible for the coding style.  They make the decision, and I abide by it. It is often a case of "pick your battles" - do you really want to waste time and energy arguing code style, or are there more important things to do?   Finally, in my 20-odd years as a developer (damn, I'm getting old) I don't recall any truly insane styles in any project or place of work.  If a bunch of rational developers work out a decent coding style, I think everyone should be able to "get on with it".
  2. Quote:Original post by kal_jez Just as an aside I read some papers suggesting that compressed audio like mp3 can actually be more damaging to hearing as the sound can peak higher than perceived in certain frequencies due to the compression process. File size compression (as in the mp3 format) is something completely different from dynamic range compression (as done with a compressor unit). Which one are you talking about?
  3. Quote:Original post by Ravyne Ah, but I didn't say that C++ was inferior across the board. What I said specifically was that C++'s implimentation of certain OOP and OOP-like features are in many cases generally inferior to those same features as implemented in a "pure" OOP language. Yes, this implies that OOP features are best implemented by pure OOP languages, but that stands to reason, doesn't it? Cool - this is an interesting topic. I am not sure I agree that C++ is even inferior in the area of OOP, but I would really like to discuss it. What areas of OOP do you feel are done better by specific, pure OOP languages? The first big question is how do you define OOP? Is the core of OOP polymorphism? Is it encapsulation of functionality? Is it both and more? (All of the above! ;-) ) Some potential arguments that C++ might be inferior to pure OOP languages: - C++ doesn't have a true "interface" concept. You can of course create a class with no members and only pure virtual functions, or you can go halfway and have some pure virtual functions, some not pure, some implementation and some members, and get the best of all worlds! </devils_advocate>. Is there any specific circumstance where you truly need a pure interface? - C++ doesn't have a base CObject class from which everything is derived. Well, you could do this in your own frameworks and programs, and personally I don't really see the value in it. - C++ encapsulation is easily broken. This one is absolutely true. A bit of const-casting, some pointer trickery, there are a lot of ways to get access to internals in C++. You don't have to hack your way around it, but the fact that it's possible does weaken certain concepts and it can lead to "broken" frameworks where hacks have destroyed the intended design. Any more ideas?
  4. Quote:Original post by Ravyne The thing is that C++ is not an OOP language. C++ is a multi-paradigm language which supports some OOP or OOP-like features in ways which are generally inferior to the ways in which they are implemented in first-class OOP languages. You have to be careful with value-statements like this - calling C++ "inferior" to what you consider first-class OOP languages. OOP is not a silver bullet, and "pure OOP" only limits language expressiveness for no good reason. What would you consider a first-class OOP language? Java and C# "pepper classes with static methods because you don't have free functions"? I'd hope not. You know what they say - if all you have is a hammer, everything looks like a nail.
  5. Quote:Original post by nlbs Quote:Why the need to store pointers for basic types like int, floats, etc?Thats by applications requirments It seems highly unlikely that this is exactly what your requirements specify. Are you trying to create a container for an "any" type? In other words, a heterogeneous container that can contain any kind of element, through storing void pointers? If so, take a look at boost::any to wrap around objects you want to store. Quote:Original post by nlbs Quote:I would at least remove the += operator that takes a reference, since you are actually storing the pointer. I've already said that one of my target is syntactic ease. so can you fulfill the application requirments without using const X& or X& arguments on += operator overload. As several posters have said before me, (ab)using operator+= for adding things to a container class is not "syntactic ease". There are various accepted ways of adding something to a vector, list or other container, such as push_back or insert. The C++ standard library defines those quite clearly and the concepts will be known to most of your users. Doing something else is going to accomplish nothing, besides confusing your users. The only halfway good reason I can see to use operator overloading is for chaining (ex = a + b + c;// -> ex contains a, b, c) , and in that case you will need to implement operator+ too. I'll remark that your users might now expect that operator= will act as follows: Example ex; ex += 1; ex += 2; // ex now contains 1, 2 ex = 3; // ex now contains only 3 After all, that's not an illogical conclusion from the way that you defined operator+= (and probably operator+). You should follow the advice of the other posters in this thread: 1. Define whether your container will have ownership of the objects contained, or not. And stick to it. 2. Stop using operator+= for adding elements. It really is going to cause more trouble than it's worth. 3. Carefully review your requirements and check if boost::any might solve them.
  6. Quote:Original post by dae_coderonin My question here is this: Are stl vectors really that slow, is it just the Debug setting (I'm working with MS VS2003) You should NEVER base ANY performance judgements on the debug build of a project. There are many, many things that could be going on behind the scenes in a debug build that slow things down, such as checked allocations and iterations, additional logging, and also some optimizations that more advanced classes may rely on will not happen in debug. I have some code around that takes a minute to complete in Release mode, and four hours in Debug. Try it in Release mode first and if you still have a problem it's worth looking into.
  7. Also, your iteration overruns the array bounds - the last valid array index is 9, not 10. i <= MAXSIZE should be i < MAXSIZE.
  8. Quote:Original post by Hodgman Thanks for the reg-ex advice. I'm still torn as to which approach to take. The reg-ex isn't a simple win because the old/existing code still needs to be maintained as well. In other words, if I do a find replace then I will end up with two copies of that code to maintain. It's not 100% clear to me why the change causes a branch. Do you mean that the same API is used for other code besides the code you are refactoring, or for code you cannot touch (or cannot rely on being available at certain client sites)? Are there already multiple branches of this code? Or are you afraid that you will affect the stability of the code with your refactoring? [Edited by - MadKeithV on October 24, 2008 5:05:49 AM]
  9. To me this seems a lot more like a job for a regexp find-and-replace in the user code. Introducing that adapter might make your job easier, but I pity the person that has to do the next bit of maintenance (and consider that the next person may be you!). Just try a regexp find-and-replace in the old API code - the convoluted syntax of the old calls make me think it would be highly unlikely to get any false hits.
  10. Quote:Original post by jpetrie I've been using UnitTest++ recently. I'm a UnitTest++ -user too. At my company we evaluated a number of unit test suites and this one had the best combination of features and ease-of-use at that time. Some niggles: the lack of unicode support, as well as the difficulty in selecting specific tests to run. I also liked CxxTest which uses Python (or Perl) to pre-process the test files. Easy-to-use, but with a lot of setup requirements that made it less suitable to the development environment here.
  11. Quote:Original post by Modena360 I've played around with including the #define _HAS_ITERATOR_DEBUGGING 0 #define _SECURE_SCL 0 lines and when enabled these actually make it crash earlier, on the first std::vector it encounters. My best guess would be that it's still one of these definitions (probably _SECURE_SCL). How complex is your project? If you are linking multiple libs or DLLs and one of them is compiled with a different definition of any of these from the others you'll get issues like this.
  12. GIMP on Win32 did not support Wacom tablets' pressure sensitivity last time I tried it. Without it the GIMP is not a serious contender for a 2D art package.
  13. I didn't mean to imply that the SM57 or SM58 were condensers. I was trying to give an example of preferring the dynamic SM58 to an LDC in particular circumstances. A dynamic microphone can sometimes (often) be a good choice and condenser mics aren't "better" by default. But one of the prerequisites is that you already have a nice mic preamp. Also note that phantom power is not the same as a mic pre, you can have one without the other. Several cheap mixing desks of old did not have phantom power for their channel preamps, and I have a separate phantom power box somewhere in a pile of old stuff too. However, I've been browsing around and it seems to be the Samson USB mic should work fine (C01u?). Kylotan - did you install "SoftPre" (http://www.samsontech.com/main/misc.cfm?pageID=45) to get the additional driver support? The FAQ mentions using the MME32 driver for it.
  14. LDCs *are* usually more desirable for vocals because of the extended upper range and the bass roll-off. SDCs are better for recording bass. Both are still very much multi-purpose and much depends on the vocalist's sound and the sonic quality of the mic preamp. I use an SM-58 dynamic for my own vocals even though I have a Haipheng Neuman TLM193 rip-off. Important to consider is that you'll need a mixer or mic pre with phantom power to be able to use a condenser microphone. If you're going to spend any serious amount of money, spend it on a good mic pre first - get the cheapest condenser mic you can find. A good pre can make even a cheap mic sing (like the SM58 and 57), and a bad pre will sound bad with even the best mics. Suggestions: Get the Samson or Behringer LDC to save some money, and then try to find the best mic pre you can afford. Secondhand is good - I got my TL Audio PA-1 that way - plenty of stuff on the market. Alternatively, try the sE Electronics USB2200A. Also a USB microphone, but targeted more to pro audio rather than podcast audiences.
  15. Quick guess: you could try creating templates with an integer non-type parameter, specializing them for each valid case, and giving a compile-time error in the default case.