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

CodeCriminal

Members
  • Content count

    226
  • Joined

  • Last visited

Community Reputation

290 Neutral

About CodeCriminal

  • Rank
    Member

Personal Information

  • Location
    Staffordshire, England
  1. [quote name='Serapth' timestamp='1348079422' post='4981774'] I would be curious to do a poll at some point along the lines of: Which do you think is harder: -- filming a movie -- coding a video game [/quote] I've been involved in both (programmer/actor though less acting than programming ) and that's a tough one lol. Each of them are equally draining but in different ways, at least that is my opinion... kinda states the obvious haha [quote name='DaveTroyer' timestamp='1348164862' post='4982109'] Me-thinks we're getting a bit side-tracked guys. ... Hope this helps! [/quote] Ah yes, I apologize. Ok so I'm pretty tired of dishing out the same old Your-Not-Going-To-Make-X. speech so lets try it a different way, pick one of the languages below, try several before settling on one if you must. In no particular order: - C# - Python - Java - C++ Then, in chosen language, try to implement what you think will be the single most easiest feature to program in your MMOx If it were me I would probably start with menu system (no fancy GUI or anything, just the ability to navigate a hierarchy of sub/menu's and have the perform different actions) simple enough. Then move onto something a little harder, perhaps an inventory (depends on how you want your inventory system to work). If you manage to achieve that, try to do something a little harder; a chat client! over the interwebs! (atleast I think its harder, probably because I have never attempted it and have little idea as to what it involves). Then keep going for as long as you can, the rest of us who were once in your exact position already know the ending to this story, but at least this way you will gain a serious amount of valuable experience!
  2. [quote name='SiCrane' timestamp='1348665253' post='4983965'] [quote name='roadysix' timestamp='1348662542' post='4983957'] I've read that allocators of the same type are required by the standard to be able to deallocate the memory that another of its type has allocated. [/quote] No, memory allocated by a allocator A can be deallocated by allocator B only if A == B is true. If they aren't equal to each other, they're not required to be able to deallocate each other's allocated memory. See section 20.1.5 of the C++03 standard or 17.6.3.5 of the C++11 standard. [/quote] I don't have the standard documentation available to me nor do I know where to get it. What you have said is essentially what I mean but the problem is that allocators of the same type are required to return true from A == B (or so I read somewhere) I am probably wrong, if so does this mean I can implement the comparison operators normally?
  3. Hello again, I have another query about custom allocators. I've read that allocators of the same type are required by the standard to be able to deallocate the memory that another of its type has allocated. This presents a problem when trying to implement a memory pool based allocator (or variation thereof) seeing as I would like each pool allocator to manage its own memory block, the size of which supplied by a template parameter. Something along the lines of [CODE] template <typename T, std::size_t Blocks> class pool_allocator ; [/CODE] But of course allocators of the same type would not be able to deallocate memory of other instances of the same type of pool class. I decided try and make the data members static, _blocks, and _size for now since I haven't really fleshed out how this is going to work. and then do something like this: [CODE] inline pool_allocator( ) noexcept { T* __Tmp = reinterpret_cast<T*>(::operator new((Blocks + _size) * sizeof(T))); std::uninitialized_copy(_blocks, _blocks+_size, __Tmp); // may not be necessary because most pools will be constructed at the beginning of the program, but it doesn't hurt runtime to have it in there if this is the case. _blocks = __Tmp; _size += Blocks; } // ... // static member initialization template <typename T, std::size_t Blocks> T* pool_allocator<T, Blocks>::_blocks = nullptr; template <typename T, std::size_t Blocks> std::size_t pool_allocator<T, Blocks>::_size = 0; [/CODE] It would be better if I could get the summation of all pool allocator Blocks at compile time but I see no way to do this at the moment - ideas anyone? ... There was something else I wanted to say as well but it escapes me at the moment.. It'll come back. Anyway, how would I deal with fragmentation in the most efficient manor possible while still maintaining contiguous blocks of memory that arrays allow for? some things may be deallocated from the middle of the memory block and the only way I can see is to keep a sort of queue of pointers to free space in memory but this is a terrible solution for obvious reasons. I'm not entirely sure my approach will work in the end, but there is little to go by on the internet that I've found
  4. Above post I'm actually working on a small library of random items that include math related things such as vectors and matrices. if you want id be willing to share code, or give feedback over skype or something though I don't have a mic. I don't yet have a class for quaternions so I'd be interested to see your implementation.
  5. I was once in the same boat as you somewhat, I wanted an algorithm to do LU decomposition because I had heard that you can compute the inverse of a matrix with the decomposition though I never was able to find any information on exactly how to go about that. I did however write a working algorithm to do the decomposition and it should still be here on gamedev somewhere.. (I'll check my posts and then get back to you) though I was told it was lacking "pivoting" or something.. I'm no math genius I just learn enough to get by in programming (and possibly a little extra if it peaks my interest which is more often than not). hold on let me find that post for you.. EDIT: Sorry, seems my old posts/topics have been deleted =/ .. blows.. well I'm not that great at math and it took me a good few hours to read about LU decomposition and how it is done, to come up with an algorithm. I'm sure if you keep at it you will come up with the algorithm as well it wasn't complex at all if I remember correctly just a few for loops. It might be around somewhere, I used to go by CodeCriminal around here but have since changed my handle. EDIT2: Woo found it http://www.gamedev.net/topic/562662-lu-decomposition-and-computing-the-determinant-of-an-nxn-matrixsolved/
  6. [quote name='Bregma' timestamp='1348578275' post='4983554'] [quote name='roadysix' timestamp='1348561194' post='4983505'] EDIT: I just tried a few things out, and one of those things was to inherit from the allocators rebind member which at first spat out some errors during compilation. Then gcc suggested something interesting - 'use Allocator::template rebind to indicate that it is a template' - I have never come across anything like this before but it seems to have fixed the original problem I had with your change to the rebind member when I change it like so: [/quote] Yes, that construct is required by the language in that situation. Older versions of the Microsoft C+ compiler fail to comply with the language specification on that, I'm not sure about current versions. GCC has required it since 3.0 which was released a decade ago now. [/quote] Ah, good to know, I've only been working with gcc for just under a year now (not counting actual time spent programming) and I was a visual studio guy before that, so that's probably the reason why I had never come across it before. (couldn't resist those c++11 features that vc10 was lacking in [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] ) [quote name='Bregma' timestamp='1348578275' post='4983554'] You're poking around with a part of C++ that has all the pointy bits at one end. Hang on, you're in for a fun ride. [/quote] Oh joy a challenge, I look forward to it haha. [quote name='Bregma' timestamp='1348578275' post='4983554'] BTW, the only place GCC should be using [font=courier new,courier,monospace]std::allocator_traits<tracking<int>>[/font] is in its test suite. [/quote] Well since changing the code in the rebind member that [i]edd[/i] suggested, that problem has pretty much disappeared, I'm now faced with the getting it to work with std::list. The problem I am getting is that std::list<T, Alloc>::get_allocator( ) or some function there within is trying to call a "supposed" non-existent copy constructor. The errors go a little something like this: error: no matching function for call to 'type::allocator<std::_List_node<int> >::allocator(const type::allocator<std::_List_node<int> >&) It works with std::allocator but not my own implementation it seems.. (recently discovered) ... After one quick look I noticed my constructors where declared explicit, for some reason this blows up in the containers. Removed the explicit keyword and now everything is working again! .. until I find the next flaw that is. [quote name='Bregma' timestamp='1348578275' post='4983554'] Oh, and one more thing. The current C++ standard changes allocators around a lot. The old C++98 allocator model is being deprecated. It's a good riddance kind of thing. [/quote] Oh really? so am I using the old allocator model? If so where can I find information on constructing allocators that comform to the new standard? Thanks [revised code] : http://codepad.org/9mrTYNT2
  7. [quote name='e?dd' timestamp='1348528945' post='4983394'] I don't think your implementation of rebind is correct. I believe it should be something like this: [code] template <typename T> struct rebind { typedef tracking<typename Allocator::rebind<T>::other> other; }; [/code] I haven't checked the rest, but I suspect that this correction will solve your immediate problem. [/quote] Hmm, that does indeed make sense seeing as the std containers are passing their first template parameter to rebind internally it seems. However it didn't solve my problem and introduced a new error, something along the lines of "template parameter 1 is invalid", and that is just trying to instantiate the template. I'll take a closer look when I get home (in class right now [img]http://public.gamedev.net//public/style_emoticons/default/tongue.png[/img]) EDIT: I just tried a few things out, and one of those things was to inherit from the allocators rebind member which at first spat out some errors during compilation. Then gcc suggested something interesting - 'use Allocator::template rebind to indicate that it is a template' - I have never come across anything like this before but it seems to have fixed the original problem I had with your change to the rebind member when I change it like so: [CODE] template <typename T> struct rebind { typedef tracking<typename Allocator::template rebind<T>::other> other; }; [/CODE] I can already see there are a few other problems with the class that will need to be addressed before I get it working, but when I do I shall report back. EDIT2: Ok, so I seem to have it working now and the latest draft is pasted below in codepad, it works as expected but I could take this class further providing something a little more feature rich. There wasn't really much that needed to be done to get it working just a few silly mistakes. Thanks for your help [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] [url="http://codepad.org/31creIpW"]http://codepad.org/31creIpW[/url] I'm not really sure what to do about the comparison operators, leave them as-is or make comparisons of that data? EDIT3: Having some troubles with std::list because of the rebinding it does from allocator<int> to allocator<_Node_t<int>*> (or something along those lines...
  8. [quote name='e?dd' timestamp='1348513957' post='4983320'] because we don't have your code [/quote] Ah yes, sorry, I've pasted in codepad simply because I don't like what this forum does to the formatting when you post code. http://codepad.org/aeiKdVxZ I thought about trying to add the template parameter Allocator as a template-template parameter, I seem to recall being able to do this but I'm not too well versed in with it so would require some reading on my behalf (though I am doubtful that it will solve my problem).
  9. Hi, so as a little excersize I've been looking into c++ allocators a little more and google'd my way to the link below (which I've come across a couple times but never really bothered to dig into it) [url="http://www.codeproject.com/Articles/4795/C-Standard-Allocator-An-Introduction-and-Implement"]http://www.codeproje...n-and-Implement[/url] Something that peaked my interest was the simple memory profiling with the tracking policy class, so I decided to implement something similar to this but instead of using policy classes I went the adapter route. Use of my class goes something like this: [CODE] #include "allocator.hpp" // my own allocator header // ... std::vector<int, tracking<std::allocator<int>>> vec; // ... std::cout << vec.get_allocator( ).total_allocations( ) << std::endl; // etc. etc.. [/CODE] However this code produces an ungodly amount of errors during compilation, after taking a look it seems that the standard library that comes with gcc at least uses something along the lines of std::allocator_traits<tracking<int>> internally which of course is not what I want. Is there any way to get around this? I don't understand why int is being passed to tracking in its template parameters, or even how since wouldn't it make more sense to do something like: std::allocator_traits<Allocator>::??? which as far as I can see would work.. I could try the policy based approach but I expect this would fail too unless I have my allocator defined with a default policy or something.. Maybe I will just roll my own containers that mimic the standard. Though as of right now it seems overkill (although fun) just for this tiny error. Thoughts?
  10. If, like me (and so many others), you enjoy programming for what it is, and not just because you want to make a game, then you will probably enjoy tinkering in c++. Though, if all you're looking for is something a little more powerful than Gamemaker to take your ideas to the next level then best bet is to stick with python, C# or some other high level/managed language. If you want to try C++, SDL/SFML as has already been mentioned, are choice libraries to develop applications such as games so don't forget to check those out (I would personally recommend SFML simply because I am familiar with it somewhat and seems generally cleaner than its C based competitor).
  11. [quote name='sundersoft' timestamp='1346546811' post='4975599'] You might want to wait for concepts to be standardized (or killed) before trying to add information about when a template would work to its interface. You're going to have to change your code if the standards comittee actually implements concepts and you want to use that feature (which would basically do what you're trying to do right now). http://en.wikipedia..../Concepts_(C++) However, this probably isn't going to be standardized for another 5 years at least (if it does become standard). [/quote] I had heard about concepts some time ago, though it is only now that I need them that I understand what they are for ("concepts" is a bit misleading), but as you said I'd be waiting a long time for them to implemented, (if the implementation of the c++11 standard is anything to go by) anyway thanks for clarifying and I think I'll stick with the regular function overload for now
  12. [quote name='Brother Bob' timestamp='1346543108' post='4975591'] [quote name='roadysix' timestamp='1346542823' post='4975590'] Incurring the overhead of a proxy function call is also undesirable [/quote] Any decent compiler will remove the extra function call. [/quote] Oh, thats good to know makes sense really
  13. [quote name='Brother Bob' timestamp='1346541495' post='4975584'] [quote name='roadysix' timestamp='1346540294' post='4975578'] I could probably cast the non-const pointer to const but this isn't really desirable. [/quote] Overloading to the rescue (how ironic...): [code] template <typename T> void function(T x) { ... } template <typename T> void function(const T* x) { ... } template <typename T> void function(T* x) { function(static_cast<const T *>(x)); } [/code] [/quote] Incurring the overhead of a proxy function call is also undesirable, where simply being able to partially specialize a function would be favourable. Alas, as pointed out it is not possible. [quote name='Brother Bob' timestamp='1346541495' post='4975584'] [quote name='roadysix' timestamp='1346540294' post='4975578'] Of course, these are all hypothetical needs, and I don't imagine I will come across anything like this in the near future, if ever, though it is still interesting and worth knowing. [/quote] Perhaps not in a near future, but they certainly aren't hypothetical. I would say that your example with just an overload for pointer type is a fairly trivial and not totally unexpected example.... [/quote] Hmm well I would still try to avoid this kind of thing some way or another. [quote name='sundersoft' timestamp='1346542575' post='4975588'] [quote name='roadysix' timestamp='1346530306' post='4975525'] [quote] You could try changing the specialization to: [code] template <> typename std::enable_if<std::is_arithmetic<mytype>::value, mytype>::type func(const mytype& x) noexcept; [/code] [/quote] I could try this but it would involve specializing is_arithmetic for mytype which is something I don't really want to do. Even still it would only evaluate to true and produce the same problems. [/quote] I really doubt you're going to be able to specialize the function if your type doesn't have is_arithmetic<mytype>::value==true . You are allowed to specialize templates in the standard library (under certain conditions). The following code compiles even though the mytype specialization of func doesn't use is_arithmetic: [/quote] I soon realized this after posting that reply and decided to go with the function overload. Extending the standard namespace is something I try to avoid, but I am interested in what these "certain conditions" are, if you could explain further.
  14. [quote name='Brother Bob' timestamp='1346539070' post='4975572'] That is not partial specialization, but regular function overloading. The two templates are separate. [/quote] Haha I realized that, that is why I put "partial specialization" in inverted commas. [quote name='Brother Bob' timestamp='1346539070' post='4975572'] So what you have is the correct way, but I suspect you're not failing to call the pointer-overload because it's a better match, but because you're passing a non-const pointer and non-const overloads are preferred over const-overloads in that case. [/quote] Ah yes, I passed a const pointer to the function and the correct function was called. Seems to me like this could be a dangerous game to play and partial specializations would be a better fit for this kind of thing.. though, I'm no c++ expert. The same incorrect result is achieved if I have two overloads, one with a const-reference and another with a const-pointer when I try to pass in a non-const-pointer the function that takes a const-reference is called. I could create two overloads that do not take const parameters but what if I didn't want the function accidentally changing the value of that variable passed to it (of course I would use const) but what if I need to pass a non-const pointer to the function that accepts a const-pointer.. silent disaster. I could probably cast the non-const pointer to const but this isn't really desirable. Of course, these are all hypothetical needs, and I don't imagine I will come across anything like this in the near future, if ever, though it is still interesting and worth knowing.
  15. Ok, I guess the overload is my best bet for now seeing as the explicit specialization doesn't work, thanks Brother Bob, you learn something new everyday haha [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] EDIT: I have a question about not being able to partially specialize a function as this is news to me. lets say that I have a template function that takes any type performs some operations and then returns, pretty basic stuff [CODE] template <typename T> void function(const T x) { /* ... */ } [/CODE] Then I would like to "partially specialize" this function for pointers to T, I tried to create an overload like this: [CODE] template <typename T> void function(const T* x) { /* ... */ } [/CODE] I have never had to do anything like this before but that is besides the point. While this compiles, I did not get the expected result and only the first template function was being called, even when I passed a pointer to the function! Which to me is surprising. Without being able to partially specialize a function, what would be the correct way to go about setting up something like this? Thanks