Morphos ra_Flags FRST_DOT not working as expected

amiga-news.de Forum > Programmierung > Morphos ra_Flags FRST_DOT not working as expected

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

23.09.2009, 23:05 Uhr

AGSzabo
Posts: 1663
Nutzer

hi,

dumme frage aber warum werden alle meine liniendraws unter morphos ohne den ersten punkt gezeichnet? ich dachte da natürlich sofort an das flag "FRST_DOT" aus rasport.i / .h aber zumidest unter uae macht es keinen unterschied ob das gesetzt ist oder nicht. also warum sollte es unter morphos einen machen? ich kann leider nur beschränkt auf morphos testen weil ich noch kein board dafür habe,

ok, ich habe es testen lassen. also de erste punkt der (meisten) linien wird nicht gezeichnet, unter morphos. egal ob ich das flag setze oder nicht, was ist da los?

ps: ich würde ja gerne nicht direkt auf den rastport zugreifen wenn ich das bit ändere aber im gfxdoc konnte ich bisher keine funktion dazu finden!

--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ Dieser Beitrag wurde von AGSzabo am 23.09.2009 um 23:50 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 09:37 Uhr

DrNOP
Posts: 4118
Nutzer

Zitat:
Original von AGSzabo:
also de erste punkt der (meisten) linien wird nicht gezeichnet, unter morphos.

Ich würde erst mal 'rauszufinden versuchen, ob du die "meisten" näher eingrenzen kannst. Gibt es dabei eine Regelmäßigkeit?

Was passiert, wenn dieser Punkt der nicht gezeichnet wird, nicht der erste der Linie ist sondern der zweite?
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 13:10 Uhr

AGSzabo
Posts: 1663
Nutzer

@DrNOP:

es ist wenn, dann immer der erste punkt. eine regelmäßigkeit konnte ich bisher nicht entdecken. ich habe gehofft dass das hier ein bekanntes problem ist zu dem es eine einfache lösung gibt. eine idee dazu habe ich noch: statt direkter in den rastport schreibung der x/y coordinate die Move() funktion benutzen. aber ich glaube mich zu erinnern dass es bei dem move ein ausname ist in der man gegen die regel schon direkt in den rp schreiben darf...
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 13:19 Uhr

thomas
Posts: 7718
Nutzer

@AGSzabo:

Ich versteh dich nicht. Warum mußt du immer so einen Müll programmieren ?

Du darfst niemals nirgendwo in eine System-Struktur reinschreiben.

Es gibt nur einige wenige Ausnahmen, die dokumentiert sind.

Aber insbesondere, wenn es eine Funktion zum Setzen eines Attributs gibt, dann ist das Schreiben derselben Werte in die Struktur absolut verboten !

Das gleiche gilt für das Flag FRST_DOT und ähnliche. Das wird nirgends in irgendeiner Dokumentation erwähnt. Bis heute wußte ich gar nicht, daß es das gibt. Wie kommst du auf die grausame Idee, das dürftest du selbst setzen ?

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 13:26 Uhr

AGSzabo
Posts: 1663
Nutzer

@thomas:

>insbesondere, wenn es eine Funktion zum Setzen eines Attributs gibt, dann ist das Schreiben derselben Werte in die Struktur absolut verboten
> Wie kommst du auf die grausame Idee, das dürftest du selbst setzen ?

lol, eben WEIL es KEINE funktion dafür gibt. :-)

es ist in rastport.h kommentiert...

mein "müll" ist auf meinem mist gewachsen. wer was dagegen hat, sollte sich zumindest die nase zuhalten. :-)

danke für deinen hinweis!
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 14:03 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
es ist in rastport.h kommentiert...

Das ist etwas völlig anderes als dokumentiert.

Zitat:
mein "müll" ist auf meinem mist gewachsen. wer was dagegen hat, sollte sich zumindest die nase zuhalten. :-)

Aber Hilfestellungen möchtest Du trotzdem, oder?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 14:33 Uhr

DrNOP
Posts: 4118
Nutzer

Zitat:
Original von AGSzabo:
es ist wenn, dann immer der erste punkt.

Jaja, das sagtest du schon.

Aber was passiert, wenn du die Linie einen Punkt weiter rechts/links beginnen läßt, so daß dein verschwundener erster Punkt zum zweiten wird? Bekommst du dann einen Punkt mehr angezeigt, so daß dein neuer erster Punkt wieder verschwunden ist, oder bekommst du gleich zwei Punkte mehr?
Passiert das nur bei waage-/senkrechten/schrägen Linien, die auf einer geraden Zeile/Spalte beginnen oder nur bei ungeraden?

Solche Dinge grenzen das Auftreten nicht ein?
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 14:51 Uhr

AGSzabo
Posts: 1663
Nutzer

@DrNOP:

hm.. das sind vieleicht fragen.... ich habe jetzt mal Move(s) eingebaut statt den direkten zugriff auf x/y im rastport und lasse das erstmal testen. leider hab ich noch kein morphos board aber es hat sich schon jemand gemeldet.
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 15:39 Uhr

AGSzabo
Posts: 1663
Nutzer

ok, mit den moves geht es nur teilweise, [edit] bessergesagt garnicht also genauso wie vorher.

--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ Dieser Beitrag wurde von AGSzabo am 24.09.2009 um 15:56 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 16:50 Uhr

AGSzabo
Posts: 1663
Nutzer

hier ist ein bild vom problem. wie man siehst wird der linkeste button korrekt umrahmt, die anderen aber nicht.

http://otaku.onlinehome.de/xuilineproblem.jpg
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 17:45 Uhr

DrNOP
Posts: 4118
Nutzer

Zitat:
Original von AGSzabo:
hier ist ein bild vom problem.

Jo, dann würd' ich mal als Beginn der falschen Linien probehalber nicht "EckeDesButtons" als Beginn angeben, sondern "EckeDesButtons - 1". Dann wirste schon sehen, ob's besser wird oder ein Punkt außerhalb des Rahmens auch noch gezeichnet wird.

Seh' ich das richtig, daß du das in Assembler machst oder war das ein anderer, mit dem ich dich jetzt verwechsle?

Da könnt's ja dann auch sein, daß sich in deinen Koordinatenberechnungen ein Käfer versteckt, oder nicht?
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 17:55 Uhr

AGSzabo
Posts: 1663
Nutzer

@DrNOP:

ja, ich mache ES in assembler.

an meinen coordinaten mag es nicht liegen, denn unter amigaos funktioniert es ja. ich wüsste nicht wie und warum mal anders und mal wieder anders gerechnet werden sollte.

eher könnte ich mir vorstellen, dass auf grund eines tipfehlers zB irgendwo versehentlich müll in den rastport geschrieben wird.

aber hier mal zum spass an der freude ein stück code von besagter rechnung:

code:

; d0-d3 x1,y1,x2,y2, a2 rp

bevel_border	movem.w	d0/d1,-(a7)

		move.l	gfxbase(pc),a6

		; topleft color

		push	d2
		move.w	d4,d0
		moveq	#0,d1
		moveq 	#RP_JAM1,d2
		move.l	a2,a1
		jsr	_LVOSetABPenDrMd(a6)
		pop	d2

		; top

		move.w	d2,d0		; right-1
		subq.w	#1,d0
		move.w	2(a7),d1	; top
		move.l	a2,a1
		jsr	_LVOMove(a6)
		movem.w	(a7),d0/d1	; left top
		move.l	a2,a1
		jsr	_LVODraw(a6)

		...
		...

--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 20:17 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
hier ist ein bild vom problem. wie man siehst wird der linkeste button korrekt umrahmt, die anderen aber nicht.

