Posts by raptr_dflo

I can find only one reference to your undeclared constant:

prompt$ pwd
<other path components>/Microsoft DirectX 9.0 SDK (Summer 2004)

prompt$ find Include/ -name \*.h -exec grep IID_IDirect3D3 {} /dev/null \;
Include/d3d.h:DEFINE_GUID( IID_IDirect3D3,            0xbb223240,0xe72b,0x11d0,0xa9,0xb4,0x00,0xaa,0x00,0xc0,0x99,0x3e);

This tells me you need to find that missing d3d.h file to proceed, but I could be wrong.

You have a stack overflow, because your algorithm is hitting an O(n^2) case.

How so? There is no copy of data anywhere in the code, so it's O(n) in space.

You can solve this by recursing into the smaller subproblem and then tail-recursing (i.e. looping, updating variables and jumping to the top of the function) for the larger subproblem.

What? The algorithm is already divide-and-conquer recursive, so O(nlogn) in execution time. (And technically yes, O(logn) in execution stack-size to handle the recursion, but that's still fairly trivial.) Your "i.e." note isn't tail-recursion, it's an approach to removing the stack overhead of function-call recursion by maintaining local variables and a loop, but that's really not the issue here, and won't increase the solvable problem-size by enough to matter.

Sorry, incorrect usage, my fault. This should work:

char _schoolInfo[100];
inFile.getline(_schoolInfo, 100);
if (inFile.fail()) {
    cerr << "school info was longer than 100 characters, sorry!" << endl;
    return 1;
}
// make a std::string from the char-array
string schoolInfo(_schoolInfo);
cout << "Test results from: " << schoolInfo << endl;

Oops did it again, missed the second page. Good work and happy game-coding!

I don't think the cin is the problem, so insert a pair of lines after line 43, and after each successive line in your KMP() function:

cout << "I got here 1" << endl;
Sleep(1000);  // 1000ms = 1 second

(changing the number each time, so it's obvious how far it gets before it crashes). I -think- the problem is invoking the effect function. Either you're somehow getting a NULL ptr back from GetEffect(), or we're not supposed to dereference the pointer before using it as a function-name. If the former, you can do something like:

if (effect == NULL)
  cout << "error: got NULL effect-pointer for the card" << endl;
else
  (*effect)(args...);

If the latter, try just effect(args...); .

:)

Excellent! Please mark the thread as "solved". :)

Ah. First of all, move the code that draws the points and the Bezier curve out of MyMouse() into its own function, and then call that function from myDisplay(). That way you can add a key-capturing function to catch the '+' and '-' keys, and adjust how the curve is drawn.

I didn't previously follow your link, so I didn't realize it was a working example, rather than an explanation. Google is your friend, give it a try (I recommend wikipedia.com for excellent explanations of math/science-related stuff). The logic/algorithm is obvious enough, and no, it isn't the same as the polynomial approach you're using now (though the polynomial can be derived directly from the de casteljau logic).

Once you're clear on what the de casteljau algorithm is, you should be able to tell me what is meant by "the level-i polylines" referred to in step 2, how to handle levels above 3 (since your instructions tell you to be able to handle up to 9), and how you would modify the recursive shell I've given you to return the information you need (or what function you would write instead, since I don't think what you have now is really what's asked for).

I LOL'd, frogboy. :)

New4lyfe, welcome to DaniWeb, and don't mind the sarcasm. Instead of telling us how lost you are, tell us what you -do- understand. Can you answer the first numbered question? The second? Instead of being overwhelmed (and panicking), try bite-sized pieces. Then when you actually get stuck, ask a meaningful question, with appropriate level of detail, such as: "I've got the first four answers, but I don't know what is meant by 'robust' in question 5. How is robustness defined in terms of algorithmic design?" Also, assume I'm similar to your course professor, and I'll know if you just copy and paste my example question back here. :)

Don't get confused! We're doing really well here (though shooting in the dark a bit). Be of good cheer!

Parenthesize (*effect) at line 47, it matters. Otherwise it's trying to call effect() first and then dereference the result (in geek-speek, the argument-passing ()-operator has a higher precedence than the dereferencing *-operator).

And since it looks like it still doesn't know that the types are the same, see if it will let you explicitly cast the function-pointers at lines 69 and 70:

KaibaDeck[0].SetEffect((Card::FunctType*)&HEAVYSTORM);
KaibaDeck[1].SetEffect((Card::FunctType*)&POTOFGREED);

