Thread View: dnet.atari
2 messages
2 total messages
Started by Frank Bergemann
Sun, 22 Sep 1991 09:07
GEM
Author: Frank Bergemann
Date: Sun, 22 Sep 1991 09:07
Date: Sun, 22 Sep 1991 09:07
21 lines
1363 bytes
1363 bytes
hallo !
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 ?
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 ;
Abhilfe schaffen ? .... logd() soll den logarithmus dualis berechnen....
das ganze soll dann die Anzahl der fuer den Bildspeicher notwendigen
Bytes ergeben ....
Gruss !
... Frank
Re: GEM
Author: 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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads