scgames

What are you trying to accomplish doing these conversions?

For everything but the size_t warnings, they are API function return values being used as arguments for other API functions.
For the size_t warnings, I get it for using vector/string's .size() as input into a API functions.
ID2D1HwndRenderTarget->DrawText(wstring.c_str(), wstring.size(), ...etc...);

I'm not sure which DrawText() function that is, but you might check and see if a second argument of '-1' is taken to mean 'treat the input string as null-terminated'. If so, you could just submit -1 and avoid the problem entirely.

Otherwise, assuming you know what you're doing, you can use static_cast<>(), as mentioned previously. The case of needing to submit an unsigned integer value to an API that expects a signed integer is fairly common, I think, and a static_cast should be fine in that case. (I'd be more wary of casting a floating-point type to an integer type though. There are certainly cases where that's appropriate, but just be sure you have a good reason for doing it.)

Is there any particular reason you're storing a pointer to a list<int>, rather than just storing a list<int>?

The camera transform shouldn't be all zeros. The fact that it is suggests that something has gone wrong elsewhere in your code, so I think the next step is probably to figure out why the camera transform has that value. (At the very least it should be identity. But, if the camera seems to be working correctly otherwise, I'm guessing you're just using the wrong matrix there or something.)

I'm not sure how GLUT works with respect to creating the OpenGL context - is the context created in glutInit(), or in (e.g.) glutInitDisplayMode()?

I'm sure someone else will know the answer to that question, but meanwhile you might check the docs and see if you can determine it yourself. (The OpenGL initialization code needs to be run *after* a valid context is created; otherwise, run-time errors can occur.)

I need to find this vector to prevent overlap.
Problem is i don't know how to find it ,with sat, because the main article i was using didn't say how

As you already know, for each axis that you test, you project the two objects onto the axis (in one form or another) and check to see if the projections overlap. Here's an example of what this might look like for one axis:

  -------------------------
  |                   	|
min1************min2*****max1**********************max2
             	|                                  |
             	------------------------------------
------------> (direction of axis)

If you can cause the projections of the objects no longer to intersect along any axis, you'll resolve the intersection. In the above example, you could resolve the (1-d) intersection by moving interval 1 to the left or the right. It should be clear that you'd have to move the interval much farther to the right than to the left. Therefore, for this particular axis, the direction to move object 1 is to the left (with respect to the axis), and the distance to move is max1 - min2.

If you perform this process for all of the axes, you'll then have a direction-distance pair for each axis. Find the one for which the distance is smallest, and that's your minimum translational direction-distance pair.

To summarize, the idea is to look at each axis in turn and find the axis for which the two objects overlap the 'least'; the minimum translational vector can then be derived from that axis and the projected intervals of the two objects for that axis.

NO MATTER how great I may become at programming, my original opinions will never change. I may take them in a different direction somewhat, but what I believe is what I believe. And that's correct, mostly. I do not EVER give things out and change them, I just may work them into better explanations that I once wasn't so good with. But one thing you'll NEVER find me doing is changing my opinions altogether. Never.

Just remember that there's a difference between sticking to one's principles, and being unnecessarily rigid and unwilling to learn and grow. While the former may be admirable, the latter is unlikely to serve you well as a developer.

To track down the car position, i will have to update the position vector each time i press up and down key. If the car is simply moving forward and backward, no problem. BUT when i press left/right, the orientation of the car will change, and the car will have to move forward/backward relative to the orientation of the car. Now, i will have to track both the X & Y Coordinates of the car's position. Here is another problem now!

Yup, that's what you have to do :)

You can store the position of the car as a vector. When it comes time to move the car (linearly), you'll need a vector representing the current forward direction of the car; then, you would add this vector (scaled by the speed and the time step) to the position vector.

There's a few different ways to compute the direction vector. If the car only rotates about its up axis, you can compute the direction vector using a little trig. Another option is to extract the forward direction vector directly from the transform matrix.

Nice example videos :) But yeah, what you're seeing in the second video is exactly what you should expect.

I explained what the problem is a couple of times previously (and I think The King2 did as well), but perhaps it was lacking context. If there's anything about those answers that was unclear, feel free to ask and I'm sure we can get it cleared up.

You need to step through it using the debugger; that will be by far the most straightforward way to determine what's going wrong.

If you're not sure how to do that, we'll be happy to help. Just tell us what development environment you're using, etc., and someone should be able to point you in the right direction.

That sounds a little misleading though...

If you're just programming for yourself and/or to learn, you can do whatever you want. In just about any other context though, your analysis is wrong.

Libraries that'll work out problems for you? How are you actually programming then if all these "libraries" are going to complete a lot of the work for you?

By that logic, the only way to 'actually program' would be (I guess) to build a processor yourself, design the instruction set yourself, and write everything in raw machine code (or something).

No matter what level you work at, there's going to be *some* work that's already been done for you. Otherwise, it'd be nearly impossible to produce anything, ever. Technology being what it is today, to get anything meaningful done, it's usually a requirement that one's work be built on the previous work of others, period.

I find that appalling because in the good old days the work was harder but you felt like you were actually doing the "work", you know?

