Zitat:

---

Original von Holger:
char* bla=" ";
InitBitMap(bla);

---

Zitat:

---

AmigaPapst:

Zitat:

---

gni:
Ich bezweifle, das jetzt kein weiterer GPL-Code mehr verwendet wird.

---

Woher nimmst du diese Behauptung? Hast du den Quellcode vor dir? Deine Freunde werden schon prüfen ob sich darin noch GPL-Code versteckt.

---

Zitat:

---

AmigaPapst:
Der DvPlayer ist ab sofort wieder unter http://amigos.amiga.hu/dvplayer/ verfügbar. Der umstrittene AC3-Teil wurde erstmal aus dem Quellcode der avcodec.library entfernt.

---

Zitat:

---

whose:
Es ist zwar richtig, daß niemand gezwungen wird, GPLd Software einzusetzen, andererseits werden Leute, die GPLd-Software als Unterbau verwenden, dazu gezwungen, ihr geistiges Eigentum (den "Oberbau") preiszugeben, ob sie das wollen oder nicht.

---

Zitat:

---

ChrisP:
So funktioniert Open Source eben nicht.

---

Zitat:

---

whose:
Noch jemand der Meinung, daß GPL in jedem Fall ein Segen ist?

---

Zitat:

---

Harague:
Gab oder gibt es Bildschirmschoner die auch mit nem MC68000 laufen.

---

Zitat:

---

Vielleicht sowas ähnliches wie vom CDTV?

---

Zitat:

---

und was muß ich machen um JPG auf dem 500er zu sehen? Geht das überhaupt

---

Zitat:

---

Original von bubblebobble:
Wenn das AROS picture.datatype das auch kann, könnte man das doch evtl. für OS3.x kompilieren, oder nicht?

---

Zitat:

---

DariusBrewka:

Zitat:

---

DTs können ohne weiteres den Alpha-Kanal laden. Nur was dann damit machen?

---

z.B. mit DoMethod(...PDTM_READPIXELARRAY,...PixelFormat = PBPAFMT_ARGB)
den User ermöglichen etwas von dem Kanal zu haben?

---

Zitat:

---

Tschuldigung, das "Nur was dann damit machen?" ist eine ziemlich blöde Antwort.

---

Zitat:

---

Ich könnte das sehr gut gebrauchen und muss auf 68K die Maske immer als zusätzliche Datei speichern. AROS kann das ja und so schwierig das in 68 zu implementieren kann das wohl auch nicht sein.

---

Zitat:

---

whose:
Also, wird noch ein paar Tage dauern, bevor man das mit dem GCC übersetzen.

---

Zitat:

---

MaikG:
und GCC bekommt man aber im Internet?

---

Zitat:

---

bubblebobble:
Gibt es die als Amiga Shared Lib mit Doku irgendwo?

---

Zitat:

---

ArtEffects schreibt einen "ALPHA" Chunk in die IFF Dateien, ist das eine eigene Erfindung oder gibt es andere Programme oder Datatypes, die das Unterstützen?

---

Zitat:

---

Holger:

Zitat:

---

gni:

Zitat:

---

Solar:
Kinder, solange ihr von der Semantik von "const" keine Ahnung habt, und ernsthaft glaubt der Hauptzweck von C++ sei, "sicherere" Anwendungen zu schreiben, diskutiert doch besser nicht darüber, OK?

---

Schön das wenigstens einer Durchblick hat...

---

Was meinst Du damit?

---

Zitat:

---

Ralf27:
Hab auch gleich mal eine mp3-Datei mit einem Bild versehn und sie da, AMP kann sie nicht mehr abspielen.

---

Zitat:

---

bubblebobble:
Weiss jemand wie man die Alphamaske aus PNG und/oder IFF-ILBM Grafiken laden kann? Datatypes (bzw. via guigfx) scheint das nicht zu unterstüten?

Wie machen das die PNG Icons ?

---

Zitat:

---

thomas:
Jedenfalls dient mein USB-Stick sowohl am PC als auch am Amiga als Boot-Gerät. Ohne irgendwas an den Dateien zu ändern.

---

Zitat:

---

_PAB_:
Wenn man schon ein Mediator hat, macht es keinen Sinn noch eine alte Amiga-Grafikkarte weiterzubenutzen, die den Videoslot braucht, da nimmt man lieber eine (kompatible) PCI-Karte und erhält gleich viel mehr Leistung.

---

Zitat:

---

thomas:
wenn die HDToolbox mit ASKDEVICE abstürzt, heißt das meistens, daß du ein Device in DEVS: hast, das nicht korrekt auf unbekannte Befehle reagiert.

---

Zitat:

---

Solar:
Kinder, solange ihr von der Semantik von "const" keine Ahnung habt, und ernsthaft glaubt der Hauptzweck von C++ sei, "sicherere" Anwendungen zu schreiben, diskutiert doch besser nicht darüber, OK?

---

Zitat:

---

Wenn etwas durch eine Konstante initialisiert werden darf (weil es von den entsprechenden Funktionen nicht verändert wird), muß es auch "const" deklariert werden! Das hat nichts mit C++ zu tun und ist schon in C schlichtweg falsch - nur daß sich der Compiler nicht so sehr darüber beschwert.

---

Zitat:

---

Und der Grund, warum heute kaum noch in C und hauptsächlich in C++ entwickelt wird, ist die bessere Wartbarkeit von C++-Code.

---

Zitat:

---

Dietmar:
Gibt es eine Chance, dass Du 3.4.3 in den nächsten Tagen zusammenstellst/veröffentlichst?

---

Zitat:

---

Ich werde heute einen neuen morphos-gcc von Marcin Kurek integrieren (nicht wirklich neu, habe den 2.95.4-4-altivec Release im Juli übersehen).

---

Zitat:

---

Wenn Du mit 3.4.3 in nächster Zeit fertig wirst, würde ich diese Version gerne mit in das nächste Update nehmen.

---

Zitat:

---

Mazze:
Ich habe jetzt das Problem, dass beim Kompilieren mit gcc folgende Fehlermeldung angezeigt wird: "undefined reference to AllocChooserNode". Es fehlen offenbar die Funktionen, die seit OS3.5 hinzugekommen sind.

---

Zitat:

---

Bitte beim nächsten Update berücksichtigen.

---

Zitat:

---

Ralf27:
Den Lame-Tag versuch ich später mal im Internet zu finden. Mal sehn was da drin steht. Denn die meisten MP3 sind bei mir mit LAME gepackt.

---

Zitat:

---

Dietmar:
Das nächste für Dich interessante Update dürfte kommen, wenn es die von gni angekündigten neuen 68k-gcc-Versionen gibt (gcc 4.x).

---

Zitat:

---

whose:

Zitat:

---

gni:
Die VarArgs-Varianten sind nur _Hilfsfunktionen_ ("convenience")!

---

Genau. Und davon schrieb ich einen Post vorher. Das vieles, was einem heute in den Includes merkwürdig vorkommen mag, damals dazu gedacht war, den externen Entwicklern das Leben zu erleichtern.

---

Zitat:

---

Zitat:

---

Beim Füllen der TagList mußt Du _auch_ Casten.

---

Eben. Deswegen sagte ich ja auch, daß das keine besonders glückliche Lösung war mit den Taglisten.

---

Zitat:

---

Die Inlines/Stubs bauen noch dazu auf einer Eigenschaft auf, die nicht auf jeder Maschine garantiert sein muß.

---

Zitat:

---

Zitat:

---

Zitat:

---

Da kommt dann sowas wie "...pointer to function makes pointer from integer without a cast"... also doch nicht ganz glücklich gelöst.

---

Das ist _ausschließlich_ ein Problem "Implementation". Der GCC unterstützt Makros mit variablen Argumenten und dieses Feature wird von den Inlines verwendet. Die Argumente werden in ein ULONG-Array gepackt. Und genau das ist die Stelle, an der die Warnung kommen _muß_. Die beschriebene Methode ist äußerst ineffizient. Deshalb empfehle ich generell mit NO_INLINE_STDARG zu arbeiten. Zum einem gibt es dann keine Warnung und außerdem ist der generierte Code dann um Längen besser.

---

Naja, im Groben habe ich das auch gesagt. "Es gibt ja immer noch die Stubs"

---

Zitat:

---

