Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » al_draw_line draw wrong line.

This thread is locked; no one can reply to it. rss feed Print
al_draw_line draw wrong line.
iwans18
Member #12,672
March 2011

When I draw line, sometimes it change its color and thickness. I want to know if there is something wrong with my code or this is bug or something.

There are 2 photos of this line(only horizontal lines are bad): http://img820.imageshack.us/g/liniaz.jpg/ (99 is gracz.y value)

Code:

#SelectExpand
1int siatka=500; 2 3 for(int i=0;i<=1024/siatka+1;i++) 4 al_draw_line(i*siatka+gracz.x%siatka,0,i*siatka+gracz.x%siatka,monitor.y2,al_map_rgb(0,0,0),1); 5 for(int i=0;i<=768/siatka+1;i++) 6 al_draw_line(0,i*siatka+gracz.y%siatka,monitor.x2,i*siatka+gracz.y%siatka,al_map_rgb(0,0,0),1);

Elias
Member #358
May 2000

Does this help? Basically if you only want full pixels lit make your shape cover only whole pixels.

I guess you could also disable super sampling if that's what you want - it should be off by default so you must enable it somehow right now.

--
"Either help out or stop whining" - Evert

iwans18
Member #12,672
March 2011

It didn't help. I don't know what super sampling is so I didn't enable it.

al_draw_line(0,599,monitor.x2,599,al_map_rgb(0,0,0),1);

This function draw grey, 2 pixels wide line. Why?

When I draw horizontal line 2 pixels wide it draw 1 grey pixel, 2 black pixels, 1 grey pixel but when I draw vertical line there are no problems.

Thomas Fjellstrom
Member #476
June 2000
avatar

iwans18 said:

It didn't help.

It wasn't just about super-sampling. Theres some very useful information there that I think you skimmed over.

Though it sounds like you have "super-sampling" aka "MSAA" or "Anti Aliasing" enabled, possibly forced enabled by your graphics drivers.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

iwans18
Member #12,672
March 2011

