amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Alphamaske aus PNG und IFF laden [ - Search - New posts - Register - Login - ]

1 -2- 3 [ - Post reply - ]

2005-08-16, 11:52 h

bubblebobble
Posts: 707
User
Zitat:
Ich weiß nicht genau, was das für eine Sprachs ist, aber aus dem Rest der da steht, würde ich sagen, du mußt entweder
code:
DoDTMethodA_ *DTPic,0,0,&DTM
oder
code:
DoDTMethod_ *DTPic,0,0,DTM
benutzen, weil DTM offenbar kein Pointer ist, sondern die Struktur selber. DoDTMethodA braucht aber einen Pointer auf die Methode.
Die Sprachei st AmiBlitz2. Was meinst du mit Pointer auf die Methode ?
DTM oder &DTMO ist ein Pointer auf das erst Element der structur pndBlitzPixelArray, die vorher erzeugt wurde und die Werte
hineingeschrieben.

Zitat:
Wie sieht denn dein Aufruf von DTM_PROCLAYOUT aus ?
Das mache ich gar nicht. Muss man das zwingen vorher tun ?
Sieht so aus, als ob DTM_PROCLAYOUT die Daten bereits auf
den Screen Typ remapped. Dabei könnte der Alphakanal verloren
gehen, deshalb will ich das nicht machen.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, UDM, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2005-08-16, 13:27 h

thomas
Posts: 7718
User
Zitat:
Das mache ich gar nicht. Muss man das zwingen vorher tun ?

Nein. Das muß man machen, wenn man die Bitmap benutzen möchte. PDTM_READPIXELARRAY scheint auch ohne zu funktionieren.

Ich habe es mal ausprobiert. Georg hat recht, mit DoDTMethod stürzt es ab, mit DoMethod funktioniert es.

DoMethod is allerdings nur in der amiga.lib enthalten, die dürfte es für Basic nicht geben.

Zitat:
Was meinst du mit Pointer auf die Methode ?

In C wird strikt unterschieden, zwischen einem Speicherbereich und einem Pointer datauf.

Wenn du z.B. sagst:

struct pndBlitzPixelArray dtm;

Dann wird der Speicher für die Struktur reserviert, und dtm bezeichnet die Struktur.

Wenn du aber sagst:

struct pndBlitzPixelArray *dtp;

Dann wird nur ein Zeiger angelegt und kein Speicher reserviert (außer den vier Bytes für den Zeiger).

Wenn du nun eine Funktion aufrufst, die einen Zeiger benötigt, mußt du im ersten Fall schreiben:

DoMethod (o,&dtm); /* & gibt die Adresse der nachfolgenden Variable zurück */

oder im zweiten Fall:

dtp = &dtm; /* damit der Zeiger auf einen Speicherbereich zeigt */
DoMethod (o,dtp);

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Answer - Quote - Direct link - ]
2005-08-16, 13:28 h

DariusBrewka
Posts: 899
[Banned user] 		@gni

Link, nunja der Quellcode von AROS ist frei verfügbar auf http://www.AROS.org

der für den Datatype befindet sich (Natürlich) in workbench/libs/datatypes/

@bubblebobble

Also wie Holger schon gesagt hat du müsstest das nicht über das picture.datatype machen sondern direkt über das PNG DataType, wie das genau geht weiss ich nicht, aber ich würde vermuten, dass du das DataType per OpenLib öffnest? ..., ich denke Thomas hat bestimmt wieder ein Beispiel dafür parat hat? ;-)

gruss

Darius

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:01 h

softwarefailure
Posts: 38
User 		Der picture.datatype von OS3.9 setzt das Alphabyte dummerweise immer auf 0. Da kann man leider nix machen, obwohl WarpPNG es unterstützt. Ich habe schon vor längerer Zeit mit Olaf Barthel darüber gesprochen und auch H&P hat die Zustimmung für ein Update gegeben, weil ich einen Alphachannel-fähigen picture.datatype für Hollywood 2.0 brauche. Es erfordert ja nur eine minimale Änderung, dass der picture.datatype den Alphachannel durchschleift und ich bin mit Olaf so verblieben, dass er das noch ändert, wenn er mal Zeit hat.

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:22 h

