ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
Reth
Nutzer
24.04.2006, 21:04 Uhr [ - Direktlink - ] |
Thema: Back again....
Brett: Amiga, AmigaOS 4 @madmat: Willkommen im Club! Ich nutze auch noch einen A4000 mit PPC und hoffe inständig, dass nix kaputt geht. Zudem bin ich noch AOS4 Betatester und von der Geschwindigkeit auf dem A4000 begeistert. Wenn aber mal neue, anspruchsvolle SW kommen sollte reicht der 4000er und seine Grakas auch nicht mehr. Bzgl. RAM-Module kannst Du auch mal einen Blick in Google und ebay werfen. Zudem gibt es noch MOS, auch für den A4000, allerdings wie für AOS4 nur mit PPC. Habs mir aber noch nicht angesehen. Ausserdem hat es noch den Pegasos als neue HW, ein in meinen Augen nettes Maschinchen. Ich hoffe und warte aber immer noch auf AOS4, solang mir 3.9 noch ausreicht und hoffe auf gute, bezahlbare HW, oder darauf, dass doch mal ein Versuch klappt ne Lizenz für den PegII zu bekommen, dann könnte ich (und andere) alles nutzen: AOS4, MOS, LINUX... Ciao |
|||||
Reth
Nutzer
14.04.2006, 22:29 Uhr [ - Direktlink - ] |
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4 Cool, endlich weissich das! Danke! Gibts vielleicht auch ne Lösung für das andere Config-Problem (s. anderer Thread)? |
|||||
Reth
Nutzer
12.04.2006, 19:57 Uhr [ - Direktlink - ] |
Thema: Amiga-Tasten für Hotkeys in GoldED verwenden
Brett: Amiga, AmigaOS 4 Hallo zusammen, weiss jemand, wie man das in GoldED Studio AIX machen kann? Hab schon verschiedenes probiert und nichts hat funktioniert. Die Amigatasten sind bei den Menüs als Symbol dargestellt, alle anderen als Text (also z.B. [ctrl]). Geht das überhaupt (wäre bisschen Schade und blöd wenn nicht)? Bin nämlich von den Menühotkeys wie Block löschen nicht so angetan! Danke schon mal Ciao |
|||||
Reth
Nutzer
07.04.2006, 11:31 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung Da wir eh schon OT sind, fällt mir gleich noch ne Frage in diese Richtung ein? Wo platziere ich am dümmsten die Warteschleife auf messages? Wenn ich mir eine Receiverklasse(nhierarchie) baue, welche z.B. auf INTUITION-Messages wartet, könnte ich den Loop z.B. in dieser unterbringen: Pseudocode: C++ code:IntuiMSGReceiver::receive(struct MsgPort *Port) { struct IntuiMessage *msg = (struct IntuiMessage *) GetMsg(Port); // reply und verarbeiten } Da fallen mir noch spontan 2 Ansätze ein: 1. Eine Abstrakte Receiverklasse mit einer virtuellen Receive-Methode (quasi das Interface). 2. Eine (evtl. virtuelle) Receiverklasse, die den Empfang und den REply der Message schon implementiert hat, abgeleitete Klassen müssen den MessageTyp in Abhängigkeit ihrer Aufgabe (IntuiMessage) noch entsprechen umwandeln. |
|||||
Reth
Nutzer
06.04.2006, 20:39 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung Zitat: Hm, dann hab ich wohl den Waal. Meine Animationsobjekte haben ihre Position und bekommen von außen ggf. neue Positionen gesetzt, sie alle werden aber in einem anderen Objekt verwaltet, welches über die Änderungen wachen soll und diese zu Bild bringen. Allerdings wollte ich die gesamte Animationshierarchie entkoppelt lassen von zeichenspezifischen Sachen, was sich ja aufhebt, wenn ich einer dieser Klassen das Painter-Interface verpasse. Zitat: Wenn aber z.B. jedes Animationsobjekt einen Painter darstellt ist es doch eher "übel" diesen im Window zu setzen, dann wäre es doch eher angebracht diese alle in den Layoutmanager zu hängen und der ruft dann die paint()-Methoden auf, wenn er ein Update vom Fenster mitgeteilt bekommt?! Ciao |
|||||
Reth
Nutzer
06.04.2006, 08:13 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung @Holger: Hm, dann würden bei mir aber für jedes Tile und jedes bewegliche Objekt ein eigener Painter entstehen, wenn ich den Objekten das Painter-Interface zuordne. Ist das nicht ein bisschen viel? Dachte eher daran, dass ein Painter (oder wie bei mir bisher ein RastPort-Objekt) alles macht, ähnlich dem Graphics-Objekt von Java-Components (das kann man ja auch nicht setzen). Der Statuspainter würde dann z.B. in meinem Fall ein Array(Liste) aus Strukturen (Objekten) übergeben bekommen mit Texten und Positionen dazu, um die Ressourceninformationen zu schreiben. Du merkst sicher schon, dass ich mich mit dem Ansatz etwas schwer tue, obwohl er mir gefällt. |
|||||
Reth
Nutzer
05.04.2006, 22:05 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung @Holger: Jetzt versteh ich schon eher wie Du das mit den Paintern meinst. Aber wie mach ich dass, wenn ich viele Bilder blitten/drawen will, sollte das doch auch mit einem Refresh gehen. Sollte es dann einen Painter geben, der z.B. einen Vector mit Bildern entgegennimmt und diese dann blittet? Oder wie ist das in Deinem Konzept vorgesehen? Jedesmal das Image setzen und requestRefresh rufen kann ich mir nicht vorstellen! |
|||||
Reth
Nutzer
05.04.2006, 20:34 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung Zitat:Gut, dachte schon ich blicks echt nich mehr! Zitat: Hm, ich seh gerad nur nicht, wo die letztendliche Implementation der Blitroutinen sein soll? Im Painter oder im RastPort, oder delegiert der Painter an den RastPort, wenn er was neu zu zeichnen hat? Also: code:painter.blit(...); window.requestRefresh(); ... // im Painter rastPort.blit(...); |
|||||
Reth
Nutzer
05.04.2006, 20:26 Uhr [ - Direktlink - ] |
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4 Zitat: Naja muss zugeben, dass ich noch nicht mit den internen Befehlen programmiert habe. Dort könnte man CTRL-V neu belegen und aus dem Menü entfernen. Dann gibt man der Tastenkombination einfach die benötigte Befehlsreihenfolge, so dass der Cursor nach dem Einfügen hinter dem Eingefügten steht (nur Theorie, noch nicht ausprobiert). Allerdings sollte sowas natürlich einfach konfigurierbar sein! |
|||||
Reth
Nutzer
05.04.2006, 20:22 Uhr [ - Direktlink - ] |
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4 Zitat: Wenn es das ist, was ich denke, dann ist das die Zeile mit den Tabs der geöffneten Dateien! Ein äußerst gutes und nützliches Feature. Sobald mehrere Dateien geöffnet sind, stehen die Dateinamen in den Tabs oben und man kann auf einen Klick darauf zwischen den geöffneten Dateien hin- und herschalten. Suuupergut. Dazu rechts noch die Projektleiste mit den Sourcen, Headern und makefile - erste Sahne!!! Hoffe, ich konnte helfen, ansonsten bringen evtl. Screenshots mehr, zur Not an meine Mailadresse (dann haben die anderen halt nicht ganz soviel davon). Aber die Konfig ist zum Teil echt schwer zu verstehen. Z.B. alles was ich im Kontextmenü des Makefiles einstelle (Farbcodes etc.) bezieht sich auf .h und .cc Dateien. Deren Kontextmenüs sind dagegen recht leer. Hab mir aber schon mit den internen Befehlen ne Faltroutine für markierte Blöcke programmiert (auf- und zuklappen, nur Eingabe der Beschreibung fehlt noch), dazu noch ne Routine die mit CTRL-7 die aktuelle Zeile aus- bzw. einkommentiert. Da geht noch viel mehr, und dann gibts ja noch Arrexx. Ist halt alles sehr aufwendig. |
|||||
Reth
Nutzer
05.04.2006, 12:49 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung Hi Holger, Zitat: Komme bei dem Bsp. nicht ganz mit. Wird da bei setPainter() im Window der internen Variable windowPainter die Referenz auf p zugewiesen, oder sind das 2 unterschiedliche Painterobjekte, die da im Spiel sind? In letzterem Fall komm ich gleich gar nicht mehr mit. Wie kommt man denn in obigem Bsp. an Blitfunktionen und so Sachen wie Vordergrund-/Hintergrundstift setzen dran? Momentan sind das Methoden meiner RastPortklasse, die public sind, da man ja die Darstellung beeinflussen will. Wird im Painterobjekt gesammelt, so lange, bis paint() gerufen wird? Vielleicht kannst Du mir hier kurz auf die Sprünge helfen?! Ciao |
|||||
Reth
Nutzer
05.04.2006, 09:34 Uhr [ - Direktlink - ] |
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4 Geht das wirklich nicht, oder weiss es keiner? Gibt es zu GoldED eigentlich irgendwo ne Doku oder Benutzerhinweise zur Konfiguration? Die ist nämlich m.M. nach nicht in allen Punkten intuitiv, sprich man weiss nicht ob versch. Dinge einfach nicht gehen, oder man sie nur noch nicht gefunden hat. |
|||||
Reth
Nutzer
05.04.2006, 09:23 Uhr [ - Direktlink - ] |
Thema: C++ Compiler
Brett: Programmierung @Honitos: Also ich kann da eigentlich nur GoldED Studio (nunmehr Cubic IDE) empfehlen. Es ist zwar nicht klein (GCC), aber schnell installiert und funktioniert "out of the box". Zudem bekommst Du viele schöne weitere Dinge mitinstalliert, wenn gewünscht. |
|||||
Reth
Nutzer
04.04.2006, 14:54 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung @Solar: Hi nochmal, genau diese Dinge bietet die RastPort-Klasse, nicht die Windowklasse, denn die genannten Operationen laufen auf einem RastPort und dieser ist unabhängig von einem Fenster (kann auch von einem Screen kommen, oder für sich existieren). Ist so ähnlich wie die Graphics-Klasse in Java. Es wird immer in einen RastPort gezeichnet, nicht in ein Fenster und nicht in einen Screen. Daher hat die Fensterklasse ein RastPort-Member. Dieses kann man sich besorgen, um dann die Zeichenoperationen darauf auszuführen. Wenn man will kann man auch ein eigenes RastPort-Objekt anlegen und darin herumzeichnen. Was man bei meiner Konstruktion allerdings (bisher) nicht kann (und auch erstmal nicht können soll), ist einem Fenster einen neuen RastPort zu setzen. |
|||||
Reth
Nutzer
04.04.2006, 09:58 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung @Holger: Die Frage ist, ob das hier wirklich hilft? Das RastPort-Objekt ist um den Zeiger auf eine existierende RastPort-Struktur aufgebaut. Bei einer Kopie kann ich zwar den Zeiger auf diese RastPort-Struktur kopieren, aber das ändert ja nichts, die Zugriffsmöglichkeiten bleiben ja die gleichen (abgesehen von evtl. vorhandenen anderen Membern der RastPortklasse)! Die dahinterliegende RastPort-Struktur bleibt dieselbe (muss sie ja, da sie ja z.B. zu einem Fenster oder Screen gehören kann, in dem ich meine Sachen angezeigt haben will). Oder soll die RastPort-Struktur auch kopiert werden und jedesmal wenn eine Operation darauf ausgeführt wird der RastPort im Fenster, Screen etc. ausgetauscht werden? |
|||||
Reth
Nutzer
04.04.2006, 09:21 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung @Solar: Versteh ich, aber das hier genannte Problem ist ja nicht GUI-spezifisch. Ist halt nur zufällig so, dass ich bei der GUI-Programmierung drauf gestoßen bin. |
|||||
Reth
Nutzer
04.04.2006, 08:45 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung @Solar: Bin in C++ ziemlich blutiger Anfänger (obwohl das ja eine Designfrage ist und daher eigentlich von der Prog.-Sprache unabhängig). Aber wie würdest Du/"man" das dann designen? Im konkreten Fall hab ich eine Window-Klasse, die eine nicht konstante Referenz auf ihr RastPort-Objekt zurückgibt, damit man darin Operationen fahren kann. Wenn ich die Referenz konstant mache, muss ich alle Public-Methoden der RastPortklasse ebenfalls konstant machen, damit darauf von außen zugegriffen werden kann. Bin mir nicht sicher, ob das geht, da die RastPortklasse einen Zeiger auf ne RastPort-Struktur kapselt und darauf z.B. Blitoperationen macht und sich dabei ja die RastPort-Struktur ändert (allerdings nicht der Zeiger darauf, mit dem ja gearbeitet wird - geb ich zu). Wie erstellt man da ein Design, dass mit konstanten Referenzen arbeiten kann bzw. wie stellt man dann das Design um? |
|||||
Reth
Nutzer
03.04.2006, 22:03 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung Es lag wohl an der Art der Implementierung von B, die auf Header und Source verteilt war und bei make nicht zusätzlich angegeben wurde. Habe das nun geändert und es sieht besser aus, habe aber noch kein endgültiges Ergebnis! Jop, das wars wohl! [ Dieser Beitrag wurde von Reth am 03.04.2006 um 22:47 Uhr geändert. ] |
|||||
Reth
Nutzer
03.04.2006, 21:06 Uhr [ - Direktlink - ] |
Thema: G++ ld undefined Reference
Brett: Programmierung Hallo zusammen, versteh gerad nicht was da los ist. Ich hab ne Klasse B, von der inner anderen Klasse A ne Klassenvariable angelegt wird. Diese Klasse A kann eine Referenz auf die Klassenvariable zurückgeben. Ein Objekt der Klasse A wird per Referenz an eine Klasse C übergeben, dort wird dann von A per Methodenaufruf die Refernz auf B geholt und ne Methode von B gerufen. Die Klassen wurden prima compiliert und gelinkt, so lange ich in C nicht den Methodenaufruf von B implementiert hatte (über die Referenz von A). Die Klassen und Methoden waren alle schon da es wurde alles compiliert und gelinkt. Nun nachdem ich den Methodenaufruf doBStuff() in C implementiert hatte meldet der Linker beim letztendlichen Linken des Executables "Undefined Reference to B::getBStuff()" in C. Muss ich in C die Klasse B auch noch inkludieren? Wenn ja, wieso? Sorry, bekomme keine Leerzeichen in den Code, bei der Eingabe sind sie jedenfalls da. //Klasse A #include "B" class A { privat: B b; public: B& getB() { return b; } } ... // Klasse C #include A class C { public: void do(A& a) { a.getB().doBStuff(); } } Danke schon mal! Ciao |
|||||
Reth
Nutzer
23.03.2006, 22:15 Uhr [ - Direktlink - ] |
Thema: YAM und Komprimierung
Brett: Amiga, AmigaOS 4 Sorry, wenn ich hier nicht ganz klar rüberkam: Ich meine die Postfachkomprimierung! |
|||||
Reth
Nutzer
22.03.2006, 20:38 Uhr [ - Direktlink - ] |
Thema: YAM und Komprimierung
Brett: Amiga, AmigaOS 4 Hallo zusammen, ich habe noch eine Frage zu diesem Thema. Aus anderen Threads weiss ich, dass man das XPK Paket installieren muss, damit man in YAM Komprimierung verwenden kann. Nun ist bei mir nur die xpkmaster.library und im Unterordner die shrink.library installiert und ich befürchte, dass ich nach Installation des XPK PAketes ausm Aminet mein System evtl. dahingehend beeinflusse, dass andere Anwendungen nicht mehr laufen. Reicht es auch, die entsprechenden Unter-Libs zu kopieren? Gibt es auch ein PPC-Version (nicht AOS4), um den PPC zum De-/Komprimieren zu nutzen? Danke schon mal! Ciao |
|||||
Reth
Nutzer
21.03.2006, 14:51 Uhr [ - Direktlink - ] |
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4 Hallo, vielleicht wurden die Fragen ja schon mal beantwortet, dann verweist mich doch bitte an die entsprechenden Stellen! Wie kann ich denn GoldED so konfigurieren, dass der Cursor nach dem Einfügen aus dem ClipBoard hinter dem Eingefügten steht anstatt davor? Danke schon mal! Ciao |
|||||
Reth
Nutzer
21.03.2006, 11:40 Uhr [ - Direktlink - ] |
Thema: Erneute Umfrage zu AOS4 auf PegII
Brett: Amiga, AmigaOS 4 Zitat: Das ist ja eigentlich nicht das Thema. Aber was AInc mit den Usern macht ist m.M. noch viel übler. Verhindern, dass AOS4 veröffentlicht wird, indem man keine neue Hardware zulässt und das Ganze totsitzen will! Das mit Genesi und den Entwicklern ist eigentlich eine interne Angelegenheit. Auf MOS/Pegasos Seite gibts aber alles: Ein OS und eine vernünftige Hardware! Und auf AmigaOS Seite? Wo kann ich denn nen AOS-Rechner kaufen und woher bekomme ich AOS4 (na gut bin Classic Betatester, drum komm ich jetzt schon in den Genuss und finds daher nur umso mehr schade, dass es hier nicht weiter geht!)? |
|||||
Reth
Nutzer
20.03.2006, 16:10 Uhr [ - Direktlink - ] |
Thema: Erneute Umfrage zu AOS4 auf PegII
Brett: Amiga, AmigaOS 4 Sorry, spenden ist hier wirklich falsch übersetzt, hab ich eigentlich nicht gemeint. Aber es stimmt auch, dass es schon andere und bessere Angebote gab und ich bin mir auch ziemlich sicher, dass AInc das Ganze auch ablehnen wird, werd das noch ergänzen. |
|||||
Reth
Nutzer
20.03.2006, 15:23 Uhr [ - Direktlink - ] |
Thema: Erneute Umfrage zu AOS4 auf PegII
Brett: Amiga, AmigaOS 4 Hi allerseits, auf amigaworld.net läuft mal wieder eine Umfrage bzgl. einer Portierung von AOS4 auf den PegII. Der Initiator würde EUR 20.000,- spenden, wenn sich mind. 250 Befürworter finden. Er favorisiert dann einen Einzellizenzpreis von EUR 110,-; EUR 80,- für seine Investition und EUR 30,- für die Nichtsdafürtuer von AInc, die das Ganze sicher wieder ablehnen oder ignorieren werden. Also, alle die dagegen oder dafür sind: Auf auf zum Voten! [ Dieser Beitrag wurde von Reth am 20.03.2006 um 16:10 Uhr geändert. ] |
|||||
Reth
Nutzer
18.03.2006, 23:37 Uhr [ - Direktlink - ] |
Thema: Messagehandling - Eure Meinung
Brett: Programmierung Hm, das Ganze geht eigentlich schon Richtung MVC. Du kanns bei jedem Fenster bzw. jedem Gadget etc. Receiverobjekte registrieren, die bei bestimmten Aktionen informiert werden sollen. Es ist egal, wie viele Fenster Du geöffnet hast, da die Methoden in der Fenster- bzw. Gadgetklasse usw. definiert sind die auszuführende Logik wird in den Receiverklassen implementiert, die damit zu Controllern werden. Es ist auch kein Problem, ein Controllerobjekt bei mehreren Fenster- oder Gadgetobjekten etc. zu registrieren, wenn man das unbedingt will. Den Code kann ich für jede Anwendung wieder verwenden, in denen ich Fenster und Gadgets verwende. Ich muss nur einmal Code schreiben, der die Intuition Messages "dekodiert" und an die Receiver verteilt. |
|||||
Reth
Nutzer
17.03.2006, 20:50 Uhr [ - Direktlink - ] |
Thema: Messagehandling - Eure Meinung
Brett: Programmierung Hi nochmal, da der letzte Thread so gut lief hier gleich noch einer! Da ich aus der Java-Ecke komme und mich gerade an C++ versuche, habe ich mir für die Message-Bearbeitung von Intuition folgendes gedacht: Ich kupfere die Java-Methodik ein bisschen ab, da ich aber auch recht faul bin, dachte ich ich belass das Ganze erst mal beim Window, ohne Delegation. Im Klartext ich mach an der Fensterklasse eine bis mehrere Methoden zur Registrierung von Receiverobjekten je nach Art der zu empfangenden Message. Wenn das einigermaßen läuft, dachte ich später daran, die Delegation nachzubauen und die entsprechenden Messages an die Komponenten des Fensters (Gadgets etc.) weiterzuleiten. Was meint ihr denn so dazu? Ist mal ein erster Ansatz. Ciao |
|||||
Reth
Nutzer
14.03.2006, 21:21 Uhr [ - Direktlink - ] |
Thema: Koordinatentransformation, Überdeckung
Brett: Programmierung Zitat: Allerdings! Ich wüsste gern mehr darüber, wie Du die einzelnen Sachen umgesetzt hast (z.B. das mit den Blitroutinen Block, Bit Maske, Alpha, Transparent, Add, Sub; oder das mit den "Rampen" bzw. Textureberechnungen für die Steigungen! Hoffentlich findest Du mal die Zeit ein paar Erläuterungen hier und da festzuhalten! Ciao |
|||||
Reth
Nutzer
14.03.2006, 15:41 Uhr [ - Direktlink - ] |
Thema: Koordinatentransformation, Überdeckung
Brett: Programmierung Zitat: Schade! Wollte mal den Unterschied zwischen gepixelt und gezeichnet begutachten. Zitat: Dann muss man aber die Objektarten unterscheiden statisch vs beweglich, damit man bei den statischen Objekten immer den größten Frame als Umriß hernehmen kann (sowas hatte ich in meiner 1. Version schon zum Hintergrund retten). Wenn man unterscheidet in statische vs. bewegliche Objekte, dann werdens bei mir wohl in einer ersten Version ca. 10 bewegliche Objekte. Wenn man nur in statische vs. veränderliche Objekte unterscheidet, kann sich das Ganze dann auf ca. 30-50 aufschaukeln. Zitat: Das ist der Vorteil der STL Container, die sind schon dynamish. Die Vectors und Maps, von denen ich sprach passen sich in der Größe an. Zitat: Ist das eine Frage, oder machst Du das so bei Dir? Zitat: Für Dein "sind weiter vorn" ohne HotSpot brauchst Du doch aber ne z-Information, oder nicht? Zitat: Wie unterscheidet sich das dann im Handling der Tiles, wenn diese unterschiedliche Höhen haben (in der Optik isses ja klar)? Danke nochmals! Ciao |
|||||
Reth
Nutzer
14.03.2006, 10:23 Uhr [ - Direktlink - ] |
Thema: Koordinatentransformation, Überdeckung
Brett: Programmierung Zitat: Lecker, gibts noch mehr davon zu sehen oder testen? Ist das schon "released" oder noch in Entwicklung? Zitat: Danke für Deine Beschreibung. Gute Idee mit dem imaginären Raster! So ähnlich hab ich mir das für mich auch überlegt. Aber Du musst immer pro Durchgang alle Objekte prüfen und in Deinem drüberliegenden Array ggf. umhängen (denke mal, es ist ein Array von Zeigern und an jeder x,y-Position liegt ne aufsteigend sortierte Liste mit Zeigern auf die zu blittenden Objekte, oder?). Bin mal gespannt, wie schnell das bei mir wird. Ich mach folgendes: Dank C++ und der STL nehme ich einen Vector, in dem liegen alle grafischen Objekte (Zeiger). Dazu nehme ich noch 2 3-dimensionale Maps, die 1. (x,y,z) bildet alle sichtbaren grafischen Objekte auf die Postionen der Hintergrundtiles (x,y) ab. An diesen Postionen liegt dann ne Map von Zeigern, der grafischen Objekte, die über dem Tile liegen (ein Objekt kann ja über mehreren Tiles liegen). Da Maps sortiert sind, werden die Zeiger mit ihrer Tiefeninformation als Schlüssel abgelegt, damit hab ich automatisch alle Objekte in der richtigen aufsteigenden Blitreihenfolge. Die 2. Map (z,x,y) enthält dann alle neu zu zeichnenden Objekte pro Durchgang, diesmal kommt an erster Stelle die Tiefeninfo und dann die genaue x,y-Position der zu blittenden Objekte. Dadurch wird dann Schicht für Schicht übereinander geblittet. Aufwändig wird wohl die Bestimmung, welche Tiles von einem Objekt überdeckt werden (dazu muss ich x,y-Position und Höhe, Breite des Objektes berücksichtigen, innerhalb dieser Bereiche [x, x+Breite] [y, y+Höhre] wird dann geschaut, über welchen Tiles das Objekt liegt und der Zeiger eingetragen dazu muss dann immer noch das max. ClipRect berechnet werden). Das müsste eigentlich klappen, hoffe ich! Ciao René |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |