|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Images auf einem Fenster | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 3 4 | [ - Beitrag schreiben - ] |
|
29.10.2005, 15:26 Uhr MaikG Posts: 5172 Nutzer |
Ich hab ein Beispiel aus dem C-Kurs genommen um ein Bild in einem Fenster zu zeigen. Ich hab es mit PPaint als C gespeichert. Das unten stehende Programm wird Compiliert, beim ausführen öffnet sich ein Fenster, das Bild erscheint jedoch nicht und das Fenster lässt sich nicht mehr schliessen. Was läuft da falsch? #include <stdlib.h> #include <exec/types.h> #include <exec/exec.h> #include <intuition/intuition.h> #include <graphics/gfx.h> #include <dos/dos.h> #include <proto/intuition.h> #include <proto/graphics.h> #include <proto/exec.h> /* Image-Daten */ #include "ramimage.h" #define WIDTH 500 #define HEIGHT 350 struct Window *Fenster; struct IntuitionBase *IntuitionBase; struct GfxBase *GfxBase; struct RastPort *rp; int main(void) { int x; int y; /* Intuition Library öffnen */ IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library",36L); if (IntuitionBase != NULL) { /* Graphics Library öffnen */ GfxBase = (struct GfxBase *) OpenLibrary("graphics.library",0L); if (GfxBase != NULL) { /* Fenster mittels Tags öffnen */ Fenster = OpenWindowTags(NULL, WA_Left, 100, /* Abstand vom linken Rand */ WA_Top, 100, /* Abstand vom oberen Rand */ WA_Width, WIDTH, /* Breite */ WA_Height, HEIGHT, /* Höhe */ WA_Title, "Images", /* Fenstertitel */ WA_CloseGadget, TRUE, /* Close-Gadget */ WA_DragBar, TRUE, /* Ziehleiste */ WA_DepthGadget, TRUE, /* Depth-Gadget */ WA_GimmeZeroZero, TRUE, /* Ursprung 0/0 */ WA_IDCMP, IDCMP_CLOSEWINDOW, WA_Activate, TRUE, /* Fenster aktivieren */ TAG_DONE); if (Fenster != NULL) { rp = Fenster->RPort; /* rp zeigt auf RastPort des Fensters */ SetRast(rp, 0L); /* Fensterinhalt löschen */ /* Bild in RastPort stempeln*/ DrawImage(rp, &ram,10,10); /* Auf Close-Gadget warten */ Wait(1L << Fenster->UserPort->mp_SigBit); CloseWindow(Fenster); /* Fenster schließen */ } } } /* Libraries schließen */ if (GfxBase != NULL) CloseLibrary((struct Library *)GfxBase); if (IntuitionBase != NULL) CloseLibrary((struct Library *)IntuitionBase); return 0; } [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2005, 17:34 Uhr Flinx Posts: 1073 Nutzer |
Was ist denn das &ram, das Du da an DrawImage() übergibst? [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2005, 17:42 Uhr thomas Posts: 7717 Nutzer |
@MaikG: Hast du beim kompilieren keine Meldungen bekommen ? Welchen Compiler benutzt du denn ? Wenn ich mit PPaint ein Bild abspeichere, dann steht da sowas drin: UWORD chip ramData[660] = Das gibt einen Fehler, weil es kein Schlüsselword "chip" gibt. Bei Compilern, die Chip-RAM unterstützen, kann man __chip benutzen. Normalerweise muß man sebst Chip-RAM allokieren und die Daten dort hin kopieren. Wenn ich chip in __chip ändere, funktioniert das Programm ohne Probleme (mit Dice C auf OS 4). Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2005, 18:46 Uhr MaikG Posts: 5172 Nutzer |
>Was ist denn das &ram, das Du da an DrawImage() übergibst? Zeiger auf die ImageStucktur wenn ich das richtig verstanden habe. >@MaikG: >Hast du beim kompilieren keine Meldungen bekommen ? Nein, nach ein paar Korrekturen nicht mehr. >Welchen Compiler benutzt du denn ? vbcc >Wenn ich mit PPaint ein Bild abspeichere, dann steht >da sowas drin: >UWORD chip ramData[660] = >Das gibt einen Fehler, weil es kein Schlüsselword >"chip" gibt. Bei Compilern, die Chip-RAM unterstützen, >kann man __chip benutzen. Normalerweise muß man sebst >Chip-RAM allokieren und die Daten dort hin kopieren. Das Chip habe ich entfehrnt, da der Compiler da gemeckert hat. Ich könnte es mit __chip probieren, allerdings hab ich OS3.9 mit Grafikkarte, wo für sowas eigentlich kein Chipram mehr benutzt werden sollte. >Wenn ich chip in __chip ändere, funktioniert das Programm >ohne Probleme (mit Dice C auf OS 4). Ich hätte jetzt gedacht das OS4 ein Problem damit hat wenn man Chip-Speicher benutzt. Ein AONE hat ja kein Chip-Ram, oder bist du einer der glücklichen BPPC/CPPC betatester? [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2005, 19:54 Uhr MaikG Posts: 5172 Nutzer |
Mit __chip Compiliert er auch Fehlerfrei, das ausführbare Programm macht jedoch genau das gleiche. Also Fenster Öffnet sich, kein Bild, Fenster lässt sich nicht mehr schliessen. [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2005, 20:01 Uhr thomas Posts: 7717 Nutzer |
Mit VBCC funktioniert es bei mir auch problemlos. Ich habe folgendes Kommando benutzt: vc ramimage.c -o ramimage -lamiga Bleibt also nur noch das Bild. Poste mal dein ramimage.h. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2005, 20:03 Uhr thomas Posts: 7717 Nutzer |
Ach übrigens, du hast da einen ganz schlimmen Fehler in dem Programm: du wartest zwar auf das Schließsymbol, du holst aber die Message nicht ab. Da gehört noch sowas vor das CloseWindow: code:while (msg = GetMsg (Fenster->UserPort)) ReplyMsg (msg); Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2005, 22:56 Uhr Mazze Posts: 263 Nutzer |
Zitat: Ich habe es ausprobiert und erwartungsgemäß Pixelmüll bekommen. Grund: Images sind palettenorientierte Bilder. D.h. für jeden Punkt wird nur die Nummer eines Stiftes in die Strukt ...imageData eingetragen. Die Farbdaten (rot-, grün- und blauanteil jedes Stiftes) stecken in der Strukt ...paletteRGB32. Da Du das Fenster auf der Workbench öffnest, kannst Du die Palette des Workbench-Screens nicht so ohne weiteres mit SetRGB32 verändern. Am einfachsten ist es, wenn Du einen eigenen Screen öffnest (kein Pubscreen). Andernfalls müsstest Du das Bild "remappen". Dann würde ich allerdings eher dazu raten, die Bilder mit der datatypes.library zu laden. -- Meine Homepage [ Dieser Beitrag wurde von Mazze am 29.10.2005 um 23:20 Uhr editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
29.10.2005, 23:42 Uhr MaikG Posts: 5172 Nutzer |
>Mit VBCC funktioniert es bei mir auch problemlos. >Ich habe folgendes Kommando benutzt: >vc ramimage.c -o ramimage -lamiga was -o ist weiss ich nicht, der rest ist gleich. >Bleibt also nur noch das Bild. Poste mal dein ramimage.h. Ist ein wenig lang, hier ein Teil struct Image ram = { 0, 0, /* LeftEdge, TopEdge */ 320, 68, 4, /* Width, Height, Depth */ ramdata, /* ImageData */ 0x000F, 0x0000, /* PlanePick, PlaneOnOff */ NULL /* NextImage */ }; UWORD __chip ramdata[5440]= { 0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF, 0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF, 0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF, 0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF,0xFFFF, usw. }; >Ach übrigens, du hast da einen ganz schlimmen Fehler >in dem Programm: du wartest zwar auf das Schließsymbol, >du holst aber die Message nicht ab. Da gehört noch >sowas vor das CloseWindow: > code: > while (msg = GetMsg (Fenster->UserPort)) > ReplyMsg (msg); Steht im C-Kurs nicht drin, ich hab das dort rauskopiert und nur die Schleife rausgenommen.(Listing 8.6.1) >Andernfalls müsstest Du das Bild "remappen". Dann würde >ich allerdings eher dazu raten, die Bilder mit der datatypes.library zu laden. Pixelmüll also Falschfarben hab ich noch nichteinmal. Das mit den Remappen wäre dann die nächste frage. In Basic hab ich mir die Farben mit Obtainbestpen geholt und mittels Vierecke, Linien und Punkte gezeichnet. Das wollte ich vermeiden, da es ein Hoher aufwand ist. [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 00:17 Uhr thomas Posts: 7717 Nutzer |
Zitat: Hinter -o kann man den Namen der Ausgabedatei angeben. Da ich nicht alle meine Programme a.out nennen möchte, finde ich das gan znützlich. Übrigens kannst du dir das Öffnen und Schließen der Libraries sparen, wenn du auch noch -lauto angibst. Zitat: Ich habe genau diesen Teil mit Cut & Paste bei mir reinkopiert (nur das "usw." weg gemacht) und es funktioniert immer noch. Zitat: Dann ist das Beispiel im C-Kurs definitiv falsch. Nunja, um deinem Problem auf die Schliche zu kommen, solltest du hinter jeden Befehl ein Printf einbauen, damit du weißt, wo er hängen bleibt. Und dann vielleicht die kritischen Befehle mal auskommentieren (in diesem Fall das DrawImage). Welche Version von VBCC benutzt du denn ? Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 00:51 Uhr Mazze Posts: 263 Nutzer |
@MaikG: hat denn deine Workbench eine genügend hohe Farbtiefe? Da dein Image eine Tiefe von 4 hat, muss der Zielscreen ebenfalls mindestens 4 (bzw. 16 Farben) haben. -- Meine Homepage [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 09:24 Uhr thomas Posts: 7717 Nutzer |
Zitat: Das stimmt nicht. Es werden nicht mehr Bitplanes geblittet als da sind. Das funktioniert schon. Außerdem schrieb er etwas von Grafikkarte, da hat er bestimmt mehr als 256 Farben. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 09:53 Uhr MaikG Posts: 5172 Nutzer |
>Dann ist das Beispiel im C-Kurs definitiv falsch. Na wenn ich davon lerne kann das nur schief gehen... >Nunja, um deinem Problem auf die Schliche zu kommen, >solltest du hinter jeden Befehl ein Printf einbauen, >damit du weißt, wo er hängen bleibt. Und dann vielleicht >die kritischen Befehle mal auskommentieren (in diesem >Fall das DrawImage). Kann ich Probieren. >Welche Version von VBCC benutzt du denn ? $VER: vbcc 0.808 (27.01.2005) >hat denn deine Workbench eine genügend hohe Farbtiefe? >Da dein Image eine Tiefe von 4 hat, muss der Zielscreen >ebenfalls mindestens 4 (bzw. 16 Farben) haben. 16 Bit Ich hab gestern das mit ReplyMsg und so versucht vor dem Close Window zu setzten, das geht nicht. Der meckert das er msg nicht kennt, wenn ich msg definiere als z.b. Long macht vbcc das auch nicht. [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 09:56 Uhr Mazze Posts: 263 Nutzer |
Zitat: Ich hatte den Autodoc-Eintrag zu 'DrawImage' falsch verstanden: Intuition always has and will continue to assume there are at least as many planes of data pointed to by ImageData as there are '1' bits in the PlanePick field. Please ensure that this is so. (See the intuition.h include file for full details on using PlanePick). -- Meine Homepage [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 10:48 Uhr thomas Posts: 7717 Nutzer |
@Mazze: Ich finde, der Satz ist eindeutig. Da steht, daß Intuition immer davon ausgeht, daß ImageData auf mindestens so viele Bitplanes zeigt, wie '1'-Bits im PlanePick-Feld sind. Da steht nichts über die Anzahl Bitplanes des Ziel-RastPorts. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 11:07 Uhr Holger Posts: 8116 Nutzer |
Zitat: Nicht abgeholte Messages werden auch freigegeben. Wenn es nicht so wäre, wäre Deine Schleife auch falsch, denn zwischen dem Ausführen Deiner Schleife und dem Aufruf von CloseWindow() können beliebig viele neue Messages an dem MessagePort ankommen, die ja auch beantwortet werden müßten. Nein, diese Schleife ist nur dann nötig, wenn man mehrere Fenster mit shared MessagePort benutzt und die Messages nicht automatisch freigegeben werden. Dann muß man aber auch vor dem Ausführen dieser Schleife mittels ModifyIDCMP die idcmp-Flags auf 0 setzen, um sicherzustellen, daß keine neuen Messages für dieses Fenster ankommen können. Für ein Anfängerprogramm ist es vollkommen in Ordnung, auf eine Message zu warten und sie nicht abzuholen. Eine Fehler wäre es, die Message abzuholen und nicht zu beantworten. Was in dem Programm nicht korrekt ist, ist, daß mittels Wait() auf das Signal gewartet wird, welches aber nicht garantiert, daß wirklich eine Message angekommen ist. Deshalb sollte WaitPort() verwendet werden. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 11:20 Uhr Holger Posts: 8116 Nutzer |
Zitat: msg ist ja auch kein "long" sondern vom Typ "struct Message*". Das sollte aber auch an der Fehlermeldung des Compilers erkennbar sein. Da sollte sinngemäß stehen, daß er "struct Message*" nicht auf "long" zuweisen kann. Manchmal ist es auch sinnvoll, sich die Fehlermeldung des Compiler durchzulesen, anstatt nur festzustellen, daß er eine Fehlermeldung auswirft. Aber wie gesagt, Du brauchst diese Schleife auch gar nicht. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 11:46 Uhr Holger Posts: 8116 Nutzer |
Mittels gcc übersetzt und auf OS3.9 getestet -> Programm funktioniert. Da scheinen ganz bestimmte Systemeigenheiten eine Rolle zu spielen... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 15:32 Uhr MaikG Posts: 5172 Nutzer |
>msg ist ja auch kein "long" sondern vom Typ >"struct Message*". Das sollte aber auch an der >Fehlermeldung des Compilers erkennbar sein. >Da sollte sinngemäß stehen, daß er "struct Message*" >nicht auf "long" zuweisen kann. Keine ahnung sowas stand nicht da. Und was der Compiler so ausgibt kann ich nicht weiter Interpretieren. >Aber wie gesagt, Du brauchst diese Schleife auch gar >nicht. Gut. Das Programm hält bei SetRast an, nehme ich setrast raus stürzt das Programm mit einen 80000006 ab. >Da scheinen ganz bestimmte Systemeigenheiten eine Rolle zu spielen... Am System wird das nicht liegen, ist nicht zugepatcht oder so. Das ich für WOS Compilere sollte ja keine rolle spielen oder? [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 16:13 Uhr thomas Posts: 7717 Nutzer |
Zitat: Doch, genau das ist das Problem. Beim PPC sind die Struktur-Alignments anders als beim 68k, deshalb funktioniert dein ramimage.h nicht. Du kannst das umgehen, wenn du in der Kommandozeile noch -amiga-align mit angibst: vc +warpos -amiga-align ramimage.c -o ramimage -lamiga Allerdings verstehe ich nicht, warum du dieses Programm für WarpOS umwandelst. Mit den zwanzigtausend Context-Switches, die da drin sind, wird es vermutlich noch langsamer laufen, als wenn du es für 68k umwandelst. Warum versuchst du als Anfänger, direkt den Mount Everest zu besteigen ? Und daß du die Compiler-Messages nicht interpretieren kannst, kann man auch nicht einfach so stehen lassen. Wenn ich mich recht erinnere, sind die in der VBCC-Anleitung alle beschrieben. Wenn du nicht verstehst, was der Compiler dir mitteilen möchte, wirst du nie in der Lage sein, ein komplexes Programm zu schreiben. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 16:40 Uhr MaikG Posts: 5172 Nutzer |
>Doch, genau das ist das Problem. Beim PPC sind die >Struktur-Alignments anders als beim 68k, deshalb >funktioniert dein ramimage.h nicht. >Du kannst das umgehen, wenn du in der Kommandozeile noch >-amiga-align mit angibst: >vc +warpos -amiga-align ramimage.c -o ramimage -lamiga Kannst du das genauer erklären? Hat dieser zusatz irgendwelche nachteile? >Allerdings verstehe ich nicht, warum du dieses Programm >für WarpOS umwandelst. Mit den zwanzigtausend >Context-Switches, die da drin sind, wird es vermutlich >noch langsamer laufen, als wenn du es für 68k umwandelst. Das ist nur ein nebenteil eines größeren Programms, wie man jetzt 68k code und PPC code in einemen erzeugen kann weiss ich nicht. >Warum versuchst du als Anfänger, direkt den Mount Everest >zu besteigen ? Ich hab schon unter Basic Programmiert, das gibts nicht für PPC. >Und daß du die Compiler-Messages nicht interpretieren >kannst, kann man auch nicht einfach so stehen lassen. >Wenn ich mich recht erinnere, sind die in der >VBCC-Anleitung alle beschrieben. Wenn du nicht >verstehst, was der Compiler dir mitteilen möchte, >wirst du nie in der Lage sein, ein komplexes Programm >zu schreiben. In der Anleitung war das glaube ich nur in kurzform. Mir reicht es eigentlich wenn ich sehe welche Zeile das ist, dann gucke ich ob das den Regeln entspricht oder nicht. Und beim Image wurde mir kein Problem gemeldet. [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 17:58 Uhr thomas Posts: 7717 Nutzer |
Zitat: Nun, das Programm wird dadurch langsamer. Demgegenüber steht natürlich der Vorteil, daß es läuft :-) Beim 68K müssen bestimmte Datentypen (WORD, LONG) auf geraden Adressen liegen. Deshalb werden in Strukturen ggf. Füllbytes eingefügt. Beispiel: struct hugo { char zeichen; long zahl; }; Diese Struktur braucht eigentlich nur 5 Bytes, ist im Speicher aber 6 Bytes groß, weil hinter "zeichen" noch ein Füllbyte eingefügt wird, damit "zahl" auf einer geraden Adresse liegt. In den AmigaOS-Includes werden diese Füllbytes meistens mit angegeben, damit es nicht zu Verwirrungen kommt. Beim PPC ist es komplizierter, denn der PPC kann auf bestimmte Datentypen besser zugreifen, wenn sie auf Adressen liegen, die durch vier oder durch acht teilbar sind. Der Compiler kennt diese Umstände und fügt entsprechend viele Füllbytes ein (je nach Datentyp bis zu 7). Wenn in deinem Programm jetzt eine Datenstruktur angelegt wird, geht der Compiler davon aus, daß du es gerne schnell haben möchtest und fügt Füllbytes für den PPC ein. Wenn du diese Struktur dann aber an eine 68k-Funktion übergibt, die die Daten für 68k angepaßt erwartet, kommt es natürlich zum Crash. Es gibt jetzt je nach Compiler unterschiedliche #pragma-Anweisungen, mit denen man für einzelne Strukturen die Alignments bestimmen kann. Damit wäre es möglich, eigene Strukturen mit PPC-Alignment und System-Strukturen mit 68k-Alignment zu benutzen. Leider enthalten die Includes des NDK 3.9 diese Anweisungen nicht. Deshalb ist es einfacher, das 68k-Alignment global einzuschalten, auch wenn dadurch der PPC-Code unnötig verlangsamt wird. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 18:15 Uhr MaikG Posts: 5172 Nutzer |
Verstehe. Das Programm funktioniert jetzt, sind nur ebend diese Falschfarben da. Wie kann man diese Remappen? [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 19:59 Uhr thomas Posts: 7717 Nutzer |
Schau mal auf http://thomas-rapp.homepage.t-online.de/examples Die ersten drei Abschnitte dürften dich interressieren. Vor allem der mit dem Pixel-Array. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
30.10.2005, 23:42 Uhr MaikG Posts: 5172 Nutzer |
>Die ersten drei Abschnitte dürften dich interressieren. Ich sehe da keine Abschnittsunterteilung. >Vor allem der mit dem Pixel-Array. pixelarray.c enthält nicht wirklich was ich brauche, wie ObtainbestPen Funktioniert weiss ich aber nicht wie ich das Image vor dem Zeichnen auf die entsprechenden Pens bekomme. Es müsste praktisch dann auch von 4 Bit auf 16 Bit gewandelt werden. [ - Antworten - Zitieren - Direktlink - ] |
|
31.10.2005, 10:32 Uhr thomas Posts: 7717 Nutzer |
Zitat: Da sind Leerzeilen zwischen den Abschnitten Zitat: Doch, das Programm macht genau, was du brauchst. Du solltest es ausprobieren, bevor du Rückschlüsse über die Funktion ziehst. Lade einfach alle Dateien von dt2raw.c bis Makefile in ein Verzeichnis und tippe make ein. Zitat: Quatsch. Wenn du mit Pens arbeitest, hast du genau 8 Bits zur Verfügung. Das Programm Pixelarray macht genau, was du brauchst. Da mit einem Pixel-Array gearbeitet wird (also 8 bit Chunky) ist die Umrechnung auch ganz einfach. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
31.10.2005, 11:14 Uhr Holger Posts: 8116 Nutzer |
Zitat:Na im Vergleich zum Overhead, der entsteht, wenn man ein Bild auf verfügbare Pens remappt und dann auf einen 16Bit-Screen blittet, dürfte das alignment kaum ins Gewicht fallen.  Und natürlich die schon erwähnten Context-Switches---Apropos, der ppc-Code greift in diesem Programm ja eh nicht auf die Struktur zu, das macht ja die 68k-AmigaOS Funktion. Zitat:Wie könnten sie auch, wie Du schon sagst, #pragma-Anweisungen sind compiler-spezifisch. Zitat:Das betrifft ja nur eigene Strukturen, und für die gibt es eine probate Lösung: byte und short gar nicht erst verwenden und Member innerhalb der Struktur in absteigender Größe ihrer Datentypen deklarieren. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
31.10.2005, 11:52 Uhr Solar Posts: 3680 Nutzer |
Zitat: MaikG, ich will Dir nicht zu nahe treten (ehrlich nicht!), aber solltest Du Dich nicht erst einmal mit C, den dort üblichen Verfahren (keine globalen Variablen!), seinen Tools (und deren Kommandozeilenoptionen) sowie seiner Bibliothek (siehe memset()...) vertraut machen, bevor Du Dich in die Tiefen der AmigaOS-API stürzt? Ich traue Dir ja zu, daß Dir das in Basic alles sehr leicht von der Hand ging, aber C ist nicht einfach nur ein etwas anderer Basic-Dialekt. Bei C ist es sehr wichtig, sich auf eine solide Grundlage stützen zu können, bevor man anfängt, mit den (ungleich komplizierteren) OS-Strukturen zu jonglieren. Wirklich nicht bös gemeint, mehr als präventives Aspirin - denn sonst sehe ich jede Menge Kopfschmerzen auf Dich zukommen... [ - Antworten - Zitieren - Direktlink - ] |
|
31.10.2005, 13:01 Uhr thomas Posts: 7717 Nutzer |
Zitat: Bei den OS4-Includes geht es ja auch. Die funktionieren mit GCC und VBCC. Zitat: Nein, es betrifft gerade nicht die eigenen Strukturen. Die eigenen funktionieren auch ohne Aufpassen, nur werden sie ggf. größer als gedacht. Es ging hier aber um die Kommunikation mit AmigaOS. Wenn eine struct Image oder eine struct NewMenu in den Includes nicht richtig deklariert sind, kann man entweder die Includes editieren oder das Amiga-Alignment global einschalten. Letzteres dürfte "sauberer" sein. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
31.10.2005, 13:14 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wenn Du Dich auf nur zwei Compiler einschränken kannst (mußt), ist das natürlich leichter... Zitat: Du hast mein Posting aus dem Zusammenhang gerissen. Du schriebst "auch wenn dadurch der PPC-Code unnötig verlangsamt wird." und ich schrieb "Das betrifft ja nur eigene Strukturen, ", denn bei den OS-Strukturen hat man ja gar keine Wahl. Weiter schrieb ich: "und für die gibt es eine probate Lösung: byte und short gar nicht erst verwenden und Member innerhalb der Struktur in absteigender Größe ihrer Datentypen deklarieren." Das bedeutet: wenn man 68k-Alignment global einschaltet, und diese von mir gepostete Vorgehensweise einhält, hat man kein Performance- Verlust. Die Alignment-Probleme gibt es ja nur dort, wo Datentypen munter durcheinandergewürfelt wurden, wie bei AmigaOS-Strukturen. Sortieren schadet nie. Und beim 68000 waren short- und byte-Zugriffe vielleicht schneller, beim ppc eben nicht, weshalb man bei eigenen Strukturen darauf verzichten sollte. (Außer bei großen arrays, aber da gibt es keine alignment-Probleme). mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 3 4 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Images auf einem Fenster | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|