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

TDragon

Members
  • Content count

    913
  • Joined

  • Last visited

Community Reputation

679 Good

About TDragon

  • Rank
    Advanced Member
  1. [google] C4312. MSDN, the definitive reference for Microsoft's products, shows up in the second link.
  2. CorelDRAW X3? ZBrush? Ogre? POVRay? Acrylic canvas and paint? "Messing around with graphics" covers a wide range of topics. Are you interested in creating graphics (digitally, I assume), in displaying graphics (2D or 3D? Realtime or static?), or in writing graphics tools to help other people do the above? Please be more specific.
  3. Quote:Original post by Exilberliner I thought when I'm freeing the allocated memory every other pointer, pointing to the same place is set to 0 or is causing a programm-crash or something. Definitely not the case. As long as you're using C++'s built-in pointers, all you can count on after deleting the memory a pointer points to is that you shouldn't access it anymore. Quote: So my Question is: How can I make class Nr3 know that the targeted Object should have been deleted. If class Nr3 truly needs that kind of information, I recommend using Boost's weak_ptr. However, in this particular case (and in every case), you should consider carefully whether a Nr3 object should have a persistent pointer to data "owned" by your linked list, or should merely query that list for a temporary (local variable) pointer to data only when it needs it.
  4. Quote:Original post by Exilberliner So now, when I'm deleting one of the list-entries which was targetet by class nr3 I'm still getting the value. Is this your problem? What exactly do you mean by it? Please be more specific.
  5. Aside from a few minor errors, Julian90 pretty much has it. Your problem boils down to the fact that the compiler needs two sets of information at compile time in order for your unary_predicate template function to work: the type of the function pointer, and the actual function address. Template argument deduction only works with the arguments to templated functions, but function arguments exist in the run-time domain rather than the compile-time; therefore, your options boil down to either passing the function pointer as both a function parameter (to obtain its type at compile time) and a template parameter (to obtain its address at compile time), or passing the type and address of the function pointer in separate template parameters. Had I the choice, I'd choose your current method of passing both in separate template parameters, but I have included some working code below showcasing the alternative. It's identical in principle to Julian90's, and compiles without error (using GCC 3.4.5). /// For testing purposes typedef int Variable; /// unary_predicate_type is the return type of our helper struct's get() typedef Variable* (*unary_predicate_type)(Variable*, Variable*); /// Your templated unary predicate function template< typename Context, typename PredInArg, bool (Context::*predPtr)(PredInArg) const > Variable* unary_predicate(Variable* self, Variable* args) { // do your stuff return 0; } /** The unary_predicate_helper struct provides persistence of the function * pointer's type data; it is instantiated by the get_unary_predicate function */ template< typename Context, typename PredInArg > struct unary_predicate_helper { /** This member function uses its parent struct's templated type data plus * its own templated value data to instantiate the actual * unary_predicate function */ template< bool (Context::*PtrValue)(PredInArg) const > unary_predicate_type get() { return unary_predicate< Context, PredInArg, PtrValue >; } }; /** The unary_predicate function makes use of the compiler's template argument * deduction for functions to instantiate a unary_predicate_helper struct with * the required type data */ template< typename Context, typename PredInArg > unary_predicate_helper< Context, PredInArg > get_unary_predicate(bool (Context::*PtrTypeDeduce)(PredInArg) const) { return unary_predicate_helper< Context, PredInArg >(); } struct test { bool somefunc(int somearg) const { return false; } }; int main() { // just getting the address of the function unary_predicate_type pass_me_to_api = get_unary_predicate(&test::somefunc).get< &test::somefunc >(); // actually calling the function Variable v1, v2; Variable* result = (get_unary_predicate(&test::somefunc) .get< &test::somefunc >())(&v1, &v2); return 0; }
  6. Quote:Original post by ViLiO As for the const char[15]'s to LPCWSTR conversions, you can either disable unicode (in your project settings), ... QFT. In VS 2005, this appears as the "Use Multi-Byte Character Set" option.
  7. Quote:Original post by Mizipzor Yes I could do that, but then it would loop until f is equal to begin(), but not including begin(), which I want. ...Are you serious? while (f != l.begin()) { --f; cout << (*f) << endl; }
  8. Quote:Original post by Mizipzor Do I have to do something extra in order for that to work? Not in GCC, but then it's obvious you aren't using GCC. Have you tried just decrementing the same iterator you already have? (Works for me.) list<int>::iterator f; for(f = l.begin(); f != l.end(); f++) { cout << (*f) << endl; } for(; f != l.begin(); --f) { cout << (*f) << endl; }
  9. Quote:Original post by Julian90 as well as what Illco said any static or global variables will contribure to the size of the executable. While this is true, static and global variables probably contribute the least to the size of any set of compiled code. To optimize for size, ensure that extraneous symbols are not being included. I'm not as familiar with Microsoft's compiler as I am with GCC, but I suspect this will involve turning debug information off and any available size-related optimizations on, and linking with the redistributable version of the CRT (rather than the debug version). Make sure _DEBUG is not defined, and NDEBUG is. EDIT: The fact that this is a static library we're creating here apparently didn't entirely permeate my gray matter the first time through. A static library is merely a collection of object files; no linking has occured yet and so advice about libraries and runtimes doesn't apply. Hope that helps, JohnE / TDragon [Edited by - TDragon on December 30, 2006 10:41:35 PM]
  10. Quote:Original post by mgoldsum I want to try to build a somewhat simple graphics engine (using OpenGL) that I can use for a few games that I am planning on making. The problem is I dont know exactly where to start and what stuff needs to be in it. The best way to start something is, in fact, to simply start it. Particularly the case when you don't have an overarching view of what the structure of your code should be, it might be best for you to dive in, starting with what you know and working outward from there. Supplement your work with a book or two on game programming if at all possible, and don't miss GameDev's articles -- invaluable. Seeing how someone else did it will give you an idea of the best way to do it. As far as creating a game engine goes, I'd advise that you not try to build a complete reusable engine by itself before starting these games you're planning -- after all, how would you know everything your engine needs to provide to the game? You'll find it easier and more gratifying to build the engine and the game in parallel. Once you're ready to move on to the next game, you'll be able to clearly distinguish the parts of your code that are reusable in it, which belong in the engine, from the parts that are specific to the previous game. Quote:If anyone can help me and let me know what functions to start with and what some good ways to store things are I would be very happy. Prefer the standard library over anything you might write yourself. Be familiar with the strengths and weaknesses of the various data structures such as binary trees (std::map), linked lists (std::list), and arrays (std::vector). For each storage problem, the method for data access and the speed of data access will determine the appropriate structure. Hope that helps, JohnE / TDragon
  11. That depends on what you mean by compiler, and what you mean by good. Seriously. By "compiler", do you mean "IDE"? Dev-C++ is one of several IDEs designed to use the MinGW compiler. I don't like Dev-C++ as an IDE very much either; I use Visual Studio and Code::Blocks. Or do you mean that you have trouble overcoming the errors that the compiler gives you when you try to compile programs you've written? This happens to all of us, even the best of us, but there are a lot of good practices and techniques out there for programming. A good reference book will help you out of many situations, and Google and the good folks here at GameDev make good backup. Do you have issues with the actual design of the MinGW compiler? It's a Windows port of GCC, the GNU compiler collection that is used on nearly every Linux OS distribution available (as well as many other OSes), but you might find Microsoft's, Watcom's, Intel's, or Digital Mars' to be friendlier. It's all a matter of what you need, and what you want. Cheers, JohnE / Twilight Dragon
  12. Such a thing does indeed exist. The Boost C++ libraries' implementation calls it a weak_ptr, and it is a "Non-owning observer of an object owned by shared_ptr", shared_ptr being your standard smart pointer. Whether and how you use this "weak" smart pointer depends on your language and the needs of the situation.
  13. Quote:Original post by Zahlman Sometimes the most logical thing is to use smart pointers, ... This is why smart pointers are often called for. Smart pointers were the first thing that came to my mind reading through your post, GenuineXP. Granted, I haven't taken the time to fully understand your problem, and also granted, smart pointers are not the solution to every ownership problem. I think, however, if you start referencing your Sequences with smart pointers, everything else should fall into place. As far as smart pointers go, your options are pretty much std::auto_ptr, boost::shared_ptr, or creating your own implementation. std::auto_ptr has some sticky semantics but it comes with your compiler; boost::shared_ptr works like a charm but has internal Boost dependencies (i.e. you can't just copy shared_ptr.hpp), and rolling your own takes work, time and debugging but can be crafted to perfectly fit your situation and is a great learning experience. Hope that helped, JohnE / Twilight Dragon
  14. Possibly dx80_mgw.zip, from http://alleg.sourceforge.net/wip.html? This is not by any means the full SDK, but I expect it'd be enough to get you going.
  15. I received the package two days ago, just a few days after receiving a shipping confirmation email and less than two weeks from signing up for the offer. These 500.13 errors are killing what used to be a fantastic site.