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

Red Ant

  • Content count

  • Joined

  • Last visited

Community Reputation

471 Neutral

About Red Ant

  • Rank
    Advanced Member

Personal Information

  • Location
  1. I'm sorry, but if you're going to go to the trouble of writing custom allocators why wouldn't you at least make them STL-compliant so you can actually use them with the various STL containers??
  2. Hi, I have a C++ module consisting of a bunch of functions containing quite complicated floating point math computations that get run over and over again in a tight loop. Profiling has shown that the program spends a substantial amount of CPU time running these floating point computations. Floating point multiplications and std::sin() / cos() / tan(), etc. seem to be a lot more expensive than I thought. We're already compiling with -xO4 (which is the second highest optimization level on our compiler). In the past few days I've been trying to optimize these computations as much as I can. I've actually had some success as some of our simulation tests scenarios have gone down from roughly 60 seconds to about 50 seconds. Not an astronomical improvement but nothing to be sneezed at either. The way I've been going about this is to mainly break up complex computations that reuse the same expression over and over. So instead of evaluating the same expression many times over, I just evaluate it once and then feed the result into the computations that depended on the original expression. The downside to this is that readability of the calculations has suffered badly. Also, it's pretty tenuous work and I have to take great care not to accidentally mess up any of the rather complicated calculations. So I was wondering if there are any fancy mechanisms or tools that can be fed a series of complicated math expressions and that will try to automatically identify and remove any redundant calculations to optimize the computations as much as possible. Does such a thing exist or am I stuck with handcrafted optimizations?
  3. [quote name='Ripiz' timestamp='1335692202' post='4935784'] C++ compiler tends to destroy loop as everything is constant (volatile fixes that) [/quote] I'm sorry, but what do you mean by that?
  4. Oops, sorry. Shame on me for not reading the whole thread before posting. [img]http://public.gamedev.net//public/style_emoticons/default/sleep.png[/img]
  5. [quote name='AlanSmithee' timestamp='1335129380' post='4933871'] And the debug call stack: #0 00424842 SearchCell::get_f([color=#ff0000]this=0x0[/color]) (C:/Projects/Individuellt Mjukvaruutvecklingsprojekt/Game/DungeonsOfZiro/files/SearchCell.h:33) [/quote] Well, there's your problem. You're invoking the get_f() method on a null pointer. EDIT: This means one of your operands in a call to [color=#ff0000]bool cell_cmp::operator()(const std::shared_ptr<SearchCell>& a, const std::shared_ptr<SearchCell>& b) const[/color] is an empty shared_ptr.
  6. [quote name='Ripiz' timestamp='1335301295' post='4934543'] Possibly it's an optimization causing object to be allocated on the local stack [...] [/quote] What optimization? Where else would it be "allocated" if not on the stack? Foo() creates a temporary. Of course it's on the stack.
  7. Yup, it's simply just UNDEFINED BEHAVIOR. May actually appear to work some of the time, or it may cause your computer to explode.
  8. Not possible, I'm afraid. To the compiler, typedefs don't really introduce new types. EDIT: You _could_ derive both WorldPoint and ScreenPoint from Point.
  9. [quote name='smile55' timestamp='1333006533' post='4926250'] Many times I define a class and soon I will feel the design is bad, making the problem more complex. Sometimes I define a lot interfaces today and change all my minds tomorrow and re-write them all.[/quote] That problem won't really go away if you switch to pure C, though, except that you obviously won't be writing any classes. Instead you'll write a set of functions operating on a certain type of data and then change your mind the next day and rewrite them all. [quote name='smile55' timestamp='1333006533' post='4926250'] So I want to know how does professional C programmer write their daily codes? For example, when a linked list is used to organize some data, will you directly operate the pointer to next node in the application's algorithm, or will make an abstraction to hide the details of linked list? [/quote] There are probably various third-party libraries available that provide somewhat generic data structures such as lists and so on. It's just that in C, "generic" usually means mucking around with void-Pointers and constantly casting to the type of data you're using the structure with.
  10. [quote name='Rickert' timestamp='1331894194' post='4922545']Among those are Paul Graham's and he series of articles on this site: [url="http://www.geocities.com/tablizer/oopbad.htm"]http://www.geocities...izer/oopbad.htm[/url] (I haven't read all, since I don't have much time). [/quote] Maybe instead of writing an article about why OOP kills baby seals, the guy should have read an article about web page design. Anyway, common sense says that a programmer who rejects OOP on principle is just as silly as one who won't consider using anything but OOP. There are problems that quite obviously benefit from the use of OOP while there are others that just as obviously benefit from the use of other paradigms. One doesn't have to waft through a dozen pages of diatribe to understand that.
  11. [quote name='Nyxenon' timestamp='1331852665' post='4922419'] Apparently the compiler was starting the compilation at "vector3.cpp" [...] [/quote] What do you mean, "it started the compilation at"? Each translation unit (i.e. each .cpp file) always is compiled separately. What you include in one translation unit has no effects whatsoever on any of the other translation units. So if you have two .cpp's that both use vector2 then they both need to include vector2.h.
  12. Either the code you showed us is not the code you're actually working with or there's ANOTHER vector2.h somewhere in your include paths that the compiler pulls in instead of the one you want. P.S. If you're using Visual Studio, you can configure the compiler to print out the path name of each included file during a compile run. That way you can see exactly what is getting included. (Configuration Properties -> C/C++ -> Advanced -> Show Includes) 2nd P.S. Under [b]Configuration Properties -> C/C++ -> Preprocessor -> Preprocess to a file[/b] you can even make the compiler generate a file showing you exactly what code is emitted by the preprocessor. Open that file and see if you can find the definition of your vector2 struct. If you can't then for some reason it's not getting included.
  13. On top of what's been said above, your copy constructor doesn't really "initialize" per se; it assigns. Instead of this [code] UsesA( const UsesA& other ) { mya = other.mya; } [/code] what you really want to do is this [code] UsesA( const UsesA& other ) : mya( other.mya ) {} [/code] When writing constructors, it's generally advisable to prefer initialization lists over assignment.
  14. [quote name='Nypyren' timestamp='1331691834' post='4921854'] At some point, your bad pointer may eventually be the cause of anything and everything the physical hardware is capable of (and anyone you're networked with.) The worst that could happen? Your program causes the LHC to create an transdimensional rift which annihilates the universe. [size=3][i]Don't cross the std::streams![/i][/size] [/quote] Hehe, yup. As soon as you get into embedded systems (where the OS might not protect you from your own stupidity in the way it does on a PC), a bad pointer could very well be the difference between a functioning machine and an accident involving human casualties.
  15. I don't think a static_cast is enough to do the trick. You will need a reinterpret_cast.