Wenn der "linkeste" Button korrekt gezeichnet wird, und die anderen nicht, würde ich mich mal fragen, was zwischen dem Zeichnen des "linkesten" Button und den nächsten passiert.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

24.09.2009, 20:29 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

ja, in die richtung habe ich schon gedacht. bisher ohne erfolg.

dazwischen liegt zB dass die DRAW-Methode an alle Objekte gebroadcastet wird, also eine rekursive funktion an alle members und members-members.

da sich an der position des buttons nichts ändert, muss ich annehmen, dass die layout-klasse richtig arbeitet (das ist die einzige klasse die zwischen den buttons steht).

das problem muss imo irgendwo in den zeichenroutinen stecken. noch habe ich nicht alle direkten zugriffe auf rp_cp_x/y durch moves ersetzt. vielleicht gibts da nebeneffekte...
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

25.09.2009, 15:48 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
da sich an der position des buttons nichts ändert, muss ich annehmen, dass die layout-klasse richtig arbeitet (das ist die einzige klasse die zwischen den buttons steht).

Nur weil eine Routine augenscheinlich das richtige tut, heißt das nicht, dass sie korrekt ist. Vor allem, wenn es darum geht, was sich nebenbei irgendwo in Deinen Daten (nicht auf dem Bildschirm) ändert.

Was auf den ersten Blick auffällt, ist, dass Deine Routine d4 verwendet, obwohl in dem Kommentar kein solcher Parameter steht. Wer weiß, welche weiteren Ungereimtheiten es gibt.

Zitat:
noch habe ich nicht alle direkten zugriffe auf rp_cp_x/y durch moves ersetzt.

Kann ja nicht so schwer sein. Oder hat Dein Editor kein Suchen und Ersetzen?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

25.09.2009, 16:43 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

indem man klassen temporär auskommentiert kann man das problem einkreisen. d4 ist in ordnung ich weis ich habe es vergessen zu nennen.

Mit suchen und ersetzen ist es nicht getan. es war etwas komplizierter.
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

27.09.2009, 08:23 Uhr

AGSzabo
Posts: 1663
Nutzer

ok, hier habe ich den beweis dass es erlaubt ist das FRST_DOT flag zu setzen:

(aus gfxmacros.h)

code:

#define SetDrPt(w,p)	{(w)->LinePtrn = p;(w)->Flags |= FRST_DOT;(w)->linpatcnt=15;}
#define SetAfPt(w,p,n)	{(w)->AreaPtrn = p;(w)->AreaPtSz = n;}

[ - Antworten - Zitieren - Direktlink - ]

27.09.2009, 09:25 Uhr

akl
Posts: 265
Nutzer

@AGSzabo:

>d4 ist in ordnung ich weis ich habe es vergessen zu nennen.

Wieso sicherst Du d0/d1 (scratch) auf dem Stack und d2-d4 bzw. a0-a2 nicht?

[ - Antworten - Zitieren - Direktlink - ]

27.09.2009, 10:40 Uhr

AGSzabo
Posts: 1663
Nutzer

@akl:

>Wieso sicherst Du d0/d1 (scratch) auf dem Stack und d2-d4 bzw. a0-a2 nicht?

d2-d4 und a2 werden nicht verändert, a0 und a1 sind scratch und d0/d1 benötige ich nach dem aufruf der systemfunktionen wieder, siehe code.
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

27.09.2009, 13:04 Uhr

thomas
Posts: 7718
Nutzer

Zitat:
Original von AGSzabo:
ok, hier habe ich den beweis dass es erlaubt ist das FRST_DOT flag zu setzen:

Du verdrehst die Tatsachen. Die Funktion ist als Makro realisiert, weil es keinen Sinn macht, eine Routine, die aus drei Assembler-Instruktionen besteht, in einem Unterprogrammaufruf zu verpacken, der in wesentlich mehr Instruktionen aufgelöst wird.

Die Existenz des Makros beweist, daß es keinen Grund gibt, das Flag selbst zu benutzen.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

