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


  • Content count

  • Joined

  • Last visited

Community Reputation

130 Neutral

About foofightr

  • Rank
  1. That's a nice screen saver. I didn't expect it to run on my old machine, but it did! There was one problem though: it tries to access the internet when it starts up. That's a definite no-no.
  2. It's useful for writing functors.
  3. Quote:Original post by DvDmanDT Well, say I only have one class then. Everyone will do the same thing. So I don't need the virtual keyword.. So I can iterate through the list in x ms.. My question is, how much slower it would become if I just added that 'virtual' keyword? If the body of the virtual function is more than a few lines (and since it's an Update method, I assume it will be), the speed difference will be negligible.
  4. I noticed that the vector's members are allocated on the heap. Might I suggest the following: namespace pde { template <class ValueType, unsigned int vectorWidth> class VectorTemplate { public: ValueType value[vectorWidth]; ... You save 4 bytes per vector, but more importantly you save all those small memory allocations, which can chew through (not to mention fragment) memory at an alarming rate. It also makes it impossible to have a memory leak.
  5. There's nothing stopping you from creating an empty texture, then locking it and writing arbitrary data to it that you read from an image file. That's probably all that D3DXCreateTextureFromFile does anyway. This should get you started: Create the texture Lock and write to it
  6. The string version is not meant for speed (FYI it just uses a binary search to look up a TypeInfo, then passes it onto the regular IsA). Using strings as the lookup type lets you do things like letting the developers (yourself included) perform actions on certain types of objects in your game's hierarchy. You can type the class name into a dropdown console as an argument to a command, like "hide projectile" if you wanted to hide all 'Projectile' objects in your game level, or "count ammo" which might tell you how many 'Ammo' objects are in the level. I already conceded that RTTI is faster regardless. I'm going after functionality.
  7. Quote:Original post by ToohrVyk typeof is a O(1) operation. dynamic_cast<A>(b) will call a typeof-like function on A and b, and then determine if typeof(A) can be reached from typeof(b) in the type lattice of your program. As such, dynamic_cast is an O(n) operation, where n is the number of parents of the type of b. This is because in a hierarchy like: class A; class B : public A; class C : public B; class D; class E : public D, public C; you can use dynamic_cast to cast an object of type E to A, B, C, D and E (which means just as many checks in the worst case). I am currently working on a comparison between various RTTI methods, you can find it on this page. It's not complete yet, though, in particular I want to redo the entire benchmarking and add typeof comparison. That was an interesting article. I also tried my hand at a "better RTTI" a while back. It works like this: class TypeInfo { // info on a type (name and up to 4 parent pointers) }; class DynamicTypeObject { bool IsA (const TypeInfo& type); bool IsA (const char* type); // performs lookup of registered types virtual const TypeInfo* GetType () = 0; }; It would be used like this: class Item : virtual public DynamicTypeObject { static TypeInfo Type; const TypeInfo* GetType () { return &Type; } }; TypeInfo Item::Type("Item"); // in .cpp file class Potion : public Item { static TypeInfo Type; const TypeInfo* GetType () { return &Type; } }; TypeInfo Potion::Type("Potion", &Item::Type); // in .cpp file class Scroll : public Item { static TypeInfo Type; const TypeInfo* GetType () { return &Type; } }; TypeInfo Scroll::Type("Scroll", &Item::Type); // in .cpp file And finally you would use it like this: void Drink (Item* i) { // basic RTTI equivalent if (i->IsA(Potion::Type)) { // it's a potion // (this does not address multiple inheritance...) Potion* p = (Potion*)i; } // something RTTI could never dream of doing if (i->IsA("Potion")) { } } This still does not address multiple inheritance, but I have not really thought that far since I never needed to yet. I think a solution to that would not be so hard. The main advantage of this method seems to be that you only have to use as many TypeInfo objects as you actually need, instead of for every single class. But it occured to me that if I can be selective in this way, then why can't the compiler be as well? After all, if you don't use dynamic_cast anywhere, you don't need any RTTI (even if it's enabled). If you only use dynamic_cast<Potion*> then the compiler knows it only needs type info for Potion and its parent(s). Something like this sounds simple to optimize. Also, I benchmarked my implementation against RTTI and it was about 3 times slower (optimized VC++ 7). So unless I am doing something horribly wrong, then the "RTTI is slow" argument is out the window, as far as I'm concerned. Not that typecasting is going to take up much CPU % anyway, but thought I'd mention it anyway. So overall, RTTI doesn't seem so bad after all. It's fast and if my assumption is correct, is lightweight (or at least could be). I'm still using my own method though. Querying with strings, mmmmm.
  8. Quote:Original post by silvermace i think you've misinterpreted the use of templates. the example you've provided would generate illogical code, eg: the compiler would generate the following code if you made a Whatever class specialised with the template parameter T = int would look like this:Whatever<int>::Function() { printf(int); } look into C++'s variable argument lists (MSDN page) I was thinking more like printf("int"). I shouldn't have used printf as an example - this is not about variable argument lists, it's about simple string representation of the template argument. If only #T worked... I was trying to find a way around template specialization, but I suppose I will need to have snippets like this all over the place: template<> void Whatever<int>::Function () { printf("int"); } template<> void Whatever<float>::Function () { printf("float"); } etc...
  9. #define PRINT(a) printf(#a) So PRINT(hello) will be replaced by printf("hello"). Basic preprocessor stuff. Is there any such functionality for C++ templates? tempate <class T> class Whatever { void Function () { printf(T); // <---- ??? } }; Is there any way I can make this work?
  10. Maybe this has been mentioned before, but if not it may be helpful... Be careful about event notifications with hardware sound buffers. I was using DirectSound to play OGG files streamed in using libvorbisfile (pretty much the same method described in this thread), and on my machine everything worked fine with events at 0.5 and 1 second. But on some other machines the events would fire dozens of times per second and mess up the audio really bad. Basically the timing was all screwed up. I tracked it down to the CreateBuffer() function in DirectSound, where I was letting it pick whether to use a hardware or software buffer. I forced it to use a software buffer and everything worked fine after that. I'm not sure whether this means event notification is hosed for all hardware buffers, or just for specific sound cards and/or drivers, but it caused me some grief so I thought I'd pass it on.
  11. Also keep in mind that STL vectors don't free their own memory until they go out of scope. Calling Sensors.clear() only sets the size to 0. To force it to release its memory, there's a trick you can use: vector<sensor*>().swap(Sensors); It basically swaps its contents with a temporary vector, and when this temporary vector goes out of scope (right after that line of code) it releases the memory. Sensors now has size 0 with no memory allocated for it.
  12. I meant for you to compile the code you originally posted (and defended), without fixing the glaring errors hoping nobody would notice... But if that's your game, then carry on I guess...
  13. Quote:Original post by Nice Coder Quote:Original post by foofightr You do realize that the code you posted is equivalent to this: x = x >> 1; which is simply dividing x by 2. Besides, it wouldn't work even if you copy pasted it properly from whichever website you got it from. If you feed it a power of 2, it'll round it down. 32 would return 16, which it shouldn't as 32 is already a power of 2. I don't realise it, because it doesn't. Once you figure out how it works, you'll know the problem with what you've posted. From, Nice coder Well, here goes: x--; // subtracts 1 x | x >> 1; // does nothing x | x >> 2; // does nothing x | x >> 4; // does nothing x | x >> 8; // does nothing x | x >> 16; // does nothing x | x >> 32; // does nothing x++ // missing semi-colon (meant to add 1) x = x >> 1; // divide by 2 I dare you to compile it with any C/C++ compiler...
  14. Quote:Original post by Nice Coder Quote:Original post by lucky_monkey that doesn't event work... sample results (ignoring the fact that you can't bitshift an integer 32 bits (as you may have been operation on a larger type for some reason)): x = 25 -> x = 12 x = 254 -> x = 127 x = 253 -> x = 126 maybe testing stuff before you post would be a good idea... Lets try an 8 bit version, shal we? x--; x | x >> 1; x | x >> 2; x | x >> 4; x | x >> 8; x++; x = x >> 1; Lets start x off as say 01101111 01101111 - 1 = 01101110 01101110 >> 1 = 00110111 01101110 | 00110111 = 01111111 ect. It won't do much as x | x >> 2, 4, or 8 = x currently. 01111111 + 1 = 10000000 10000000 >> 1 = 01000000 Which is the answer. Read before posting. From, Nice coder You do realize that the code you posted is equivalent to this: x = x >> 1; which is simply dividing x by 2. Besides, it wouldn't work even if you copy pasted it properly from whichever website you got it from. If you feed it a power of 2, it'll round it down. 32 would return 16, which it shouldn't as 32 is already a power of 2.
  15. I think what he means if that if you have this: class A { ... }; class B : public A { ... }; B* ptrB = new B; A* ptrA = ptrB; then sizeof(*ptrA) will return the size of A, not B, even though the pointer is pointing to an object B. The compiler checks the type at compile time, not runtime.