There are a variety of more C++-ish type-casting operators, but I'm woefully ignorant on that particular subject, and this should be sufficient to do what you need! (Fingers crossed!)

Lol, if it works for ~340,000 values, then it's probably not the algorithm! Likely the problem is that the allocation is failing because you're somehow out of system resources, or (since the algorithm is recursive) your program stack and allocation heap are meeting in the middle.

Things to check:
+ did your array-allocation succeed (after line 3 in generate_vector(), check for vec == NULL)? how big a vec can you allocate (if you comment-out the call to quicksort())?
+ how far into the recursion can you get? At the beginning of the 3-parameter quicksort() function, add a debug line like:

cout << "sorting elements " << s << " through " << e << endl;

and see what you get....

I'd suggest replacing your drawBezier() function at line 61 (which should really be called something like computeBezierPoint(), since that's what it does), with a new computeDeCasteljauPoint() function.

Note that the de casteljau definition lends itself well to recursion -- given an initial set of N points, and a value t, you compute a new set of N-1 points. And continue until there's only one point left. So maybe a shell of your function should look something like this:

Point computeDeCasteljauPoint(vector<Point> points, double t)
{
  // TODO: check for valid input before continuing, decide what to return if input is bogus.
  int numPoints = points.size() - 1;
  vector<Point> computedPoints(numPoints);
  // loop over input points, computing computedPoints
  // decide whether to recurse or return
  // if returning, return the correct thing
  // recursing should be simple enough
}

Also, I suspect that your desire to use function pointers this way stems from a lack of understanding about deriving subclasses (though it will eventually still work). Instead of having only a single Card class, with an externally-defined Effect function-pointer attached to it, start with a BaseCard class (with an Effect() method which may do nothing, if that's appropriate) and then derive specific card-types such as HeavyStormCard, which reimplement the Effect() method to do the right thing for that card. You can then have a vector of type BaseCard* which can contain instances of that or any class derived from it: vector<BaseCard*> KaibaHand; Note that you have to allocate and delete cards, because vector<> needs a constant-sized object (in this case a pointer is always pointer-sized) to do its job. But that's a small price to pay for polymorphism (the ability to store objects of different classes all in the same container). Cheers!

Line 15 needs to return a FunctType*:

FunctType* GetEffect() {return Effect;}

And my bad, I should have noticed this before, C++ has no good way of knowing that the FunctType typedef defined inside class Card is the same as the one declared outside. Since Card::FunctType is public anyway, just use that (and specify it that way outside of Card methods), and delete the external one. Specifically, at line 46:

Card::FunctType *effect = Field[0][0].GetEffect();// problem here

Does this get you close?

There's quite a bit of useful sample code at xmlsoft.org, and for your specific needs, the xmlNode struct contains field:

struct _xmlAttr * properties; // properties list

which I believe will prove useful to you in extracting the attributes.

As far as saving it into a map, that should be straightforward. Assuming you will have a possibly-empty map for each XML element, then you should be able to extract the attribute-name and attribute-value for each attribute and use the name as the key into the map.

To be clear, you have your notations reversed in lines 52 and 75. The variable you're passing at line 52 is InitWord (an array of 50 characters). The argument you're expecting at line 75 is char InitWord[50] .

You have to read the desired line out of the file between the time you open the file and the time you start reading student information out of it, maybe around line 57:

string schoolInfo = inFile.getline();
cout << "Test results from: " << schoolInfo << endl;

It's probably most readable (and sane) if GetEffect returns a FunctType* rather than trying to dereference the pointer before returning. Also, since HEAVYSTORM and POTOFGREED are both of type FunctType and SetEffect() expects a FunctType* (the error message you're seeing), try passing an explicit pointer, e.g. KaibaDeck[0].SetEffect(&HEAVYSTORM); (note the '&').

When you retrieve the function-pointer, you also presumably need to invoke it with arguments. At line 46, try above, try something like:

FunctType *effect = Field[0][0].GetEffect();
effect(KaibaHand, KaibaDeck, YugiDeck, Field, KaibaGraveyard, YugiGraveyard);

