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:

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.

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.

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.

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??

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%).

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.

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

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"}

{"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"}

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.

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"}

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)

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 )

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.

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?

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

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.

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

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.)

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...

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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"}

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"}

^^^

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

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);

Still nothing ;/ Bitmap is blurred too

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