bubblebobble
Posts: 707
User 		Die Unterschiede mit Pointern und Speicherbereichen sind
mir klar, ich programmiere auch viel mit C/C++, nur auf
dem Amiga nutze ich Amitblitz.
So wie ich oben in Amitblitz mache stimmt das schon.

Wenn es mit DoDTMethod abstürzt und mit DoMethod geht
ist mir das dann auch klar. Leider habe ich DoMethod
tatsächlich nicht unter Amiblitz. Wie kann man das
nachbauen ? Gibt es eine Alternative ?

@softwarefailure:
Dann hoffen wir mal, dass Olaf Zeit hat.
Kannst du mir die Email geben, dann kann ich ihn auch
nerven und er sieht dass noch mehr Leute daran interessiert sind.
Die Änderung dürft minimal sein und nicht viel Zeit kosten.

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

Wird der Alphakanal dann also auch bei READPIXELARRAY alles genullt,
selbst bei pixelformat ARGB ?


--
<hr>
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2005-08-16, 14:45 h

gni
Posts: 1106
User
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.

[ - Answer - Quote - Direct link - ]
2005-08-16, 14:53 h

bubblebobble
Posts: 707
User 		@gni:
Ich dachte, die einzelnen Datatypes sind normale AmigaShared Libs,
die man auch direkt nutzen kann. Und wenn das so ist,
bräuchte ich auch eine Docu + .fd File dazu. Evtl. hat das png
Datatype ja Funktionen, um an die Alphamakse zu kommen.

Beste Lösung wäre aber tatsächlich, wenn ich das DoMethod hinbekomme
und Olaf das datatype fixed.
Dann hätte ich genau das was ich will, die Daten als ARGB PixelArray.
--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2005-08-16, 15:26 h

gni
Posts: 1106
User
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.

[ - Answer - Quote - Direct link - ]
2005-08-16, 16:26 h

thomas
Posts: 7718
User
Zitat:
Original von bubblebobble:
Leider habe ich DoMethod
tatsächlich nicht unter Amiblitz. Wie kann man das
nachbauen ? Gibt es eine Alternative ?

DoDTMethod und DoGadgetMethod sind die einzigen AmigaOS-Funktionen, die Methoden unterstützen und beide stürzen in diesem Fall ab.

Wenn du in AmiBlitz Zeiger auf Funktionen und Funktionen mit Registerargumenten verarbeiten kannst, hier ist ein Stück Code, wie DoMethod funktionieren könnte:

code:
ULONG DoMethodA (Object *o,Msg *msg)

{
Class *cl;
ULONG (*dispatcher) (__a0 Class *cl,__a2 Object *o,__a1 Msg *msg);

cl = ((Class **)o)[-1];
dispatcher = cl->cl_Dispatcher.h_Entry;

return (dispatcher (cl,o,msg));
}

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Answer - Quote - Direct link - ]
2005-08-16, 16:53 h

Georg
Posts: 107
User 		@thomas:

Einfacher ist:

ULONG DoMethodA(Object *o, Msg *msg)
{
return CallHookPkt((struct Hook *)OCLASS(o), o, msg);
}

CallHookPkt ist in utility.library.

[ - Answer - Quote - Direct link - ]
2005-08-16, 17:03 h

softwarefailure
Posts: 38
User 		@bubblebobble:

Ich hab' Olaf eben nochmal angeschrieben und ihm den Link auf diesen Thread mitgeteilt. Weiter nerven ist wohl keine gute Idee... er weiß ja Bescheid und war damals (letzten Dezember/Januar) schon nicht sonderlich begeistert nochmal ein Update machen zu müssen, aber es ist wirklich eine denkbar triviale Sache und ich brauche es unbedingt.

