Geändertes Verhalten von "Line"?

[Sven]

Ich habe in einem älteren Programm (vlt. 5 Jahre her) einige Änderungen vornehmen müssen und dabei etwas Eigenartiges festgestellt:

In der alten Version wurde mit Line(x, y, a, 0, c) eine waagerechte Linie der Länge a gezogen. Das geht jetzt nicht mehr. Ich musste alle Befehle zu Line(x, y, a, 1, c) ändern.

1. Weiss jemand, seit wann das so ist?
2. Weiss jemand, warum das so ist? Meines Wissens zeichnen Line-Befehle üblicherweise bei Breite / Höhe 0 eine gerade Linie. Bei Breite / Höhe 1 gibt es ein Pixel Versatz. Also so, wie es vorher war.

Ich habe das neu mit PB Version 4.6 compiliert, da mit einer neueren Version wahrscheinlich noch ettliche andere Sachen nicht gehen und ich noch mehr Anpassungen im Code vornehmen müsste. Vielleicht später... Ich weiss nicht mehr, mit welcher Version die alte Variante funktionierend mit Breite / Höhe 0 compiliert wurde, wie gesagt etwa 5 Jahre her, vielleicht länger.

[ts-soft]

Ich weiß jetzt nicht, mit welcher Version der Bug behoben wurde, aber es steht ganz deutlich in der Hilfe:
http://www.purebasic.com/german/documen ... /line.html

daher wird bei einer Höhe von 1 eine horizontale Linie gezeichnet, während bei einer Höhe von 0 gar nichts gezeichnet wird.

Gruß
Thomas

[Sven]

Das ist nicht die Frage, es steht auch in der 4.60er Version schon so in der Hilfe.

Aber es war vorher anders, definitiv, sonst hätte mein altes Programm nicht funktioniert. Und es wurde meines Wissens in anderen Basic-Dialekten (Amiga-Basic, QBasic) und auch in Pascal (aus der Erinnerung, ewig nichts mehr damit gemacht) auch so gehandhabt: Eine Höhe / Breite von 0 zeichnet eine gerade Linie, eine Höhe / Breite von 1 zeichnet eine Linie mit 1 Pixel Versatz zwischen Anfang und Ende. Ist Höhe = Breite = 0, wird ein Punkt gezeichnet.

Warum sollte das ein Bug gewesen sein?

[ts-soft]

Warum sollte das ein Bug gewesen sein?

Weil eine Linie mit einer Höhe von 0 nichts sichtbares sein kann , das wiederspricht jeder Logik.
Wie es in anderen Basics gehandhabt wird, ist auch uninteressant, es wird in PB so gehändelt, wie dokumentiert.
Da interessieren irgendwelche Mutmaßungen nicht.

Allerdings war dieses Verhalten in älteren Versionen noch anders, dies war aber definitiv ein Bug!

[Sven]

Weil eine Linie mit einer Höhe von 0 nichts sichtbares sein kann

Aber ein Kreis mit dem Radius Null ist sichtbar? Und eine Ellipse mit der Achse Null? Eine Linie oder Box der Höhe Null dagegen nicht?

DAS widerspricht jeder Logik.

Ich mein, das kann man ja so definieren. Aber dass

Line(xstart, ystart, laenge, 1) = Line(xstart, ystart, laenge, -1) ist, dagegen Line(xstart, ystart, laenge, 2) != Line(xstart, ystart, laenge, -2)
Line(xstart, ystart, laenge, hoehe) != LineXY(xstart, ystart, xstart + laenge, ystart + hoehe)

finde ich nicht sehr hilfreich.

[STARGÅTE]

Hier mal mein DiskussionsThread von damals, zu diesem Thema:
http://www.purebasic.fr/german/viewtopi ... 16&t=21169

Es ist auch für mich "unlogisch" diese Definition von Line() zu haben.
Du kannst aber einfach LineXY() nutzen, und mit einem Macro Line überschreiben:

Code: Alles auswählen

Macro Line(X, Y, DX, DY, Color)
  LineXY(X, Y, X+DX, Y+DY, Color)
EndMacro

[NicTheQuick]

Ich finde das auch unlogisch. Für mich war Line() nichts anderes wie das, was STARGÅTE da so schön als Macro gebaut hat. Der Höhen- und Breite-Parameter hat ja nichts mit der Höhe oder Breite der Linie zu tun. Sie ist weiterhin 1 Pixel breit.
Aber es macht Sinn für mich, dass der letzte Punkt nicht inklusive ist. Also wenn man Line(0, 0, 1, 1) schreibt, dann macht es Sinn, dass nur genau ein Punkt gezeichnet wird. Damit hat die Linie nämlich eine Breite von 1 und eine Höhe von 1. LineXY(0, 0, 1, 1) hingegen zeichnet den zweiten Punk inklusive, also werde da zwei Pixel gezeichnet. Hintergrund war glaube ich, dass wenn man zuerst Box(0, 0, 4, 4) und dann Line(0, 0, 4, 4) zeichnet, die Linie auch beim letzten Pixel der Box aufhören soll und nicht darüber hinausgeht. Also nicht so (. = Linie, # = Box):

Code: Alles auswählen

  0 1 2 3
0 . # # #
1 # . # #
2 # # . #
3 # # # .
4         .