If you get an type-error on the line where you call effect(), try dereferencing the pointer right there (but I'm not sure you need to, pointers to functions are slightly odd in C/C++). e.g. (*effect)(same args...);

I think you changed the wrong line. It's hard to say, since the source code didn't get line numbers when you posted it. The "for i" line, not the "for x" line. Here, I'll copy it:

fr << setw(20) << left << "Pavardė" << setw(10) << "Vardas" << left
   << setw(16) << "Įstojimo metai" << "Egzaminu pažymiai" << endl;
for(int i = 0; i < S[i].ImtiKieki() ; i++)
{
    fr << left << setw(20) << S[i].ImtiPavardę() << setw(14) << S[i].ImtiVardą()
       << fixed << right << setw(4) << right << S[i].ImtiĮMetus() << "       |";
    // cycle to print given numbers (students grades), maybe something's wrong here?
    for (int x = 0; x < S[i].ImtiKieki(); x++)
        fr << fixed << right << S[i].ImtiPažymius(x) << " ";
    fr << endl;
}

Line 3 above (not line 8).

can i see the overall code

If they had posted the overall code, then you'd be able to see it. Since the thread is over 2 years old at this point, I suspect the original poster has moved on.

Please do not post into ancient threads. Instead, create a new one if you have a specific question.

As others have already pointed out (and even solved for you):

I suspect you need to write your own factorial function. The likelihood is small that x! is implemented as written. And sure enough I don't see a factorial function already implemented in cmath.

So you'll need to write your own function:

int factorial(int value)
{
    int fact;
    // compute the factorial of value here
    return fact;
}

and then call it from your switch() statement.

That's a lot of code to ask us to pore over by hand, rather than doing what was already asked. If you don't know how to use the debugger for your development environment, then start by inserting lines like cout << "Here #1" << endl; into your main(), and see how far it gets before you get the Segmentation Fault. Once you've narrowed it down to a particular function call, you can start outputting more detailed information, and/or inserting output lines within the function.

That said, I started following the flow in main(), looks like sort.MakeEmpty() is fine, but after that, you call this absurd sort.IsFull() function which wastefully allocates and frees a node, just to see if it can. The point of a linked-list is that there is no concept of "full". It can grow until the system runs out of memory, which is what you're in fact testing. Instead, it is more practical simply to allocate the node within the Insert function, and if you fail, return a value that indicates failure. Thus bool InsertItem(args) rather than void InsertItem(args) .

I then looked for where you allocate the -actual- node you're going to add to the list in InsertItem() and discovered you've commented out the allocation at line 151 of SortedType.cxx. There's your first problem.

Hopefully, this has not only solved your immediate issue, but given you some insight into how to debug your own programs! :)

Sorry to be so abrupt before, and welcome to DaniWeb. When you get a chance, please read the "Read this before posting" sticky-post at the top of the forum list, it provides lots of helpful advice (including "don't post your homework assignment and wait for somebody to solve it for you", wink, wink).

So a while loop looks like:

while (someExpressionIsTrue) {
    // do something that needs to be done
}
// program execution will resume here when the expression is no longer true

Personally, for nice fixed-size loops, I'd use for() loops instead of while() loops, but either will work. Either way, you need to determine (a) what expression you wish to evaluate, and (b) what needs to be done within the loop. Consider also, that since the number of lines to be printed, and the length of each line, are both dependent on the input, you may wish to have two nested loops in the form:

while (expression1) {
    // maybe do something here
    while (expression2) {
        // do something here
    }
    // maybe do something here
}

Keep in mind that part of what needs to be done in a loop may include adjusting a value that is examined as part of the expression in the while() statement.

Does this help?

Well, since this is a C++ forum, let's start with some basic OO analysis. What are the objects that your program will be handling? What are their members? What methods should they have? How should they be logically organized into classes?

In more detail: Whose responsibility is it to manage critical sections? How will that be implemented?

And too many university computer science programs focus almost entirely on theoretical concepts, and leave basic programming skills as "an exercise for the reader". But still, this sounds like a junior- or senior-level course in conceptual operating system design, and how you've gotten this far without knowing how to approach a decent-sized program is quite disconcerting. What kinds of programs -have- you written so far?

Thanks for posting your homework question. Now what is -your- question?

And sorry, I have no working knowledge of your DarkGDK, but there is a set of related threads pointed out on the right-hand-side of the screen here, they may be helpful to you as well.

Probably the line in your code:

for(int i = 0; i < S[i].ImtiKieki() ; i++)

I think you meant for this line to specify "i < n". Happy coding!

kv79, is VC++ finding the header files, e.g. windows.h?

you need to import the correct library /packages is DWORD In the standard library? are you using.....[using namespace std]...... at the top of your code?

DWORD is a type defined by Windows (so is TCHAR, so is most of the rest of the mess. Joke about Microsoft and lightbulbs omitted.) It's not part of the standard library, but then the user also isn't including any of the standard library headers, so specifying "using namespace std" is moot.

Your HEAVYSTORM and POTOFGREED function implementations (at lines 50 and 63, respectively) need to provide argument names for each argument, whether or not you use the args in the function.

As far as I can tell at a quick glance, your use of function-pointers is ok as-is. What compile-time or run-time errors are you seeing?

I would think you shouldn't declare your variables like you did[ float zero(float);].And why are you declaring them like variables when they are methods?
Ima newb programming only a year of experience but I've never seen it done like that.

Technically, they are functions. "Methods" are functions specifically bound to a class instance (or class itself, if declared as "static"). And the original poster is not "declaring them like variables", he's providing prototype declarations for the functions, which are then implemented farther down in the code.

The previous responder provided the first steps however: the prototype declaration must match the implementation, e.g.

int zero(float[9][13]);

Third hit on a google search for your undeclared identifier provides a substantial sample code. Right at the top of it:

#define INITGUID
//#define D3D_OVERLOADS //might need to "unremark" this line, depending on if you use the overloads
#include <windows.h>
#include <stdio.h>
#include <ddraw.h>
#include <d3d.h>

The differences are: including d3d.h instead of d3d9.h, and defining INITGUID before including it. Do either of these resolve your problem?

Without code blocks that start from line 1, it's hard to tell which line of your code has generated the error. That said, I'll take a stab at it.

Error #1. I'm not at all sure what it's complaining about.

Error #2. If you're specifying:

#include <someSTLheader>
using namespace std;

then iterator refers to std::iterator which is probably already included into your scope, and you're now trying to override it. There are a number of possible solutions, including (in no particular order)
limiting what you're "using" (rather than everything in the std:: namespace), not including a "using" statement at all (and prefixing std:: wherever needed), and/or using a fairly common idiom of using CamelCase for your own types and classes (or simply Capitalize them in the case of a single word -- "Iterator" is less likely to be defined within STL than "iterator").

Error #3. Try declaring your template as:

TFileMgr<T*,N>

but again, a bit more code might be helpful, especially the class constructor.

Error #4. The "QuadPart" member of the variable is presumably a LONGLONG type, therefore, the difference between two is also a LONGLONG. If you're sure the difference won't be that large, then explicitly cast the result to your return type, e.g.:

return (DWORD)(m_n64CounterEnd.QuadPart - m_n64CounterStart.QuadPart);

I'm sure others will contribute additional ideas!

As far as drawing the game in SDL, computers are -really- fast these days, so it's probably fast enough to just redraw the entire game each update -- in fact, it might be -too- fast: you may want to limit it to a much slower frame-rate, just so you can see what's happening!

Anyway, determine an appropriate screen/window size for your grid, a formula for where to draw each "cell" in the screen/window, and then just redraw your background and then blit your dot shape (or any other small image) on top of it at each cell-position where your grid indicates a live cell. Basically replace "cout << a[j];" with

if (a[i][j] == '*') {
    // compute x & y from i & j
    blit(dot, screen, x, y);
}

I'm not sure which items in the posted pic are supposed to be colliding, but from your text, I suspect one of them is the arbitary cloud-shape. There's nothing about divisibility in the one line of code you provided; instead, it might be an issue of how levelW or dotW are defined, compared with the actual image contents. For instance, if your "dot" is a 64x64 PNG image, but only the center 32x32 region has any non-transparent pixels.

"Perfect" collision detection depends on your application needs and definition of perfection, but is likely to be computationally expensive. Such as "if the bounding boxes of the two shapes overlap, then determine if any non-transparent pixels overlap(*)". There are reasonably-fast algorithms for determining if two arbitrary polygons intersect, and particularly convex polygons, if it's appropriate to approximate your shapes with polygons (or they already -are- polygons).

(*) determine the set of pixels in each shape that fall into the shape-overlapping region, then for each non-transparent pixel in one shape's region, see if the corresponding pixel in the other shape's region is also non-transparent.

No problem. I did a little bit of work with SDL audio on Linux, maybe 8 years ago, synchronizing audio with adjustable-frame-rate video playback so visual effects animators could lip-sync their creations to a pre-recorded voice-track.

Other than that, I've done a variety of programming work, but my training was all in 3D computer graphics, and that's still what I enjoy most, even though I rarely get to do it. :)

No worries. Looks like what's going on is: you're moving a dot around on a "large" level (1280 x 960, but can be arbitrarily large), then you're also moving the smaller "camera" window (640 x 480) around to view just a piece of the level at a time. Since both camera coordinates and dot coordinates are both offsets into the level coordinate system, in order to draw the dot onto the piece of the level you can see through the camera, you need to know it's position relative to the camera, which is (x-camera.x, y-camera.y).

If you're background.png is 1280x960, or if you can make one that's bigger, make sure you blit the correct portion of that into your output SDL window. Without looking up the references, maybe your line 354 above needs to be:

blit(background,screen,0,0,camera);

to clip the portion of the background visible through the camera (and paint it to the screen at postion (0,0)).

Cool! :)

Hi nuclear, sorry I've been so long getting back to you.

I think I finally understand what you're talking about, and agree it generally doesn't make sense to call fps.start() each time through the loop, but I see why LazyFoo is doing it: the work that is done between the call to fps.start() and the call to fps.get_ticks() takes a small but non-zero amount of time, so fps.get_ticks() will presumably return a small number of milliseconds (possibly even zero on a fast enough machine). The line

SDL_Delay( ( 1000 / FRAMES_PER_SECOND ) - fps.get_ticks() );

then tells SDL how long to wait before resuming the loop:
1000 (units of ms/s) divided by FRAMES_PER_SECOND (units of f/s) gives a value in units of milliseconds-per-frame, so if fps.get_ticks() tells us how many milliseconds have expired so far, then the difference is how many remaining milliseconds we should wait to maintain the frame-rate.

Restarting the timer each time means you don't have to maintain the previous value of get_ticks(). An alternative approach is something like:

fps.start();
unsigned long prev_ticks = 0;
while ( quit == false )
{
    ...
    unsigned long current_ticks = fps.get_ticks();
    if ( cap == true  &&  current_ticks - prev_ticks < 1000 / FRAMES_PER_SECOND)
    {
        SDL_Delay( ( 1000 / FRAMES_PER_SECOND ) - (current_ticks - prev_ticks) );
    }
    prev_ticks = current_ticks;
}

If you're always maintaining the desired frame-rate (and as currently implemented, FRAMES_PER_SECOND doesn't change), you could also use the frame counter variable 'frame' to …

Do you understand the methods in the Timer class from lesson13? Timer::get_ticks() does -not- always return 0. If you don't believe that, write some simple code that creates a timer instance, starts/stops/pauses/unpauses it, and prints out the value returned from get_ticks() a bunch of times throughout. Then go back to the code and see why the printed values are what they are.

From what i get get_ticks() always return 0 value since every loop we basicly subtract two same values

Where on earth are you coming up with that logic? As long as the timer is running, get_ticks() subtracts the STARTING value of SDL_GetTicks() from the CURRENT value of SDL_GetTicks(). Are you under the impression that SDL_GetTicks() returns the same value every time you call it? What would be the point of that? Try:

for (int i = 0;  i < 100;  ++i)
    cout << SDL_GetTicks() << endl;

VICTORY!!! THANK YOU FOR YOUR HELP!!!

Awesome! And you're quite welcome. Enjoy!

The glTranslate in your Draw() command is in (x,y,z) that take into account your heading rotation, while the one out in your do-while loop does not. One of them is probably incorrect. If you leave them where they are, and just change the rotations, does your model stay centered in your view and twist around as you expect? If so, try moving the one in Redraw to before the glRotates. If not, try moving the new one inside Redraw before the glRotates.

The "right" answer can certainly be painstakenly worked out on paper, given the documentation for how the OpenGL commands work, but I find it actually faster to take a known model (like a simple 3-axis, 3-color ball & stick object) and use trial and error to get the operations into the proper order and in the right directions. Now that you can actually see your model, it should go quicker. If you can't tell why it's moving incorrectly, start over and change as few values as possible, to narrow down which operations might be inverted, or specified in the wrong order. If needed, comment out operations while you test other ones, then put them back in when you're ready. Good luck!

In Mouse(int *x, int *y), temp isn't allocated. Replace lines 12-15 with:

POINT temp;
    GetCursorPos(&temp);
    *x=temp.x;
    *y=temp.y;

In fact, if you might want to collect only the x or y value, pass NULL for the other pointer and reimplement as:

