optimize algorithms.. for example this one:
for every vertex {
for every triangle {
if vertex is part of this triangle {
generate face normal
add face normal to vertex
}
}
}
that means you go through every triangle for every vertex.. an O(n*m) operation
if you do it like this:
for every triangle {
generate face normal
for each of the 3 vertices {
add face normal to vertex
}
}
(as you stored the indecees to the vertex array you find the vertices for free, just use the indecees)
result:
O(3*n) for the vector additions, O(n) for the crossproduct..
result is that for meshes with big polygoncount say 1024 vertices and 1024 faces (if this is possible..
)
your amount of calcs go from 1024*1024 to 1024*4 (more or less
)
a boost of 256!
algorithmic optimations are always great.. if your algo is short and clean structured, it normally is fast (means if you know what you do you are not too stupid to do it slow
)
an other thing is data management object oriented programming can help there a lot but not at all if used wrong (you possibly know the scare cries uh virtual function calls are SLOW! they arent.. if used correctly.. means not perpixel please, but per object its no problem at all)
means structure your whole code to be fast.. this is easy for simple engines like this:
while(1) {
for every object {
object->Update();
object->Draw();
}
}
but gets difficult with networking and other stuff and fixed time steps but variable frame rate etc..
depends on what you wanna do
dont try to optimize onliners of code..
but make sure you don''t do some major faults:
if you know math, you can get rid of a lot of trigonometic funcion calls with trigonometric identities or a simple piece of paper..
example:
cosine(2x) == 2cosine(x)^2-1
if you calculate with halfangles (often used for fast perpixellighting) you can''t use for example this:
cosine(2x) = cosine(2*arccosine(x)) in a pixelshader.. those functions are simply not there in..
math functions used in your engine should not use that much if/else statements, for example in a vector class there should be no if/else (except for the normalization making sure /0 does not happen.. well except u use an automatic function taking care of this, namely some fast_reverse_square_root
)
try to optimize the mathfuncs if you _WANT_ (like invert_matrix4x4 or something) but don''t try to optimize one-liners like that x = -x or something..
this is job of your compiler, not of you..
and if you write it in a normal way the compiler will have a big chance to recocnise this structure and says ahh! he wants to negate it! so well.. lets use an automated assember instruction wich simply changes 1 bit, the sign bit.. if this is fast on the cpu.. (the instruction is called fneg i think, but not 100% sure
)
care about a fast collisiondetection algo, not about a fast sign-inversion-algo
for your main question:
if you have a surface normal vector, then a reflection for arbitary directions is this:
reflected = incomming - 2*dotproduct(normal,incomming)*normal
for a bottom floor the normal is for example (0,1) (1 is one in y direction, one up)
resulting equation:
reflected = incomming - 2*(0*incomming.x+1*incomming.y)*(0,1)
reflected = incomming - 2*incomming.y*(0,1)
reflected = incomming - (0,2*incomming.y)
this means your x-direction is not affected, but the y-direction gets
reflected = incomming.y - 2*incomming.y = -incomming.y
what the suggestions had for reflecting on the floor
got some ideas?
"take a look around" - limp bizkit
www.google.com