Wie gesagt, du kommst mit dem OS3.x picture.datatype nicht an die Alphamaske ran, auch nicht über DTM_READPIXELARRAY. Das Alphabyte wird immer auf 0 gesetzt - auch wenn die png subclass es übermittelt.

[ - Answer - Quote - Direct link - ]
2005-08-16, 18:23 h

bubblebobble
Posts: 707
User 		"Nerven" war nicht so ernst gemeint.
Ich dachte nur, vielleicht ist sein Motivation größer wenn er weiss,
dass noch jemand das UNBEDINGT braucht ;-)

Danke für die Vorschläge wie man DoMethod realisieren kann.
Ich werds dann mal ausprobieren.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2005-08-16, 21:10 h

srupprecht
Posts: 39
User
Zitat:
Original von softwarefailure:
@bubblebobble:

Ich hab' Olaf eben nochmal angeschrieben und ihm den Link auf diesen Thread mitgeteilt. Weiter nerven ist wohl keine gute Idee... er weiß ja Bescheid und war damals (letzten Dezember/Januar) schon nicht sonderlich begeistert nochmal ein Update machen zu müssen, aber es ist wirklich eine denkbar triviale Sache und ich brauche es unbedingt.

Der picture.datatype von OS4 unterstützt schon seit geraumer Zeit das Alphabyte (gleiches gilt für die Unterklassen). Ich bezweifel aber, daß Du für OS3.x noch jemals eine entsprechende Anpassung bekommen wirst.

[ - Answer - Quote - Direct link - ]
2005-08-16, 21:21 h

DariusBrewka
Posts: 899
[Banned user] 		Also ich habe mich daran gemacht das picture.datatype aus dem AROS source für os3 zu anzupassen und es läuft auch NUR der AlphaChannel ist auch hier nicht da, jedenfalls kommt nur etwas heraus wenn ich nachträglich im Buffer die AlphaWerte auf 0 setze.

Da dieses picture.datatype scheinbar nur das was es vom png.datatype erhält kopiert habe ich keine Ahnung woran das liegen könnte. Habe den letzten warppng.datatype benutzt und auch die Entsprechenden ENV Variablen gesetzt ALPHA_MODE=KEEP im file env:datatypes/warppng.prefs.

Andererseits habe ich davon auch wirlich keine Ahnung, habe mich schon gewundert das mein Library startup code sich so einfach integrieren liess. Und es auf anhieb geklappt hat.

[ - Answer - Quote - Direct link - ]
2005-08-16, 22:15 h

softwarefailure
Posts: 38
User 		@DariusBrewka:

Hau' mal Oliver Roberts an. Ich glaube seine 68k-Kompilate erlauben kein ALPHA_MODE=KEEP weil es ja der picture.datatype nicht unterstützt. In der Doku steht nämlich:

KEEP:
simply pass the alpha channel data through to picture.datatype
by creating a 32-bit RGBA bitmap. IMPORTANT: this mode
requires a picture.datatype that supports RGBA output, and as
such this mode is only available under OS4 and MorphOS 1.x
(default for OS4 & MorphOS 1.x)

Er müsste dir da evtl. eine Version kompilieren, die KEEP erlaubt.

[ - Answer - Quote - Direct link - ]
2005-08-16, 22:20 h

DariusBrewka
Posts: 899
[Banned user] 		Ja es klappt nun, ich habe einfach das WarpDT.datatype durch das akPNG.datatype ersetzt und nun liesst er den AlphaKanal auch aus, dieses dürfte sich aber nur auf die DTM_READPIXELARRAY methode beziehen nicht jedoch auf DRAW, da will ich nicht zuviel dran machen, war halt nur so zum Testen ;-)

Nun weiss ich die Rechtliche situation nicht muss mir mal die Aros lizens durchlesen, ob ich das einfach so verbreiten darf und wie Georg gesagt hat unterstützt dieses picture.datatype noch vieles nicht.

[ - Answer - Quote - Direct link - ]
2005-08-16, 23:20 h

