Since you are adding to the angle, you should be adding 0 when the mouse doesnt move. However, if the mouse doesnt move (dx=dy=0), you end up adding mouseSpeed*float(width/2) horizontally and same for vertical.
If you want to move the camera when the mouse moves, remove the width/2 and height/2 parts and it might work like you intended it to.
If you want to move the camera whenever the mouse is not at the center of the screen, pass in the mouse position relative to the center of the screen (mouse.x-width/2, mouse.y-height/2) instead of the delta position.
I think the tool to use here is the Separating Axis Theorem (SAT). If there is a plane/line that separates two objects, they dont intersect.
Basically, you would take all the planes (/lines) that bound your rectangle (based on the faces of the rectangle),
Then, for each of those, you check if the other box is completely on the 'outside' side of the plane (you can do this by checking each vertex separately).
If the above is true for even a single plane/line, there is no intersection.
This works for any convex shape. It wont get you the point of intersection though, but you didnt need that. Google for an optimal way to implement it, the above was just a vague description of how it works (might not even be exactly correct).
Yeah you usually do mirrors by rendering the scene from the mirrors perspective.
Think of the mirror as a plane.
Now, to render whatever the mirror should see, simply REFLECT MIRROR the real camera to the other side of the mirror and render (render only the area of screen covered by mirror) on top of the real scene. The mirrored camera should not render anything behind the mirror plane (so you only render the part of scene on one side of the mirror, the side that can actually be reflected off of it)
I dont know, ive never implemented anything like it.
I guess you could throw away the concept of edges entirely and only have vertices, but the vertices dont need to be points, they could also be lines.
So all you would need to change is to make collisions be against a line instead of a point, and modify them constraints such that they try to match up the endpoints of the lines instead of the centers.
One way to do it at least is to treat each vertex as a small mass.
You then do collisions to those vertices individually.
Then you have some constraints which attempt to keep the rope in a rope like form (keep adjacent points at a set distance apart basically). Youll likely need a proper integrator to avoid the rope exploding all the time too...
I guess you could also test collisions against the edges for more accuracy, but testing only the points is probably sufficient in most cases if they are not too sparsely spaced.
You need to either modify the higher LoD chunk to have the edge vertices align with the lower LoD vertices of the adjacent chunk (someone used different index buffers to do this, such that the correct indices for the cracks not to appear can be used depending on the LoD levels of the adjacent chunks) or you need to use some kind of 'skirts' (between the chunks, connecting the two chunks together)
There are lots of resources online since this is a somewhat common problem so you should be able to find something using google.
It doesnt really need to be a text file if you can just separate the bounding box definition code to its own source/header file, or wherever that information can be hidden without getting on the way.
How is your game structured? The example you posted has some magic numbers (which should probably be defined elsewhere, maybe not in a separate text file but elsewhere in the codebase), doesnt have any vector class or bounding box class to make the operations neater, and the check against a single object in the scene has been hardcoded.
-Make a Vector class to represent positions, so you dont have to do everything 3 times once for each dimension.
-Make a bounding box class to represent bounding boxes for the same reason
(So you can do if (nuclearBunkerBB.contains(player.position)) to check if the player is in the box)
-Try to abstract the collision code such that all objects are treated equal if possible. Most objects probably behave pretty much the same regarding collision, so you can have a vector<Collider> which you loop over to check for collisions. If you need object specific collision responses, you can give each Collider a callback function or something similiar which allows you to implement these custom behaviors.
-Define the magic numbers and such so that the logic isnt filled with them. This is somewhere where you define what a nuclearbunker is, or what a player is. These definitions can be loaded from disk, or they can be defined in code (Eg you could do something like have a vector of object types, each one identified by some enum, and each object type tells its dimensions and any other relevant information)
I think a single crossing per road wouldnt look too bad if you make it so that they always cross relatively perpendicular to each other (you could even make it be a perfect square angle crossing if you did some fancy curve based roads)
Or some sort of tunnel where there is a crossing so that the roads wont overlap.
The quadtree itself doesnt do anything, its used as an aid to broad-phase collision detection to query the world to find sets of possibly colliding objects. The objects are usually represented by simplified geometry such as spheres or bounding boxes.
I would implement this by doing a breadth first kind of search down the quadtree to find pairs of potentially colliding objects (if two objects are in the same node, they are potentially colliding, even if one is in a subnode and the other in a higher level node)
You can either place the objects in the deepest cell in which they fit entirely, but that causes some objects that are located on the border of the high level cells to not really fit anywhere, possibly rising all the way to the root, such that the quadtree is only partially effective.
One solution to this is 'loose quadtrees' where the rectangles representing the nodes overlap (the node sizes have been essentially doubled along each axis). This means you can place the objects using their center position, and there will always be a node to place it in at a depth corresponding to the size of the object being placed. Naturally this means you also have to check adjacent quadtree nodes when finding sets of potentially colliding objects now that the nodes overlap with each other.
Im not exactly sure what you mean by depth, but if you mean the amount of levels in the quadtree or what levels the objects are placed in, that is probably very dependent on the situation. Its possible to make a quadtree that can create new levels as required to grow practically infinitely. If all your objects are of the same size, you can place them all to the leaf nodes of the quadtree (in this case a hashmap or something might work better, might not). If you have multiple sizes, you can use all depths.
You basically optimize it to the situation.
You should also consider the difference between 'dense' (???) and sparse quadtrees. Eg. Do you allocate nodes from somewhere as they are needed, or do you implement it using some multidimensional grids.