Article View: dnet.atari
Article #386Re: GEM
From: Karsten Isakovic
Date: Sun, 22 Sep 1991 19:00
Date: Sun, 22 Sep 1991 19:00
49 lines
3148 bytes
3148 bytes
Hallo Frank, >Fuer eine saubere GEM-Einbindung brauche ich Infos ueber den Overscan... >die Fkt. vrt_cpyfm benoetigt in ihrem parameterfeld MFDBs in denen u.a. >eine Angabe "Breite des Speicherblocks in Integers". Das hiesse allerdings, >dass vorausgesetzt wird, fuer saemtl. moegl. bildschirmgroessen wirkl. >jede zeile ein vielfaches von einem Word im speicher belegt - ist dem so ? Ja, das GEM arbeitet nur mit Zeilen die in 16 Pixel Schritt organisiert sind. Du machst allerdings einen grossen (frueher weit verbreiteten) Fehler: Wenn man vom/auf den Bildschirmspeicher blittet darf man den Screen-MFDB nicht selber ausfuellen! Dies geht bei mindestens 5 mir bekannten Grafikkarten garantiert schief. Immer einen NULL-Pointer in fd_addr benutzen! Es bereitet dem VDI keinerlei Probleme, zwischen MFDBs unterschiedlicher Wort-Breite zu kopieren, womit wir gleich zu Deiner zweiten Frage kommen... >ausserdem finde ich keine funktion, die angibt, wie gross der in der >gegebenen Aufloesung verwendete Bildspeicher ist - kann man da einfach >mit der Rechnung (nach v_opnvwk) > > (work_out[0]+1)*(work_out[1]+1)*logd(work_out[13])/8 ; > Nein, nicht ganz ;-) Nimm statt logd(work_out[13]) lieber die Anzahl der Planes, die Du bei vq_extnd in work_out[4] erhaeltst. Lege Deine 2.Bildschirmseite mit BPL = Width/8 * Planes und obriger Laenge an. Wenn Du den zugehoerigen MFDP korrekt ausfuellst und fuer den Screen den MFDB mit einem Nullpointer verwendest geht es unter allen Aufloesungen. Du kannst auch mit eigenen Routinen in diesen Speicher schreiben und den Bereich mit vro_cpyfm auf den Schirm bringen (macht Zb Script-II so). Dies geht aber nur, wenn das Bitplane-Layout, dem des STs entspricht. Allerdings gibt es ja mittlerweile auch wieder eine Menge VGA-Karten, bei denen dieses nicht der Fall ist. In diesem Falle (schreiben auf eigenem Bildschirmspeicher) muss man daher folgendermassen vorgehen: Anlegen einer 2.Bildschirmseite mit 'obriger' Laenge. Allerdings nicht im 'bitplane-interleaved' Geraete-Format, sondern im ATARI Standardformat. Dies heisst, 'Planes' monochrome Bitplanes hintereinander. Nach dem Beschreiben dieses Hintergrundpuffers muss noch in das jeweilige Geraeteformat gewandelt werden. Dies geschieht mit vr_tranfm und es ist wesentlich guenstiger, wenn man noch eine 3.Bildschirmseite anlegt, in die tranformiert wird. Das transformierte Ergebnis kann man dann mit vro_cpyfm auf den Schirm bringen (wie immer Null-pointer in fd_addr verwenden). Gruss, Karsten
Technical Details
Message-ID:
<4861@trick.cs.tu-berlin.de>Path:
arc1-ca.pugleaf.net!gmdzi!unido!opal!kiReferences:
<2681@netmbx.UUCP>Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII-7-bit X-Google-Thread: 12bdcf,27a7b83a68c20f06,start X-Google-Attributes: gid12bdcf,public X-Google-Thread: 14eee0,27a7b83a68c20f06,start X-Google-Attributes: gid14eee0,public X-Google-ArrivalTime: 1991-09-22 12:38:43 PST Path: arc1-ca.pugleaf.net!gmdzi!unido!opal!ki From: ki@opal.cs.tu-berlin.de (Karsten Isakovic) Newsgroups: dnet.atari,sub.sys.st Subject: Re: GEM Message-ID: <4861@trick.cs.tu-berlin.de> Date: 22 Sep 91 19:00:21 GMT References: <2681@netmbx.UUCP> Distribution: dnet Organization: Technical University of Berlin, Germany Lines: 49