A weird problem with blended lines

Started by
4 comments, last by skow 19 years, 10 months ago
I'm having this problem on a project I'm working on. I'm using anti-alised lines, so blending is required for the lines to work. The lines arnt drawing untill i leave the mose over an object and send a status bar message. This is only happening when I have blending enabled for the lines, otherwise they are drawing fine. Has any one heard of some win32 stuff causing problems with blended GL_LINES? This really has me puzzled. EDIT: Quads, triangles, etc work, it's just lines. [edited by - skow on June 3, 2004 8:05:24 PM]
Advertisement
Wow, some one explain this one. It was because in the init funtion, the string that I would pass wasn''t initally set to a value. Once it got a value the lines work, this is the std::string. Very werid.
I suspect you are using an uninitialised variable somewhere. That or you have memory corruption. Can you post code, or is the project too big? Best to find the source of this bug now if it is an uninitialised variable or memory corruption, otherwise it''s liable to pop up again later on, when you''re project is twice as big.

Enigma
Hey, thanks for the responce. It already did show up again, when a paticular int was above 0, lines would change color/disapear depending on the value.

The project is far to large to post the code. You said memory corruption could be a problem. I''m not sure what you mean with that, if its related to the program how would I go about tracking it down?
Memory corruption occurs as a result of buffer under/overflows or writing to bad pointers. Basically it means you''re writing to an area of memory that you shouldn''t be. It can be very difficult to track down. A good debugger will help you, but I don''t know of any easy way to find the source of the problem otherwise, especially when the project is already so big.

If you don''t have a debugger then try reducing your program to a minium and make it output pointer and array index values at every step. Gradually add code back into the project once you are sure there are no problems with the part that you are testing. Alternatively retrofit your code with checked pointers and arrays (this can take a very long time to do) which will alert you to a bad pointer access or array index out of bounds error.

The best way to avoid making such errors in the first place is to change your programming style. Use references where ever possible instead of pointers and use std::deque or another checked container class instead of raw arrays. 99% of the time standard containers will be more than fast enough (they can even be faster than raw arrays) and for the cases where they aren''t you can go back and change them when you''re sure that everything is working properly.

Enigma
I use a very limited amount of pointers, mostly the std classes. I''ll check out all the pointers, and make sure everything is declared.

Thanks for the responce.

This topic is closed to new replies.

Advertisement