amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste << 9 10 11 12 13 -14- 15 16 17 18 19 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)
gni   Nutzer

22.08.2005, 09:51 Uhr

[ - Direktlink - ]
Thema: SASC
Brett: Programmierung

Zitat:
whose:
Zeiger auf UBYTE in ein ULONG "hineincastete" (worüber sich der GCC übrigens nicht wirklich beschwert hat, er schmiß nur die (verständliche) Warnung, daß man versucht, aus einem Zeiger einen Integerwert zu machen).

Wenn das per Cast geschieht, sollte der Compiler doch nicht meckern. Diese Warnung ist mir jedenfalls nicht untergekommen.
Zitat:
Zitat:
Es gibt Fälle bei denen man __far verwenden muß, zb. wenn man bei Near-Data auf die CIAs bzw. Custom-Chips per extern Deklaration des Basissymbols draufzugreifen will. Sowas geht nicht mit den GCC. Da muß die "Basis" als #define haben.
Wie ist der letzte Satz hier genau zu verstehen? Oder meinst Du damit, daß die Resource-Base als #define vorliegen muß statt als "extern" Deklaration?
Genau das. Mit SAS/C kannst Du mit extern arbeiten. Bei GCC mußt Du ein #define nehmen, wenn Du mit -fbaserel arbeiten willst. Ansonsten wäre die Basis für den GCC eine normale Variable, die in der Datensektion liegt und die würde dann per Indexregister adressiert werden.
Zitat:
Zitat:
Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.
Die sind mir in den Quellen noch gar nicht aufgefallen. Bisher waren's nur die Warnungen Zeiger<->Integer ( (ULONG) statt (UBYTE *) )und "Different width due to prototype" aufgrund des festen "-traditional" des StormC-GCC (implizite Erweiterung von short auf int), welche dann zum größten Teil beim "normalen" GCC wegfallen dürften.
Ich werde Storm nie verstehen :-(
 
gni   Nutzer

19.08.2005, 13:58 Uhr

[ - Direktlink - ]
Thema: SASC
Brett: Programmierung

Zitat:
whose:
Auch nicht, wenn Du versuchst, 16Bit relative und 32Bit absolut-Adressierung im selben Quellcode unterzubringen

Reden wir hier von C? Da kommst Du damit in keinster Weise in Berührung. Der Compiler nimmt die passenden Adressierung und gut. Das hat mit Casts wirklich nichts zu tun. Auf dem Amiga gibt es keine Cast wegen Near-Code bzw. Near-Data. Wirklich nicht. Es gibt Fälle bei denen man __far verwenden muß, zb. wenn man bei Near-Data auf die CIAs bzw. Custom-Chips per extern Deklaration des Basissymbols draufzugreifen will. Sowas geht nicht mit den GCC. Da muß die "Basis" als #define haben.
Die Casts, über die sich der GCC beschwert hat, waren Zeiger <-> (U)WORD wegen der unterschiedlichen Größen.
 
gni   Nutzer

19.08.2005, 12:38 Uhr

[ - Direktlink - ]
Thema: SASC
Brett: Programmierung

Zitat:
whose:
...daß diese Casterei im Zusammenhang mit dem "Near Code"/"Small Data a4/a6 relative" Modell steht.

Near Code bedeutet nur, das sich jeder Funktionsaufruf in 32k Reichweite befindet. Smalldata heisst maximal 64k Data über A4 adressiert. Beides hat *nichts* mit eventuellen Cast in den Quellen zu tun. Wer mit [U]WORD in den eigenen Quellen arbeitet, macht sich das leben nur selber schwer.
BTW1, 'FORM' und Freunde erzeugt man korrekterweise mit MAKE_ID.
BTW2, laß besser die Finger von diesen schrottigen Quellen.
 
gni   Nutzer

19.08.2005, 12:32 Uhr

[ - Direktlink - ]
Thema: SASC
Brett: Programmierung

Zitat:
whose:
Da gibts z.B. so lustige Zeilen, in denen eine Funktion, die einen Zeiger auf UBYTE zurückgibt, gezwungen wird, den Zeiger in ein ULONG zu schmeißen...

Kann mir mal jemand verraten, wozu das gut sein sollte?

IMHO, der Autor konnte weder C noch mit seinem Compiler umgehen...
Zitat:
Ich frage, weil ich den Verdacht habe, daß der Originalautor auch an anderen Stellen "Tricks" eingebaut hat, die evtl. dazu dienen, auf 68000er Maschinen "besser" zu laufen.
Das hat mit dem 68000 eher weniger zu tun. Eher mehr mit Nichtwissen.
 
gni   Nutzer

19.08.2005, 12:27 Uhr

[ - Direktlink - ]
Thema: SASC
Brett: Programmierung

Zitat:
whose:
Zirkelbezüge in den Includes

Das ist doch einfach: den Headern fehlt "#ifndef\n#define...#endif".
Strukturen vor Prototypes + Forwards und gut.
 
gni   Nutzer

19.08.2005, 11:22 Uhr

[ - Direktlink - ]
Thema: SASC
Brett: Programmierung

Zitat:
whose:
ich habe das dumpfe Gefühl, daß diese Casterei im Zusammenhang mit dem kleinen Code-/Daten-Modell steht.

Das ist kein MS-DOS.
 
gni   Nutzer

18.08.2005, 09:10 Uhr

[ - Direktlink - ]
Thema: ak-Datatypes oder Warp-Datatypes für 68k?
Brett: Amiga, AmigaOS 4

Zitat:
aPEX:
noe, sicher nicht, aber das sind die die ich kenne und wo alle aus einer hand kommen...

Warum schaust Du nicht in die Guides dr WarpDTs und guckst, welche DTs zum Verglich genommen werden? Da bekommst Du eine gute Übersicht.
Zitat:
klar im aminet liegen tausend mal mehr, aber viele sind um 1995-1998 erschienen
Da nimmst eben neuere. Die gibt es.
 
gni   Nutzer

18.08.2005, 09:05 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
softwarefailure:
Für mich als Softwareentwickler ist OS3.9 alles andere als tot.

Für mich auch nicht. Das ändert jedoch nichts daran, das Du keine Updates mehr zu erwarten hast. Natürlich würde ich mich über kleinere Updates auch freuen, aber die wird es meines Erachtens nicht geben.
 
gni   Nutzer

17.08.2005, 17:06 Uhr

[ - Direktlink - ]
Thema: ak-Datatypes oder Warp-Datatypes für 68k?
Brett: Amiga, AmigaOS 4

Zitat:
aPEX:
welche Datatypes sind für ein 060-System eher zu empfehlen:
Die Sammlung von Andreas Kleiner, oder die WarpDatatypes?

<wunder>
Sind das alle Datatypes, die es gibt?
</wunder>
 
gni   Nutzer

17.08.2005, 15:49 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
ac-logic:
@DJBase:
Es hat nichts damit zu tun, daß das Produkt an dem er arbeit MorphOS ist

Haha... Demzufolge würde es also keine Aufregung gegeben haben, wenn ein Nicht-MOS Beteiligter die Quellen eingefordert hätte? Ein Lizenzverstoß bleibt ein Verstoß egal wer Ihn öffentlich macht.
 
gni   Nutzer

17.08.2005, 15:45 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
Micha1701:
Wenn ich die verfechter der GPL hier richtig verstehe _ist_ also ein Programm, welches Teile von Linux benutzt ebenfalls GPL.

Du meinst Teile der Kernelquellen? Wenn die GPL lizensiert sind, dann ja.
Zitat:
Also muß der Quellcode offengelegt werden.
Wenn Du Binaries Deines Programmes verteilst, dann mußt Du spätestens wenn Dich jemand nach den Quellen fragt, diese auch rausgeben. Da kannst Du sie auch gleich rausgeben.
Zitat:
Also warum schreiben wir dann nicht mal eine Mail an ID-Software, damit die die Quellcodes von Doom3 freigeben. Die werden wohl Teile von Linux (Grafikkartentreiber, Inputkram) benutzen (die GPL sind) damit ihr Game läuft. Also ist Doom3 ebenfalls GPL - ist ja klar...
Ohje, das wurde hier schon durchgekaut. Entweder Du liest hier im Thread nochmal nach oder Du ließt die GPL. Du hast die Wahl.
 
gni   Nutzer

17.08.2005, 12:42 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
softwarefailure:
Aber ich kann mir wirklich nicht vorstellen, dass die Ignoranz beim OS3.9 Team so weit geht, dass man es durch Nichtanpassung vorzieht, dass ein Großteil der User den OS3.9 picture.datatype durch den minderfunktionellen AROS Datatype ersetzt, nur damit ein Byte pro Pixel von der Subclass durchgeschliffen wird.

OS3.9 ist *tot*. Von offizieller Seit ist nichts mehr zu erwarten. Selbst so ein Update von Olaf erfordert, Aufwand. Nicht unbedingt beim Programmieren, sondern beim rechtlichen Aspekt.
 
gni   Nutzer

17.08.2005, 12:39 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
whose:
Besitzt Du den SAS

Ja.
Zitat:
kann ich ggf. auf Dich zurückkommen, um die Kompatibilität der FileMaster-Sourcen zum SAS zu testen, wenn ich die GCC-freundlich umgebaut habe?
Ja.
 
gni   Nutzer

17.08.2005, 10:48 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
Holger:
Zitat:
gni:
Ich kennen keinen ANSI/ISO C Compiler, der das nicht macht. Wobei zb. der der SAS/C sogar etwas cleverer vorgeht als GCC. SAS/C kann erkennt auch Substrings am Ende eines Strings.

Dann hätte SAS/C also alle Leerstrings auf denselben Speicherbereich legen müssen?
Wenn sich diese Literale in der selben Trasnlation-Unit befinden, dann ja. Konstrukte wie 'char foo[] = "...";' gehören nicht dazu.
Zitat:
Mit welchem Compiler haben die Commodore-Entwickler dann gearbeitet?
Ursprünglich mit "Greenhills C" (Cross-Compiler auf einer Sun), vermutlich Lattice C and später dann SAS/C. Teile des OS (zb. Intuition) wurden aber immer mit "Greenhills C" übersetzt. Wie gesagt das Zusammenfassen von Strings kenne ich nur von ANSI/ISO Compilern. Und SAS/C ist das erst seit 5.x (?) von 1990.
 
gni   Nutzer

17.08.2005, 09:30 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
whose:
Zitat:
gni:
Merkwürdig ich seh nur eins im TopLevel-Verzeichnis. Was für ein zweites soll wo sein?

Siehe OS4Depot, da siehst Du dann auch das passende Readme der eigentlich älteren Version der avcodec lib, welche schon lange vorher unter LGPL stand...
Ich habe vom ffmepg README gesprochen, das ist entscheidend und *nicht* das Readme das der Autor des Amiga-Ports geschrieben hat. Niemand hat bestritten, das die avcodec Bibliothek selber der LPGL unterliegt. Aber auch dann sollte es eine Selbstverständlichkeit sein, das man den Quellcode dazulegt. Das erspart Arbeit. CISC hat auch die Quellen der mpega_libmad verfügbar gemacht.
Zitat:
Zitat:
Dann guckst Du in die Quellen vo liba52.
Womit wir bei der Frage wären, ob sich die GPL von dort auf das gesamte Projekt ausweitet oder doch nur für den AC3 Codec gilt.
Sobald Du GPL Code verwendest, unterliegt _alles_ der GPL. Da der Amiga-Port *mit* dem GPL-Code rausgegeben wurde, steht der Port automatisch unter GPL. Das gilt aber nur für diese spezielle Version. Da Steffen Fellner diese explizit als notwendig, angegeben hat, steht auch DVPlayer in der Version unter GPL. Spätere Versionen kann er wieder anders lizensieren.


[ Dieser Beitrag wurde von gni am 17.08.2005 um 09:31 Uhr editiert. ]
 
gni   Nutzer

17.08.2005, 09:16 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
Holger:
Denn einige Compiler optimieren konstante Strings, in dem sie identische String in denselben statischen Speicherbereich legen.

Ich kennen keinen ANSI/ISO C Compiler, der das nicht macht. Wobei zb. der der SAS/C sogar etwas cleverer vorgeht als GCC. SAS/C kann erkennt auch Substrings am Ende eines Strings.
 
gni   Nutzer

17.08.2005, 09:05 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
bubblebobble:
Ich nutze auch den AK-Datatype. Die 15 Pfund für das WarpDatatpye
finde ich etwas viel, nur damit man .png Grafiken laden kann

<werbung>
Es gibt weitere PNG Datatypes, wie man zb. dem WarpPNGdt Guide entnehmen kann.
</werbung>
 
gni   Nutzer

16.08.2005, 15:35 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
whose:
Zitat:
Original von gni:
Diese Methode zum Platz reservieren mag unorthodox sein, aber wo genau ist jetzt das Problem? Das der String read-only ist? Das sich das mit neuen Compilern nicht übersetzen läßt?

Das der String ReadOnly ist und sich sowas mit bestimmten _alten_ Compilern auch nicht übersetzen ließ.
Leider beides falsch ;-) Der Code ließ sich garantiert übersetzen und hat auch funktioniert, sonst hätte man es doch anders geschrieben oder? Und zweitens haben alte (K&R) Compiler Stringliterale in den Datenbereich gelegt. Damit waren sie schreibar und es gab Programme, die auch davon ausgingen, das sie schreibar sind. Deswegen gab es beim GCC bis einschließlich 3.4 die Option "-fwritable-strings".
Zitat:
Üble Tricksereien halt.
Sicher. Über den Grund dieser Tricksereien können wir aber nur Mutmaßungen anstellen.
Zitat:
Und das Thema lautete: Wie geht man mit Altlasten um?
Danke. Allerdings glaube ich nicht, das so alte Programme noch Bedeutung haben.
 
