|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Little Endian | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
07.07.2002, 18:32 Uhr mrbbc Posts: 101 Nutzer |
Hiho... wie wird beim Amiga der Videospeicher addressiert ? Es werden ja Planes benutzt wie beim Atari ST auch... - auch bei 15(?), 16, 24, 32 bpp ??? Sind die Planes aber jetzt GE oder LE ? - beim Atari waren sie LE - also Intel-like, was zwar verwirrend aber in dem Fall auch sinnvoll war. Ist das beim Amiga(...Mac ???) auch so ? [ - Antworten - Zitieren - Direktlink - ] |
|
07.07.2002, 20:04 Uhr Michael_Mann Posts: 1012 Nutzer |
Zitat: Addressierung von Video-Speicher: ad Hoc 2 Möglichkeiten: 1. AllocRaster => planeptr=AllocRaster(width, height) planeptr=APTR width, height müssen jeweils durch 16 ganzzahlig teilbar sein. Abschließend FreeRaster aufrufen. 2. AllocMem mit MEMF_PUBLIC+MEMF_CHIP Abschließend FreeMem oder AllocVec mit obigen Flags Abschließend FreeVec (entspricht AllocMem/FreeMem, aber exec merkt sich hier die Mem-Größe AllocAbs auf keinen Fall verwenden. Bitteschön was soll das GE/LE??? Wenn du meinst das hier die Bit-Inhalte vertauscht sind dann gilt das bei Amiga nicht. Michael [ Dieser Beitrag wurde von Michael_Mann am 07.07.2002 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
07.07.2002, 20:12 Uhr Micha1701 Posts: 938 Nutzer |
Hi! Die Bytes sind im Big Endian Format (Motorola-like) - also das niedrige Byte als letztes. Standardmäßig unterstützt das AMIGA AGA Grafikset allerdings nur 8 bpp über die graphics.library. Um eine Grafikkarte direkt ansprechen zu können muß man eine Grafikkartensoftware direkt programmieren (Cybergfx oder Picasso96). Es gibt auch noch generelle Lösungen wie z.B. RtgMaster, die unterstützen dann beide Software. Bei den Grafikkarten ist es dann wieder Herstellerabhängig (bzw. von der GPU) ob im LittleEndian oder BigEndian Format gearbeitet wird. Welches Format unterstützt wird, bekommt man von der Grafikkartensoftware mitgeteilt. Schau Dir mal RtgMaster, CyberGfx oder Picasso96 an. Dort ist es ganz gut erklärt. --  Micha Look at my HP: http://www.lanser-online.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
07.07.2002, 20:20 Uhr thomas Posts: 7717 Nutzer |
Bitplanes sind Little Endian, wie alles im Amiga. D.h. das höchstwertige Bit ist links. Planare Bitmaps werden nur von der Original graphics.library benutzt (also maximal 8 Planes / 256 Farben). Unter Cybergraphics oder Picasso96 sind Bitmaps "Black Boxes" und dürfen nicht mit AllocMem/Vec/Raster etc. angelegt werden. Unter AmigaOS eigentlich auch nicht. Es gibt extra die Funktionen AllocBitMap/FreeBitMap dafür ! High- und TrueColor Bitmaps sowie palettenbezogene Grafikkarten-Bitmaps werden chunky abgelegt. Auf die rohen BitMap-Daten zugreifen darf man nur, wenn man sie vorher mit LockBitMap für sich reserviert hat. LockBitMap teilt einem auch mit, in welchem Pixel-Format die Daten vorliegen. Gruß Thomas -- Email: thomas-rapp@web.de Home: home.t-online.de/home/thomas-rapp/ [ - Antworten - Zitieren - Direktlink - ] |
|
07.07.2002, 20:23 Uhr thomas Posts: 7717 Nutzer |
Zitat: Das sollte man aber nur tun, wenn man es gar nicht vermeiden kann. Am besten kommt man zurecht, wenn man sich gar nicht um das Format kümmert und nur AmigaOS-Funktionen benutzt, um die Bitmaps zu ändern. Das funktioniert auch mit Truecolor-Grafiken ! Zum Laden und Speichern der Grafiken nimmt man Datatypes. Gruß Thomas -- Email: thomas-rapp@web.de Home: home.t-online.de/home/thomas-rapp/ [ - Antworten - Zitieren - Direktlink - ] |
|
07.07.2002, 20:40 Uhr mrbbc Posts: 101 Nutzer |
THX Rauft ruhig noch etwas aus, ob der Amiga wirklich immer LE ist... Steck' gerade in der Programmierung von der graphic.lib von UniverC. Da meine Version plattformübergreifend in den Videospeicher schreibt, muss ich schauen, was so alles auf mich zukommen kann... UniverC.org [ - Antworten - Zitieren - Direktlink - ] |
|
07.07.2002, 21:21 Uhr Michael_Mann Posts: 1012 Nutzer |
Zitat: Kennt jemand einen gescheiten Freeware-Reader fürs AUTODOC-Format??? Zum 1. Sätzchen male ich da mal einige große und fette Fragezeichen. Warum funktionieren denn die Proggis - die eigentlich nicht für P96 pp. geschrieben wurden auf eben diesem Device? AllocBitmap pp. gab es unter OS 2.0+ noch nicht. Scheint da auch etwas empfindlich zu sein wenn man in den docs blättert. Ich frage mich in diesem Zusammenhang wieviele Amiga-Programme ausschließlich für OS 3.5+ programmiert wurden bzw. tatsächlich benutzt werden. Michael [ Dieser Beitrag wurde von Michael_Mann am 07.07.2002 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
08.07.2002, 13:22 Uhr thomas Posts: 7717 Nutzer |
Natürlich funktionieren die. CGX erkennt oldstyle-Bitmaps und konvertiert sie so wie es sie braucht. Was ich meinte ist, daß du eine 16 oder 24bit Bitmap oder eine chunky 8bit Bitmap nicht so anlegen darfst. Du darfst auch gar nicht wissen, wie diese Bitmaps intern aufgebaut sind. Und du darfst nicht auf die Felder dieser Bitmaps zugreifen. Dafür gibt es GetBitMapAttr(). Lies dir die Einleitung der CGX-Autodocs durch. Ich finde die AmigaGuide-Version der Autodocs ausreichend. Gruß Thomas -- Email: thomas-rapp@web.de Home: home.t-online.de/home/thomas-rapp/ [ - Antworten - Zitieren - Direktlink - ] |
|
08.07.2002, 14:05 Uhr Solar Posts: 3680 Nutzer |
Zitat: Ähem... Most significant first nennt sich allgemeinhin Big Endian, wenn ich mich jetzt nicht *ganz* fürchterlich vertue... [ - Antworten - Zitieren - Direktlink - ] |
|
08.07.2002, 15:35 Uhr Solar Posts: 3680 Nutzer |
Aus perldoc perlfunc: Basically, the Intel, Alpha, and VAX CPUs and little-endian, while everybody else, for example Motorola m68k/88k, PPC, Sparc, HP PA, Power, and Cray are big-endian. MIPS can be either: Digital used it in little- endian mode, SGI uses it in big-endian mode. Some systems may even have weird byte orders such as 0x56 0x78 0x12 0x34 0x34 0x12 0x78 0x56 You can see your system's preference with print join(" ", map { sprintf "%#02x", $_ } unpack("C*",pack("L",0x12345678))), "n"; The byteorder on the platform where Perl was built is also available via the Config manpage: use Config; print $Config{byteorder}, "n"; Byteorders '1234' and '12345678' are little-endian, '4321' and '87654321' are big-endian. [ - Antworten - Zitieren - Direktlink - ] |
|
08.07.2002, 15:38 Uhr g0ldm0m0 Posts: 122 Nutzer |
Zitat: Genau! BIGEndian! Also in E/OCS & AGA werden die Bildpunkte Bitweise dargestellt, d.h ein Bit ist ein Pixel. Um dann mehr Farben zu ermoeglichen werden sie *uebereinander* gelegt. Es ist immer nur eine Indizierung auf eine Farbtabelle. Die unter AGA max. 256Farben (8Planes) haben kann (OCS/ECS max. 64 (6Planes)). HAM6/8 sind andere Modies, die fuer schnelle ausgaben *fast* ubrauchbar sind. Da du aber (scheinbar) fuer auch Graphikkarten unerstuetzen willst, solltest du fuer AGA/(E/O)CS eine c2p Routine benutzen, dadurch kannst du dir viel Arbeit (und performance  ) sparen.Mfg goldmomo [ - Antworten - Zitieren - Direktlink - ] |
|
08.07.2002, 16:45 Uhr Holger Posts: 8116 Nutzer |
Zitat:Soweit ich weiss, hatte der Atari ebenfalls einen MC680x0, war also genau wie der Amiga ein Big-Endian System. Wieso war es in diesem Fall sinnvoll, wenn die Bitplanes LE waren? Verwirrend verstehe ich ja noch... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
08.07.2002, 17:46 Uhr mrbbc Posts: 101 Nutzer |
Zitat: Du hast Planes von 16 bit, je 16 Pixel eine Plane. Im GE wär' das Pixel 0 aber im (zweiten) Byte 1 und Pixel 8 in Byte 0. Dammit... war das Pixel 0 jetzt ganz vorne mit Wert 1 oder hatte es Wert 128 ??? - und wie machen die Grafikkarten... ach, ich programmier' einfach alles rein ! Zur Erklärung "Plane": die Farben wurden gesplittet; es kam nicht Farbwert Pixel 0, 1, 2 etc. sondern Bit 0 von Farbwerten von Pixel 0 - 15 = Plane 0, dann Bit 1 von Farbwerten von Pixel 0 -15 usw. Auf die Art hätte man super 32-Farb-(5 Planes), 64-Farb-(6 Planes) usw. Systeme implementieren können. Den Inhellprogrammierern ist hingegen nichts zu peinlich: die hängen die Farbwerte einfach so verschachtelt in den Bildspeicher; guten Appetit. [ - Antworten - Zitieren - Direktlink - ] |
|
08.07.2002, 18:45 Uhr Micha1701 Posts: 938 Nutzer |
Hi! Ich glaub ich kanns nu lösen: Auf dem AMIGA werden Bitplanes bis zur Farbtiefe von 256 Farben bzw. 8 Bitplanes verwendet. Für das erste Pixel wird jeweils das erste Bit aller Planes benutzt. Wobei das Bit der ersten Plane auch das niederwertigste (sprich rechteste) Bit ist. Im BigEndian Format sind die Bits aufsteigend von rechts nach links sortiert. Genauso sind auch die Planes zu lesen (bzw. die Bits zu sortieren oder auseinanderzunehmen). Das Bit aus Plane 1 liegt an der Position 1, das Bit aus Plane 2 an Position 2 ,usw. . Brauchen tut man das, damit man weiß, welche Farbe denn nu eigentlich benutzt wird in all den Planes.... Beim Atari kann es eventuell anders gewesen sein. Plane 5 stand vielleicht für Bit 1 und Plane 4 für Bit 2 usw.... Aber das hat nicht mit Little und BigEndian zu tun... Little und BigEndian stehen für die Bytefolge in einem Word nicht für Bits in einem Byte.... Sollte es jetzt immernoch Probleme bei der Sicht auf die Planes geben, ich habe gerade mal im AMIGA intern nachgeschlagen und dort ein gutes Bild gesehen, könnte es ja mal einscannen und hier ins Forum packen.... -- Micha Look at my HP: http://www.lanser-online.de.vu [ - Antworten - Zitieren - Direktlink - ] |
|
08.07.2002, 22:20 Uhr g0ldm0m0 Posts: 122 Nutzer |
>Wobei das Bit der ersten Plane auch das niederwertigste (sprich >rechteste) Bit ist. Im BigEndian Format sind die Bits aufsteigend von >rechts nach links sortiert. Genauso sind auch die Planes zu lesen(bzw. >die Bits zu sortieren oder auseinanderzunehmen). Das Bit aus Plane 1 >liegt an der Position 1, das Bit aus Plane 2 an Position 2 ,usw. . Das stimmt aber nicht (so ganz)! Das 1 Bit eines Planes ist IMMER das hoechste im Byte. D.h. Wenn ich move.b #$80,bildschirmspeicher mache wird das linkste Bit gesetzt (Also das 1. Pixel). Das naechste Bit (das rechte daneben) ist das 2. Pixel. Somit hat eine Lowres Screen in der Breite aus 320Bit was 40Byte sind. Wenn man nun aber mehr Farben will, muss man der Hardware sagen, das man noch ein(oder mehr) Bitplane(s) will. In diesem hat man wieder die Bits gesetzt. Und die Kombination vom niedrigsten zum hoechsten Bitplane ergibt den Farbindex. Z.b.: 1Bit in Plane 0 = 0 1Bit in Plane 1 = 1 1Bit in Plane 2 = 1 ergibt 110 = 6 (Farbe 6)! (Bei hier 3Bitplane sind exakt 8Farben moeglich). Und der Bildschirmspeicher ist 100% Bigendian (der Blitter ja auch)! mfg Goldmomo [ - Antworten - Zitieren - Direktlink - ] |
|
09.07.2002, 07:23 Uhr Micha1701 Posts: 938 Nutzer |
Goldmomo: Das war das was ich gesagt habe /sagen wollte....  -- Micha Look at my HP: http://www.lanser-online.de.vu [ Dieser Beitrag wurde von Micha1701 am 09.07.2002 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
09.07.2002, 08:59 Uhr Solar Posts: 3680 Nutzer |
[quote] Original von mrbbc: Zitat: Das Verwenden von Bitplanes hatte Mitte der 80er Sinn. Der Standardbildschirm hatte weniger als 256 Farben (bedingt durch die damalige Hardware - mehr Farben -> langsamer). Mit Bitplanes hatte man nun die Möglichkeit, auf recht einfache Weise nur genau so viel Speicher (der damals knapp und teuer war) zu verbrauchen, wie für die Anzeige wirklich gebraucht wurden - halt 4, 5, 6, 7 Bitplanes. (Planar Graphics.) Mit der Verbesserung der Grafikhardware wurden 256 Farben zum Standard, mit 16bit- und 24bit-Anzeigen als "TrueColor"-Erweiterung. Ab dieser Konfiguration (Bittiefe durch 8 teilbar) wurde es einfach praktischer, die Information für ein Pixel nicht mehr über den ganzen Speicher zu verteilen, sondern in 1, 2, oder 3 aufeinanderfolgenden Bytes abzulegen. (Chunky Graphics.) Spätestens mit dem Aufkommen der 3D-Engines, die Farbinformationen per Pixel berechnen (und nicht mehr Paralaxenverschiebungen wie zu besten Amiga-Zeiten, die sind mit Bitplanes nämlich einfacher), wurde der Vorteil der Chunky Graphics deutlich. Darum gibt's auch keine aufwendigen Amiga-3D-Spiele für AGA - die Konvertierung von Chunky in Planar (c2p) frißt einfach zu viele Ressourcen. Hat also nichts mit "peinlich" zu tun, sondern mit "den veränderten Gegebenheiten angepaßt". Allerdings bleiben Parallaxen (wie z.B. in Worms oder Worms DC) die Domäne der Amiga-Hardware - nur leider (sic!) sind Plattformspiele inzwischen ziemlich out... Zitat: Wo Du das herhast ist mir schleierhaft... [ Dieser Beitrag wurde von Solar am 09.07.2002 editiert. ] [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Little Endian | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|