OpenGLInstance &OpenGLInstance::Mouse(int *x, int *y)
{
    if (x==NULL && y==NULL)
        return *this;
    POINT temp;
    GetCursorPos(&temp);
    if (x)
        *x=temp.x;
    if (y)
        *y=temp.y;
    return *this;
}

As far as keyboard keys, I'm not sure, but try putting a debug-print in your WndProc WM_KEYDOWN event and make sure that the value you're getting corresponds to the one you're checking for. I wouldn't be surprised if 'a' is really returning 'A' or even 'w' or 'W' depending on when the dvorak translation happens. Also try bumping the angle-increment up to 5 or 10 degrees, temporarily, so you -know- when it happens. :)

On translation/rotation: keep in mind that order-of-operations matters. I think yours will likely do as you expect, as long as it's acceptable that R/L and F/B movement is relative only to the heading (and not the pitch U/D or roll CW/CCW). Also, since the OpenGL camera looks along its own Z-axis, I think maybe you want pos.h to rotate around that, rather than the X-axis. (And since it looks like you intend pos.h=0 to indicate a compass-heading of north, pos.t should rotate around Y and pos.v around X, try changing only one of those values away from zero at a time until you're getting the behavior you expect. Also as you change more than one value, you may find that you need to do roll first, then pitch, then heading.

As far as your Move function, pos.h-90 is 180 degrees off from pos.h+90, so sin and cos of one are negatives of the other, and the entire else{} block is redundant. Instead, double-check that you're moving in the correct direction for obvious values of pos.h (like 0 and 90). Again, to test, set all values to zero except pos.h, then Move only F/B or only L/R and make sure you see what you expect! Also, since the camera is at (0, 0, 0) to begin with, make sure you start with a sensible z value to push the model out in front of the camera. Getting close now! :)

Wow, I'm really running out of good ideas. When all else fails, debug-prints!

Next up, if you can run your executable from a command-prompt, put a couple of printf/cout lines inside your do-while loop to make sure it's actually looping at the expected rate. Feel free to drop your desired frame-rate to 1Hz or less, so you can see the print's ticking by ... and/or add a counter that you can print out so you can see how fast that's changing. I have the vague feeling that something in the functionality is blocking when you aren't expecting it to, but I'm not sure. If your loop is running, we can then try to figure out why the Escape key doesn't exit, and why it doesn't appear to be rendering anything to the window. If it -isn't- looping, we can start narrowing down where it's getting stuck.

And have you sanity-checked your frame-rate maintaining Sleep() value, within GL.Update()? If you accidentally send it a negative number, that may well be automatically converted to an unexpectedly very-large positive number! :)

Assuming the stray #endif at line 53 is a left-over typo.

Also, from earlier, does your do-while loop in main() now look something like the following?

do {
    glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
    model.Draw();
    GL.Update();
} while (!GL.window.key[VK_ESCAPE]);

Nothing. Best bet is to start with the html link to mesa3d.org, and go from there. It will likely get you to the same point anyway, but in a more obvious fashion. (I put the ftp link up first, then went and tracked down the website, which was more user-friendly. Anyway, grab v7.11 I guess, and follow whatever instructions you can find for installing it. Or v7.10.3 if you can do without the absolute latest-and-greatest features and want a version that may be more stable until they get a bug-fix release out for 7.11.)

Sorry, looks like a threw a bogus URL into my previous link. Try here:
ftp://ftp.freedesktop.org/pub/mesa/

from the main mesa site at http://www.mesa3d.org/

Should I try to see if I can update the version of OpenGL on my machine?

I guess that depends on your machine. If you're on a laptop or other graphics-minimal machine, then I'd say yes, try downloading the latest stable version of Mesa (software OpenGL implementation).

If you're on a desktop-style machine with a half-decent graphics card, then the problem is more likely that you're building against the wrong version of the OpenGL headers and libraries, and have to find the correct ones ... if you need updates or are reasonably sure they didn't get installed when the card was added, go to the manufacturer's website to look for up-to-date drivers and possibly OpenGL implementations too.

Oh, and it looks like I'm way out-of-date (obviously I don't do any new OpenGL development on this box!) -- Mesa is at 7.10 as of January 2011....

Grrr... well, when I get more time, I'll see if I can beat some better behavior out of some version of your code. I'm out of ideas for the moment, and headed away from my computer for a few hours too. More later!