|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Hintergrundbild für eigenen Screen laden | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
04.04.2010, 20:19 Uhr Reth Posts: 1858 Nutzer |
Hallo zusammen, vielleicht ist das nicht ganz die richtige Frage, aber was ist denn die beste und ressourcenschonendste Möglichkeit sich einen Hintergrund für nen eigenen Screen zu laden? Ein Bild in der gleichen Auflösung und dann direkt auf den Screen blitten (bzw. in dessen RastPort)? Was ich eigentlich benötige ist eine "Umrandung" für ein Spielfeld, dass aus lauter einzelnen Hexagonen besteht. Da es sich dabei um eine Insel bzw. abgeschlossene Welt handeln soll, habe ich das Glück, einen einheitlichen Rand darstellen zu können. Bin daher auch für andere passende Vorschläge offen! Vielen Dank schon mal! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
04.04.2010, 20:40 Uhr inq Posts: 445 Nutzer |
Zitat:kommt drauf an, was fürn Bild. Normalerweise könntest du es direkt in die Bitmap des Screens laden, falls es ein Amiga-Screen ist (also nativ). für GFX-Karten müßtest du sicher "Blitten". Ressourcenschonend ist relativ: wie oft willst du das Bild denn neu laden? du brauchst eh nur soviel Speicher, wie zum Laden/decodieren etc. nötig ist. wenn du später den Hintergrund buffern willst, ist es gleich, ob der ein Bild enthält oder nicht. gruss [ - Antworten - Zitieren - Direktlink - ] |
|
04.04.2010, 20:56 Uhr Reth Posts: 1858 Nutzer |
Zitat: Dann besser blitten, da es sich um beide Screen-Arten handeln kann. Zitat: Will es nur einmal laden, dann soll es fest bleiben. Mmit Ressourcenschonend mein ich, sowenig Speicherverbrauch wie möglich. Da durch das Spielfeld ein ganzer Bereich ständig verdeckt ist, wäre evtl. eine schonendere Möglichkeit, nur in den wirklich freien Bereichen darzustellen bzw. nur Bildmaterial für diese zu laden. Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
04.04.2010, 21:03 Uhr inq Posts: 445 Nutzer |
Zitat:siehe oben. den Speicher für die Screen-Bitmap hast du eh schon. ob da ein Bild ist oder nicht, ändert nur die Bits im Speicher, nicht die Größe. Wenn du sowenig Speicher übrig hast, kannst du noch versuchen, ein sich wiederholendes Muster zu blitten, das geht dann auf jeden Fall mit weniger Verbrauch einher. [ - Antworten - Zitieren - Direktlink - ] |
|
04.04.2010, 21:14 Uhr thomas Posts: 7718 Nutzer |
@Reth: Um den Hintergrund zu füllen, egal mit was, eignet sich SA_BackFill sehr gut. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
04.04.2010, 23:06 Uhr inq Posts: 445 Nutzer |
Zitat:wäre aber in diesem fall nicht nur nicht angemessen, sondern auch unnötig schwierig, oder? nen hook installieren für eine Screenbitmap geht vielleicht ein wenig zu weit, finde ich. hätte auch keinen Einfluß auf den Speicherverbrauch. Oder liege ich da falsch? [ - Antworten - Zitieren - Direktlink - ] |
|
05.04.2010, 00:14 Uhr thomas Posts: 7718 Nutzer |
@inq: Kommt drauf an. Wenn man eine große Bitmap hat, die den Hintergrund darstellt, dann ist der Hook sehr einfach programmiert und es macht kaum einen Unterschied, ob man BltBitMapRastPort oder EraseRect benutzt, um einen Bereich zu löschen. Wenn man stattdessen den Hintergrund aus kleineren Kacheln zusammensetzen möchte, dann spart es Speicher, wenn man dies "on the fly" macht. Wenn man dann einen kleinen Bereich löschen möchte, muß man entweder eine komplizierte Berechnung anstellen, um herauszufinden, welchen Teil welcher Kachel man zeichnen muß, oder man läßt sich die Werte vom Betriebssystem ausrechnen. Im ersten Fall macht es keinen Unterschied, ob man einen Hook benutzt oder es selbst programmiert, im zweiten Fall ist es mit dem Hook sogar einfacher. Im übrigen möchte ich mal darauf hinweisen, daß CPU auch eine Resource ist. Ein Programm, das auf Teufel komm raus Speicher spart und dafür aber nur auf übertakteten 68060 halbwegs flüssig läuft, ist noch eher als resourcenhungrig zu bezeichnen, als eins das allen verfügbaren Speicher ausnutzt aber dafür zehnmal schneller läuft. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
05.04.2010, 00:42 Uhr inq Posts: 445 Nutzer |
@thomas: Als unnötig schwierig meinte ich, den Hook betreffend, daß der Source fürs Blitten und Picladen ja sowieso schon vorhanden ist (?) und daher kein erheblicher Aufwand mehr nötig sein würde. Das ganze Drumherum ist mir eh unbekannt, wahrscheinlich würde ich keine Speicherfrage überhaupt als Argument akzeptieren... Ich darf außerdem mal (frei) eine Studie von (Irgendjemandem) zitieren: Der Antrieb des Coders liegt nicht im Schreiben von Text, sondern im Lösen von Problemen. Demzufolge zöge ich die "händische" Variante sowieso vor  inq [ - Antworten - Zitieren - Direktlink - ] |
|
05.04.2010, 11:18 Uhr Reth Posts: 1858 Nutzer |
Zitat: Hier möchte ich mal einhaken: Wie funktioniert denn das, dass man sich vom Betriebssystem sagen lassen kann, was man neu zeichnen muss? Habe nämlich genau das Problem mit meinem Spielfeld, auf dem immer wieder Sachen an neuen Positionen neu gezeichnet werden müssen. Dann muss an der alten Position der Hintergrund (also Teile der Kacheln, die das Spielfeld bilden), aber auch alle dort zusätzlich positionierten Objekte neu zeichnen. Bisher mach ich das nämlich mit "komplizierten Berechnungen" und Tiefenebenen, um heraus zu finden, was überdeckt war. Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
05.04.2010, 13:59 Uhr thomas Posts: 7718 Nutzer |
@Reth: Der Backfill-Hook zeichnet nur den Hintergrund neu. Wenn du andere Objekte vor dem Hintergrund hast, mußt du die selbst neu zeichnen. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
05.04.2010, 14:17 Uhr Reth Posts: 1858 Nutzer |
@thomas: Gibts da irgendwo ein gutes Bsp. für (hab bei Dir schon geschaut, leider erfolglos). Evtl. kann ich mein Spielfeld mit als Hintergrund anlegen und dadurch dessen Neuzeichnen organisieren!? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
05.04.2010, 15:44 Uhr thomas Posts: 7718 Nutzer |
@Reth: Jetzt gibt's eins: http://thomas-rapp.homepage.t-online.de/examples/backfill.c Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
05.04.2010, 22:32 Uhr Reth Posts: 1858 Nutzer |
@thomas: Vielen Dank! Kam ja wie aus der Pistole geschossen! Leider hab ich noch nicht alles verstanden, drum hier noch ein paar Fragen: Was ist in den Parametern der Message der Hook-Funktion enthalten bzw. was bedeuten sie? Also was enthalten der Zeiger auf die Layer-Struktur, das übergebene Rechteck und die Offset-Koordinaten? Handelt es sich dabei um den betroffenen Bereich der im ebenfalls übergebenen Rastport neu gezeichnet werden muss? Was passiert denn genau innerhalb der beiden Schleifen in der backfill_funct? Wird dabei der Hintergrund wiederhergestellt? Wenn ja, warum reicht hier dann nicht der Blit des ggf. betroffenen Rechteckes, sondern es muss iterativ vorgegangen werden? Die andere Frage bezieht sich auf die load_img-Funktion, da ich mit BOOPSI und DataTypes keinerlei Erfahrungen habe: An welcher Stelle wird dort denn das Bild von HD geladen? Passiert das mit innerhalb von NewDTObject? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
05.04.2010, 22:54 Uhr thomas Posts: 7718 Nutzer |
Zitat: Der Layer ist der Layer des Fensters. Das Füllen des Hintergrunds ist eine Funktion der layers.library und die arbeitet nurnmal mit Layern. Das Rectangle enthält die Koordinaten des Rechtecks, das neu gezeichnet werden soll, relativ zur Zielbitmap, also zum Screen. Der Offset ist die linke obere Ecke relativ zur Quellbitmap, also zum Fenster. Beachte, daß die Dokumentation ausdrücklich verbietet, den übergebenen Rastport zu benutzen, sondern man darf dort nur den Pointer auf die Zielbitmap auslesen. Wenn man eine Funktion benutzen möchte, die einen Rastport benötigt, muß man selbst einen anlegen und mit der Bitmap verknüpfen. Zitat: Wenn du weißt, daß die Quellbitmap mindestens so groß ist, wie das ganze Fenster, dann reicht natürlich ein Blit. Aber wir sprachen hier im Thread ja über Kacheln und wenn die Kachel kleiner ist als das Rechteck, das gefüllt werden soll, dann mußt du mehrmals zeichnen. Zitat: NewDTObject prüft den Dateityp und lädt die Datei von der Platte, DTM_PROCLAYOUT passt das Pixelformat und die Farben an den Screen an. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2010, 12:24 Uhr Holger Posts: 8116 Nutzer |
Nur mal ein kleiner Denkanstoß: Wenn man ein rahmenloses, bildschirmfüllendes Fenster mit WA_SmartRefresh öffnet, das Bild dort hinein blittet und dann das Datatypes-Objekt wieder freigibt, hat man maximal denselben Speicherverbrauch wie bei der manuellen Variante, nämlich eine zusätzliche Offscreen-Bitmap. Ohne dass man irgendetwas kompliziertes programmieren muss. Den zusätzlichen paar hundert bytes für Fenster und Layer-Struktur stehen der gesparten Speicherplatz für das wieder freigegebene Datatypes-Objekt gegenüber. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2010, 12:30 Uhr thomas Posts: 7718 Nutzer |
Zitat: ... sind die Pens nicht mehr gelockt und jedes weitere Bild, das mit Datatypes geladen wird, verändert die Palette des Hintergrundbilds. Bei Truecolor fällt das nicht auf, aber bei palettebasierten Bildschirmmodi ist das sehr unschön. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
06.04.2010, 13:02 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wenn ein Spiel ernsthaft in palettebasierten Umgebungen laufen soll, sollte der Entwickler sich auch Gedanken um die optimale Palette für alle Grafiken, die auftauchen können, machen. Entweder, in dem ohnehin alle Bilder die gleiche Palette verwenden, oder durch sorgfältige Auswahl. Andernfalls wäre es eine Katastrophe, wenn die Grafikqualität davon abhängt, in welcher Reihenfolge die Bilder geladen, bzw. auf den Screen gemappt werden. Die vorher ausgewählte Palette sollte auf dem Screen fixiert werden, bevor überhaupt das erste Bild geladen wird. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
07.04.2010, 18:49 Uhr Reth Posts: 1858 Nutzer |
Zitat: Eine andere Frage zu dem Thema Layer: Kann ich denn nicht mit deren Hilfe meine "Tiefenebenen" für verschiedene graphische Elemente realisieren? Bisher mache ich das komplett selbst, in dem diese Elemente einen Wert für die "z-Ebene" (zusätzlich zu x,y-Ebene) mitbekommen, so dass ich weiss, welches Element unter/über welchem anderem liegt. Zitat: Das hab ich noch nicht ganz verstanden. Soll hier der Screen-Hintergrund neu gezeichnet werden, der zuvor von einem Fenster oder einem Teil davon verdeckt war? Oder soll der Hintergrund eines Fensters wieder hergestellt werden? Im ersten Fall habe ich noch nicht verstanden, wieso man den Offset relativ zur Quellbitmap braucht? Ich hatte mir das so vorgestellt, dass mit dem Rectangle der Bereich angegeben ist, der in der Screen-BitMap neu zu zeichnen ist. Zitat: Der Teil spricht für mich eher dafür, dass der Hintergrund eines Fensters wieder hergestellt werden soll. Sorry, für diese Grundlagenfragen, aber da kenne ich noch zu wenig Internes vom AmigaOS! Habe daheim das Amiga Intern, aber das ist dann doch etwas älter. Doch selbst in diesem hab ich nicht alles kapiert. Wo findet man denn aktuelleres Material? Auf der Developer CD 2.1 (hab ich auch daheim)? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
07.04.2010, 20:26 Uhr Holger Posts: 8116 Nutzer |
Zitat:Sofern Du damit leben kannst, dass Du Dich entweder auf rechteckige Formen beschränken musst oder AOS3.x nicht unterstützen kannst, kannst Du Layers für diesen Zweck verwenden. Zitat:Ja nachdem, SA_Backfill für den Screen, WA_Backfill für ein Fenster. Zitat:Weil ein Layer immer ein Layer ist, egal ob er zu einem Fenster oder zu einem Screen gehört. Dementsprechend ist die Schnittstelle zwischen Layer und Backfill-Hook so definiert, dass sie sowohl für Fenster als auch für Screens funktioniert. Zitat:So ist es ja auch. Zitat:Ja klar. Aber warum fragst Du? Wenn Du die CD hast, kannst Du doch selber nachschauen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
08.04.2010, 13:53 Uhr Reth Posts: 1858 Nutzer |
Zitat: Bedeutet das, ich kann für alle Objekte einer Tiefenebene denselben Layer verwenden und kann darüber meine Überdeckungsproblematik abhandeln? Mit rechteckigen Bereichen kann ich gut leben, die hab ich sowieso immer beim Blitten. Alles, was eine andere Form haben soll blitte ich durch eine Maske. Aber was ist mit dem Punkt AOS3.x-Unterstützung genau gemeint? Zitat:Zitat:Weil ein Layer immer ein Layer ist, egal ob er zu einem Fenster oder zu einem Screen gehört. Dementsprechend ist die Schnittstelle zwischen Layer und Backfill-Hook so definiert, dass sie sowohl für Fenster als auch für Screens funktioniert. Bedeutet das dann lediglich, dass der Offset nur bei Fenstern gebraucht wird (und man damit quasi den Fensterrand berücksichtigt) und beim Wiederherstellen von Screen-Hintergründen ignoriert werden kann? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
08.04.2010, 18:00 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nee, entweder bekommt jedes Objekt seinen eigenen Layer, oder der Layer hat keine rechteckige Form. Zitat:Missverständnis. Wenn Du durch eine Maske blittest, bedeutet das, Du hast transparente Pixel, also eine nicht-rechteckige Form. Rechteckige Form meint in diesem Zusammenhang immer rechteckige Form, bei der jedes Pixel opaque ist. Das bedeutet, wenn diese transparenten Pixel aktualisiert werden müssen, muss der unter der rechteckigen Bounding-Box des Objekts liegende Layer ebenfalls aktualisiert werden und das wird von AOS 3.x (und älter) nicht unterstützt. Zitat:Damit ist gemeint, dass AOS4 und MOS nicht-rechteckige, bzw. teilweise transparente Layer unterstützen. AOS3.x dagegen nicht. Zitat:Ich habe jetzt die Spezifikation gerade nicht zur Hand, deshalb ist das jetzt nur eine Annahme, dass der Offset beim Screen-Layer immer 0 sein wird. Aber was hindert Dich daran, den Offset korrekt zu berücksichtigen, und somit zu verhindern, dass es irgendwann knallt, wenn Du denselben Hook für ein Fenster statt einem Screen benutzt? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
08.04.2010, 23:59 Uhr Reth Posts: 1858 Nutzer |
Zitat:Hm, dann bin ich mir aber nicht mehr sicher, ob der Overhead nicht evtl. Vorteile auffrisst!? Es können nämlich schon eine ganze Menge Objekte werden. Zumindest könnte ich alle Hintergrundobjekte in einen Layer packen. Ach ja: Kann man Nicht-Rechteckige-Layer anlegen? Zitat:Dann kommen Layer für mich wohl doch nicht in Frage. Genau das, was Du hier beschreibst erledige ich aktuell "von Hand" mit eigenen Algorithmen. Leider ist die Performance auf 68k-Systemen (auch 68060) zu schlecht! Kann das Ganze ggf. mal in einem anderen Thread posten, um Verbesserungsvorschläge einzuholen. Zitat: In diesem Fall: Natürlich nichts! [ - Antworten - Zitieren - Direktlink - ] |
|
09.04.2010, 19:02 Uhr Holger Posts: 8116 Nutzer |
Zitat:Der Zweck des Ganzen ist die Möglichkeit, optimiert zu aktualisieren, und zwar dahingehend, dass man nur die Teile des Bildschirms neu zeichnen muss, die von den Änderungen betroffen sind. Wenn Du viele Objekte hast, und diese sich auch noch ständig bewegen, so dass Du keine andere Wahl hast, als den größten Teil des Bildschirms regelmäßig neu zu zeichnen, gewinnst Du natürlich nichts. Hast Du viele Objekte, die sich nicht bewegen, können auch viele Layer von Vorteil sein. Zitat:Mach das ruhig. -- [ Dieser Beitrag wurde von Holger am 09.04.2010 um 19:05 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
10.04.2010, 09:43 Uhr Reth Posts: 1858 Nutzer |
Zitat:Genau das ist auch mein Anliegen, nur dass ich das momentan alles selbst erledige, in dem ich bei Änderung eines Objektes alle "darüber" und "darunter" liegenden ermittle, die auch neu gezeichnet werden müssen (einschl. Hintergrund). Dann blitte ich "von unten nach oben" neu. Wäre das mit Layern effizienter und CPU- bzw. Graka-schonender machbar? Zitat:Ich hab viele Objekte, die sich nicht bewegen, aber ihre Form ändern, daher müssen sich alle "darunter" und "darüber" liegenden Objekte neu darstellen. Bewegliche Objekte habe ich momentan immer nur eines und das wird auch nicht immer dargestellt (sollen aber mal mehr werden). Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
10.04.2010, 17:19 Uhr Holger Posts: 8116 Nutzer |
Zitat:Da Du die Layer aufgrund der nicht rechteckigen Formen sowieso nicht benutzen kannst, erledigt sich die Frage von selbst. Du kannst allenfalls die Funktionsweise des Layer-Systems mit Deinen Routinen vergleichen und überlegen, ob Du bestimmte Dinge bei Dir verbessern kannst. Zitat:Ob die Objekte sich bewegen oder ihre Form ändern, ist für die Betrachtung irrelevant. Wichtig ist die Frage, wieviel Fläche sich verändert hat und deshalb mit neuen Daten gefüllt werden muss, und ob die dabei mögliche Einsparung den Aufwand der Ermittlung dieser optimierten Flächen wett macht. Z.B. kann man den Refresh so implementieren, dass die über den veränderten Objekten liegenden nicht aktualisiert werden müssen. Ob das aber effizienter ist, hängt von der Situation ab. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
11.04.2010, 19:50 Uhr Reth Posts: 1858 Nutzer |
Zitat:Vielleicht nicht ganz! Ich ermittle immer, welche Objekte sich überdecken und blitte diese dann vollständig durch ihre Masken neu. Wenn ich das Layer-Beispiel richtig verstanden habe, wird durch Layer bereits die Ermittlung der Überdeckung gemacht, blitten muss ich allerdings immer noch selbst. Wenn ich nun jedem Objekt seinen eigenen Layer spendiere, oder alle Objekte einer Ebene in denselben Layer stecke, dann könnte ich mir doch die eigene Ermittlung der Überdeckung schon mal sparen (muss sie ggf. noch anpassen). Zitat:Wie gesagt, bisher blitte ich alle betroffenen Objekte komplett neu, da diese nicht sehr groß sind (die größten sind bisher die Hintergrund-6-Ecke, die jeweils in glaub 100x80 großen Rechtecken liegen). Zitat:Wie das? Indem man alle Objekte einer Ebene in denselben Layer legt und alle nicht betroffenen, darüber liegenden Layer vor dem Neuzeichnen sperrt? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
11.04.2010, 23:45 Uhr inq Posts: 445 Nutzer |
@Reth Vielleicht machst du einfach nur zuviele Masken? Was, wenn du eine globale Maske erzeugst und diese mit jedem geblitteten Object aktualisierst? Zbuffer vorwärts? inq [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2010, 19:12 Uhr Holger Posts: 8116 Nutzer |
Zitat:Irgendwie scheinen wir aneinander vorbei zu reden. Nochmal: bis einschl. AOS3.9 hat ein Layer immer eine rechteckige Form und das heißt, alle Pixel unterhalb dieses Rechtecks werden immer als verdeckt betrachtet und deshalb werden alle darunter liegenden Pixel niemals neu gezeichnet. Wenn Du in dieses Rechteck mit einer Maske blittest, bleiben alle in der Maske nicht gesetzten Pixel unverändert und enthalten somit einen unspezifischen Wert, der nur im absoluten Glücksfall dem Hintergrund entspricht, von dem Du offensichtlich willst, dass er an diesen Stellen durchscheint. Die Form eines Objekts bestimmt zwei grundsätzliche Dinge: Mit Deiner Maske erledigst Du den zweiten Punkt, der erste fehlt aber. Zitat:Um Himmels Willen nein. Wenn Du Layer verwendest, sorgt die Layers-Library automatisch dafür, dass nur die Zeichenoperationen im sichtbaren Bereich ausgeführt werden. Das hat mit dem Sperren von Layern überhaupt nichts zu tun. Einzige Voraussetzung ist, dass Du die Graphics-Funktionen benutzt, die ein RastPort-Argument erwarten, und dass in diesem RastPort auf den zugehörigen Layer verwiesen wird (bei RastPorts von Intuition-Fenstern ist das vom System bereits so eingerichtet). Genau deshalb kannst Du die Layer auch nicht für nicht-rechteckige Objekte verwenden: es wird automatisch alles beim Refresh weggelassen, was unterhalb eines solchen Rechtecks liegt. Und das ist für Deinen Anwendungsfall zuviel. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.04.2010, 23:52 Uhr Reth Posts: 1858 Nutzer |
Zitat:Ok, nun hab ichs verstanden! Zitat:In meiner momentanen Lösung nicht, da ich alle Objekte in denselben RastPort blitte (verwende derzeit keine Layer und kein Refreshing, es wird immer nur geblittet). Beim Blitten der Objekte durch ihre Masken bleibt das "darunter" liegende Objekt (das zuerst geblittet wurde) an allen Stellen erhalten, an denen die Maske des darüberliegenden Objektes ein Darstellen verhindert. Bei Entfernen oder Ändern eines Objektes müssen allerdings "darunter" und "darüber" liegenden Objekte auch neu dargestellt werden (weiss nicht, ob ich das hier richtig verständlich machen kann?). Zitat: Dann mal ne grundsätzliche Frage, die sich mir aus dem Lesen von den entsprechenden Funktions- und Strukturbeschreibungen noch nicht erschloss: Kann ich denn mit Layern und ClipRegions verhindern, dass dargestellte Objekte innerhalb eines Layers durch darüber liegende Layer und deren Darstellung "zerstört" werden? Das würde eine Neudarstellung von überdeckten Objekten von "unten" nach "oben" erleichtern! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
15.04.2010, 03:48 Uhr whose Posts: 2156 Nutzer |
@Reth: Solange Du auf 68k RTG bleibst, wird Dir auch ein noch so ausgefeiltes Layer-System nicht bei der Geschwindigkeit der Darstellung helfen. Der eigentliche Flaschenhals ist das maskierte Blitten. Die wenigsten der verwendeten PC-Chips beherrschen das maskierte Blitten so, wie es der Amiga-Blitter durchführt. Soweit ich weiß, kann das keiner der für den Amiga adaptierten Chips, die wenigen GraKas, die einen dem Amiga-Chipsatz ebenbürtigen Blitter onboard hatten (IIRC Retina BLT Z3 und die Merlin) haben das mit einem zusätzlichen Custom-Chip erledigt. In den allermeisten Fällen muß das Ausmaskieren dann also per CPU erledigt werden. Das bedeutet im Endeffekt, daß das böse "Lesen aus dem VMEM" ständig vorkommt, weil Du mit hoher Wahrscheinlichkeit die zu blittenden Bitmaps als Friend und Displayable angelegt hast (das wird einem ja auch dauernd als essentiell verkauft. Blöd nur, daß das nur bei nicht-maskiertem Blitten/Vanilla-Copy wirklich sinnvoll ist. Wieder eine Klippe mehr, die "dank" RTG umschifft werden muß). Bei AmijeweledRTG gibt es dieses Problem auch (es ist grottenlahm auf Z2-Systemen, selbst mit einem 060) und da werden gerade mal 2 Ebenen behandelt (Spielfläche und Steine). Meiner Meinung nach solltest Du Dich mehr darauf konzentrieren, so wenig wie überhaupt möglich durch Masken zu blitten. Noch schneller wäre, vollständig auf die Blit-Funktionen der RTG-Systeme zu verzichten und statt dessen die erforderlichen Bilddaten aus dem FastRAM zur GraKa zu schieben. RLE kann da schon hilfreich sein, da Du damit eine Art Maske implementieren kannst. Erwarte aber keine Wunder auf Z2-Systemen  -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Hintergrundbild für eigenen Screen laden | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|