PureBoard

Echt cool unter PB 4.60b2 x86 ! Bei PB 4.60b2 x64 gibt es allerdings einen Assembler-Error:Funktioniert das mit der neuen PB 4.60b3 x64 Version?

Ich hätte da noch einen Wunsch, den ich bei den PB Befehlen stark vermisse: ich will eine Transformation angeben können und alle Objekte, die danach gezeichnet werden, werden durch diese Transformation manipuliert.

>> Funktioniert das mit der neuen PB 4.60b3 x64 Version?
Nein, selber Fehler!

dito.
Wenn man alle Color.q durch Color.i ersetzt, werden die Grafiken zwar angezeigt, aber
der Schatten wird dann auch weiß.

[Edit]
#gNOCOLOR = $1FFFFFFF
Ein F zuviel. So läuft's bei X86 und 64-Bit-PB korrekt.
[/Edit]


Gruß Falko

ts-soft hat geschrieben:>> Funktioniert das mit der neuen PB 4.60b3 x64 Version?
Nein, selber Fehler!

Hier ebenfalls.
Allerdings läuft der Code aus dem alten Thread unter PB 4.60b3 x64.

SoS hat geschrieben:

ts-soft hat geschrieben:>> Funktioniert das mit der neuen PB 4.60b3 x64 Version?
Nein, selber Fehler!

Hier ebenfalls.
Allerdings läuft der Code aus dem alten Thread unter PB 4.60b3 x64.

Der Code hat ja auch kein #gNOCOLOR = $1FFFFFFFF
wo ein F zu viel ist.

Falko hat geschrieben:wo ein F zu viel ist.

Stimmt,muss man erst mal finden.

SoS hat geschrieben:

Falko hat geschrieben:wo ein F zu viel ist.

Stimmt,muss man erst mal finden.

Die Fehlermeldung dazu war ja folgende:

PB-IDE-64Bit hat geschrieben:---------------------------
PureBasic - Assembler error
---------------------------
PureBasic.asm [2110]:

PUSH qword 137438953471

error: value out of range.


---------------------------
OK
---------------------------

Da dort qword steht, was aussagt, das der Wert in Quad ausserhalb der Grenze liegt,
habe ich nach den Variablen mit .q gesucht. Also kam da nur color heraus. und was diesem
Color dann übergeben wurde, ist diese Konstante. Darum konnte man das finden.

Übrigens funktioniert das auch einfach mit #gNOCOLOR = 0 bei beiden Bit-Versionen von PB.
Ich konnte da keinen Unterschied sehen.

Damit die Schatten auch dem entsprechen, was die Zeichnungen anzeigen, habe ich auch das
gSetPenCaps(#LineCapRound,#LineCapArrowAnchor)
gleich hier zwischen eingesetzt. Ist nur eine kleine Schönheitskorrektur:
Gruß Falko

Meiner Meinung nach sollten das doch 8 F und n 1 sein, damit das hier:
Problem mit 32-Bit-Farbe als optionaler Parameter

Deswegen muss man hier Quads übergeben, um sicher zu sein, wann wirklich eine Farbe übergeben wurde.
Und Default ist dann etwas über $FF FF FF FF also zB $1 00 00 00 00

Hallo,

und erstmal vielen Dank für den vielen Dank und die
Motivation weiter zu machen!
Habe heute auch schon weitergemacht und 2 neue Befehle
eingebaut. Werde aber erst noch weiter machen und die
nächste Version dann in den nächsten 1 oder 2 Tagen
hier rein stellen.

Zu dem Fehler:
$1FFFFFFFF ist ein legaler Wert für den Variablentyp Quad.
Das muß so sein, wie STARGÅTE bereits sagte, um zwischen
"Farbe" und "keine Farbe" zu unterscheiden.
RGBA()-Farben können schließlich den kompletten Long-Raum (32bit)
einnehmen. Man kann also nicht $1FFFFFFF nehmen, da dass dann
eine legale Farbe wäre.

Festzustellen ist: PureBasic gibt keinen Syntaxfehler oder bemängelt
irgend etwas. Auf x86 läuft es wie es soll. Auf x64 gibt es einen
Assemblerfehler. Der Assembler meint $1FFFFFFFF ist kein
legales qword (Quad, 64bit), was imho nach einem Fehler im Assembler
aussieht.

Der Assemblerfehler kommt bei Default-Parameter vom Typ Quad: Das sollte einen Bugreport wert sein.

EDIT:
Der Unterschied im generierten Assemblercode: Das sieht danach aus, als wenn es nicht erlaubt ist direkt qwords
auf den Stack zu pushen. Das würde heißen, PB generiert falschen
ASM-Code.
PB müßte dann auch für Default-Parameter den Code über das Register
generieren, der korrekt geht.

Danilo hat geschrieben:Habe heute auch schon weitergemacht und 2 neue Befehle
eingebaut. Werde aber erst noch weiter machen und die
nächste Version dann in den nächsten 1 oder 2 Tagen
hier rein stellen.

Ich freue mich schon darauf. Prima Arbeit, die unter Windows sehr nützlich ist



Das mit dem ASM-Fehler ist sowieso komisch, da die 32-Bit-Version von PB überhaupt nicht darauf
reagiert, auch wenn ich diesen Wert um weitere $F's erhöhe.

Blödes Beispiel unter PBX86
Damit meine ich, das es max. #gNOCOLOR = $1FFFFFFFFFFFFFFF geht.
Ein weiteres F zeigt mir keinen ASM-Fehler an, sondern einen Überlauf.

X86-PB hat geschrieben:---------------------------
PureBasic
---------------------------
Zeile 108: Numerischer Überlauf: zu große Zahl.
---------------------------
OK
---------------------------

Gruß Falko