Georg
Posts: 107
User 		@DariusBrewka:

Zitat:
nicht jedoch auf DRAW

Das mit dem DRAW ist auch so ne Sache. Wer sagt denn daß ein datatype Benutzer es immer so will, daß alpha-geblendet geblittet wird? Möglicherweise will er ja die Daten in der BitMap so wie sie im Original PNG File waren (also praktisch wie per READPIXELARRAY nur will er halt die Daten direkt in ner BitMap anstatt in nem PixelArray), und nicht zusammengemixt/geblendet mit dem Hintergrund.





[ - Answer - Quote - Direct link - ]
2005-08-16, 23:31 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von Georg:
Das mit dem DRAW ist auch so ne Sache. Wer sagt denn daß ein datatype Benutzer es immer so will, daß alpha-geblendet geblittet wird? Möglicherweise will er ja die Daten in der BitMap so wie sie im Original PNG File waren (also praktisch wie per READPIXELARRAY nur will er halt die Daten direkt in ner BitMap anstatt in nem PixelArray), und nicht zusammengemixt/geblendet mit dem Hintergrund.

das ist die Frage, aber ggf. könnte man auch eine ENV Variable definieren, oder es ganz einfach lassen.

Mir ist es wichtiger an die Daten heranzukommen, über die Datatypes muss ich nicht unbedingt zeichen, d.h. wenn man weiss das man das nicht über DTM_Draw machen kann, dann kann man sich ruhig die daten per ReadPixels holen. Hauptsache es geht!


[ - Answer - Quote - Direct link - ]
2005-08-17, 00:20 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:
das ist die Frage, aber ggf. könnte man auch eine ENV Variable definieren, oder es ganz einfach lassen.

Mir ist es wichtiger an die Daten heranzukommen, über die Datatypes muss ich nicht unbedingt zeichen, d.h. wenn man weiss das man das nicht über DTM_Draw machen kann, dann kann man sich ruhig die daten per ReadPixels holen. Hauptsache es geht!
Aargh.
Irgendwie werden Env-Variable inzwischen für alles mögliche mißbraucht. Env-Variablen sind nicht dafür da, tiefgreifende System-Routinen zu steuern. Schlimm genug, daß WarpOS Benutzer sich damit quälen müssen.
Wenn ein Programm eine Routine aufruft, sollte deren Arbeitsweise so sein, wie das Programm es will, und nicht wie ein User es per Env-Variable definieren mußte. Wenn das Programm eine Verhaltensweise konfigurierbar machen will, muß das Programm diese Option anbieten, nicht das Datatype.
Zur Draw-Method. Diese bekommt meines Wissens keine BitMap, sondern einen RastPort. Dieser ist genau dafür da, Parameter für eine Grafikoperation zu liefern. Zwar gibt es keine sinnvollen Optionen für Blending-Modes in True-Color Umgebungen, aber da z.B. der Blitter-Minterm dem am nächsten kommt und auch für TrueColor sinnlos ist, könnte man dessen Bedeutung umdefinieren. Ansonsten gibt's noch den DrawMode, der zwischen Vordergrund und Vorder+Hintergrund unterscheidet. Auch der wäre passabel.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2005-08-17, 00:35 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von Holger:
Aargh.
Irgendwie werden Env-Variable inzwischen für alles mögliche mißbraucht. Env-Variablen sind nicht dafür da, tiefgreifende System-Routinen zu steuern. Schlimm genug, daß WarpOS Benutzer sich damit quälen müssen.

Nur das das picture.datatype schon von sich aus gewisse ENV-Variablen ausliest da kann ich nichts für, ich hatte auch nicht vor die Draw methode zu ändern schon alleine aus Kompatiblitätsgründen nicht,

Zitat:
Wenn ein Programm eine Routine aufruft, sollte deren Arbeitsweise so sein, wie das Programm es will, und nicht wie ein User es per Env-Variable definieren mußte. Wenn das Programm eine Verhaltensweise konfigurierbar machen will, muß das Programm diese Option anbieten, nicht das Datatype.