Almost all games are built using at least some existing technology (whether it's a licensed engine, a graphics API such as OpenGL or DirectX, or whatever). It may be that the way games are made has changed somewhat, but you have to remember that the games themselves have changed as well. Today's AAA game is the product of a large team working (in some cases) for some number of years, and that's *still* using existing technology. Creating everything from scratch just isn't practical anymore for projects of that scale (or for just about any project, arguably).

Sure, "re-inventing the wheel" may be harder but it's always going to be more appreciated in the end.

By whom? The end user is unlikely to know or care how your game is implemented. If you're working for someone else, it's unlikely they'll 'appreciate' it if you spend a month implementing subsystem X when you could've just used library Y. And most people with experience will be more impressed by your ability to choose and utilize existing tools wisely than to spend great amounts of time re-implementing the equivalent functionality from scratch.

There are certainly cases where doing the kind of work you're talking about is important and/or appropriate, but 'always' more appreciated? No.

Plus, to make a game exactly like FF7 it'd be close to impossible without tons of workarounds to make the game flow and logic much slower, low-poly and no tessellation at all plus stencil buffers and low-quality graphics. It'll seem almost like DirectX 9 is too powerful, in some ways, without some amazing knowledge on how to re-create the "past"....

I'm not completely sure what you mean by all that, but the things you mentioned really shouldn't be issues. (For example, the 'speed' of game flow and logic is completely under your control, regardless of what technology you're using, more or less.)

It's clear you've got some strong opinions, but I'd suggest not getting too attached to them, and instead remaining flexible in your thinking. Developers learn and refine their views on things over their entire careers; if you're just getting started, your views on this sort of thing will likely change over time. Again, one of the nice things about programming for yourself is that you can do whatever interests you and that you enjoy. But practically speaking, using existing tools is not only common and recommended, it's absolutely necessary in many cases if you actually hope to get anything done.

Hi, it's me again
I wonder how do I know the end point in advance if rays are supposed to be infinite.
I am interested in knowing (as in the code) if the distance between origin and dest is shorter than the ray, it would return a false to the invoker.

So is it a ray test or a segment test that you want? If you want to impose a 'max distance' limit on the ray, then it's actually a segment test that you want.

Also, did you see my post above? It includes some info that might be relevant to your question.

However, I was wondering what the destination/end point means. Is it any point on the target mesh or do I randomly choose an end point?
In case I already had the ray direction, do I ignore this end point? because I see that the ray is calculated by normalize (end-origin);

The code in question implements a segment-triangle test rather than a ray-triangle test (although it can easily be adapted to implement a ray-triangle test instead).

The 'end' parameter simply represents the endpoint of the segment. If you have a ray represented by an origin and a unit-length direction vector, and a maximum distance that you're interested in, you can compute 'end' as:

end = origin + direction * max_distance;

A couple of other things to be aware of regarding the code posted above. First, the code may fail if the ray/segment is parallel or nearly parallel to the triangle plane. (Normally you would check for this and early-out in that case.)

Note that this variable:

float dp = GeomUtil::dot(ray, normal);

Is never used and can be removed.

The code checks to see if the intersection point is past the end of the segment by comparing squared lengths. However, this test can be performed in a more straightforward manner in the 'intersect plane' function itself. Also, it shouldn't be necessary to normalize the ray direction in linePlane(). (With a few changes, the code could be tightened up and made both more efficient and more robust.)

This is a corner case, but note that with this code, there's a chance rays/segments might 'fall between the cracks' between triangles; that is, false negatives may be returned. This case is unlikely enough that you could easily use this method and never see it occur. However, it's something to be aware of. In any case, for a truly robust, production-quality solution, you'd want to use a different method (one that handles edge tests uniformly and will therefore never miss intersections between triangles).

The topic isn't directly related to AI or OpenGL; it's really just a general math topic. (Maybe you could get a mod to move the thread for you...)

The code looks ok (although I didn't proof it thoroughly). But, it's not a complete test, and you shouldn't need to normalize the triangle normal.

More importantly though, before moving forward, I'd recommend that you refactor the code. You never want to be writing anything like this:

edge3[0] = b[0] - a[0];
edge3[1] = b[1] - a[1];
edge3[2] = b[2] - a[2];

float n2[3];
memcpy (n2, temp, sizeof(float)*3);

float sqroot = sqrtf(temp[0]*temp[0]+temp[1]*temp[1]+temp[2]*temp[2]);

Even if you're programming in pure C, these types of operations should be factored out into their own dedicated functions (or macros, if you must). Doing so will make the code easier to read, write, understand, and debug.

I'd say in most cases if it seems like there's a grid of some sort, there probably is. (A game can be essentially grid-based, but still include 'cosmetic' effects such as animation, interpolation, etc. in order to smooth out the visuals.)

In more general terms, the kind of games you're talking about most likely usually involve a graph of some sort (that is, a set of nodes and edges, where each edge connects two nodes in the graph). A rectilinear grid would be a special case of a graph (and one where the connectivity is implicit). For other types of games, the graph might be arranged differently.

Once you have a graph representation, a variety of methods can be employed to determine connectivity and to find connected groups of items that meet certain criteria. For example, you can use a flood fill to find connected items of the same type, or a simple linear walk to find rows or columns of like items (as you would do in, say, Tetris or Bejeweled).

Beyond that, I think it depends on the particular graph configuration, and what types of patterns you want to detect.

Just making sure i'm supposed to assign this ship a position on the world map, which will also be the origin of the ship correct?

I'm not completely sure what you mean, but in general, yes, the position of the object in the world will correspond to the local-space origin of the model. (That is, the world-space position of the model x, y, z will correspond to the local-space origin 0, 0, 0.)

So to move the ship i am technically "Moving the world to adjust to the ships movement" Is that a good way to think of it?

We were just discussing this in another thread :)

Generally speaking, as far as the simulation is concerned, you move the ship and not the world. There are some conceptual issues involved, and there's more than one way to look at things, but when it comes to actually updating the entities in your simulation, you should think of the ship as moving, rather than the world. (In the general case, at least.)