Well, I tried with WinMerge but it doesn't work, only compares files with files or folders with folder, which software are you using to generate/treat that .diff file?, I have never seen something like that before.

C:\Users\Armando>cd c:/a5.1
c:\a5.1>pa -p0 < winpos.diff
patching file src/win/wwindow.c
Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Then I put the files (pa.exe and winpos.diff) inside win and I got this:

C:\Users\Armando>cd c:/a5.1/src/win
c:\a5.1\src\win>pa -p0 < winpos.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: src/win/wwindow.c
|===================================================================
|--- src/win/wwindow.c (revision 15027)
|+++ src/win/wwindow.c (working copy)
--------------------------
File to patch: wwindow.c <-- Here I typed the file to see what happens but nothing.
patching file wwindow.c
missing header for unified diff at line 18 of patch
can't find file to patch at input line 18
Perhaps you used the wrong -p or --strip option?
File to patch:

Tested on Windows XP. It fixes the ALLEGRO_FULLSCREEN_WINDOW issue but for normal windowed mode it seems to position the display at the right position but it doesn't take into account the title bar, so for al_set_new_window_position(0, 0) the whole title bar is left out of the screen.

Oh, in that case it's OK; although, by the name of the function, one could expect it to set the whole window position, but as long as it's clearly stated in the documentation I guess it's not so bad.

One more thing though, I just checked and it seems like ALLEGRO_NOFRAME also presents this issue (with and without the patch). Actually, there's a difference with the patch and without it, but both result in a misplaced window.

The new patch fixes the ALLEGRO_NOFRAME issue on Direct3D but not on OpenGL.

In fact, it's weird; the window size is the same with both OpenGL and Direct3D but while the OpenGL window position is correct, the position for drawing bitmaps is wrong. With Direct3D, on the other hand, looks like bitmaps are automatically scaled.

In both of the following screenshots, the bitmap is drawn at (0, 0). The actual bitmap size is 248x324, so apparently OpenGL is the one drawing it with the right size.

Using OpenGL:{"name":"winposbogl.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/8\/a8e06f8a29b4276d9155d19452433f04.png","w":486,"h":672,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/8\/a8e06f8a29b4276d9155d19452433f04"}

Using D3D:{"name":"winposbd3d.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/2\/9202ad1883ef9116de80cb04d1d22498.png","w":486,"h":672,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/2\/9202ad1883ef9116de80cb04d1d22498"}

If someone could confirm this on recent hardware, it would be great as it may only affect ancient hardware like mine.

[OFF-TOPIC:] AMCerasoli, you should try the patch.exe included in MSYS, if you have it installed, that is.

This is the code I used. I added some primitives and changed the window size. Basically, all operations when using Direct3D are correct except for the automatic scaling (haven't checked what it does if I explicitly call al_draw_scaled_bitmap()).

Edit: Just so you know, if you want to draw the rectangle on the last pixel of the display, you should use "-0.5". So it's your example that has the bug of not displaying the right and bottom pixels of the rectangle. Allegro is doing it right from my tests (adding -0.5 to those numbers).