darum wird das auch so bleiben! und zwar nur mittels DoMethos(..ReadPixels,, FMT_ARGB), ggf. wird es nur so geändert das Alpha im ARGB immer auf 0xff gesetzt wird, falls das Bild keinen solchen Kanal hat.

Zitat:
...
ist, könnte man dessen Bedeutung umdefinieren. Ansonsten gibt's noch den DrawMode, der zwischen Vordergrund und Vorder+Hintergrund unterscheidet. Auch der wäre passabel.

an DrawMode habe ich auch schon gedacht, aber wenn ich Ehrlich bin habe ich dazu nicht wirklich Lust, wie schon gesagt der Pogger hat sich darum zu kümmern und wenn er Alpha braucht dann kann er auch diese mit READPIXELARRAY auslesen.



[ - Answer - Quote - Direct link - ]
2005-08-17, 00:56 h

bubblebobble
Posts: 707
User 		@DariusBrewka:
Hey cool! Warum sollte man das nicht verwenden dürfen ?
Es gibt ja auch 68K AROS.
Wäre eine super Sache wenn man das nutzen könnte.
Allerdings sagst du es unterstützt eine Menge Dinge noch nicht ?
Evtl. gibt es eine Möglichkeit das parallel zu installieren,
damit es mit dem original datatpye nicht in die Quere kommt.
Hängt davon ab wie komplett das ist.
Ich nutze auch den AK-Datatype. Die 15 Pfund für das WarpDatatpye
finde ich etwas viel, nur damit man .png Grafiken laden kann. Der Amiga war zwar mal kommerziell,
aber fragt mal einen Windows User, ob er er 20 Euro zahlen würde um ein bestimmtes Grafikformat laden zu können.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2005-08-17, 01:01 h

whose
Posts: 2156
User
Zitat:
Original von Holger:
Zitat:
Original von DariusBrewka:
das ist die Frage, aber ggf. könnte man auch eine ENV Variable definieren, oder es ganz einfach lassen.

Mir ist es wichtiger an die Daten heranzukommen, über die Datatypes muss ich nicht unbedingt zeichen, d.h. wenn man weiss das man das nicht über DTM_Draw machen kann, dann kann man sich ruhig die daten per ReadPixels holen. Hauptsache es geht!
Aargh.
Irgendwie werden Env-Variable inzwischen für alles mögliche mißbraucht. Env-Variablen sind nicht dafür da, tiefgreifende System-Routinen zu steuern. Schlimm genug, daß WarpOS Benutzer sich damit quälen müssen.

Amen :D

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Answer - Quote - Direct link - ]
2005-08-17, 06:35 h

DariusBrewka
Posts: 899
[Banned user] 		@bubblebobble

Paralell installieren wird wohl nicht gehen und was Fehlt weiß ich auch nicht, Georg hat's angesprochen welche Auswirkungen das hat?, wer weiß das was ich mache, dafür hat's gelangt.

[ - Answer - Quote - Direct link - ]
2005-08-17, 09:05 h

gni
Posts: 1106
User
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>

[ - Answer - Quote - Direct link - ]
2005-08-17, 11:01 h

softwarefailure
Posts: 38
User
Zitat:
Original von srupprecht:
Der picture.datatype von OS4 unterstützt schon seit geraumer Zeit das Alphabyte (gleiches gilt für die Unterklassen). Ich bezweifel aber, daß Du für OS3.x noch jemals eine entsprechende Anpassung bekommen wirst.

Wenn es wirklich niemand anpasst, haben wir ja jetzt mit dem AROS Backport einen Plan B. 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. Das muss einfach möglich sein! Wenn nicht, bin ich zwar auch stocksauer, aber die Leidtragenden sind wie so oft am Amiga die User.

[ - Answer - Quote - Direct link - ]
2005-08-17, 12:42 h

gni
Posts: 1106
User
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.

[ - Answer - Quote - Direct link - ]
2005-08-17, 13:30 h

