Suche - amiga-news.de Forum

amiga-news.de Forum > Suche

[ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste 4 5 6 7 8 -9-

Ergebnisse der Suche: 265 Treffer (30 pro Seite)

akl Nutzer

13.04.2007, 15:08 Uhr

[ - Direktlink - ]

Thema: MathLibs Programmierung - Mathematisches Problem...
Brett: Programmierung

Ohne mich jetzt in die genannten Threads im Detail eingelesen zu haben:

- Amithlon-Versionen halte ich sehr wohl sinnvoll
- man sollte aber genau schauen ob und wie man das nicht mit einer echten Emulation innerhalb des UAE-JIT verbinden könnte

Was FFP angeht kann es sehr wohl sinnvoll sein, diese Bibliotheken zu verwenden (was ich auch mache) und zwar aus folgenden Gründen:

- bei den mathieee-Bibliotheken ist die Library-Base an den öffnenden Task gekoppelt
- bei FFP nicht
- für bestimmte Libraries mit rein globalen Library-Bases kann es daher unter bestimmten Umständen sinnvoll sein, mit FFP zu rechnen

Ganz konkret macht es Sinn, wenn:

- Floating Point nicht vermieden werden kann (kein Integer-Algorithmus)
- die Präzision nicht ganz so wichtig ist
- keine task-lokalen Bases verwendet werden
- das Ganze dennoch multi-threaded sein soll (ohne Semaphoren o.ä.)

akl Nutzer

13.04.2007, 14:59 Uhr

[ - Direktlink - ]

Thema: 48 bit support in CyberGraphX/Datatypes/...
Brett: Programmierung

[Kopie eines Postings unter http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=5220&forum=2 ]

On the AROS-Dev mailing list I've made a proposal to extend the AmigaOS (Clone) API with support - i.e. a corresponding PIX/PBAFMT - for 48/64 bit bitmaps.

I'd appreciate everyone interested to participate in the discussion thread there - it would be important to sync this API extension among AOS4/MOS and AROS anyway.

As a short summary - the idea is to add the following:

16:16:16 RGB (48 bit)
16:16:16: RGBA (64 bit)

in addition to the conventional:

8:8:8 RGB (24 bit)
8:8:8:8 RGBA (32 bit)

This is supported already today by PNG and TIFF and required for professional image processing / video editing systems - even though you won't find any conventional framebuffers which directly support it.

Still it would be helpful, if not the application but the OS would take care how to render/convert this "high data range" bitmap data.

akl Nutzer

04.04.2007, 18:46 Uhr

[ - Direktlink - ]

Thema: V: AmigaOne G4 im DesignTower
Brett: Kleinanzeigen (keine Auktionen!)

Hört sich interessant an. Hätte gerne ein Foto an info@ar-kleinert.de

akl Nutzer

31.03.2007, 22:56 Uhr

[ - Direktlink - ]

Thema: MorphOS: C++ & OpenWindowTags
Brett: Programmierung

@[ujb]:
Vermutlich kommt der C++ Compiler mit den Macros für variable Argumente nicht klar, d.h. in dem Fall varargs68k

akl Nutzer

04.03.2007, 15:29 Uhr

[ - Direktlink - ]

Thema: AREXX Open Window auf Ambient
Brett: MorphOS

@AmigaHarry:
Ja, allerdings steht in Zeile 46 des C-Quellcodes das folgende:
//"LoadURI URI/U,NEW=NEWWIN/S,RELOAD/S,FORCE/S,BROWSER/N,VIEWID/N"

akl Nutzer

03.03.2007, 23:20 Uhr

[ - Direktlink - ]

Thema: AREXX Open Window auf Ambient
Brett: MorphOS

Wenn mich nicht alles täuscht, wäre das LoadURI:
http://morphosambient.cvs.sourceforge.net/morphosambient/ambient/wblib/objects.c?revision=1.9&view=markup

akl Nutzer

19.01.2007, 17:15 Uhr

[ - Direktlink - ]

Thema: akgif-datatype
Brett: Programmierung

@Ralf27:
Vielleicht lieferst Du uns ja irgendwann mal die volle Systemkonfiguration und die Version von akGIF, um die es geht.

akl Nutzer

19.01.2007, 17:14 Uhr

[ - Direktlink - ]

Thema: akgif-datatype
Brett: Programmierung

@thomas:

Es kann sehr gut sein, dass in der GIF-Datei 0 als Tiefe steht, weil die Range nur von 0..7 geht und als 1..8 interpretiert wird :-)

Im Übrigen finde ich es lustig, was hier so alles an unterschiedlichen Meinungen über Bitmap-Tiefen von 0 steht - dass die Allozierung einer Bitmap mit Tiefe 0 via AllocBitmap() dann eigentlich fehlschlagen sollte, wäre dann allerdings auch zu bedenken...

akl Nutzer

14.01.2007, 19:58 Uhr

[ - Direktlink - ]

Thema: S: AmigaOne SE/XE/XC o. µA1
Brett: Kleinanzeigen (keine Auktionen!)

[ Dieser Beitrag wurde von akl am 25.04.2007 um 23:10 Uhr geändert. ]

akl Nutzer

13.01.2007, 22:01 Uhr

[ - Direktlink - ]

Thema: akgif-datatype
Brett: Programmierung

@Ralf27:
>Und wenn GetBitMapAttr bei der Datatypebitmap mit BMA_DEPTH eine NULL
>liefert...
Dann handelt es sich möglicherweise um eine RTG-Bitmap, die entstanden ist, indem die ursprüngliche Bitmap auf einen RTG-Screen remappt worden ist.

akl Nutzer

13.01.2007, 21:58 Uhr

[ - Direktlink - ]

Thema: akgif-datatype
Brett: Programmierung

@Holger:
Der akGIF-Datatype pinselt nicht selbst, sondern der picture-datatype. Je nach Umgebung alloziert letzterer auch die Bitmap. Dass es mit MultiView geht, beweist, dass die Standard-OS-Klassen sich richtig verhalten - nicht mehr, nicht weniger.

[ Dieser Beitrag wurde von akl am 13.01.2007 um 21:59 Uhr geändert. ]

akl Nutzer

13.01.2007, 21:56 Uhr

[ - Direktlink - ]

Thema: akgif-datatype
Brett: Programmierung

@malte2:

Ok, immer der Reihe nach.

1. Ob BMF_INTERLEAVED eine "Standard"-Bitmap ist, oder nicht, ist Ermessenssache. Jedenfalls ist das Layout anders und vor allen Dingen die Bytes pro Zeile. Und diese Bitmaps sind nunmal in V39 zeitgleich mit dem Verbot eingeführt worden, in Bitmaps direkt herumzupeeken oder irgendwelche entsprechenden Annahmen zu treffen, wie früher bei Standard-Bitmaps.

2. Was diverse Patches und/oder CyberGraphics & Co. unter bestimmten Bedingungen aus einer Interleaved-Bitmap machen, weiss ich nicht. Jedenfalls möglicherweise etwas anderes als aus einer BMF_STANDARD-Bitmap... (siehe 6.)

3. akGIF setzt nirgendwo eine Tiefe von 0 für 1 Bit-Grafiken an, sondern immer exakt die Tiefe, die in der GIF-Datei steht (also 1).

4. akGIF enthält jedoch zusätzlich einen expliziten Workaround für irgendeinen Bug (dem ich irgendwann einmal begegnet bin) der dafür sorgt, dass jede Tiefe <= 1 auf exakt 2 erhöht wird.

5. Der pic-dt erhält also von akGIF für Bitmaps der Tiefe 1 unter gar keinen Umständen eine Tiefenangabe 0, sondern stets eine Tiefe von 2. Das ist der Wert, der auch in bmh_Depth steht. Ob akGIF die Bitmap selbst alloziert, oder ob der pic-dt das macht, hängt von der OS-Umgebung ab.

6. Eine Tiefe von 0 in der Bitmap-Struktur (die sich von der in der BMHD-Struktur unterscheiden kann) deutet stark auf eine Tiefe größer 8 bzw. eine RTG-Bitmap hin.

Hope, that helps.

akl Nutzer

29.12.2006, 15:04 Uhr

[ - Direktlink - ]

Thema: SAS-C und GST
Brett: Programmierung

@geit:
vbcc in allen Ehren (ich lerne ihn auch gerade zu schätzen), aber man muss den SAS/C ja nicht schlechter machen, als er ist - der 68060 ist schliesslich auch nicht mehr weiterentwickelt worden. So gesehen reicht SAS/C für jede existierende 68k-Emulation vollkommen aus. Spannend wird es erst mit diversen angekündigten Coldfire-Karten, für die man vielleicht anders optimieren könnte.

akl Nutzer

29.12.2006, 15:00 Uhr

[ - Direktlink - ]

Thema: SAS-C und GST
Brett: Programmierung

@platon42:
Sehe ich auch so. Übrigens ist SAS/C ohne GST teilweise deutlich langsamer, von daher empfiehlt sich ggf. doch das Erzeugen eines neuen, zumindest für die reinen OS-Includes.

akl Nutzer

29.12.2006, 14:55 Uhr

[ - Direktlink - ]

Thema: akgif-datatype
Brett: Programmierung

@ZeroG:

akGIF setzt das Flag BMF_INTERLEAVED, d.h. die Bitmap ist keine Standard-Bitmap - daher verbietet sich auch das Peeken direkt in der Bitmap bzgl. Tiefe usw. (ich hoffe, das machst Du nicht ;-)

MultiView hat übrigens keine Probleme, 1bit-Bitmaps anzuzeigen, die von akGIF geliefert werden.

