BASIC example BOX gives different outcome than pictures in manual

[MauriceMEGA65]

All three BOX examples give a variant of the attached picture, not the pictures as given in the manual.

[gurcei]

Aah, it seems like the examples have been written to suit the provided description of the command, which conveys that the lines will be drawn from pairs 0->1->2->3->0.

But the reality of the drawing logic appears to be quite different. The unofficial docs corrupted the ascii-art, but it's more like this:

BOX x0,y0, x1,y0, x0,y1, x1,y1 [,solid]

       (pair0) x0,y0  +--------------------+ x1,y0 (pair1)
                      |                    |
                      |                    |
       (pair3) x0,y1  +--------------------+ x1,y1 (pair4)

Their param format pairs, in relation to this diagram, could be described more like BOX TopLeft, TopRight, BotLeft, BotRight.

So a true-rectangle example, based on this understanding is like this:

BOX 0,0, 160,0, 0,80, 160,0

If I type SLOW prior to running this, I can see the order of drawing each line segment is more akin to pair 0 -> 3 -> 4 -> 1 -> 0.

As it stands, it probably doesn't feel terribly elegant/logical, and I can understand why the description 'hoped' for things to be more straightforward than they presently are.

I took a look at the C128's BOX command, and it is quite different to the C65's. So given that C65's implementation is 'unique', perhaps we aren't under any obligation to stick to it, and perhaps future iterations of this command ought to present the parameters in a more friendly order (such as pairs 0->1->2->3->0).

Until then though, I'll just update the description and examples to match the existing behaviour.

[gurcei]

Actually, think I'll hold back on updating the description, as I kinda feel the existing description describes a good logical behaviour, and the existing behaviour is less pleasant and clumsy. So maybe a question for @Edilbert , could the implementation be modified in future to match the description?

[MauriceMEGA65]

Your above drawings seems correct for the coordinates. I like your description BOX TopLeft, TopRight, BotLeft, BotRight, but not sure if that holds true for the second and third example.

The actual drawing is as you mentioned 0 -> 3 -> 4 -> 1 -> 0

In the manual, the first example needs to be updated to 0,0, 160,0, 0,80, 160,80 to make them work as provided in the picture. The other two examples I need to check later on

[Edilbert]

The current handling of the BOX command is crazy and not compatible to earlier BASICs, so I tend to change it to a more logical way. 1) BOX topleft-x, topleft-y,bottomright-x,bottomright,y This requires only 4 parameter, but can only draw rectangular boxes. 2) BOX x0,y0,x1,y1,x2,y2,x3,y3 This will draw 4 lines, 0->1, 1->2, 2->3, 3->0 The mode can be determined from the number of parameters (4 or 8). What do you think?

[gurcei]

Yep, I really like this idea, of having a short form and long form, and logical ordering of parameters, thumbs up from me 👍

Ok, so as @Edilbert is aiming for this pathway, I'll switch assignment of this ticket from me to him.

[Edilbert]

I changed the BOX command in the ROM as described and updated and tested the examples in the manual. So, it works now as documented, but is not compatible to old ROM versions or BASIC 10. Using old programs will paint bow ties instead of rectangles and vice versa. The fix is to exchange x2,y2 with x3,y3