• 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

3267 Excellent

About KulSeran

  • Rank

Personal Information

  1. Re-read the documentation I linked. Putting in 0 causes it to pick within the range [49152, 65535) Even if you used your current code, you'd still need to port forward the exact same port range [49152, 65535), so you're in the same situation.   UPnP is one option to get around manually port-forwarding.  Your program can ask the router to temporarily port-forward which-ever port it opens. Whomever is hosting always has the option to use DMZ mode on their router (effectively "port forward everything")   The only way to shrink the size of the manually added port-forward, it to use a smaller manually picked range.  To do that you'd need to use something similar to your code, but on a much smaller port range (eg only 99 rooms from [50001, 50100)). But if you go with manually choosing, for each port number you manually choose, you still have to attempt to open a socket on that port (which may fail due to it already being open by another program), so your process of marking ports used/unused needs to also have a state for temporarially-in-use-by-other-program.
  2. I think you're going to see a theme in my bullets...   Opaque planning is bad.  It's really nice to know when and why plans are going to likely change.  It's frustrating to no end to have work scrapped due to seemingly random planning. It's even worse to have constant "emergencies" where X is now the most important thing to get done. Changing deadlines is bad, but no deadlines can be worse.  Make sure there's a plan, and that everyone's making progress, and that you have deliverable laid out to try and catch "not fun" or "not the right style" long before anyone wastes time polishing it.  Games are dynamic, in that you're often searching for what is "fun", so make sure you have plenty of deliverables like "Friday play testing with the team!" before hitting the drop dead date on "we have to have _something_ finalized for the demo build". Lack of cross-discipline planning.  Artists should not have polished art before someone puts it into the game.  Gameplay should not be expected to have polished gameplay without any help from art.  Sound shouldn't be left for last.  Make sure people are on the same page for building prototypes, polishing work together, and making a whole presentation.
  3. One of your issues might be the fact that your calling "new Random" in each invocation of your function. new Random() provides you with a brand new generator, who's seed is set based on the time at which you called it, thus calling it alot quickly, gives similar or the-same results. You probably want to create one Random at program start, and re-use it between all the calls to your triangle function.     edit... tried your code (with my sugested fix) and for a run of 100K calls I get counts like the following: (0, 7, 10) 0       : 1408  (1%) 1       : 4297  (4%) 2       : 7057  (7%) 3       : 10003 (10%) 4       : 12605 (12%) 5       : 15726 (15%) 6       : 18902 (18%) 7       : 16535 (16%) 8       : 10109 (10%) 9       : 3352  (3%) 10      : 6     (0%)   (0, 9, 10) 0       : 1093  (1%) 1       : 3319  (3%) 2       : 5489  (5%) 3       : 7817  (7%) 4       : 9830  (9%) 5       : 12142 (12%) 6       : 14451 (14%) 7       : 16976 (16%) 8       : 18883 (18%) 9       : 9994  (9%) 10      : 6     (0%)   (0, 1, 10) 0       : 9901  (9%) 1       : 18732 (18%) 2       : 16636 (16%) 3       : 14476 (14%) 4       : 12392 (12%) 5       : 9935  (9%) 6       : 7928  (7%) 7       : 5546  (5%) 8       : 3308  (3%) 9       : 1140  (1%) 10      : 6     (0%) Which does appear to center closer to the mode than the extremes, which is what you'd expect from the distribution image you showed.
  4. There's a bunch of known protocols (and a nice wiki page with a lot of them).  As long as your base server address doesn't overlap with anything you think your users will be using, it makes for an ok default port.  But you should probably make it configurable, so that individuals hosting the server could change it later.   As to your port-cycling code, it's likely going to need to be more robust than what you have.  Other processes (like your browser) are free to open up ports in that same range.  But you don't really need any of that logic you wrote. To quote MSDN's bind documentation for a socket "For TCP/IP, if the port is specified as zero, the service provider assigns a unique port to the application from the dynamic client port range.". That is going to be far more reliable, than using your own tracking for the port number.  You can always retrieve the port number that a socket got bound to.
  5. Reserve. Reserve. Reserve.  You know the sizes of your results, so reserve. result.reserve(kNumCards); for (int card = 0; card < kNumCards; card++) { result.push_back(std::vector<bool>()); result.back().reserve(kNumHands); This will avoid a lot of allocation/copy that is happening behind the scenes, and will help improve your write speed.
  6. The profiler isn't just telling you things are slow. It's telling you were all the time was spent.  What it is telling you is that 5% of the samples ended up on that line, and that amounted to 8s of real execution time.  You have only two things to look at:   1) Why is that line getting called so much.  This is the most likely problem.  The objective of good optimization usually isn't fixing why lines are slow but fixing why lines are called so often.  Try to pick a better algorithm or storage container for your use case and you can usually improve performance.   2) Why is this line so slow.  But sometimes the line really is just slow. In this case, if it really is as simple as a lookup, the lookup table is probably too big to fit in the cache reasonably along side the rest of your data.  If the profiler has a cache hit view you'd be able to see this.
  7. Thanks Starfarer42, that's really what I was trying to get at.  My issue with your implementation TheComet is that it puts too much emphasis on allocating and attaching things to an Entity.  That provides flexibility, but costs performance.  An ideal entity component system focuses more on the components / systems than it does on the "entity" part, because it should be rare that you ever need to check what other components an entity has.  Components can be stored in a single array per-type, like Starfarer42 suggests.  If you keep them sorted by entity id (or in a binary tree pattern), it's possible to quickly traverse one or more component ('attribute') lists in parallel paired off by id for the rare cases where you need multiple attributes together to perform a calculation.
  8. Yes. One of the standard spacial partitioning schemes for Ray Tracers is a k-d tree which allows you to more quickly traverse space to find relevant triangles to test against.  The main issue with this approach is that it works best for static scenes, since building the k-d tree can be time consuming and must be done every time a dynamic scene would change.   edit: As to how to implement that traversal on the GPU, I'm not entirely sure but a quick google does turn up quite a few papers.
  9. Yeah... That's totally wrong.  C++, unlike other languages like Java has a really bare-bones notion of what an "object" is. vector<int> numbers; numbers.push_back(20); numbers.push_back(10); int *n1 = &numbers[0]; int *n2 = &numbers[1]; std::sort(numbers.begin(), numbers.end()); std::cout << *n1 << " " << *n2 << std::endl; // NOTE: after this line, n1 and n2 may no longer point to valid memory!!! numbers.push_back(30); Pointers point to a memory locations, not "objects".  In this case a vector has a pointer to a contiguous block of memory that it uses for storage.  The pointers n1 and n2 point into that storage.  Sorting the vector moves around values within that storage, and now your pointers are pointing to different numbers because that is the data now stored at that memory location.  Then, to my final note, adding more objects to a vector can cause it to copy it's content to totally different location in memory, leaving n1 and n2 pointing into nothingness/undefined-bahavior land.
  10. First off, smart pointers are not meant for managing items on the stack. They are meant for managing items on the heap.  They are designed to change { int *foo = new int(10); delete foo; } into { std::unique_ptr<int> foo(new int(10)); } notice how unique pointer removes the need to remember the matching call to delete?   That also means that it's always going to delete it's input, so attempting to feed it a pointer off the stack will cause it to crash on destruction: { int num = 5; std::unique_ptr<int> ptr1(&num); } // <-- crash Secondly, each smart pointer type has it's own semantics about how it manages memory.  unique_ptr in particular is designed to give a single point of code ownership of an object on the heap.  That means that a unique pointer must transfer ownership, and may not be a copyed. So if you did want to transfer ownership you need to use move semantics std::unique_ptr<int> p1(new int(10)); std::unique_ptr<int> p2(std::move(p1)); which will result in p1 being empty, and p2 containing the integer valued 10.
  11. So, in your case, did you check that in->gcount() == iNumBytes A failure for which would imply that the file was not actually read in full.   Also, I notice in your code that if this isn't exactly what you have in your code, you should probably correct iNumBytes to iNumBytes = epos - cpos; because you might not seeking back to 0, since you're seeking back to cpos.
  12. You'll need to demonstrate what exactly you're doing.  Given that: #include <fstream> #include <vector> int main(int argc, char **argv) { std::ifstream ifile("test.txt", std::ios::binary); ifile.seekg(0, std::ios::end); long fileSize = ifile.tellg(); std::cout << "file is " << fileSize << "bytes" << std::endl; std::vector<char> bytes; bytes.resize(fileSize + 100, 0); ifile.seekg(0, std::ios::beg); ifile.read(&bytes[0], fileSize + 100); std::cout << "read in " << ifile.gcount() << "bytes" << std::endl;   for (auto itr = bytes.begin(); itr != bytes.end(); ++itr) {     std::cout << (int) *itr << " ";   } } reports the same value for both size and bytes read.  In my case, 34 bytes for the test file: this is some text hello The output is: file is 34bytes read in 34bytes 116 104 105 115 32 105 115 32 115 111 109 101 32 116 101 120 116 13 10 13 10 13 10 13 10 13 10 13 10 104 101 108 108 111 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 for which you can clearly see there are 34 bytes in the file, and every newline is "\r\n" because i used notepad to create the file.   edit-- and if I use GVim to convert the file to unix line endings as I suggested, i get: file is 29bytes read in 29bytes 116 104 105 115 32 105 115 32 115 111 109 101 32 116 101 120 116 10 10 10 10 10 10 104 101 108 108 111 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Where it again, should be clear that no '\r' (13) were inserted without reason, as the unix line endings only contain the '\n' character.
  13. This is entierly dependent on the program and platform you used to save the text file. Windows standard line endings are "\r\n", linux standard line endings are "\n". In binary mode fstream's "read" is only exposing this platform specificness to you by returning the raw bytes in the actual file. It is likely your file actually does contain "\r\n" at every line ending.   It is text mode fstream that will interpret file << "hello\n";  or file << "hello" << std::endl; both as a chance to insert "\r\n" if you're on windows, or just "\n" if you're on linux.   --edit, if you want to see this for yourself in an easier way. Use gvim to convert the line endings in a text file between windows and linux.  In gvim, it will look fine either way because it determines the file mode by the presence of \r\n or \n. But from notepad the windows endings look ok, while the linux endings cause the file to appear as a single line.
  14. On the face of it, this doesn't look that different from many polygon reduction algorithms, which are largely driven by picking an error tolerance.  But could just as easily be done by picking a target polygon count or reduction percentage. In the simplest terms those type of algorithms take your squiggly line and compute an error function for the removal of each point, and then remove points the produce the least error while updating the error on the other points.   Depending on what this data means, you could do it in one or more passes.  A simple one-pass solution (given that this is say, a line stroke from an artist's pen) is to read the line in point by point, collapsing the points as you go via comparison of the raw direction, or the tangents.  This is useful for say smoothing a user input in 3d space to a much shorter list of directions from a very noisy input.  But if this data has more information than just direction, Alvero is on the right track that you want to iteratively reduce your line by removing the points that contribute the least to the overall shape of the function.