Ansonsten bitte auch gerne immer direkt per eMail anschreiben, dann lässt sich vermeiden, dass irgendwelche Gerüchte über Bugs kursieren, von denen ausgerechnet der Autor nichts weiss 8-) Umgekehrt kann ich das dann auch gleich überprüfen und ggf. korrigieren. Danke!

akl Nutzer

06.10.2006, 23:33 Uhr

[ - Direktlink - ]

Thema: IconEdit und PNG-Bilder ?
Brett: Amiga, AmigaOS 4

@Amaris:
Wenn Du die Daten einsehen und ggf. ändern möchtest, die z.B. MorphOS' Ambient zu PNG-Icons hinzufügt (auch wenn nicht jedes PNG-Icon die zwingend besitzen muss) kannst Du das mit dem "PNG-Box"-Tool von SView5 machen, das seit kurzem einen entsprechenden "Icon-Editor" mitbringt.

akl Nutzer

06.10.2006, 23:20 Uhr

[ - Direktlink - ]

Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

@DariusBrewka:
akPNG exportiert PBAFMT_ARGB (32 Bit) bei Bildern mit Alphachannel, sonst PBAFMT_RGB (24 Bit) - der Alpha-Support lässt sich auch abschalten, dann wird stets 24 Bit exportiert. PBAFMT_#? entspricht den CyberGraphics-Datentypen für RTG-Bitmaps. Was der pic-dt damit macht, ist eine andere Sache - solange jedoch nichts gerendert wurde, kann er damit auch nichts gemacht haben.

akl Nutzer

05.08.2006, 12:45 Uhr

[ - Direktlink - ]

Thema: S: AmigaOne SE/XE/XC o. µA1
Brett: Kleinanzeigen (keine Auktionen!)

[ Dieser Beitrag wurde von akl am 25.04.2007 um 23:10 Uhr geändert. ]

akl Nutzer

10.02.2006, 21:20 Uhr

[ - Direktlink - ]

Thema: Bilder Voranzeige?
Brett: Amiga, AmigaOS 4

@thomas:

Der xyz.datatype als Unterklasse erhält nur ein OM_NEW und muss darauf reagieren - das Layout macht die Superklasse, d.h. der picture.datatype. Eine andere Vorgehensweise war nie dokumentiert.

Natürlich wäre eine Menge theoretisch möglich - man kann sich allerdings nur auf dokumentierte Verhaltensweisen aller pic-dt Versionen stützen.

Es reicht nicht, nur als Applikationssicht die aufgerufenen Methoden zu betrachten.

akl Nutzer

04.02.2006, 17:57 Uhr

[ - Direktlink - ]

Thema: TIFF Einzelbilder anzeigen
Brett: Amiga, AmigaOS 4

@BJ:
akTIFF-dt kann's ab V45.40

akl Nutzer

01.02.2006, 14:56 Uhr

[ - Direktlink - ]

Thema: Bilder Voranzeige?
Brett: Amiga, AmigaOS 4

Das Klassen*konzept* hätte es zwar hergegeben, die real existierende picture-datatype API von V40/43 allerdings nicht. Es bringt ja nichts, wenn ein einzelner Datatype irgendwelche privaten Methoden implementiert, die dann z.B. MultiView gar nicht unterstützt.

[quote]
Original von thomas:

Obwohl das Klassen/Methodenkonzept das hergeben würde, hat die mangelnde Dokumentation dazu geführt, daß alle Programmierer direkt beim Öffnen der Datei das komplette Bild dekodieren (siehe C_V43-DT).

akl Nutzer

01.02.2006, 14:51 Uhr

[ - Direktlink - ]

Thema: DigiCam-Fotos
Brett: Amiga, AmigaOS 4

@Tulpe:
einfach eines der anderen SView5-Tools verwenden (Tools-Schublade) um das Ganze in einem Fenster (statt Screen) anzuzeigen - oder vorher einen passenden/verfügbaren Screenmodus voreinstellen

akl Nutzer

01.02.2006, 14:42 Uhr

[ - Direktlink - ]

Thema: SV5 passphrase's für lzw support ??
Brett: Amiga, AmigaOS 4

@R-TEAM:

Damit es nicht mehr "eine seltsame Sache ohne Klarheit" bleibt:

Die Passwort-Einstellung ist zwar noch vorhanden, es läuft seit dem Ablaufdatum des Patentes allerdings auch wieder ohne.

akl Nutzer

01.02.2006, 14:39 Uhr

[ - Direktlink - ]

Thema: suche AkMPEG
Brett: Amiga, AmigaOS 4

@hjoerg:
unter MOS mit G3/G4 läuft es ganz gut, mit Ton

akl Nutzer

01.02.2006, 14:38 Uhr

[ - Direktlink - ]

Thema: suche AkMPEG
Brett: Amiga, AmigaOS 4

@Acki:
siehe auch
http://groups.yahoo.com/group/pswx-beta/files/

Erste 4 5 6 7 8 -9-

Ergebnisse der Suche: 265 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