It sounds more like custom vertices are a horrible pain

Yup. a pixel coordinate is anchored to the line between pixels, rather than the center. So you have to add 0.5 to any coord to make sure it won't randomly select a pixel on either side of the line (different cards and drivers will pick a different pixel if you try and draw between pixels).

It indeed doesn't, but it probably should. Though I think there are issues with that, and it might need a shader to make work properly. Not 100% sure though. They were just talking about this on the [AD] list. Some kind of solution was bashed out I think.

I would have thought that anywhere between 48.1 and 48.9 would be safe... I guess that shows how little I know!

As for James Lohr's comments, fortunately A4 is still available and completely functional - so keep using it if that's what you prefer. I personally like A5, mostly for its events system, so I'll be using that from now on.

I am using 1.0 for thickness. When trying to set pixel 48 as the endpoint of a horizontal line:

• 48.5 = fail

• 48.502 = success

I've found that adding +0.25 on the left and +0.75 on the right gives the proper results every time (using draw_line, draw_pixel, and draw_prim). But I suppose it will totally break on any other computer or with the next version of Allegro.

I'm trying to draw scalable widgets. Off-by-one errors are extremely obvious, making the whole thing look ridiculous.

What's the intended purpose of the current primitives add-on?

With OpenGL, you should not add 0.5 to pixels. That is to draw this:

{"name":"Rect.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/1\/f1ac95ba021ee1562cc8dac5c6e05f10.png","w":400,"h":400,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/1\/f1ac95ba021ee1562cc8dac5c6e05f10"}

You would use this:

al_draw_filled_rectangle(2, 2, 7, 7);

This will be a 5x5 rectangle. If you do al_draw_filled_rectangle(1.9, 1.9, 7.1, 7.1) it has the same result (as long as the midpoint filling rule is used), so this should be completely stable.

For outlines, do this:

al_draw_rectangle(2.5, 2.5, 6.5, 6.5, 1);

What happens here is, thickness of 1 means you add a radius of 0.5 for each drawn position. So the outer rectangle is 2,2,7,7 again just like before. The inner rectangle is 3,3,6,6. Again, if you add a bit to the left or right it does not matter with the midpoint fill rule.

In my experience I can use this to draw pixel perfect rectangles in a robust way. However the fact that others want to add 0.5 or 0.25 or 0.75 to things is very confusing to me... if that indeed is the case and my description is wrong, I also want a new primitives addon :/

[edit:]
Quoting from the OpenGL (ES 2.0) specification:

So, in essence, what I said. The problematic case is if you add 0.5 (so never do that) - because then the special rule applies. In all other cases as long as the pixel center (0.5/0.5 position) lies inside the polygon edge the pixel (fragment) is produced.

al_draw_rectangle(2.5, 2.5, 6.5, 6.5, 1) is 100% identical [edit: of course not] has the identical outline to this:
al_draw_filled_rectangle(2, 2, 7, 7). And the inner rectangle is like this: al_draw_filled_rectangle(3, 3, 6, 6). So yes, to clarify, only for filled rectangles use whole integer positions (but compared to Allegro4, the lower right corner is 1 pixel more as it's the lower right corner of the pixel). For a line with thickness 1, you would indeed draw it from pixel center to pixel center, so yes, add the 0.5 then.

Your horizontal line would be at 48.5 then, yes.

I agree. One solution is to always use OpenGL. I bought the cheapest notebook I could get with some Intel GMA gfx card and it would run my old A5 OpenGL .exes without any troubles out of the box. So while I might have been extremely lucky it seems to me OpenGL support is good enough under Windows. Of course it's only OpenGL 1.1 with no FBO support (so you can't draw into bitmaps at all) but for most games that should work out.

[edit:]
Can you post a screenshot of ex_draw of how it draws filled rectangles and rectangles with tickness 1? It draws them all at 0/0, 0.25/0.25/ 0.5/0.5 0.75/0.75 so can see the difference.

Hmm... looks like I was wrong, for some reason I thought the fragment centers were not in the place they actually are. Elias is right. Ignore my previous post.

My point was that using hairline lines when you want reproducible output is unwise, since how you render hairline lines in unspecified in OpenGL, and only has been recently defined in DirectX. Polygon rasterization is, however, robust and consistent between most all drivers and API's. Non-zero thickness should result in proper rendering between platforms. If it does not, it is bug in Allegro, since polygon rasterizing is well specified in both OpenGL and Direct3D.

As for the purpose... its simple: send polygons/lines/points in a cross-API way to the graphics card such that the same inputs give the same outputs. Due to hardware limitations, this is only possible for polygons and (maybe) points. I suppose the current high level primitives are simplistic in this sense, since they expect the user to understand all these polygon filling rules.

Now...

If it does, then it is a bug. Both API's have well defined polygon rasterization rules, and there's no reason we can't make them output the same pixels.

No, that's not the reason why a fix like that might be unwanted. My concern is how these little fixes interact with the transformations. I'll need to think more about how that works, but think of this scenario: you offset the outlined rectangle by 0.5, and then apply a scale of 20... now the rectangle is offset by 10 pixels from where you actually meant to draw it. Is that a problem? Maybe.

I am in principle fine with following this manifesto for high level primitives: "Same behaviour as in Allegro 4, but potentially counter-intuitive results when you use transformations." I mean, maybe the last point is not an issue, but I want that investigated before I commit to it. Specifically, I want the scaling of primitives to work properly: I use transformations to scale up my pixel art games to higher resolutions, I don't want that operation to look different from me just scaling the output pixels directly.

There is already an auto offset like that. Direct3D and OpenGL have different coordinates for the origin. In OpenGL the center of the top-left pixel is at 0.5,0.5 while in Direct3D it is at 0,0. This offset is handled by the transformations, so it should not be apparent to the user that this happens.

What Matthew may be experiencing though is that DirectX 10 might have changed the origin system again, I'm not sure... looking at this seems to suggest that the centers are at 0.5,0.5 for DirectX 10. I have no means to verify this however.

I'm using OpenGL under Ubuntu.

{"name":"601605","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/8\/2867c082b05fbc0c292b06d38beabd84.png","w":640,"h":640,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/2\/8\/2867c082b05fbc0c292b06d38beabd84"}

But I'm talking specifically about drawing horizontal lines:

{"name":"601604","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/0\/80ec4542988952c0dd8bc76b00ae3e55.png","w":312,"h":356,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/0\/80ec4542988952c0dd8bc76b00ae3e55"}

  al_draw_filled_rectangle(2, 2, 49, 49, al_map_rgb(255,255,255));
  
  al_draw_rectangle(2.5, 2.5, 48.5, 48.5, al_map_rgb(128,128,128), 1);
  
  al_draw_line(2.5, 1.5, 48.5, 1.5, al_map_rgb(255,255,255), 1);

The line is drawn shorter than the outline rectangle, which isn't what I would expect.

Somebody who knows how this works just needs to update the documentation that tells you how to draw a line/box/triangle/etc from a to b. Most people aren't going to care about why the functions are not intuitive; they are just going to want to know how to use them...

It's no more of a bug than the coordinates for al_draw_rectangle and al_draw_filled_rectangle not lining up. It should be:

al_draw_line(2, 1.5, 49, 1.5, al_map_rgb(255,255,255), 1);

Because that call is equivalent to:

al_draw_filled_rectangle(2, 1, 49, 2, al_map_rgb(255,255,255));

IMO it's pretty bad when your line drawing function can't get perfectly horizontal or vertical lines right .