Thats what i did, i figured i could never get the number or looks for the cursors out of win.

Look at my display list problem thread please, it has to do with the mouse cursor rendering.

Hi Eber

I''ve been thinking about this sort of thing off and on for a few weeks and these are some of the conclusions i''ve arrived at from my occasional experiments:

1.forget the std mouse - use ShowCursor(FALSE) to kill it off at app start.
2. Since a triangle seems to be quickest to draw (and presumably to texture?) then go for that.
3. Mouse messages (moves & clicks) can seem to be intermittent so it''s probably best to have some kind of boolean variable that''s true when the mouse move etc is fired and false once you''ve finished processing it - in much the same way as WM_KEY***
events are handled in NeHe''s excellent tutorials, just test the variable value in each ''draw'' cycle.
4.In non-ortho (normal?) gl fullscreen window I was only able to empirically determine the boundaries for my mouse ''cursor'' (which is a fancy way of saying I tried heaps of things until I got it to sort of work!). I also found it to be a bit slow when other things were happening too so perhaps using a separate thread might be in order (I never tried that). Apparently there are some gl functions that can get values for the display size that could be used for mapping mouse movements - I think they have been mentioned on this forum before but, unfortunately, I can''t remember those function names.

Anyway, that''s just some thoughts/observations on the subject from someone that doesn''t know too much about openGL. Hopefully someone else can help or clarify these points.

what i did was set up an ortho view with the dimensions of the window, and use that with the mouse position to draw the cursor in the right spot, the only problem lay in the fact that windows assumes 0,0 to be on the top left, and gl is the bottom left, therefore you have to invert the mouse coords whenever you interface with opengl.