Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 28 May 2011
Offline Last Active Today, 02:55 AM

#5169512 What happened to Rastertek?

Posted by Waterlimon on 27 July 2014 - 09:29 AM



seems to have the tutorials there, dont know if you can download the files though.

#5168563 Rotating camera with mouse

Posted by Waterlimon on 22 July 2014 - 10:00 PM

m_horizontalAngle+= mouseSpeed*float(width/2-dx);

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.

#5168004 [Depth buffer] From linear -> non-linear depth values

Posted by Waterlimon on 20 July 2014 - 02:58 PM

You should be able to just do the inverse operations in the exact reverse order to do that (+ becomes -, / becomes * and apply operations in reverse order)

#5167408 2D rotated rectangle collision detection

Posted by Waterlimon on 17 July 2014 - 08:50 AM

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

#5166834 How to avoid "stacks of doom" in 4X?

Posted by Waterlimon on 14 July 2014 - 03:45 PM

The usual solution seems to be area of effect based weapons.

Ineffective against single targets but can be very effective against larger groups.

Try to come up with a similar mechanism maybe.

#5160559 problem with my reflection idea

Posted by Waterlimon on 14 June 2014 - 05:31 PM

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)


Idk how to do that in unity tho.

#5159735 2d Physics of Rope

Posted by Waterlimon on 11 June 2014 - 05:35 AM

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.

#5159704 2d Physics of Rope

Posted by Waterlimon on 11 June 2014 - 02:12 AM

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.

#5157602 Terrain LOD tessellation cracks

Posted by Waterlimon on 02 June 2014 - 12:54 PM

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.

#5155995 What am I forgetting to optimize?

Posted by Waterlimon on 26 May 2014 - 06:12 AM

Profile all of dat code and youll find out.


Could it have something to do with the camera angle relative to the ground? Do you have LoD for everything?

#5155439 Best way to store collision detection BBs

Posted by Waterlimon on 23 May 2014 - 08:17 AM

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)

#5155191 Roads (connection between villages/cities)

Posted by Waterlimon on 22 May 2014 - 04:55 AM

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.

#5154586 How collision detection relates to Quadtrees

Posted by Waterlimon on 19 May 2014 - 02:40 AM

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.


Posted by Waterlimon on 04 May 2014 - 04:08 AM

a please into more of coherence

#5148552 Fast-moving 2D collisions?

Posted by Waterlimon on 21 April 2014 - 10:54 AM

If your game is simple, I would probably just do some extra physics updates for fast moving objects to decrease the distance they jump over between collision checks.


Eg instead of






for 1 to n do:

Ball.updatePhysics(dT=(1/FPS) / n)


where you determine n using the velocity of the object relative to its surroundings. If its moving fast, you increase n to advance its physics in smaller steps.