Weiter unten in dem Post habe ich aber auch gesagt, daß die IText-Struktur zur _Wiederverwendung_ gedacht war und das wäre mit nem CONST UBYTE * als Member nun mal unmöglich. Einmal zugewiesen, nie mehr verändert.

---

Zitat:

---

Im Fall der IText-Struktur wäre es aber witzlos, in einer neuen OS-Version Rücksicht auf die enorme Typstrenge der C++-Compiler zu nehmen.

---

Zitat:

---

Wie ich weiter oben schon sagte: Im AmigaOS gibts vieles, was historisch gewachsen ist und zu einer Zeit entstand, als man von strenger Typprüfung eines C++-Compilers noch nicht allzu viel Ahnung hatte.

---

Zitat:

---

Ich fasse das Ganze mal so zusammen: Manchmal sind die Casts nicht schön, aber wer den alten Krempel in AmigaOS benutzen will, wird sich wohl oder übel damit anfreunden müssen.

---

Zitat:

---

whose:
Die Funktionen, die die Taglisten als VarArg-Parameter akzeptieren (und genau dafür sind die Taglisten gedacht!), bauen darauf, daß man Zeiger- und ULONG-Typ innerhalb der TagItem-Struktur beliebig casten kann.

---

Zitat:

---

Ansonsten wären z.B. die inline-Aufrufe der VarArg-Varianten gar nicht machbar.

---

Zitat:

---

Der GCC meckert trotzdem gerne bei solchen Funktionen, wie z.B. BestModeID(). Da kommt dann sowas wie "...pointer to function makes pointer from integer without a cast"... also doch nicht ganz glücklich gelöst.

---

Zitat:

---

Sei mir bitte nicht böse, aber Konstanten verwende ich z.B. eher selten im Zusammenhang mit IText. Da kommen höchstens Texte hinein, die mir die locale.library liefert, und diese Strings sind nur scheinbar konstant...

---

Zitat:

---

Streng genommen bräuchte man den jeweiligen String nie konstant zu definieren.

---

Zitat:

---

Holger:
Die TagList sind im Gegensatz zum Rest überhaupt kein Problem. Das sind ja ausnahmesweise sogar mal Strukturen, die keine Abhängigkeiten zu Internas des OS enthalten.

---

Zitat:

---

whose:
Wie will man denn Casts vermeiden, wenn viel mit Zeigern auf unterschiedliche Strukturen gearbeitet wird? Abgesehen davon bietet sich dadurch doch erst die Möglichkeit, den Compiler einen Großteil der Typüberprüfung erledigen zu lassen... (?)

---

Zitat:

---

Naja, was heute sinnvoll erscheint war damals (1984) halt noch kein Thema (und C++ war auch noch keins zu dieser Zeit ). Insofern sind die Definitionen den Strukturen schon recht sinnvoll

---

Zitat:

---

Zu der Zeit, als man auf diese (zugegebenermaßen "glorreiche" ) Idee kam, hat noch niemand daran gedacht, Funktionseinsprünge per Makro erledigen zu lassen anstatt über eine Linkerbibliothek mit Stub-Funktionen. Daher auch die Probleme damit, wenn C++-Compiler da dran müssen.

---

Zitat:

---

Und es wäre etwas dumm, wenn man das als const char * bzw. CONST UBYTE definiert hätte, dann würde ein C++-Compiler wohl noch viel öfter meckern bzw. Nicht-konstante Strings (wie sie doch ziemlich häufig vorkommen) würden halsbrecherische Casts erzwingen...

---

Zitat:

---

fisch08:
Packalgorithmen waren früher einfach schwerfälliger, weil die Rechner nicht schnell genug waren

---

Zitat:

---

Und wenn ich bei 250 GByte 30% durch Packer einsparen kann, so sind das mal so eben 75 GByte an Speicher, der "mal eben" zur Verfügung steht...

---

Zitat:

---

Holger:
Ich kann mir auch nicht vorstellen, daß ein Archiv, daß als selbstentpackend für OS XYZ daherkommt, für den Amiga verwertbare Informationen enthält.

---

Zitat:

---

alphamann:
UPX ist kein Packer im herkömmlichen Sinne er Packt ausfürbare Dateien so das sie ausführbar bleiben!!!

---