gni   Nutzer

16.08.2005, 15:26 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
bubblebobble:
@gni:
Ich dachte, die einzelnen Datatypes sind normale AmigaShared Libs,
die man auch direkt nutzen kann.

Es sind shared-Libraries.
Zitat:
Und wenn das so ist, bräuchte ich auch eine Docu + .fd File dazu.
Ein Datatype hat keine Funktionen, die ein Nutzer aufrufen kann. Das Interface ist die datatypes.library.
Zitat:
Evtl. hat das png Datatype ja Funktionen, um an die Alphamakse zu kommen.
Der erste V43 picture.dataype hatte in seinem Include PDTA_AlphaChannel definiert. In den OS-Includes taucht das dann nicht mehr auf. Dafür gibt es dort andere Referenzen auf den Alpha-Kanal bei
"Pixel formats" und "Masking techniques".
Zitat:
Beste Lösung wäre aber tatsächlich, wenn ich das DoMethod hinbekomme
und Olaf das datatype fixed.

OS4 und MOS sollen mit RGBA klar kommen.
 
gni   Nutzer

16.08.2005, 15:17 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
whose:
Zitat:
gni:
Zitat:
whose:
Zitat:
gni:
Wer nicht lesen kann, hat halt ein Problem. Ein README ist immer das erste was man sich durchlesen sollte. Das beweisst nur, das Piru lesen kann.

