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

Pink Horror

Members
  • Content count

    400
  • Joined

  • Last visited

Community Reputation

2459 Excellent

About Pink Horror

  • Rank
    Member
  1. For me, using move semantics in the context of this is somewhat equivalent to using reserve on a collection class like vector. I just get some efficiency for a little bit of additional thinking/design overhead. So yes, whenever possible (in places where it can matter) I tend to move expensive temporaries (like string, vector, ...). However this mostly means that I adjusted my design. IE, where you would usually see something like this: Foo foo;std::string& string = foo.GetString();string = "Test";string.append("whatever"); Or something along those lines, I would instead do: std::string string = "Test";string.append("whatever");Foo foo(std::move(string)); I find the latter much cleaner, especially in non-fabriacted examples :D Obviously you could have done this before without the move-semantics, but it would have most likely invoked a copy operation for the content of the string. EDIT: i think i misread your question. Anybody who is actively using C++11 surely has at least a basic understanding of how and when to use move-semantics. Anyone else wouldn't have that knowledge, so its probably a matter of who you target.   I know this isn't important to the example, but I feel obligated to point out that a 12-character string isn't really a compelling use of std::move, considering the popularity of small string optimization.
  2.   That is the role.     You are not going to get an entry level job as a designer.  Game designer is a senior role, it is a person who is figuring out the core of a multi-million dollar project. You don't give multi-million dollar projects to entry level workers.   There were intern game designers at one company I used to work for. There's a lot of little stuff to design that the senior people don't want to have to do.
  3. I wonder what percentage of new C++ games are being made with exceptions and RTTI turned off.
  4. I just want to point out, if you are debugging a problem and a raw pointer is NULL, that doesn't mean the object has been destroyed or has gone out of scope. A pointer to something keeps its value until you overwrite it. It isn't going to change just because the object it's pointing to isn't valid any more. It'll keep pointing to the same memory address. So, if you're working on a problem and you see a NULL pointer, look for places in your code that modify the pointer itself, not the value it references.
  5. You're not transcending the boundaries of C++ and OOP. You're just achieving your goal of caching these numbers with the smallest, easiest edit possible. There's no balance here. There's no actual concern for legibility that I can see. You're modifying your code in the same way practically every modification is made to so-called OOP C++ programs out there - in whatever way lets the programmer move on to the next task and keep collecting paychecks. Please do not act like this is something special. You are not challenging conventional thinking. You are demonstrating it.
  6. First, how much faster did your program get because of this? That's how you measure performance gain, not cache hits. Second, no, not many veteran programmers I know appreciate functions that look like they should be pure functions, and unexpectedly read and write from static variables. These "creative" solutions are very annoying when you finally figure out what's causing the rare animation bug in a multi-threaded application. I hope no beginners copy this approach. If you want to make an optimization, hacks like this should be the last resort, ideally only made on a "release" version of your game, not on code you would continue to use in future products. You should be willing to refactor your code and actually change where the function calls are made, if the performance gain is meaningful.  
  7. How do you expect to compare a pair of iterators to only one iterator with just the == operator? I'm normally for using auto in cases like this, but if people cannot understand what's going on because of the lack of readable type information, I'm beginning to wonder whether it's made C++ worse.
  8. And of course, if it "has to be" written in C, you cannot write it in Checked C.
  9. Are you sure? When reading it through, it looked like ptr<T> was designed to NULL out when the original data was invalid. That is the functionality from std::weak_ptr<T> that would be very nice. C++ can't solve this issue because it itself is based upon potentially dangerous C libraries. As a library consumer, C++ (even Java and C#) seem better than C but remembering that underneath all their hoods, the same dangers can (and almost certainly do) still lurk, it removes all the fun ;). Plus these languages end up running more C than a C program due to their additional layers written in C so they are still not ideal. Checked C aims to remove these issues at a much lower level than possible by just bolting on another random language.   The paper says it is about bounds-checking. a weak_ptr has nothing to do with bounds checking. The introduction is entirely about bounds-checking. It mentions problems such as using already-deleted memory are beyond the scope of Checked C. C++ can at least partially solve the issue, because you can use templates to create the checked pointer classes. That's what the team who made this did as a prototype. Just building with Checked C instead of C gets you nothing. You have to use the new types. Converting one of those potentially dangerous libraries to Checked C means putting in the correct changes to use bounds-checking everywhere they would belong, and making no mistakes or oversights while doing so. As long as you're rewriting chunks of the library, why not rewrite them in C++? What's the difference? How does the library go from potentially dangerous to knowing it's safe? How do you know you did the conversion correctly? How do you know the library isn't dangerous because of something that wasn't covered, like memory allocation? If, for some reason, you have a code base that's in C, and you're willing to rewrite every part of it that uses pointers, and compiling it in C++ scares you and/or you're not willing to create the helper templates yourself, but compiling it in a new version of C from Microsoft is something you're willing to do, and you're having trouble with buffer overflows, and compile-time checks will help or run-time crashing is ok, than sure, Checked C might solve a problem for you.
  10. So, you're saying that Tangletail's game's DB performance will be similar to a 40TB database, and that one frame of a typical  video game happens in tens of nanoseconds?
  11. I don't know what database you're using, but on the servers I typically work with, the complete round-trip time of sending a simple, plain-text SQL query over the network to another server, processing it, and getting the result back often takes less than one millisecond. I'm sure a game could do it even faster with a local, in-memory database. And actually, I know that's true, because I've also worked on a game that did that.
  12. You can add integer ID's (and void* ID's!) to the C++ type system like this, in order to maintain type safety: struct PrimitiveBase {}; template<class T, class Name> struct PrimitiveType : PrimitiveBase { typedef T Type; PrimitiveType() : value() {} explicit PrimitiveType(T v) : value(v) {} operator const T&() const { return value; } operator T&() { return value; } private: T value; }; #define MAKE_PRIMITIVE_U64(name) struct tag_##name; typedef PrimitiveType<u64,tag_##name> name; #define MAKE_PRIMITIVE_U32(name) struct tag_##name; typedef PrimitiveType<u32,tag_##name> name; #define MAKE_PRIMITIVE_U16(name) struct tag_##name; typedef PrimitiveType<u16,tag_##name> name; #define MAKE_PRIMITIVE_S16(name) struct tag_##name; typedef PrimitiveType<s16,tag_##name> name; #define MAKE_PRIMITIVE_U8(name) struct tag_##name; typedef PrimitiveType<u8,tag_##name> name; #define MAKE_PRIMITIVE_S8(name) struct tag_##name; typedef PrimitiveType<s8,tag_##name> name; #define MAKE_PRIMITIVE_PTR(name) struct tag_##name; typedef tag_##name* name; MAKE_PRIMITIVE_U32( MyObjectId ); class Foo { MyObjectId Create(); void Release( MyObjectId ); }; What does PrimitiveBase do for you in this case?
  13. Is it bad if every time I see the whole IO "<<" overload I vomit in my mouth a little?   Vomit all you want. I just personally think that "vomit in my mouth a little" is extremely overused. I still manage to keep my stomach acid down when I read it.
  14. I think only around 2% of these types of questions asked on here actually post the code that's responsible for the problem. You've showed us where this thing is allocated. Great. Now show us where it is de-allocated. And I don't mean just in the CComPtr. Give us the whole call stack for how it'll get there. Where are those member variables stored? Where does that parent class live? When is it destructed? Can you put a breakpoint where that happens?