Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Pink Horror

Member Since 02 Jul 2013
Offline Last Active May 22 2015 07:39 PM

Posts I've Made

In Topic: Circle embedded in line-- fastest vector to unembed

20 May 2015 - 02:57 PM

I am only interested in the sign of the dot product. Does that make things more clear?


Yes, thanks.


I'm still curious if it is correct to always move in the direction of the normal of the line segment. For example, if p1 == p2, there's still a best direction. But I was missing something with the sign, so I could also be missing something else.


Edit: oh, maybe I'm missing that it is just a "line" instead of a segment. From the description, I'm not sure. It uses the word line but describes it as a line that goes from one point to another, which I pictured as a segment.

In Topic: Circle embedded in line-- fastest vector to unembed

20 May 2015 - 11:40 AM

I don't know if this is very different from what you have, but it feels more natural to me:

Vector ray_direction = p2 - p1;
Vector normal(-ray_direction.y, ray_direction.x);
Vector from_p1_to_pt = pt - p1;
Vector move_direction = normal * dot_product(normal, from_p1_to_pt);


Does this work? I'm trying to figure out why you would multiply a vector by a dot product, and then immediately normalize it. I don't see how that would change its direction.

In Topic: How to separate xyManager effectively into smaller responsibility classes?

03 May 2015 - 11:12 AM

Well, i am pretty sure passing some refs/pointers all around the code base just because somewhere deeply in the codebase somebody might want to use it is a bigger antipattern than using singletons...
And if 99 command from 100 don't use it, then i feel like it's unnecessary.


And making a global variable so 1 command out of 100 can access it is... better?


I generally agree with the others who don't like global variables. However, this sometimes results in making "Manager" classes, especially when I cannot think of a better name. After all, everything that is not global has to live somewhere else. I don't really feel like having 50 objects sitting at the bottom of my call stack. To organize them into something more manageable, all of these non-global objects have to be packed together into other objects, which may or may not be "managers". I try to avoid the typical ugliness of a manager by keeping all of the real work in the owned classes instead of the top-level class.


So, if a generic Command class needs to be able to mess with anything in the whole world, maybe you have a "World" object that could be passed into it. With just a World object, you might be able to change any gameplay stuff around, but things like the current user input state or a sound player or any rendering commands would be inaccessible. At least you've partially restricted what a Command can do. If the sound player or rendering or user input were just global variables, there's nothing stopping a Command from touching them. At least with parameters, your intent is clear for what a function is supposed to be able to effect.


If some function is supposed to be able to do absolutely anything to the whole game, and every top-level game class is passed into it, at least it's clear that the function can do anything. You might call it an "antipattern", but changing parameters into global variables doesn't solve the problem apparent with the antipattern. It just hides it. Every global variable is already an implied parameter to everything.

In Topic: Random Number Generation

28 April 2015 - 09:54 AM

I guess this is a programming question, but only indirectly (I wasn't sure where to post it).

Anyway, I need random data, and lots of it! I need many megabytes worth of random bits, and it can't be PSEUDO-random, but actually random (at least in the sense that it wasn't created by any mathematically predictable pattern at all)!


Is there any way to prove that even exists?

In Topic: c++ shared_ptr usage

27 April 2015 - 08:23 AM

However, I worry there are some design pitfalls I'm overlooking here, or performance issues I'm not seeing, or simply something I'm unaware of (I would guess it's actually easier on the cpu as it's not copying anything for the parameter, but I haven't profiled it, and I could be mistaken). I can imagine this getting rather convoluted, if not used sparingly (I imagine if the shared_ptr count got rather high, it could be difficult to debug where exactly you're doing something to the object it references).

Anyhow, my question is whether this is a terrible idea, for reasons I'm overlooking, or if this would be considered a rather typical use of shared_ptrs and is completely recommended? I find plenty of information out there of how shared_ptrs work but little in the way of practical use cases for them. I'd welcome any advice, whether general or specific here. Thanks in advance


If you're doing this for performance, it sounds like a bad idea.


With a reference or raw pointer passed as an argument, the only thing that might be copied is a pointer that is currently in a register or on the stack, and it will be copied into a register or onto the stack. Also, by adding another parameter, you might cause other reads or writes involving the stack, saving and restoring registers or forcing other arguments onto the stack. So, it's not guaranteed to be free, but register copies are pretty close to free compared to memory access, and stack access is likely to use the cache. There's also a good opportunity for inlining such copies away.


With a shared_ptr in each object that relies on some resource, when that pointer is used, it has to be copied from memory into a register. Depending on how often you use the pointer and what code your compiler has available when it is optimizing, that load might happen just once or multiple times in a function - it might not be able to assume the pointer stays the same. Also, if you have many different objects with the same pointer - and you suggest this will be the case when you mention ref counts - every different copy of the pointer has to be loaded from memory before it is used. I sincerely doubt the compiler will be "smart enough" to treat them like they all point to the same thing. If you imagine a loop calling the same function on a bunch of objects using this pointer, that loop goes from loading a pointer from the same location on the stack each frame (or using registers) to skipping through memory. Now, you're probably using other chunks of memory from these objects, so it's not that bad, but it's still probably worse than the problem you're trying to solve.


And, if you use this pattern often for many different classes, you will also likely run into the problem of circular references. You'll have to switch to weak_ptr or add unitialize functions to unset some shared_ptrs to allow things to be deleted.