Jump to content

  • Log In with Google      Sign In   
  • Create Account

Mussi

Member Since 12 Oct 2004
Offline Last Active Today, 06:30 PM

#5247722 Matching Parameter Names to Class Fields

Posted by Mussi on 19 August 2015 - 12:59 PM

If your declaration and definition are separated, i.e. you have a .h and .cpp file, you can use a different name in your definition like gasIn or gasArg while still having declared it as gas.




#5247363 Code Review

Posted by Mussi on 18 August 2015 - 05:23 AM


'rotated' is supposed to be treated as a bool value. I use uint8_t because I wanted it strictly typed for POD purposes so it's more portable when exporting to a file. I try to stay away from bool when working with POD due varying to compiler implementation. bool can vary between platforms/implementations, so I wanted to strictly type something to an unsigned 8-bit value. Also, it doesn't seem like I can XOR bools on some compiler. I use XOR to toggle rotation state of my BinRects. If using a bool, I could toggle simply by myBoolVar = !myBoolVar. Checking > 0 is true, but again, I should just check if(rotated == true) { }. Would a bool still be a better way to go? It'd certainly make it more readable.

If you want to go for portable serialization you should either be using a library(e.g. Boost::Serialization) or manually write the serialization code, because even for POD structures, the memory layout may differ due to alignment and padding and then there's also the issue of endianness.

 

Also for clarity sake simply write the following instead:

if(rotated) {}



#5246792 How can this code be refactored to be more proper OOP?

Posted by Mussi on 15 August 2015 - 05:59 PM

Why is the Enemy class responsible for loading textures?

 

Personally, I would just make a member public if your set method is just an assignment, if it's not, it should probably not be called set in the first place. This saves you from having to write unnecessary setter and getter methods. Now some would argue that it's good to have these methods for re-factoring, which is arguably a good point, but I personally have never felt bottlenecked by having to re-factor a public variable to a private variable. Also, I think they look hideous tongue.png.




#5246712 A little math problem

Posted by Mussi on 15 August 2015 - 09:58 AM

Shift everything so that the range becomes 0 to 2n + 1, then it's basically the same as indexing a normal array:

i = (y + n) * dimx + x + n
x = i % (2n + 1) - n
y = i / (2n + 1) - n



#5244292 Octrees with multiple-sized objects

Posted by Mussi on 03 August 2015 - 08:46 AM

It depends on your octree implementation. If you only allow for leaves to contain objects, your "planets" might cause many "asteroids" being contained in a single leaf. In this case you could create two octrees, one for very large objects and one for smaller objects.

 

If you allow for all your nodes to contain objects, you can place a large object into the biggest encompassing node and your smaller objects into sub-nodes of that node. This will increase the size of your octree data structure though.




#5242784 Who wants to see a C replacement?

Posted by Mussi on 26 July 2015 - 11:28 AM

Jonathan Blow is working on a new language, he has a lot of good ideas. You can check out some demos on his Youtube channel.




#5241766 Sphere - triangle intersections

Posted by Mussi on 21 July 2015 - 02:17 PM

Removing that line makes my characters unable to move.

solveCollision doesn't fully move my basePoint, it only moves it to the point of intersection and changes the velocity vector to a "slide" vector, so (basePoint + velcoity) will make the sphere slide.

 

Ah I see, it should be placed in an else block then:

//solve that collision
if(col.foundCollision)
{
    solveCollision(&col);
    iter++;
} 
else
{
    col.basePoint += col.velocity;
}

As for your other problem, have you tried not positioning exactly onto the plane by moving slightly less?




#5241425 Sphere - triangle intersections

Posted by Mussi on 19 July 2015 - 04:15 PM

You're weclome, feel free to up vote any post you deem helpful :D.

 


1. In the collision response routine on page 47, why does the author moves the sphere slightly less than the collision detection routine suggests?

 

This is to avoid floating point issues, trying to move exactly on to a plane might cause it to be seen as inside the plane on your next iteration. Moving slightly less than the exact distance will prevent any bugs concerning pushing the sphere out of plane into another one.

 

Your second issue is caused by an illegal move in your simulate method:

col.basePoint += col.velocity;

You haven't checked collision for that, so this will cause you to go through planes. You already move in your solveCollision function, so removing that line should fix your problem.




#5241280 Sphere - triangle intersections

Posted by Mussi on 18 July 2015 - 04:19 PM

//slide plane from point and normal
Plane slidePlane(colPacket->intersectionPoint, colPacket->basePoint - colPacket->intersectionPoint);

 

Are you sure the normal is correct? I think you want to use something like (basePoint + t*velocity) - intersectionPoint instead of basePoint - intersectionPoint.

 

Also this line:

colPacket->velocity = colPacket->velocity * colPacket->nearestDistance + intersectionToNewDestination;

nearestDistance is the actual distance, i.e. multiplied with the length of velocity, but here you are multiplying it again with the velocity. I think your intersectionToNewDestination is the new velocity you want.




#5241220 Sphere - triangle intersections

Posted by Mussi on 18 July 2015 - 10:33 AM

Ah I see, well I don't see anything pop out really. How do you calculate the signed distance to a plane?

 

What happens if you remove the collision response and just stop once you collide?




#5238764 How to make 3D art look more like a 2d?

Posted by Mussi on 07 July 2015 - 07:41 AM

On the topic of making 3D look like 2D, you might find this talk about the art style of Guilty Gear Xrd interesting

 




#5238170 Setting the pivot point for exportation

Posted by Mussi on 03 July 2015 - 07:30 AM

That creates a bigger box, but you should really be translating your box upwards(as in add something to it's y position). I'm guessing the box is clipping through your ground where you can't see it's actually bigger than the boundary of the mesh. So something like:

// Draw model here
D3DXMATRIX matrix;
D3DXMatrixTranslation(&matrix, 0.0f, (m_vMaxd.y - m_vMind.y) / 2, 0.0f);
directXDevice->SetTransform(D3DTS_WORLD, &matrix);
// Draw bounding box here



#5238163 Setting the pivot point for exportation

Posted by Mussi on 03 July 2015 - 06:21 AM

Are you sure your bounding box becomes half it's size? I'm guessing half of the box is just clipping through the ground. If you add

(m_vMaxd.y - m_vMind.y) / 2

to the y-position of your bounding box, does it show up correctly?




#5238160 Setting the pivot point for exportation

Posted by Mussi on 03 July 2015 - 06:08 AM

Does the 3DS Max pivot even export to X? I can't recall that, but I would position models so that (0, 0, 0) is the ground, if you ever want to animate your models this will make your life easier. This means you will have to adjust the position of your bounding box, either manually or automatically.

 


But if I put the pivot point at ground zero, the bounding box will be half the size.

Why is that? How are you getting your bounding box?




#5237371 Why didn't somebody tell me?

Posted by Mussi on 28 June 2015 - 06:41 PM

Wow... those debugger tips, 16 minutes in and I'm pretty sure this is one of the best videos I've watched in quiet some time! Writing expressions in comments during debugging and evaluating them on the fly == mind is blown.






PARTNERS