Luc Pattyn answered this question here: http://www.codeproject.com/script/Forums/View.aspx?fid=326859&select=2993859#xx2993859xx

hello, i am using it because i was told to use it. I can't use OpenGL for rotation so somehow i need to apply the pixels from glDrawPixels to the rotation matrix... please don't tell me not to use glDrawPixels and use something else because i am just following the assignment. I must use it. So i am curious having that.. how can go around and trying to rotate those pixels with rotation matrix. NOT OPNEGL... I know it's not the best way to do it but this is what i am asked to do. thanks

If you want to see a VERY well written (I'm biased) article which has a lot of transformation work with matrices, look at: Warping Coordinates with Matrices[^] I like to think my diagrams will help you also. Iain. In the process of moving to Sweden for love (awwww). If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), give me a job!

If you are using recursion as shown, even if you're drawing a bounded shape, the maximum stack depth will be roughly equal to the number of pixels in the area to be filled. For shapes of non-trivial size, that's not going to work. Much better would be to add points to be drawn into a queue and then have a loop which takes a point from the queue, fills it, and queues up any neighbors that need filling. If you use that approach, the number of items in the queue will be limited to approximately twice the larger dimension of the shape you're filling. Performance with that approach won't be great, but it will work. Things may be improved considerably if each queue item is a horizontal line rather than just a point. The code will be more complicated, but if written properly it will run much faster. One caveat is that there won't be any nicely-defined limit on the required queue size. On the other hand, one could design the algorithm so that when the queue is nearly full, queue items that would generate too many more queue items simply get re-queued instead of being processed. Some care would be necessary to prevent 'deadlock' conditions, but I would expect that in practice things shouldn't be too bad.

See OpenGL[^]. Of one Essence is the human race thus has Creation put the base One Limb impacted is sufficient For all Others to feel the Mace (Saadi )

For msg based painting you should only draw in the paint handler. In the mouse handler save any mouse specific state that's important then invalidate the area that needs to be redrawn. ...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack

Member 3375334 wrote: Ok the fact that my code is so ugly is because i am brand new to all this so please don't be judgmental I don't judge you, I was just saying that what you did is not the best design. Member 3375334 wrote: the reason why i am doing it in mousemove..is because that's what i need to do.. i need to draw on mouse move not paint. Of course, but storing your information (the coordinates of each lines for instance) in the mouse handler and forcing a repaint of the view will have the same effect. Besides, all drawing code from the MFC has to be put in the OnPaint handler, otherwise if your window is hidden for a while (even partially), all the MFC drawing will be lost because windows doesn't store any information about what to draw but instead issues a WM_PAINT message and lets the window repaint itself. As you didn't provide any drawing code there, everything is lost. Member 3375334 wrote: The reason why i need to see MFC is because that's what i need to do based on the requirements. And what are your exact requirements here ? Because I don't see any reason why you would need to use MFC AND OpenGL on the same window. How can you expect to see one drawing through the other one ? I'm not an expert in mixing MFC and OpenGL drawings together, but I think this is not possible (not sure about it, but it sounds really strange anyway). Think of it this way: imagine that OpenGL and MFC are painting things on a buffer (like a real life painting). Now, each of them puts its buffer on the screen ("they hang their paintings on the wall" :) ). So, you can't see both of the paintings at the same time... Besides, another strange thing is that OpenGL and MFC have different levels of 'abstraction': with MFC, you draw things on your screen and everything is 'pixel based'. With OpenGL, you are one level higher: your model have a space which is converted to screen coordinates by OpenGL. In your case, it happens that your units in the space correspond to pixels because you configured OpenGL this way. Suppose now that you want to add features like zoom, which is easy to do in OpenGL, then the MFC drawing won't follow. Cédric Moonen Software developer Charting control [v1.5]

Chris Losinger wrote: the compiler will optimize that multiplication away. Thank you for pointing out that... :) - ns ami -

Save the point in OnLButtonDown to a variable within your program and then use that point as reference to line drawing calls like LineTo. You may also want to set a flag in OnLButtonDown and reset it in OnRButtonDown. Also take a look at SetCapture and ReleaseCapture to capture and release the mouse. «_Superman_»

I'd just draw on a plain dialog surface. Create a dialog-based MFC application. Draw your lines and things in the dialog's OnPaint handler. Add button click handlers for the dialog.