Why it only affects horizontal lines and how can I disable it(or check if it's enabled)?
And I tried al_draw_line(0,100.5,1000,100.5,al_map_rgb(0,0,0),1); but still nothing.

And if I draw
al_draw_line(0,1,1000,1,al_map_rgb(0,0,0),1);
or
al_draw_line(0,2,1000,2,al_map_rgb(0,0,0),1);
or
al_draw_line(0,3,1000,3,al_map_rgb(0,0,0),1);
....

there are no problems(black 1-pixel wide line). Why??

Elias
Member #358
May 2000

Well, look at the other pictures in my link (or the documentation).

Basically, if you draw a black line but it's not exactly covering whole pixels then the pixels will get gray according to their pixel coverage. So if you draw a vertical line which is 1 pixel wide and half of it is on the pixels to the left and half of it on the pixels to the right, then both will get 50% gray.

If you want a fully black line, then don't draw it besides the pixels, instead make it cover whole pixels. In your case that means to for example draw it from 0/1.5 to 1000/1.5 - that means you draw it in the pixel row with y=1. (If you draw from 0/1 to 1000/1 as you were doing then that means you draw it exactly between the pixel rows y=0 and y=1 so with super-sampling both get a coverage of 50%).

--
"Either help out or stop whining" - Evert

iwans18
Member #12,672
March 2011

I said that I tried!

al_draw_line(0,54,1000,54,al_map_rgb(0,0,0),1);
al_draw_line(0,54.5,1000,54.5,al_map_rgb(0,0,0),1);
al_draw_line(0.5,54,1000.5,54,al_map_rgb(0,0,0),1);
al_draw_line(0.5,54.5,1000.5,54.5,al_map_rgb(0,0,0),1);

I tried every combination with ".5" and it didn't help. Post a code that should work and I will try it.

Audric
Member #907
January 2001

Try a combination where y1 is not equal to y2 ? Like y1=54.4 and y2=54.6, so that they 'surround' the middle 54.5

Elias
Member #358
May 2000

What operating system and graphics card are you using? Can you run the ex_draw example and see if it also has this problem?

This is how ex_draw looks with and without super-sampling for me:

{"name":"Screenshot-ex_draw-2.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/e\/6e1f3175fd92dd7356ea44c57020b3ef.png","w":650,"h":669,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/e\/6e1f3175fd92dd7356ea44c57020b3ef"}Screenshot-ex_draw-2.png

{"name":"Screenshot-ex_draw-1.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/9\/b96eee9991aecacd2b291b0201ac2961.png","w":650,"h":669,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/9\/b96eee9991aecacd2b291b0201ac2961"}Screenshot-ex_draw-1.png

The case which only has completely covered pixels (3rd row, 3rd column) looks the same in both and it's also the case which should look the same on all graphics cards - most of the other cases will be drawn differently by each card.

--
"Either help out or stop whining" - Evert

iwans18
Member #12,672
March 2011

I use Windows XP Professional x84 and GeForce 7300GT.
{"name":"63049766.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/e\/5e60081db65a89fdf37594e4b112e50f.jpg","w":646,"h":672,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/e\/5e60081db65a89fdf37594e4b112e50f"}63049766.jpg

With supersampling on 4x or higher there is no difference.

Red rectangle is only 1 pixel wide in this example. I can't compile it I get "55 "invalid conversion from `void*' to `unsigned char*' "
unsigned char *data = lock->data;

EDIT: I changed to (unsigned char*)lock->data; and compiled, but program ends immediately.

Other primitives have this problem too(e.g. rectangle)

Maybe this is compiler fault? I downloaded allegro-5.0.1-mingw-3.4.5 and I use it with default dev-C++ Compiler MinGW 3.4.2(I think)

Neil Roy
Member #2,229
April 2002
avatar

iwans18 said:

Maybe this is compiler fault? I downloaded allegro-5.0.1-mingw-3.4.5 and I use it with default dev-C++ Compiler MinGW 3.4.2(I think)

That would be my guess! I finally threw in the towel on MinGW today, they have broken that too much for my liking. I recommend grabbing Microsoft's Visual Studio Express 10... it's free, and free to use commercially etc... there are prebuild allegro binaries for it and a nice little MSVC project builder. The link to the builder which has links to the binaries is here:

MSVC Project Generator

And you shouldn't have a difficult time finding Visual Studio Express. Unless of course you enjoy the headaches that MinGW will give you. ;) I tried compiling some libraries which I had compiled in the past and couldn't get past the bloody makefile, on other code I had that always compiled fine in the past, suddenly I get problems like you describe (const char * seems to be a popular one). Maybe it's all nessecary, maybe not, but it has broken a lot of projects and code, after hours of work/heaches, I'm switching to MSVC10. (where I'm sure there will be no problems... LMAO ;D)

LennyLen
Member #5,313
December 2004
avatar

The problems that are arising from later versions of GCC (including MinGW) are mostly due to it being stricter with standards than it had been. Things that used to give warnings now give errors. Of course, when the code was written, the coders should have heeded the warnings and written the code properly, so both sides are at fault.

Elias
Member #358
May 2000

The output of ex_draw looks like it should (the rectangles are all drawn as solid lines, unlike your initial screenshots). I was kinda expecting the lines would be blurry as well, which would have hinted at some problem outside of Allegro. Not sure now what could be causing it. Maybe you can make a small compilable example which reproduces the original issue?

iwans18 said:

I can't compile it I get "55 "invalid conversion from `void*' to `unsigned char*' "

That sounds like the file is being compiled as C++ instead of as C.

Quote:

Maybe this is compiler fault? I downloaded allegro-5.0.1-mingw-3.4.5 and I use it with default dev-C++ Compiler MinGW 3.4.2(I think)

Your MinGW version seems to be quite old, I think over 6 years. So yes, I would try and upgrade to a newer version of MinGW :) Still, if you figure out why the file is being compiled as C++ and make it compile as C instead it probably will work with what you have.

Neil Roy said:

That would be my guess! I finally threw in the towel on MinGW today, they have broken that too much for my liking. I recommend grabbing Microsoft's Visual Studio Express 10... it's free, and free to use commercially etc...

The C++ compiler in VS doesn't support C99 making it utterly useless if you code in C.

LennyLen said:

The problems that are arising from later versions of GCC (including MinGW) are mostly due to it being stricter with standards than it had been.

The same is true for MSVC and a lot more than for gcc. MSVC will for example warn about simply using many standard libc functions like strcpy or strcat. (Which is probably a good thing.)

Neil Roy said:

(const char * seems to be a popular one)

Assigning a const string to a non-const pointer will likely not work in MSVC either as it's not valid C++ as far as I know. No C compiler would complain about it though, certainly not gcc/MinGW. g++ will complain of course. But maybe I'm thinking of a different issue...

--
"Either help out or stop whining" - Evert

Matthew Leverton
Supreme Loser
January 1999
avatar

MSVC has a C compiler (or mode), so there's no problems there. It does not support C99, but that doesn't make it "utterly useless" especially if you never even learned any of the new stuff.

Neil Roy
Member #2,229
April 2002
avatar

I was using the newest MinGW, that's where the problems all cropped up. I reinstalled the old Mingw 3.4.2 and it all works again. EVen after I recoded the projects so that things like char * were const char * (only a few instances of this popped up and usually in someone else's function from a library or whatever). Code that I created from scratch always have strings as const char *. But I still had problems anyhow. I always heed warnings, I hate them. I always have -Wall on so I can catch them all and when i am done, no warnings exists. That's why it was so much more annoying when my own code suddenly wouldn't compile. Not just the gnu compiler but the mingw32-make is broken. It stops in some makefiles with some new error. I looked in the makefiles (usually not my own) and I don't see the problem. When you spend days just trying to get the tools to work, than I think that's too much. The old tools work, I compiled up a couple 3D projects today with MingW 3.4.2 and Dev-C++ and was so relieved that they all work. I had to undo some of the "fixes" I done ironically. ;)

I'll try MSVC... I don't actually code strictly in C, I actually prefer C++, I just don't tend to use the classes. Although I have put forth an effort to use them more so that wouldn't be a problem with MSVC. If I had to code strictly in C, I could do so no problem, C99 isn't a necessity.

Anyhow, back on topic... I don't like the way Allegro draws primitives. I understand the logic behind how it is done, I just think there should be an option for the standard pixel functions, especially seeing that not all cards treat the sub pixel drawing the same gives even more reason to have standard pixel drawing functions for primitives.

Arthur Kalliokoski
Second in Command
February 2005
avatar

Neil Roy said:

I don't like the way Allegro draws primitives. I understand the logic behind how it is done, I just think there should be an option for the standard pixel functions, especially seeing that not all cards treat the sub pixel drawing the same gives even more reason to have standard pixel drawing functions for primitives.

Doesn't that imply that Allegro needs to have special cases for every card in existence? As well as every card that will be put on the market in the future?

The alternative would be to use software rendering and copy the pixels to the frame buffer, and we're back to A4 again.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Neil Roy
Member #2,229
April 2002
avatar

Adding in support for A4 style pixel rendering wouldn't mean going back to doing things like A4, it just means adding in an extra option for those that want it. Gawd, it doesn't have to be one or the other, it can be both. That would make A5 an even better library in my opinion, especially given the problems people are having with the simplest of tasks.

SiegeLord
Member #7,827
October 2006
avatar

Neil Roy said:

especially seeing that not all cards treat the sub pixel drawing the same gives even more reason to have standard pixel drawing functions for primitives.

How on earth does it give more reason to have them, given that there is no such thing as sub-pixel drawing in A4?

Neil Roy said:

Adding in support for A4 style pixel rendering wouldn't mean going back to doing things like A4, it just means adding in an extra option for those that want it. Gawd, it doesn't have to be one or the other, it can be both.

I still see no reason why A4 style functions are necessary.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Elias
Member #358
May 2000

The point of super sampling is that you don't see pixels any longer. At all. It doesn't matter whether the actual RGBA values are the same or not, you cannot see the difference. Just look at any modern game.

--
"Either help out or stop whining" - Evert

Neil Roy
Member #2,229
April 2002
avatar

I am ALLLL for anti-aliasing, allegro 5 sets it up nicely so the pixels are drawn so they won't be aliased... only there doesn't seem to be a function to enable anti-aliasing on primitives. So the drawing is set up so you can have them anti-aliased, you use them and you see pixels, only they're not being drawn where you want them to be... either bring back pixel functions like A4 or provide a way to enable anti-aliasing.

Elias
Member #358
May 2000

There is no anti-aliasing by default (the issue in this thread is a bug) - and the mid-point rule of filled shapes means you can draw 100% exact pixel outlines. You just can't use the same coordinate system as in A4 because we changed to floating point coordinates which makes more sense when you are using transformations.

Whether super-sampling and texture filtering should be on by default is another question... maybe they should be. But it's just one line of code to enable each so I don't think it's a big problem.

--
"Either help out or stop whining" - Evert

Neil Roy
Member #2,229
April 2002
avatar

I tried out the drawing example after recompiling with MSVC, when I enabled super sampling to anything other than zero (I tried 4, then 3, 2, 1...) it crashes on me.

I also noticed... when drawing a filled rectangle 1,1 (row 1, col 1) was the most accurate, but a rectangle (unfilled) as done in these examples it was 3,3 that was the most accurate. WIth filled circles, 1,1 was most accurate (3,3 was a square) regular circle it was 3,3, a line was 1,1 (3,3 is off by one pixel). Just some consistency would be nice. It would clear up the confusion anyhow.

iwans18
Member #12,672
March 2011

Still can't think of anything. I downloaded CodeBlocks and use it with GNU GCC 4.4.1 compiler and it still draw grey line instead black. I can't install MSVC.

{"name":"64791226.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/c\/5cf34d33fb7fcc9994a2afe2e76de571.jpg","w":1003,"h":565,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/c\/5cf34d33fb7fcc9994a2afe2e76de571"}64791226.jpg

You can see that one time line is good and one time it's blurred.

{"name":"14776220.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/f\/5fac3ad05252b9be1551531ae76d2e6a.jpg","w":1024,"h":735,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/f\/5fac3ad05252b9be1551531ae76d2e6a"}14776220.jpg

^^^

for(int i=0;i<10;i++)
                al_draw_line(0,100*i,1000,100*(i+1),al_color_name("red"),1);

SiegeLord
Member #7,827
October 2006
avatar

The only thing I can think of is that somehow you have multi-sampling turned on by default. Try adding these lines before you create your display:

al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 0, ALLEGRO_REQUIRE);
al_set_new_display_option(ALLEGRO_SAMPLES, 0, ALLEGRO_REQUIRE);

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

iwans18
Member #12,672
March 2011

Still nothing ;/ Bitmap is blurred too :(

EDIT: I have no idea why but it works now(I didn't change anything)

Go to: