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!


Member Since 28 May 2011
Offline Last Active Yesterday, 04:02 PM

#5240866 typeid operator

Posted by Waterlimon on 16 July 2015 - 12:42 PM

I think std::type_index is what you are supposed to use here. Assuming C++11.


IIRC its implemented as a pointer to the type info so if you dont have C++11 you can read if the standard says anything about directly using a pointer to the type info structure as the key. EDIT: though it says nothing about how the comparison is done so its possible that internally it just compares the string names or other such complicated operation.


Why would the hash_code() or name() functions ever return the same for two different types? And why could they change on different invocations of the program?

Hashes compress a large amount of information into a smaller amount of information so by the pigeonhole principle some pieces of information will 'compress' to the same hash. These are called hash collisions and are inevitable unless you specifically find a hash function for a set of known data that has no collisions. That could be done here, but if its not in the standard, its not.


The reason the name might be same for different types is probably the same. For some reason, it wasnt thought necessary to require that. Perhaps the intended purpose of the method is different and does not require uniqueness.

#5239969 best way to connect 2 random people around the world in winsock

Posted by Waterlimon on 12 July 2015 - 05:19 PM

If you have a central matchmaking server you can do NAT punchthrough to circumvent the need to do port forwarding.


Though its not 100% guaranteed to work so in some cases it might be necessary to route traffic through the central server, or do port forwarding manually, so take that into consideration. You can probably find statistics online for how well it works.

#5239789 How do I find the tiles that a sprite occupies in a tile based game?

Posted by Waterlimon on 11 July 2015 - 02:10 PM

You basically need a 2D collision detection algorithm, with the knowledge that some of your colliders are static, uniform size, and organized in a uniform grid.


That knowledge allows you to implement a fast broad phase detection so you quickly find which tile-entity pairs to test against each other for collision. Eg use the AABB of the entity and an algorithm like Juliean posted to quickly find which tiles MIGHT be colliding with the entity, then do AABB-Circle or AABB-Convex polygon or whatever tests to get the precise answer.



1. Implement a broad phase collision detection, treating entity as AABB. to find tiles which might be colliding with the entity

2. Use appropriate function to do more precise collision detection between those tiles and the entity shape (google for eg AABB-circle, AABB-polygon, AABB-OOBB collision detection or whatever you need for your entities)


Also consider using a proper physics engine to do this if it seems likely youll need more advances physics later on. It might take some work to optimize it to take advantage of the fact that you are checking for collisions against a regular grid of tiles instead of arbitrarily placed boxes.

#5239032 Simulating the sun

Posted by Waterlimon on 08 July 2015 - 12:20 PM

You could just write a quick simulation of a virtual earth orbiting around a virtual sun, initialize it at some time of year, time of day, with correct axial tilt, calculate the orientation matrix of the place on earth (using latitude/longitude) and then do a bunch of matrix math to transform the sun direction into that local space. (or probably quaternions since youre only working with rotation, not translation... assuming they can do the same operations without having to go through matrices anyways)

#5238195 Portal view

Posted by Waterlimon on 03 July 2015 - 09:32 AM

To render the scene from the other portals viewpoint, the camera position/rotation must be same relative to the other portal as it was to the first portal.


Of course the other portal will be facing out of the wall, while the first portal will be facing into the wall.


So if you camera is 5 meters in front of the first portal, it needs to be 5 meters inside the wall when rendering the scene from the other portals point of view.



This 'relative position/rotation' would normally be encoded in a 4x4 affine matrix and you would use matrix math to calculate the correct location for the camera.

The logic would be something akin to (portal1 and portal2 are matrices that hold the pos/rot of the portals):

Matrix relative = portal1:toObjectSpace(camera)
Matrix renderFrom = portal2:toWorldSpace(relative) //if portal2 faces out of the wall and portal1 faces into it, this works. If not, I think you need to transpose/inverse the relative matrix first

I dont know how to express that using 'proper' matrix notation. Probably something like

relative = camera * inverse(portal1)

renderFrom = portal2*relative

(renderFrom = portal2*inverse(relative) if portal2 is pointing into wall just like portal1)

But Im really not sure.


If you are not using matrices, you can use the same logic as in the first piece of code except instead of matrices you do the operations on position/rotation or whatever it is youre using.


Also since the camera will be inside the wall when rendering the scene from other portals PoV, you need to make sure nothing behind the portal gets rendered somehow (unless required for reflections or whatever).

#5238038 Edge artifact with basic diffuse shading

Posted by Waterlimon on 02 July 2015 - 12:51 PM

Looks like you have face-culling disabled and the depth-buffer precision isn't enough to avoid Z-fighting at the edges.

Create a 24-bit depth-buffer, or increase the distance to your near-plane in the projection matrix, like changing 0.01 to 0.1 or even 1.


Its implicit here, but you should enable face culling if you dont need it to be disabled, as well. At least this particular scene does not need it disabled, assuming the cube meshes are defined correctly (counterclockwise order defined triangle vertices)

#5237212 Hash Table Element Lookup

Posted by Waterlimon on 28 June 2015 - 01:16 AM

If you did that, you would also have to compare the actual values at the end (due to possibility of collisions).


So either you:

A. Compare each key in list until correct one is found

B. Do A, except add a hash as part of the key to more quickly reject nonmatching keys


Given that:

1. You probably wont have very many keys in the list

2. The keys will probaby be rejected pretty quick anyways (for random strings in the map, most can be rejected after a single char-char or string size comparison!)

3. You have to do the full comparison anyways at least once


Storing the hash and using that doesnt seem to add much when it comes to optimizing the search for the correct element in the list. Perhaps if all your strings tend to begin with the same initial characters and theres many of those characters (so you can use the hash to 'early out' from the costly equivalence check).



But, there is another good reason to store the hash with the key-value pair. If your key is expensive to hash (depends on key and hash func), resizing the hash table will be very expensive since all keys have to be hashed to place them in the newly resized table. If you store the hash, no rehashing needs to be done. This wont be very useful if the table doesnt need to be resized, or if the keys are not expensive to hash as mentioned.

#5236919 Researchers, Archeologists and...

Posted by Waterlimon on 26 June 2015 - 08:16 AM

Reverse engineers?

#5236483 Glitches in Navigating my NavMesh

Posted by Waterlimon on 23 June 2015 - 08:59 PM

it seems you want the agent to overshoot the waypoint if entering the portal 'region' from left, and undershoot if from right (eg would leave portal region if overshot)


Let p1 and p2 be the waypoints that define the portal, with p1 our waypoint and p2 the other one.


Find (p2-p1).unit and take dot product of that and agent position.


If negative, overshoot. If positive, undershoot. This should ensure you never go too far or get stuck in corners etc.

#5236472 how to get length of a int vector without overflow on 32 bit int

Posted by Waterlimon on 23 June 2015 - 06:20 PM

Divide the vector by a constant before finding length, then do the sqrt(dot(v,v)), then multiply it back up. This will avoid overflow in the dot operation. Ideally you would only do this when required, eg if any component is so big it would overflow if squared (>65535 ?) and the constant would 'normalize' the vector WRT this 'maximum limit', so the largest vector is brought down to 65535 or below.



int largest = findLargestComponent;
int bits = 0;
if (largest > 65535) //squaring would overflow
bits = ceil(log2(largest)); //how many bits in the int the largest component takes - squaring will double this (usually? always? dunno)
int scale = bits - 16; //by how much we must adjust to avoid overflow
vec >> scale; //adjust every component (division by 2^scale)
return sqrt(dot(v,v)) << bits; //make sure shift by 0 is ok or dont do it in that case...

So thats how I would solve the issue with overflow when squaring in dot.


Then theres the issue with overflow when adding the squared components in dot. this can increase the bit usage my at most 2 bits (multiplication by 3 if each component is maximum size) so maybe just add 2 to the 'bits' variable (or calculate if its 0, 1, or 2, but that feels like a waste of performance):