DariusBrewka
Posts: 899
[Banned user] 		Ich habe im Aminet ein picture.datatype entdeckt, welches auch APLHA weiterreicht, aber das braucht so wie es aussieht Cybergfx (ist aber kein Problem), dieses Datatype hat bei mir auf e-uae auf dem Schirm ein wenig Chaos hinterlassen, ggfx kann das mal jemand testen ob's Normal ist?

http://main.aminet.net/util/dtype/PictDT43.lha


Nunja ich dachte man könnte den Author nach den Source fragen aber nach dem hier

code:
picture.datatype V43
                          Copyright 1995-97
                           Ralph Schmidt
           Additional libs/tools/changes by F.Mariak/M.Scheler
  	       Sub datatype classes by Matthias Scheler

kann man das wohl vergessen, das wäre wichtig weil das AROS DTT z.Z. kein DTM_WRITE implementiert hat, was sehr wichtig sein dürfte.

[ - Answer - Quote - Direct link - ]
2005-08-17, 13:40 h

bubblebobble
Posts: 707
User 		Ja, ich finde das auch schade. Eigentlich ein Armutszeugnis wenn man sich die Sachen von AROS borgt wegen mangelndem Support für OS3.9.
Aber ich kanns verstehen. OS3.9 ist verkauft, jeder hat es der es will (oder doppelt, so wie ich),
da ist nichts mehr zu holen. Andereseits will man OS3.9 absichtlich sterben lassen, damit man mehr AOnes verkaufen kann. Allerdings ist die 68K Basis zu gross für diese Strategie. Leute die ein AOne haben wollen besitzten einen bereits denke ich, also wird man kaum noch Verkäufe erwarten können, auch für OS4 nicht. Deshalb bin ich für eine 68K Version ;-) Dann könnte sich jeder OS4 holen und seine Software anpassen, also mehr OS4 Verkäufe und bessere Software für OS4.
"a man can dream though, a man can dream" (professor farnsworth)

Aber lasst den Tread bitte jetzt nicht zum Flamewar werden, konzentrieren wir uns auf die Sache.
Vielen Dank bisher an die sehr konstruktive Hilfe!

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ - Answer - Quote - Direct link - ]
2005-08-17, 15:56 h

softwarefailure
Posts: 38
User
Zitat:
Original von gni:
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.

Für mich als Softwareentwickler ist OS3.9 alles andere als tot. Es ist immer noch die Hauptplattform und der Großteil der User benutzt die 68k Versionen meiner Software, egal ob native oder auf Emulatoren. Das mit dem rechtlichen Aspekt wird gern vorgeschoben, aber H&P hat zugestimmt (Dezember 2004) und wenn plötzlich irgendein fataler Bug entdeckt werden würde, gäbe es auch ganz schnell einen Fix. Außerdem hatte ich im Februar Olaf schon so weit, dass er gesagt hat, dass er sich nächstes Wochenende drum kümmert. Dann habe ich geantwortet, dass es so eilig nun auch wieder nicht ist, Hauptsache er macht es irgendwann - ich will ja hier nicht stressen. Tja, und so sind wir verblieben.


[ - Answer - Quote - Direct link - ]
2005-08-17, 19:16 h

Georg
Posts: 107
User 		@DariusBrewka:

Zitat:
kann man das wohl vergessen
.

Na ja. Wer weiß. Frag' den Ralph ruhig mal. Als der "Deal" zwischen AROS-MorphOS zustandekam, hab' ich ihn gefragt ob' er nicht evtl. den picture.datatype source contributen könnte. Wenn ich mich richtig erinnere sagte er, daß er sich das schon vorstellen könnte. Nur der Source müßte vorher aufgeräumt werden. Gleiches galt übrigens sogar für die 68k emu (JIT gab's aber damals noch nicht).




[ - Answer - Quote - Direct link - ]

1 -2- 3 [ - Post reply - ]


amiga-news.de Forum > Programmierung > Alphamaske aus PNG und IFF laden [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.