Fehler in P96/Cgx oder graphics.library?

amiga-news.de Forum > Programmierung > Fehler in P96/Cgx oder graphics.library?

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

-1-

[ - Beitrag schreiben - ]

20.08.2002, 20:53 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

Ich habe irgendwelche unerklärlichen Fehler die ich anfangs auf mein Programm abschob obwohl das eigentlich nicht sei konnte.

Es geht darum das ich Sachen abbilde die dann in seltenen Fällen an einer völlig anderen Position auftauchen, obwohl ich die Koordinaten überprüft habe und sowohl die als auch der RastPort korrekt sind.

Nun erhalte ich die selben Fehler mit den Unterschiedlichsten Programmen, sodass ich nicht davon ausgehen kann, dass es an meinem Programm liebt. An WinUAE was ich anfangs annahm kann es auch nicht liegen, da andere mir den Fehler auch berichteten, die WinUAE nicht benutzen. Also muss es ein Problem in der graphics.library oder mit P96 sein, Fehler äussert sich darin, dass z.B. Bilder oder einfarbige Blöcke am linkern oberen Bildschirmrand auftauchen.

Ich habe mich an ein Problem mit ChangeWindowBox erinnert, z.B. war es unmöglich nach ChangeWindowBox() graphikoperationen durchzuführen, da die Funktion zurückzukehren scheint obwohl noch garnicht beendet, so habe ich nach ChangeWindowBox() ein Delay() eingefügt wodurch die Probleme verschwanden, nun habe ich das selbe mit dem anderen Problem ausprobiert und seit 3 Monaten habe ich diese Fehler nicht mehr.

Hat jemand ähnliches erlebt oder kennt die Lösung dafür?

gruss

[ - Antworten - Zitieren - Direktlink - ]

20.08.2002, 21:54 Uhr

thomas
Posts: 7718
Nutzer

Vielleicht solltest du damit anfangen, die Autodocs zu lesen. Da ist ausdrücklich beschrieben, daß die Funktionen zur Änderung von Window-Position und Größe nicht sofort wirken, sondern erst, wenn die eintsprechende IDCMP-Message empfangen wird !

Zitat:
Like MoveWindow() and SizeWindow(), the effect of this function
is deferred until the next input comes along. Unlike these
functions, ChangeWindowBox() specifies absolute window position
and dimensions, not relative. This makes for more reliable
results considering that the action is deferred, so this
function is typically preferable to MoveWindow() and SizeWindow()
paired.

You can detect that this operation has completed by receiving
the IDCMP_CHANGEWINDOW IDCMP message

Gruß Thomas

--
Email: thomas-rapp@web.de

Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

21.08.2002, 12:56 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

@thomas,

Irgendwie finde ich deine letzten beiden Ausdrucksweisen ein wenig unverschämt!

Was ChangeWindowBox() angeht, geht das Problem auf das Jahr 95 zurück, wo es zumindestens mir nicht Möglich war die AutoDocs einfach so aus dem Internet zu laden, man war auf Bücher beschränkt wo das nicht drinne stand!

Meine Frage hast du damit nicht beantwortet, warum diese grauen (bunten) Kästen auftauchen.

gruss

[ - Antworten - Zitieren - Direktlink - ]

21.08.2002, 13:39 Uhr

thomas
Posts: 7718
Nutzer

Sorry, wenn ich unverschämt klinge, aber ich kann es eben nicht leiden, wenn Fremdsoftware schlechtgemacht wird, obwohl nur eine Fehlbedienung vorliegt. Ich habe auch angefangen zu Programmieren, als es noch keine Autodocs frei verfügbar gab. Aber wenn ich einen solchen Fehler beobachte, versuche ich erstmal herauszufinden, ob ich alles richtig gemacht habe. Und die Developer CDs sind schon etwas länger verfügbar, ich weiß nicht mehr genau wann, aber in den späten 90ern kam die erste heraus.

Zu dem Fehler: soetwas wie du beschreibst habe ich noch nicht erlebt. Wenn du mir ein Beispielprogramm (mit Source) schickst, kann ich vielleicht herausfinden, ob der Fehler bei dir oder in der Graka-Software liegt.

Gruß Thomas

--
Email: thomas-rapp@web.de

Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

21.08.2002, 15:13 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

Es kann nicht an mir liegen, da ich die Sachen überprüft habe. Das Fenster und somit auch der RastPort ist vorhanden als auch die Koordinaten stimmen, anfangs habe ich vermutet dass es irgendwie an der guigfx.library liegen könnte aber da dieser Fehler in letzter Zeit auch in anderen Programmen auftaucht die diese nicht nutzen muss es etwas anderes sein.
Wie gesagt ein Delay() schien diesen Fehler zu beheben (nach OpenWindow() ), habe jetzt nicht nachgeschaut ob dieese Funktion auch "asynchron" arbeitet aber ich habe auch noch nie Probleme damit gehabt und habe nie bei irgendeinem Programm ein Delay() oder eine sicherlich bessere Wartemöglichkeit nach OpenWindow() gesehen.

[ - Antworten - Zitieren - Direktlink - ]

22.08.2002, 08:55 Uhr

tokai
Posts: 1071
Nutzer

Vielleicht hast du ja auch nur einen "krummen" patch im System!
--
http://www.taniquetil.de

[ - Antworten - Zitieren - Direktlink - ]

22.08.2002, 10:02 Uhr

g0ldm0m0
Posts: 122
Nutzer

Schon mal MuForce mitlaufen lassen?

mfg Goldmomo

[ - Antworten - Zitieren - Direktlink - ]

22.08.2002, 12:37 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

Wie gesagt benutze ich WinUAE und Patches habe ich alle Entfernt ohne Erfolg. Ferner berichteten mir andere vom gleichen Fehler die nicht WinUAE nutzen.

Das Problem daran ist, dass der Fehler extrem Selten kommt, sodass man eigentlich kaum daran arbeiten kann. Wie gesagt bei meinem Programm trat er nicht mehr auch.

Mir kommt es vor ob die Graphikkarte als Zwischenspeicher missbraucht wird. Ich beispielweise habe guigfx benutzt um Sachen zu zeichnen und habe mir gedacht dass vieleicht der RastPortpointer NULL ist, also habe ich den extra auf NULL gesetzt um zu sehen was Passiert, aber es tat sich nichts hier wurde nichts gezeichnet.

Was MuForce&Co angeht bin ich mir sicher dass WinUAE keine MMU unterstützt.

gruss.

[ - Antworten - Zitieren - Direktlink - ]

22.08.2002, 15:23 Uhr

thomas
Posts: 7718
Nutzer

Ich kann nur mein Angebot wiederholen: schick mir eine Beispiel-Source und ich versuche herauszufinden, woran es liegt.

Gruß Thomas

--
Email: thomas-rapp@web.de

Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

22.08.2002, 15:54 Uhr

Georg
Posts: 107
Nutzer

Benutzt du simple refresh Fenster? Und eine Clip Region
(layers/InstallClipRegion)?

[ - Antworten - Zitieren - Direktlink - ]

23.08.2002, 10:08 Uhr

Solar
Posts: 3680
Nutzer

Zitat:
Original von DariusBrewka:
Es kann nicht an mir liegen, da ich die Sachen überprüft habe.

Oha, Darius, da lehnst Du Dich aber weit aus dem Fenster...

[ - Antworten - Zitieren - Direktlink - ]

23.08.2002, 13:45 Uhr

gni
Posts: 1106
Nutzer

Zitat:
DariusBrewka:
Wie gesagt benutze ich WinUAE und Patches habe ich alle Entfernt ohne Erfolg. Ferner berichteten mir andere vom gleichen Fehler die nicht WinUAE nutzen.

Solange Du es nicht auf einem echten Amiga überprüft hast, ist keine Aussage über den Fehler möglich...

[ - Antworten - Zitieren - Direktlink - ]

23.08.2002, 13:59 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

@gni

Ich habe es von verschiedenen Personen gehört, die einen echten amiga benutzt haben.

@solar

natürlich ist es schwierig zu behaupten dass es Fehlerfrei ist.
Aber wenn es wirklich die simpelsten Operationen sind kann man nicht von Fehlern sprechen.

hier ein Beispiel (ein anderes habe ich durch Falschen Tastendruck leider gelöscht)

code:

SAVEDS ULONG shapeDraw(struct IClass *cl,Object *obj,struct MUIP_Draw *msg) {
   struct MyShapeData *data = INST_DATA(cl,obj);
   		 UWORD ocx, ocy;

   DoSuperMethodA(cl,obj,(Msg) msg);

   if (!(msg->flags & MADF_DRAWOBJECT)) return(0);

   if (data->layer) {
      SetAPen(_rp(obj), 0);
      RectFill(_rp(obj), _mleft(obj), _mtop(obj), _mright(obj), _mbottom(obj));
      ocx = data->layer->cx;
      ocy = data->layer->cy;
      data->layer->cx = -_mleft(obj);
      data->layer->cy = -_mtop(obj);
      RepaintShapeLayerRastPort(_rp(obj), data->layer);
      data->layer->cx = ocx;
      data->layer->cy = ocy;
   } else {
      SetAPen(_rp(obj), 0);
      RectFill(_rp(obj), _mleft(obj), _mtop(obj), _mright(obj), _mbottom(obj));
   }
   return(0);
}

es geht um die RectFill() Anweisung, es kann niemand behaupten das dort irgendetwas Falsch ist und dennoch ist es gerade eben passiert das der Block in der gleichen Grösse nicht bei _mleft(), _mtop() und schon garnicht bei _rp(), sondern bei 0,0 in &WorkbenchScreen->RastPort gezeichnet wurde

[ - Antworten - Zitieren - Direktlink - ]

24.08.2002, 20:29 Uhr

Holger
Posts: 8116
Nutzer

Zitat:

Original von DariusBrewka:

code:

SAVEDS ULONG shapeDraw(struct IClass *cl,Object *obj,struct MUIP_Draw *msg) {
   struct MyShapeData *data = INST_DATA(cl,obj);
   		 UWORD ocx, ocy;

   DoSuperMethodA(cl,obj,(Msg) msg);

   if (!(msg->flags & MADF_DRAWOBJECT)) return(0);

   if (data->layer) {
      SetAPen(_rp(obj), 0);
      RectFill(_rp(obj), _mleft(obj), _mtop(obj), _mright(obj), _mbottom(obj));
[...]

Rufst Du denn ObtainGIRPort auf? Ich weiß ja nicht, ob das _rp() Macro das erledigt (glaub ich nicht so recht, wäre ziemlicher Overkill, so oft wie es benutzt wird).

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

25.08.2002, 02:07 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

@Holger

Nein tue ich nicht, aber das ist auch völlig Egal ob ich MUI oder sonst etwas nutze, früher oder später kommt das immer.
Hier war es RectFill, aber es kommt bei jeder BlockOperation vor, z.b. auch in guigfx etc.

Entfernung aller Patches bringt nichts, vieleicht würde die Entfernung von P96 etwas bringen aber mit AGA kann ich nicht arbeiten und mir macht das eigentlich auch nicht soviel aus, nur für andere scheint das ein Bug zu sein und ich bin überzeugt dass es das nicht sein kann.

[ - Antworten - Zitieren - Direktlink - ]

26.08.2002, 17:36 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von DariusBrewka:
@Holger
Nein tue ich nicht, aber das ist auch völlig Egal ob ich MUI oder sonst etwas nutze, früher oder später kommt das immer.

Ich kann nicht ganz nachvollziehen, was Du damit sagen willst. Wenn Dein Programm fehlerhaft arbeitet, und zwar nur Dein Programm, an welchem Programm wird das wohl liegen?
Oder glaubst Du, Du bist der einzige, der jemals RectFill() auf einem Amiga benutzt hat?
Also, wenn Du innerhalb einer Gadget-Render Routine den RastPort nicht mit ObtainGIRPort() holst, wie es in den Intuition-Dokumentationen gefordert wird, und dann Grafikroutinen fehlerhaft arbeiten, egal ob in diesem Moment oder später, sollte man vielleicht mal den RastPort korrekt belegen. Wenn es nicht daran liegt, hat man wenigstens eine Fehlerquelle ausgeschlossen.

Zitat:
[...]nur für andere scheint das ein Bug zu sein und ich bin überzeugt dass es das nicht sein kann.

Wenn ein Programm nicht das macht, was es soll, nennt man das eben einen Bug, ob es dem Programmierer gefällt oder nicht.

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

26.08.2002, 21:36 Uhr

Georg
Posts: 107
Nutzer

@Holger:

ObtainGIRPort() ist nur für intuition boopsi gadgets da,
nicht für mui gadget klassen, da die immer nur im app task
ablaufen

@Darius:

Ist data->layer ein echter layers.library Layer? Versuch'
mal die data->layer->cx bzw. cy Pokes rauszunehmen. Evtl.
handeln das die P96 Ersatz-Grafik Routinen nicht richtig,
bzw. nur richtig bei Verwendung von SuperLayers.

Es gibt wohl extrem wenige Programme die Layer->cx/cy
bei simple/smart refresh Fenstern verändern. Deshalb
kann es schon sein, daß da ein möglicher P96 Bug ewig lange
nicht auffällt.

Und was macht RepaintShapelayerRastPort?

[ - Antworten - Zitieren - Direktlink - ]

27.08.2002, 00:26 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

@Georg

nein data->layer ist natürlich kein Layer der layers.library es ist eine Private Struktur und dass ist auch nicht worauf es ankommt, genauso könnte ich alles nach RectFill löschen.

@Holger

wo habe ich geschrieben, dass dieses nur in meinen Programmen auftritt? und wo habe ich geschrieben dass das nur bei RectFill auftritt, genausogut kann ich auch BlitBitMapRastPort, eine Funktion der guigfx oder irgendeine andere Blockop nutzen.

Selbst ein einfaches

win = OpenWindow(....)
RectFill(win->RPort, ....)

würde früher oder Später den gleichen Fehler produzieren.

Mein Programm tut was es soll und wie viele andere auch macht es den gleichen Fehler für den es keine Ursache gibt.

[ - Antworten - Zitieren - Direktlink - ]

27.08.2002, 10:09 Uhr

Georg
Posts: 107
Nutzer

@Darius

Mach' mal ein debug output vor den RectFill aufruf, der
rp->Layer ausgibt. Evtl. wird das von was auch immer getrasht
woraufhin dann rp->Layer NULL ist und die gfx operation
praktisch dann direkt in der screen bitmap landet, anstatt
(geclippt) in dem Window.

[ - Antworten - Zitieren - Direktlink - ]

27.08.2002, 12:59 Uhr

DOM
Posts: 1044
Nutzer

@ DariusBrewka

Hm ich hatte das gleiche Problem, allerdings konnte ich es
unter verschiedenen Systemen testen. Ich hatte was programmiert
und unter CGX sah es auch wunderbar aus, aber unter AmigaXL
und P96 war ich ziemlich überrascht, also installierte ich
auf nen Amiga P96 und da war es das gleiche, die X/Y Positionen
werden irgendwie neu ausgelegt/berechnet. Seufz!

[ - Antworten - Zitieren - Direktlink - ]

27.08.2002, 16:29 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

@Georg

Wie ich oben einige Male geschrieben habe kommt das Problem bei den einem meiner Programme nicht mehr vor, nachdem ich ein kleines Delay() nach OpenWindow() eingebaut habe. Ansonsten kann man mal schauen, ob du recht hast.

Wieauchimmer, es steht nirgends Geschrieben dass nach OpenWin() eine Verzögerung nötig ist und gesehen habe ich das auch noch in keinem Programmm.

gruss

[ - Antworten - Zitieren - Direktlink - ]

27.08.2002, 22:08 Uhr

Georg
Posts: 107
Nutzer

@Darius

Versuch' auch mal das RectFill() innerhalb von LockLayer(0, rp->Layer)
und UnLockLayer(rp->Layer) zu machen.

Das würde eine (evtl.) best. Art von Fehler in den (p96) gfx routinen
unschädlich machen, den es bei AROS mal in verschiedenen gfx routinen
gab. War in etwa so:

struct ClipRect *cr = layer->ClipRect;

LockLayer();
[cr kette durchgehen und reinrendern]
UnlockLayer().

Der Fehler ist hier wie du sicherlich siehst, daß layer->ClipRect
ausgelesen wird, noch bevor der Layer gelockt ist, was natürlich
verboten ist.

[ - Antworten - Zitieren - Direktlink - ]

28.08.2002, 00:03 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

@Georg

Nee ich werde mein Programm nicht dahingehend ändern um Fehler anderer Software zu überspielen :-(, es stürzt halt nicht ab und daher stört es mich auch nicht.

gruss

[ - Antworten - Zitieren - Direktlink - ]

28.08.2002, 07:46 Uhr

Georg
Posts: 107
Nutzer

@Darius

Das soll ja nur ein Test sein, um zu sehen ob der Fehler dann
verschwindet. Um eine Idee zu bekommen wo der Fehler liegen
könnte.

[ - Antworten - Zitieren - Direktlink - ]

28.08.2002, 10:57 Uhr

DariusBrewka
Posts: 899
[Benutzer gesperrt]

@Georg

Recht hast du, aber ich will mich eigentlich nicht mehr länger damit beschäftigen.

gruss

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Fehler in P96/Cgx oder graphics.library?

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