KulSeran

Members
  • Content count

    2420
  • Joined

  • Last visited

Community Reputation

3267 Excellent

About KulSeran

  • Rank
    Contributor

Personal Information

  1. Aiming turret (math question)

    You shouldn't need the angles, if you can set the joint's matrix. I'll label your matricies from the base to the barrel as: A (base), B(joint), C(barrel base), D(barrel end) Firstly, you have a target to find, relative to your joint: target_dir = normalize(target_pos - B.pos()) Secondly, your barrel is offset from the joint: offset = D * inv(B) Thirdly, you need to apply that offset to get the correct position, which means rotating your turret into the same plane as the target and applying the inverse of the offset to the target position. offset_pos = target_pos * look_at(target_dir) * inv(offset) Lastly, you have your corrected target position, so you can look at it relative to world space, and multiply by your turret's bind pose to get B in the correct spot. B = look_at(normalize(offset_pos - joint_pos)) * joint_bind_matrix Where "look_at" if your library doesn't define it is basically building a matrix from a guess of the "up" direction combined with your desired "at" direction: look_at(dir) { left = cross(up_guess, dir); up = cross(dir, left); return [at, up, left, zero_vec]; } However, if you do actually need the angle, you can extract them from that final matrix's `at` vector.
  2. Question About Port assignments

    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.
  3. Starting fresh

    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.
  4. 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.
  5. Question About Port assignments

    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.
  6. c++ Performance boost needed

    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.
  7. c++ Performance boost needed

    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.
  8. 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.
  9. GPU ray tracing in real time

    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.
  10. c++ smart pointer question

    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.
  11. c++ smart pointer question

    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.
  12. 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.
  13. 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.
  14. 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.