27.09.2009, 19:50 Uhr

AGSzabo
Posts: 1663
Nutzer

Wer hätts gedacht, ich habe alle writes nach rp_cx/_cy durch Move() ersetzt ABER das problem der offenen buttonränder unter Morphos besteht weiterhin ... manchmal!

Es wird wenn, dann immer der LETZTE punkt der linie nicht gezeichnet.

Ich dachte blos vielleicht hatte hier mal jemand ein änliches Problem und kennt die lösung.

--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ - Antworten - Zitieren - Direktlink - ]

27.09.2009, 20:31 Uhr

DrNOP
Posts: 4118
Nutzer

Zitat:
Original von AGSzabo:
Es wird wenn, dann immer der LETZTE punkt der linie nicht gezeichnet.

Wie nun!? Sieht dein Bild nun anders aus, oder hattest du Beginn und Ende der Linie verwechselt? Im ersteren Fall solltest du untersuchen, wieso die Änderung eines Befehls einen solchen Einfluß haben kann.

Ich vermute immer noch, daß du dich bei den Koordinaten bzw. der Linienlänge um einen Pixel vertust.
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

27.09.2009, 20:43 Uhr

AGSzabo
Posts: 1663
Nutzer

@DrNOP:

auf jeden fall hab ich nix falsch gerechnet, weil unter amiga os funktioniert es ja. nur unter morphos tritt das problem auf.

registers,
Andreas
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ Dieser Beitrag wurde von AGSzabo am 27.09.2009 um 20:48 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

28.09.2009, 09:58 Uhr

DrNOP
Posts: 4118
Nutzer

Es hilft dir aber nix, MorphOS die Schuld zu geben. Deswegen läuft dein Programm noch lange nicht. Also stell' fest, ob du unter MorphOS die Koordinaten anders angeben mußt als woanders.

Falls es daran liegt kannst du
a) dieses Verhalten an den inneren Zirkel melden, und zwar so daß es nachvollzogen werden kann und
b) dein Programm entsprechend einstellen, daß es auch unter MorphOS richtig reagiert.

Hast du die verwendeten Koordinaten schon mal überprüft? Also das, was du meinst zum Zeichnen zu verwenden und das, was er gezeichnet hat, verglichen?
--
Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker

[ - Antworten - Zitieren - Direktlink - ]

28.09.2009, 12:45 Uhr

akl
Posts: 265
Nutzer

@AGSzabo:
Dein Code geht ja noch weiter, wie Du durch 2x "..." angedeutet hast, insofern ist das für uns nicht überprüfbar.

[ - Antworten - Zitieren - Direktlink - ]

28.09.2009, 12:50 Uhr

akl
Posts: 265
Nutzer

@AGSzabo:

>d2-d4 und a2 werden nicht verändert

Klar wird d2 verändert:

moveq #RP_JAM1,d2

Aber da ist ja lustigerweise auch noch ein zugehöriges push weiter unten:

push d2

Ich hoffe mal, das zugehörige pop-Statement findet sich am Ende der Funktion dann auch.

[ - Antworten - Zitieren - Direktlink - ]

28.09.2009, 15:41 Uhr

AGSzabo
Posts: 1663
Nutzer

@akl:

da hast du dich verschaut. das push und pop ist um die benutzung von d2 herum.

ps @ DrNOP,

der innere zirkel meint es gäbe tasächlich so ein (oder änliches) problem mit den fehlenden pixeln schon im bugtracker. es könnte vielleicht an der graka liegen.
--
Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1600mhz Ubuntu Linux / WinXP -- BenQ FP93G TFT - 1048 like CRT - HP psc1110

[ Dieser Beitrag wurde von AGSzabo am 29.09.2009 um 12:04 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Morphos ra_Flags FRST_DOT not working as expected

[ - Suche - Neue Beiträge - Registrieren - Login - ]