RECTANGLE and RECTANGLE FILL

[Zaphod]

In looking at the SDL versions on the Windows platform if found minor graphical flaws in the SDLIDE scroll bars. Richard tells me that he cannot reproduce it so I am at a bit of a quandary.
I think the issue relates to a what I see on BB4W as a discrepancy between RECTANGLE, LINE and RECTANGLE FILL commands.
Perhaps people could run this short code in BB4W and any SDL platform although it only makes sense on a screen big enough to use the SDLIDE program.

Code: Select all

      RECTANGLE FILL 100,100,100,100
      PRINT POINT(100,100);
      PRINT POINT(100,200);
      PRINT POINT(200,100);
      PRINT POINT(200,200);
      PRINT

      RECTANGLE 300,300,100,100
      PRINT POINT(300,300);
      PRINT POINT(300,400);
      PRINT POINT(400,300);
      PRINT POINT(400,400);

Perhaps you could also indicate the screen resolution, in case that makes a difference. on a 1600 x 900 monitor I see:
15,0,15,15,15
0,0,0,0
For me RECTANGLE FILL maps a different rectangle than RECTANGLE, strange as that may seem.

Z

[DDRM]

Hi Zaphod,

I get the same results.

Yes, they plot different rectangles, at least in BB4W. This is covered in the "pixel-perfect graphics" page, where it explains that, due to the vagaries of the Windows commands, line draws between coordinates (used for outlines) are INclusive, while fills are EXclusive: top and left coordinates are coloured, but bottom and right are not. That means that outline shapes are 1 pixel bigger than you might initially expect (but both the start and end pixel row/columns are coloured), while filled shapes are the specified width/height, but finish one pixel earlier than you might initially expect.

Presumably the SDL drawing routines make different decisions: both outlines and fills include all four "edges". Again, it is noted in the "differences between BB4W and BBCSDL" page that results will be similar but may not be pixel identical.

Best wishes,

D

[Zaphod]

Thanks, DDRM for reiterating the BB4W case, I had forgotten where that was detailed. And I was aware that BBCSDL graphics were different although exactly how I hadn't determined

Presumably the SDL drawing routines make different decisions: both outlines and fills include all four "edges".

That was my presumption also which I really wanted to check from Linux users of BBCSDL. BBCSDL on WIndows maps the same rectangles and I think that will hold true for all BBCSDL versions but I was after verification.

Why I am pursuing this is because SDLIDE has very minor interface issues that I wanted to correct because I like the program and can see it being useful to customize. I made a suggested change to Richard which worked for me but it turned out didn't work on BBCSDL and so was not acceptable, obviously.
Upon digging deeper I think that this RECTANGLE FILL difference is the heart of the issue and so it is important that I verify how any change might work on other BBCSDL platforms. So before offering any further fixes I want to do my homework, as it were.
Even so there appear to be more things that need to be changed to make SDLIDE totally compatible for BB4W users or are perhaps very minor flaws for everybody, I don't know at present, but I suspect most of the things aren't there on BBCSDL.
I think that since SDLIDE uses dlglib that is where most of the changes need to be made but as Richard pointed out to me that using SLDIDE under BB4W was not really the intended use, but he would consider changes if they worked for all platforms.

So anyone running BBCSDL under Linux that would be willing run that routine to give confirmation of your result that would be useful. I am expecting you will see all zeros.

Thanks in advance, if I have any SDLIDE suggestions I may be asking for testers later.

Z

[p_m21987]

I've recently become aware that BB4W's graphics look a bit different when you're running it on windows with Wine. I'm assuming it's because BB4W uses Windows APIs for drawing primitives like circles, etc, and Wine's implementation of those routines is different from the genuine Windows versions.

I ran your program on BB4W 6.12a on wine-3.19 (staging) and got this result:

Code: Select all

15	0	15	15
0	0	0	0

With the version of BBCSDL I happen to have on this old computer (the version is more than half a year old), I get all 0s.

[Zaphod]

Thanks.
It looks like BB4W is the odd one out so I will go ahead with my patches to SDLIDE and the dlglib so that it looks the same on all platforms.

If you write in BBCSDL and want it to look the same in BB4W then any RECTANGLE FILL needs to be preceded or followed by RECTANGLE with the same parameters to fill in the missing row and column in BB4W. Or you could replace RECTANGLE FILL in both with a PROC as shown below . If you have a slow graphics system the PROC may be noticeably faster. On my Windows machine it is 20-30% faster. BBCSDL is quite a bit faster than BB4W drawing rectangles on my desktop machine.

Code: Select all

      REM For BBCSDL code backward compatibility with BB4W 
      DEF PROCrectfill(x%,y%,dx%,dy%)
      IF INKEY(-256) = &57 THEN
        RECTANGLE FILL x%, y%-2, dx%+2, dy%+2
      ELSE
        RECTANGLE FILL x%, y%, dx%, dy%
      ENDIF
      ENDPROC

If your program was originally written for BB4W then any critical RECTANGLE FILL needs to be adjusted for BBCSDL so you would have to write the opposite conversion. You would then replace the RECTANGLE FILL with PROCrectfill using your BB4W parameters and they will adjust to the same size on BBCSDL.

Code: Select all

      REM For BB4W code update compatibility for BBCSDL 
      DEF PROCrectfill(x%,y%,dx%,dy%)
      IF INKEY(-256) <> &57 THEN
        RECTANGLE FILL x%, y%+2, dx%-2, dy%-2
      ELSE
        RECTANGLE FILL x%, y%, dx%, dy%
      ENDIF
      ENDPROC

Now this is only necessary for pixel perfect translations, which in many cases isn't the case as the difference would never be noticed. But if you have bounding items it might show up if you look carefully and have a large screen. On small portable devices you would probably need very much younger eyes than mine to see the difference.

Z