int largest = findLargestComponent;
int bits = 0;
if (largest > 65535) //squaring would overflow
bits = ceil(log2(largest)) + 2; //how many bits in the int the largest component takes plus extra to make room for addition
int scale = bits - 16; //by how much we must adjust to avoid overflow
vec >> scale; //adjust every component (division by 2^scale)
return sqrt(dot(v,v)) << bits; //make sure shift by 0 is ok or dont do it in that case...

Now the only issue is the final shift to right to scale it back to the original coordinate system. Since as you say, vector length can be bigger than 2^32.


The only solution is to either:

-convert the sqrt result to 64 bit before returning, shift, return that

-dont shift by bits, but return the unshifted number and the bitcount.

-return as float. We have the mantissa (what the sqrt returns) and the exponent (bits). This is pretty much what floating point numbers were made for. Eg convert sqrt result to float, multiply that by 2^bits (=shift by bits). But at this point you might just want to do all the length calculation using floats...


EDIT: oh you already did this... :>

#5236125 Read a text file from a .zip container

Posted by Waterlimon on 22 June 2015 - 03:02 AM

So what exactly do you get instead of the expected data?

#5235871 Model View Controller

Posted by Waterlimon on 20 June 2015 - 10:16 AM

AFAIK the controller exists to allow having an interface between the source of input and the model. So you could control the model using keyboard, AI, network, or some complex mess with little bits from here and there.


Maybe have something like




And in the controller you somehow link that to the correct input 'device' (at the simplest maybe youll just read keyboard state to determine the x and y to do the above call)


Just design the interface between model and controller such that the division is actually useful for different controllers you might have - worldModel.attemptMovePlayer(keyboardkey) would be kind of pointless.

#5234911 Calculate volume of convex solid?

Posted by Waterlimon on 15 June 2015 - 10:57 AM

The volume algorithm works by taking each face. Then we work in a space where the face is axis aligned. The dot product in this space gets the distance from the face plane to the origin (doesnt matter which vertex is used - theyre all on the same plane!).


The edge/area of the polygon is proportional to this origin-to-plane distance - its 0 at origin, full value at the plane end.


For 2D we integrate length of edge over this distance to get area. For 3D we integrate face area over the distance to get volume.



Integrate(0->1) edge*x dx  (edge(x) = edge*x)

=> edge*x*x/2 (x = 1 for full area)

=> edge/2 (so in 2D youd divide by 2 instead of 3)


Integrate(0->1) area*x*x dx (area(x) = area*x*x because area grows/shrinks on 2 dimensions as x changes instead of just 1)

=> area*x*x*x/3 (x = 1 for full volume)

=> area/3 (so we divide by 3 in 3D)


I guess you can generalize it so it always divides by the amount of dimensions...

#5234879 Scale world geometry with an aspect ratio?

Posted by Waterlimon on 15 June 2015 - 07:26 AM

If user is looking at center of screen, more 'stretched' image at edges looks correct (the edges of screen take less space of your visual field because theyre far, so this 'reverses' the stretching from users point of view)


It only looks incorrect if:

-User doesnt look at center of screen (And unless youre going to use a webcam or one of those head direction trackers to figure out where they look, you can do nothing about this)

-FoV is wrong


I dont recommend doing any math on vertices. Triangles will remain linear, so if you do nonlinear math on vertices, triangles will not line up.

You need a per-pixel process.


Eg render as:

1. Draw scene to offscreen texture normally

2. Use shader to draw a fullscreen quad that reads from the texture. Modify the texture coords based on position, so the result is stretched in center and compressed at edges.


I dont recommend that either as it will probably make other stuff harder to implement, and probably wont even look correct.


If your game doesnt have the mouse fixed at center of screen, perhaps you can use that as "position user is looking at" and translate the projection so its centered there. This way stretching will not happen where user is focused.

#5234876 Scale world geometry with an aspect ratio?

Posted by Waterlimon on 15 June 2015 - 07:13 AM

Are you setting aspect ratio as x/y or y/x? (should be former)




Or do you perhaps mean how the geometry at edges of screen appears "stretched"?