Polarist

the main difference is that an oct-tree divides the space into 8 regions in each step, so requires less recursion, but has to do a few more checks at each step (since there are 8 possible regions to step into). dividing the space in a binary-fashion allows simpler logic, but a larger number of internal nodes.

That's not necessarily true, you can implement an "oct-tree" with a b-tree under the hood; your recursion step should cycle over each axis.  Thus the number of recursive steps would be similar in complexity to a BSP-tree.

But I think my question was poorly worded.  Simply put, I'm curious about if it's worth it to "choose" a splitting plane versus naively cutting it down some midpoint in the dynamic real-time situation you were describing.  The obvious difference is that choosing the latter would be O(1), and the former would be (presumably) at least O(N).  That of course would pay off as searching would be faster.  If the tree were generated before-hand and kept static, then of course it'd be better to load the cost up front, but in the case of a real-time dynamically generated tree, I'm wondering if, generally, such an approach is still worth it.

It's a bit of a subjective question and it begs more for intuition/experience than a purely academic response, I suppose.

It's not about memory it's about how much CPU time doing a lot of ray casting takes really.

I'm wondering if there's a subtle point here that you're also describing.  If you're just talking about memory allocations, then of course it's almost never an issue, but isn't memory bandwidth is a large bottleneck for speed these days?  I don't work in the games industry, so I'm not aware of the current state, but isn't it a challenge to maintain cache coherency in collision detection systems, too?  Or is cache coherency kind of a solved issue at this point?

Take a look at Screen-Space Ambient Occlusion (SSAO), it's a relatively cheap way to achieve AO.

I'm not sure what effect you're referring to in particular, as there are a lot of things going on in those screenshots..  specular maps, reflections, lens flares, to name a few

If you want a normal vector like the one he describes, then you need to know the polygon that the player is "standing" on.  This requires a much finer calculation than a bounding box, as you need the exact polygon to get that normal vector.  How expensive it is depends on the complexity of the world, but when compared to the super-cheap alternative of  subtraction of two vectors, it's extremely expensive.

It's not that you shouldn't do collision casts per frame, as you do these all the time for things like shooting projectiles and such.  It's just that you only have so much processing power to spare if you want your game to run smoothly, so you'd rather save calculations for other things.  One of the guys mentions that the reason why there are only so many monsters in the game is because more would be too much for the hardware.

Also, keep in mind that this hardware is the PS1 (I believe) so we're talking about much worse hardware than today.

You're talking about different concepts.

Practically every 3d game will find a use for forward, up, and right vectors.  But they also need direction, position, velocity vectors for each entity.

In the context of the video, forward, up and, right are are constantly changing (as opposed to most games which can hardcode "up" to an arrow pointing along the positive y axis, meaning that only forward and right are changing.)  The three directions are a basic inputs used, among other things, to orient the player and to orient the camera (set up a "view matrix" and "projection matrix").  Their optimization was that in a spherical world, the up vector could be calculated simply by taking the position of the player and subtracting the center of the world.  This makes it cheap to calculate the right vector.  This is compared to a more general approach of finding the normal vector that corresponds to the polygon that you're standing on (the collision approach he describes as super expensive).

I watched the entire video (thanks, it was interesting), but they did not compare forward, up, right to direction, position, velocity, directly.  They are not competing concepts.  Defining forward, up, and right are useful constructs to describe orientation, in general.  Where as direction, position, velocity are useful to describe movement and physics and such.

Sounds like just semantics. I think you might be over-thinking the concept if you understand vectors, cross products, and dot products (and other basic ideas in linear algebra).  These are super, SUPER basic ideas, so if they are confusing you then you're probably thinking about them the wrong way.

Again just to make it clear.  EVERY 3D game will use vectors that represent forward, up, right, direction, position, velocity, acceleration, etc.  These are just terms to describe what a particular vector is trying to describe.  Unless I missed something, there aren't "two approaches" here.  

Don't even think about vectors as "a direction and a magnitude," that idea will be limiting and it conveys them as being special in a sense.  Really, the best way to think about it is that a vector is just a number.  (Sure it's actually 3 numbers, but just think of it as a bloated "number".)   So a vector *could* be used to describe a point, or a direction, or a direction and a magnitude, but that's giving them special meaning.  It just happens that in a 3d world, it's convenient to use 3 numbers at a time to describe things.  That's really all there is to it.

(Tangential side note: In higher mathematics, they are useful because often you want to describe things in higher dimensional space or even n-dimensional space, meaning that you don't define whether the problem lies in 1-D, 2-D, 3-D, 12,345-D.  To grasp these concepts, you'll have to "unlearn" that stuff about "directions" and "magnitude" if you've internalized it too much.)

It may be not as efficient, but I tend to use STL everywhere (until I need to optimize).  It's much easier to maintain/read.

const int NUM_THINGS = 10;

std::vector<int> myThings(NUM_THINGS);

for( const auto& thing : myThings ){
   do_something_with(thing);
}

It also makes it quite difficult to accidentally overrun your buffer.

Also, are you using those values (texcoord and bytewidth)?  If not, the shader compiler could optimize those variables away.

I'm not sure what you mean by smooth movement, but I would remove the move___ = false; statements so that you don't have to keep pressing the buttons over.  Once you do this, you would have to add another event listener for 'keyup' and set the move___ = false when that happens.  This way, as long as you're holding down a direction, the gameloop will update your position, but as soon as you let go, it will stop.  If you do it this way, you can change the 6 to a smaller number like 1 to achieve a less "jumpy" motion.

Also, typically you'd want to keep track of your delta_time in the game loop (how much time has passed since the last run of the loop).

Then to update position, you would add (velocity * delta_time) to your position.

It looks a lot like you're not setting the blend mode correctly.  

The black borders is a sign that your texture is stored with pre-multiplied alpha.  (Since you're not handling alpha blending correctly, it'll look black because the color is being pre-multiplied by an alpha close to 0)  This is most likely fine.

With pre=multiplied alphas, you probably want to set your blend mode to something like: S + D(1-Sa)

Hope this helps.