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

MichaBen

Members
  • Content count

    119
  • Joined

  • Last visited

Community Reputation

481 Neutral

About MichaBen

  • Rank
    Member
  1. If the input string is ASCII, you can easily expand the string using the methods given above. However if the input string is unicode, that won't work. In unicode a single character can consist of multiple code points which in turn can consist of multiple bytes. Typically you don't think in characters when encoding strings, but in code points. This is because unicode can combine characters from two code points, for example ' and e become é (although in this particular case there is a code point for é as well). This is also why you can never compare if two unicode strings are equal without normalizing them first. Unicode also has over a million code points (although not all are used yet), but a byte can only hold 256 and a 16-bit wchar only 65536. In order to be able to store all million code points, both UTF-8 and UTF-16 (although lots of people seem to forget this about the latter) encode code points in one or more pairs. For UTF-8 this means a single code point can take 1, 2, 3 or 4 bytes, for UTF-16 it's always 2 or 4. That means when converting, you first have to decode the code point, then encode it again, there is no direct convertion byte by byte possible.   You could do this yourself, it's not that hard and a good exercise to make a UTF-8 to UTF-16 converter. I would be useful if you start mixing the two to actually understand how it works, rather then to copy/paste a piece of code that may or may not work, or code that will later fail (the wstring constructor trick seems to fail horribly if your string is non-ascii). Or lookup boost, it has some conversion stuff in it as well.
  2. Visual Studio 2012 is very limited in C++11 support as well. The stable version of the compiler is lacking some major features like variadic templates, and the preview version is not production ready yet. I did use it for testing, but got several situations already where the compiler was simply to buggy to compile the code properly, and some features aren't implemented at all yet even in the preview version. Personally I managed to hit the limitations of Visual Studio pretty quickly when it comes to C++11 support, so I don't think it's worth the trouble getting VC2012 running on your macbook if your goal is to use C++11. And personally, I would go for C++11 as much as you can, I'm using it as much as I can right now since it really makes things easier. Right now I would go for GCC or Clang, which seem to have a lot better support for C++11 at the moment. I had some test code that to experiment with C++11 that didn't compile with the latest preview version of MSVC, but GCC and Clang both compiled it fine. But in either case, you should drop Windows XP as well.
  3. Then again, you can make the same example like this: if ((a || b) && (c || d) && (e || f)); {     DoSomething();     DoSomethingElse(); } And this will not even generate a compiler error, maybe a warning. Truth is I don't think a bracket style will prevent human errors in the code, as no matter where you place them, a single mistyped character can break them.   Personally I prefer to use indention over brackets to see the structure of a code, it's must faster to scan code by indention level then by looking for the tiny brackets. Also modern IDEs are more then capable of visualizing scopes for you, for example in QtCreator:
  4. C++ is complex and easy at the same time, mainly because it lets you choice how to do things. If you choice the safe and easy C++ path development can go fast and smooth, but if you take the wrong turn you might up on a path that leads to certain death with no way to recover other then going back and starting over again. This is probably the biggest pitfall for new C++ programmers, the language doesn't prevent you from making a wrong turn, it allows you to mix automatic memory management with manual memory management, for example the compiler won't prevent you from calling delete on a stack variable, it will just horribly crash when you run the program.   That doesn't mean it's a bad language for beginners though, that depends on how your skills are and how patient you are. If you are planning to learn programming by diving straight into it and hope to succeed using trial and error, you probably shouldn't start with C++. However if you are patient and can refrain yourself from using certain language features before you understand how they work, it shouldn't be a problem. So called 'easy' language are no guarantee for success either, for example I started out with basic, which was considered easy, but the first attempts didn't turn out very well. And managed languages as Java certainly have their pitfalls as well, garbage collectors are unpredictable and can have some nasty side effects that are not beginner friendly.   Personally I would stay away from garbage collected languages and stick with predictable memory management systems, but that has a safe mode (preferable no undefined behaviour in debug mode, either safe and defined or debug assertion). Specially when you are learning, I rather have a debugger that says that you are doing it wrong, then a magic software component running in a second thread that attempts to silently fix your mistakes (specially as this sometimes fixes it the wrong way and you have no clue what happened). Question is, is there such a language, that is also suitable for making games...
  5.     I wonder with this statement if you even used other IDEs. Or you must mean that other IDE don't come close because they are already far ahead. But when it comes to code editing, Visual Studio is probably the least innovative and modern IDE you can think of. The main strong point of VS is the debugger, but for writing code it's horribly unproductive to work with VS (at least with the basic product without plugins). Some things I'm missing from Visual Studio that for example QtCreator has natively: - Smart indention (copy/paste a piece of code into a scope with different indention and it automatically adds or remove tabs for you, rather then manually select all lines and press tab several times). - Pointer recognition (press . after a variable that is a pointer and it is replaced with -> automatically). - Automatic closing quotes/brackets for literals/function calls/scopes/includes. - Hotswap between cpp/header (VS only has this for cpp>header using context menu). - Hotswap between declaration/implementation (VS only has separate go to definition/declaration that is still slow and buggy with large projects). - Syntax highlighting is still limited in VS without plugins, although it's catching up with 2012. Basically, when it comes to writing code, I find using plain old Visual Studio without third party plugins bad for your productivity.
  6. If you love perspective so much, you should read further then this post, for example at the extremely biased posts by phantom, where my post was mainly made in response of. Calling things 'pants-on-head retarded' is typical behaviour of trolling fanboys. Maybe I should have been more clear in stating who I responded to, but it's odd how trolling fanboys are allowed to post garbage, but it's not allowed to post a response to it in the same manner.   About the biased information being posted here that OpenGL is bad, DirectX has many of the same (or similar) problems that OpenGL gets blamed here. Sure, there are problems with vendor implementations of OpenGL. But the exact same thing is true for DirectX. Only a few weeks ago, we had problems with completely random crashes with AMD cards with a HLSL shader that worked fine on NVIDIA cards. And this is not the first time I have seen differences in HLSL shaders between NVIDIA and AMD drivers. This is just something you have to deal with, no matter which API you are using. And while I admit that the bind-to-edit model can be a pain at times, and I would gladly accept a different solution, it's hardly fair to badmouth the whole API for that. First of all in a well designed engine you will hardly ever suffer problems from this, and secondly because also with DirectX it's a piece of cake to mess up something because you call functions in the wrong order. Or what about the DirectX functions that return you a pointer with increased reference count you have to remember to release? How many times have you seen that going wrong with inexperienced DX programmers, and even with experienced programmers? Or the D3DXVECTOR3 structure that is completely messed up with an evil implicit conversion operator to float pointer (and yes, I have actually seen that causing bugs in an engine where implicit conversion to float * was used by the compiler when resolving the proper function overload).   In the end, I don't think there is a 'better' in terms of easier, or less likely to shoot yourself in the foot with. Personally I did find OpenGL easier, and of course the cross-platformness is a pro, not just Windows-Mac-Linux but OpenGL also supports more Windows versions then Direct3D does. Of course, if your goal is to make a game, then you have a third choice which is use neither and find a engine to use, which is even easier.
  7.   Oh please, grow up kid. I have been using both Direct3D and OpenGL for ages. Maybe if you would actually *read* my post, you would see that I didn't advice the usage of OpenGL at all, only state the truth about Direct3D and try to safe people from learning C++ the wrong way by jumping into it to soon. But of course, I could have guessed some pathetic troll would come in...
  8. The fanboys here will probably never admit it, but D3D is a horrible API to work with for beginner programmers. Basically it uses extremely outdated pre-standard C++. You will find yourself using pointers and pointer pointers all over the place rather then references, it uses global functions rather then constructors/destructors, and COM is just a nightmare. Unless you mastered object oriented programming first, I would strongly recommand against jumping into Direct3D, as it will teach you lots of bad practices in modern C++. For the same reason you should avoid using WIN32 API like the plague when you are new to programming, and once you mastered C++ you probably still want to avoid it, but then at least you can tell it's bad, rather then get confused of what is proper modern C++ and what is pure evilness.
  9. Seems like you are trying to make your copy constructor into a move constructor. Although this will probably work (as far as I know, the compiler does recognize this as the copy constructor, and replaces the default copy constructor with const ref with your non-const ref one, trying to use it with a const object results in a compiler error), it's probably best to use a real move constructor this: Class( const Class &other ); // Copy constructor, makes copies of the memory in a newly allocated location, leaves other intact. Class( Class &&other ); // Move constructor: take the memory from other to this, and leave other in a state where the destructor won't free the memory you took anymore.   But I expect that indeed the problem lies in the copy constructor that calls assignment operator. Your assignment operator calls swap(m_that, other.m_that), but at that point m_that is uninitialized. I don't know what type it is, but if it's a pointer, you are swapping an uninitialized pointer with other, which will very likely result in undefined behavior, and undefined behavior is the biggest cause of why something crashes with certain compiler options and not with other options.
  10. I would personally look into Qt, it's a very powerful GUI toolkit and I have yet to see something more powerful. For simple applications like this you don't even need to use a programming language at all, I never tried it myself yet but Qt has tools to create interactive GUIs with a simple scripting language and visual editors, no need for actual coding is needed unless you want to have some more advanced stuff.
  11. I have to agree that installing Windows is not something for beginners though. Recently I installed Windows 7 three times on two different machines. So that is twice on one PC on the same day, as after installing some weird error came up that even the helpdesk didn't know how to fix, so the advice was to just wipe the harddrive and install again. On the second machine installing went fine, until installing some additional software (ironically with Microsofts own installer) failed because it had no access to write to C:\ProgramData\Microsoft\Windows\Start Menu. Right, Windows installer not having permission to add icons to the start menu, after a fresh install. Luckily there was a solution, involving either changing advanced user account control properties of a hidden folder (good luck for beginners) or entering a number of obscure command line commands (good luck for beginners). Installing Windows 8 luckily goes a lot faster, and except for the blue screen of death that showed every time you booted it up it worked perfectly. So in the end, out of four clean Windows installations, just one went correctly. And still some people claim Windows is easy....
  12.   If you are constantly juggling with deleting objects, then you are doing something seriously wrong, and it's hardly fair to blame the language for that. In a well designed C++ program, it's fairly obvious where something has to be deleted. However if you start returning pointers from functions and expect the caller to delete it at some point, or pass pointers as parameters to functions and expect that function to delete it for you, yes then you will be juggling with deletes for some time. But doing that kind of reckless coding will result in unmanageable code in every language. If you have to rely on a garbage collector because your code is such a mess that you have no idea when to delete a pointer, you are doing it very wrong. Also, C++ does allow you to use unique_ptr for that specific job. So again, it's not really fair to blame a language to be counter productive because you choice not to use some 'safer' version.
  13. I see people talking about programmer productivity a lot, but I really wonder if this is really noticeable. The typical comparison that people make to suggest this is comparing making a simple GUI application in [language X] compared to using Win32 in C++. Of course this increases productivity, but not because of [language X], but because of using a proper GUI library. Anything other then pure Win32 will increase productivity of GUI development, a C++ GUI toolkit like Qt probably achieves the same productivity boost. The language is probably a minor factor here, most of the productivity is determined by the libraries and/or engines you are using.   Some aspects that do make a difference in productivity are better error detection at compile- and runtime, this can decrease the time needed to debug nasty bugs. How big of a difference this would make I can't really tell, but in my experience the majority of the debugging time is spend into logic errors, which are very hard to detect by any automatic system and therefore will not be much different with another language. Type and memory safety would be a nice to have, for high performance applications it would be nice to have this optional so you can enable it only for debugging, that way you can still benefit from it to decrease debugging time. Garbage collector systems and shared pointers are not suitable for this however, as these systems do not support being disabled.   But the main problem with things like garbage collectors and shared pointers is the fact that they don't solve any problems, only symptoms. For example you have an NPC referencing another NPC as target, and this NPC is then deleted. With manual memory management it would crash because of a dangling pointer, with 'automatic' memory management it would not collect the object and therefore not delete the NPC, even though your intentions were to delete it. So in the end, you removed a crash, but kept the bug. A system with possibility to assert that no references are left when you try to delete the object would really increase productivity here, as it tells you where the problem it, rather the crashes sometime later (C++) or obscuring the symptoms of the bug (C#). Also a system like that can actually be disabled in final release mode, if there are worries about it's performance. With a slightly customized version of the C++ unique pointer you can achieve this, significantly decreasing debugging time of pointer errors, while keeping 100% performance since you can fully disable this in release mode.   I think the main problem with C++ are programmers who refuse to use modern and safer features, like in my office it's still a crime to use the word "exception", and you will be frowned upon for suggesting to use templates instead of macros. Once in a while I still see raw memory being allocated for a temporary array that is deleted again the same function, while std::vector would do the exact same thing in a safer way. In that case moving to a different language does increase productivity, but mostly because people are then forced to drop their old habits from the C era.
  14. Personally I'm using Qt, it is easy to hook up your own rendering system in it, and it's a very good GUI toolkit.
  15. Personally I don't mind using something else then C++ for game development, as long as the language has a decent support in terms of tools and libraries, and the language itself is decent enough. I wouldn't mind having a language that doesn't feature any undefined behaviour (everything is either defined or an error) and with pointer safety (dangling pointer protection and leak detection). However, the garbage collector system that several languages introduces is in my opinion not the way to go, as it's a counter-productive method to conceal the symptoms of pointer errors, rather then fix the problems itself. The technology behind garbage collectors is interesting, but it does not belong in a release version of an application, but as part of a debugger, to tell the developer when exactly you are leaking memory, and using a dangling pointer should trigger an assertion you can debug to fix the actual problem, rather then obscure the problem.