Tja, und deswegen ist DVPlayer jetzt wieder zum Download freigegeben, mit ner avcodec.library, die den "umstrittenen" AC3-Codec nicht mehr enthält "bis die Frage nach der Lizenz des umstrittenen Codecs zweifelsfrei geklärt ist".
Sowas nennt sich "Schutzbehauptung".
Das wiederum könnte man "Unterstellung" nennen...
Wenn Du meinst. Dummerweise *gibt* es nichts zu klären. Die AC3-Bibliothek in den ffmeg Quellen ist GPL. Was es da noch zu klären gibt würde ich doch gerne wissen.
Zitat:
Zitat:
Warum ließt Du nicht selber das README bevor Du Dich dazu äußerst?
Du wirst lachen, ich habe _beide_ ReadMe gelesen.
Merkwürdig ich seh nur eins im TopLevel-Verzeichnis. Was für ein zweites soll wo sein?
Zitat:
Und beide sind da etwas... unterschiedlich.
Dann guckst Du in die Quellen vo liba52.
Zitat:
Wie es aussieht aufgrund einer ungeklärten Lizenzfrage.
:-(
 
gni   Nutzer

16.08.2005, 14:53 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
whose:
Zitat:
gni:
Wer nicht lesen kann, hat halt ein Problem. Ein README ist immer das erste was man sich durchlesen sollte. Das beweisst nur, das Piru lesen kann.

Tja, und deswegen ist DVPlayer jetzt wieder zum Download freigegeben, mit ner avcodec.library, die den "umstrittenen" AC3-Codec nicht mehr enthält "bis die Frage nach der Lizenz des umstrittenen Codecs zweifelsfrei geklärt ist".
Sowas nennt sich "Schutzbehauptung".
Zitat:
Das README scheint doch nicht so eindeutig zu sein, oder? Oder können alle anderen außer Piru nicht lesen? Noch nicht mal der Autor der library?
Warum ließt Du nicht selber das README bevor Du Dich dazu äußerst?
Zitat:
Wie war das mit dem Verallgemeinern?
Mag sein, das einige die GPL als Noplusultra betrachten. Das hat aber rein garnichts mit dem Thema dieses Threads zu tun. Fakt ist, das es eine Lizenzverletzung gab/gibt.
 
gni   Nutzer

16.08.2005, 14:45 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
bubblebobble:
Gibt es eine Doku zu den einzelnen Datatypes, z.B. png?

Was für eine Dokumentation suchst Du denn?
FYI, Du kannst sub-datatypes nicht direkt benutzen. Du hast ein Objekt und Methoden. Wo was ausgewertet wird, darüber hast Du keine Kontrolle.
 
gni   Nutzer

16.08.2005, 14:40 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
whose:
Das Konstrukt habe ich aus uraltem Code, teilweise ist der auf FishDisks zu finden, teilweise habe ich den vom CATS.

Dann war das eben fehlerhaften Code. Nur was hat das jetzt alles mit dem Design des AmigaOS zu tun? Ich habe irgendwo den Faden verloren.
Zitat:
Es ist halt simpler, Code mitsamt (kleinen) Datenbereichen einfach in den Speicher zu kopieren.
Diese Methode zum Platz reservieren mag unorthodox sein, aber wo genau ist jetzt das Problem? Das der String read-only ist? Das sich das mit neuen Compilern nicht übersetzen läßt?
 
gni   Nutzer

16.08.2005, 14:33 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
Lemmink:
Zitat:
Die erforderliche und zum Download angebotetene Bibliothek ist GPL. DvPlayer benutzt die Bibliothek. DvPlayer ist automatisch ein GPL Produkt.
Hmm, wenn diese Kausalitätskette stimmt, das selbst die indirekte Nutzung von GPL-Software dazu führt, daß das eigene Programm unter GPL fällt, dann dürfte es völlig unmöglich sein, für z.B. Linux auch nur irgendeine kommerzielle Software zu schreiben:
Beim betrachteten Fall ist das so. Das Stichwort heisst "dynamisches Linken". Lies Dir die Mail von Piru durch. Da steht alles relevante drin.
 
gni   Nutzer

16.08.2005, 14:30 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
whose:
Zitat:
schluckebier:
Wie gerade schon geschrieben: Wer Code von anderen nimmt, muss sich halt vorher schlaumachen, wie die Lizenz dafür aussieht.

Tja, und was macht der Schlauberger, wenn die Lizenzlage nicht so eindeutig ist? Hast Du Dir mal das Posting von AC-Pseudo angesehen? Und die Antwort von gni darauf?
Wer nicht lesen kann, hat halt ein Problem. Ein README ist immer das erste was man sich durchlesen sollte. Das beweisst nur, das Piru lesen kann.

[ Dieser Beitrag wurde von gni am 16.08.2005 um 14:30 Uhr editiert. ]
 
gni   Nutzer

16.08.2005, 14:20 Uhr

[ - Direktlink - ]
Thema: Gleiches Programm wird von GCC kompiliert aber nicht von G++ ?
Brett: Programmierung

Zitat:
whose:
Stell Dir vor, jemand wäre so brilliant, das char *bla=" " exakt so groß zu definieren, daß ne BitMap-Struktur reinpaßt. Also sizeof(bla) == sizeof(struct BitMap). Kein AllocMem(), kein FreeMem()...

Woher hast Du dieses Konstrukt? Warum sollte man es *so* machen? Da kann ich auch gleich ein BitMap Objekt definieren. Ich kann immer noch nicht folgen.
 
gni   Nutzer

16.08.2005, 13:30 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
ac-logic:
3. Die avcodec.library basiert auf Sourcen des "ffmpeg" und diese stehen unter LGPL.

Teilweise. Der beanstandete Code ist defintiv GPLed, siehe README.
Zitat:
Es gibt also eine Version der avcodec.library (die ohne AC3-Codec) die zweifelsfrei unter LGPL steht und eine Version die zur ersten Version kompatibel ist aber möglicherweise unter GPL steht, aufgrund des jetzt enthaltenen AC3-codec. Es dürfte wohl jedem unter Berücksichtigung dieser Tatsachen klar sein das Stephen keinen Sourcecode rausgeben muß,
- den Source für die avcodec.library nicht weil er nicht der Author ist und diesen wahrscheinlich gar nicht hat - den Source für den DVPlayer nicht da dieser nicht unter GPL steht, da eine spätere Änderung des Lizenzmodels, einer nicht statisch gelinkten kompatiblen externen Komponente, keinen Einfluß auf das Lizenzmodell des Programms hat.

Die erforderliche und zum Download angebotetene Bibliothek ist GPL. DvPlayer benutzt die Bibliothek. DvPlayer ist automatisch ein GPL Produkt. Das mag unbeabsichtigt gewesen sein, ändert die Tatsachen aber nicht mehr.
 
gni   Nutzer

16.08.2005, 10:53 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
Georg:
Ansonsten kann man sich auch den Source vom AROS png.datatype anschauen, der auf libpng basiert.

Hast Du auch einen Link?
 
gni   Nutzer

16.08.2005, 10:47 Uhr

[ - Direktlink - ]
Thema: Alphamaske aus PNG und IFF laden
Brett: Programmierung

Zitat:
DariusBrewka:
Zitat:
gni:
Welcher picture.datatype unterstützt PBPAFMT_ARGB?

Was meinst du mit unterstützt PBAFMT_ARGB?, also aufrufen kann ich das immer und bekomme auch ein 32 Bit Image heraus nur ist dann das Alpha==0, also Sinnlos.
Ich meinte, das der picture.datatype dieses Format auch verarbeiten kann und nicht auf _RGB besteht.
Zitat:
Zitat:
Ich bezweifle auch nicht, das ALPHA nutzlos ist. Ich weis nur nicht, wie ein DT diese Information weitergeben soll bzw. behandeln soll, da meines Wissens PBPAFMT_ARGB nicht unterstützt wird.
Hoffe zuerst einmal dass du dich verschrieben hast
Sollte natürlich heissen, das Alpha nicht nutzlos ist...
 
gni   Nutzer

16.08.2005, 10:18 Uhr

[ - Direktlink - ]
Thema: DvPlayer
Brett: Amiga, AmigaOS 4

Zitat:
AmigaPapst:
Da steht LGPL nicht GPL, das ist ein Unterschied wie Tag und Nacht.

Nein, so groß ist der Unterschied leider nicht :-( Ich warte auf die Quellen für diese Bibliothek.
 
 
Erste << 9 10 11 12 13 -14- 15 16 17 18 19 >> Letzte Ergebnisse der Suche: 1106 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.