Suche - amiga-news.de Forum

amiga-news.de Forum > Suche

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

Erste 1 2 3 4 5 -6- 7 8 9

Ergebnisse der Suche: 265 Treffer (30 pro Seite)

akl Nutzer

14.01.2008, 10:14 Uhr

[ - Direktlink - ]

Thema: Seek-Problem
Brett: Programmierung

@tboeckel:
>Wenn man den Rückgabewert ignoriert, dann weiß man nicht, ob Seek()
>auch wirklich funktioniert hat. Und wenn man ihn nicht ignoriert,
>dann muß man beim Überschreiten der 2GB-Grenze feststellen, daß das
>nicht funktioniert hat, weil der Rückgabewert dann negativ wird, und
>das bedeutet Fehler.

Natürlich hast Du recht, man sollte Rückgabewerte überprüfen - allerdings ist man relativ auf der sicheren Seite, wenn man nur lesend auf eine <2GB-Datei zugreift, von der man die Größe kennt. Seek kann dann eigentlich nicht fehlschlagen.

Was die Fehlerbehandlung angeht, signalisiert -1 einen Fehler, die restliche Information liefert IoErr(). -1 ist jedoch gleich 0xFFFFFFFF - man kann also Werte bis zu 4 GB minus 1 Byte problemlos übergeben, solange man den Fehlerfall gegen == -1 und *nicht* auf < 0 überprüft (was ein Programmierfehler wäre - zugegeben kein seltener und kein schwerer; außerdem war Seek() bis V39 selbst auch fehlerhaft implementiert und hat nie -1 geliefert, sondern ebenfalls die aktuelle Position).

Seek() kann und darf ab V39 überhaupt keine anderen negativen Werte als -1 im Fehlerfall zurückliefern, es muss sich dann also andernfalls um einen gültigen Offset handeln.

Für OFFSET_BEGINNING und OFFSET_END sind negative Werte ebenfalls eindeutig zu interpretieren (nur positiv oder nur negativ) - und wenn der Treiber es nicht kann, gibt er zumindest letztlich -1 zurück. Allerdings sollte man vorsichtig sein, da sicherlich auch viele Treiber nicht entsprechend programmiert sind.

Sicherheitshalber kann man auch hier in mehreren Etappen Seek()en, d.h. nur beim ersten mal eine der beiden Optionen verwenden, und den Rest der Strecke unter Verwendung von OFFSET_CURRENT zurücklegen. Gleiches gilt für OFFSET_CURRENT selbst, wo man es zwangsläufig muss, da implizit vorzeichenbehaftet.

Damit muss auch jeder alte Treiber umgehen können, da es schliesslich auch früher schon vorkommen konnte, dass jemand 1 Byte vor Ende der Datei versucht bis zu 2 GB - 1 Byte relativ dazu über das Dateiende hinaus zu Seek()en bzw. das gleiche in die andere Richtung...

Ablauf:

LONG ret;

if(OS_VER < 39) // or check IoErr() each time
{
printf("sorry");
exit(0);
}

// forward
ULONG64 my_pos64 = 0;
ret = Seek(handle, upto_2gb-1, OFFSET_BEGINNING);
if(ret == -1) ; // IoErr(); else my_pos64 = upto_2gb-1;
ret = Seek(handle, upto_2gb-1, OFFSET_CURRENT);
if(ret == -1) ; // IoErr(); else my_pos64 += upto_2gb-1;
ret = Seek(handle, upto_2gb-1, OFFSET_CURRENT);
if(ret == -1) ; // IoErr(); else my_pos64 += upto_2gb-1;
// file end can only be determined by iteratively
// decreasing the seek value and trying again, until 0
// and ret != -1

// backward
ULONG64 my_pos64 = size_of_file; // a little bit harder ;-)
ret = Seek(handle, -1*(upto_2gb-1), OFFSET_END);
if(ret == -1) ; // IoErr(); else ;
ret = Seek(handle, -1*(upto_2gb-1), OFFSET_CURRENT);
if(ret == -1) ; // IoErr(); else my_pos64 -= upto_2gb-1;
ret = Seek(handle, -1*(upto_2gb-1), OFFSET_CURRENT);
if(ret == -1) ; // IoErr(); else my_pos64 -= upto_2gb-1;
if(ret == 0) my_pos64 = 0; // start of file

Für die Ermittlung der Dateigröße muss man den "forward"-Ansatz durchlaufen - bzw. alternativ nochmal überprüfen ob Examine() für bis zu 4 GB das korrekt handhabt.

@tboeckel:
>Beim anschließenden Lesen mag das ja vielleicht noch zu verschmerzen
>sein, man liest höchstens "unerwartete" Daten. Aber Schreiben würde
>ich definitv sein lassen, weil du dir sehr wahrscheinlich den Inhalt
>der Datei zerschießt. Du weißt halt nicht wo genau du in der Datei
>bist, wenn du nicht auf Seek() hörst.

Man muss eben selbst mitzählen, konservativ Seek()en und auf Fehler überprüfen. Reicht es nicht, dem Anwender eine Empfehlung zu geben, dass er >4 GB-Dateien mit bestimmten Dateisystemen tunlichst nicht erstellen soll? Kopieren wird ohnehin fehlschlagen... ;-)

@Holger:
>Selbst wenn das Dateisystem Dateien >4GB handhaben kann, gibt es noch
>das Problem, dass das alte Seek() laut Spezifikation die
>resultierende Position zurückgibt. Somit kann man auch nicht
>stückweise vorwärts springen, da beim Überschreiten der 4GB-Grenze
>die Rückgabewerte ungültig werden würden.

Man kann schon stückweise vorwärts springen - was nicht mehr geht, ist jedoch den Rückgabewert von Seek() als absolute Dateiposition zu interpretieren, die man zum Rücksprung an eine bestimmte Stelle, für OFFSET_BEGINNING, verwenden kann.

>Der Wert wird zwar nicht oft benötigt, aber es gibt durchaus
>Programme, die Seek() benutzen, um die tatsächliche Dateigröße zu
>ermitteln.

Das ist der andere Knackpunkt. Aber so gesehen sind <2GB-Programme ja alleine durch ihre eigenen Programmierfehler und/oder Limitierungen davor geschützt, über 4 GB hinaus zu lesen:

1. entweder wird der Fehlerfall gegen < 0 geprüft (schlägt fehl)
2. oder die Dateigröße wird falsch berechnet und alles oberhalb 2 GB wird nie versucht zu lesen bzw. das Programm kennt ohnehin nur 4GB-Offsets und Längenangaben
3. das Programm überprüft immer IoErr() oder gegen bestimmten Wert, weil bis V39 Seek() nie Fehler zurückgab (bzw. jedenfalls nicht -1)

>Insbesondere, weil man früher nicht mal einen Disk-Monitor benötigte,
>um die Größenangabe in den Dateieinträgen zu manipulieren, das boten
>einem auch einfache Dateimanager an.

Naja, mögliches Hacking von Datenträgern kann keine Begründung für ein bestimmtes Pattern sein. ExamineFH() und DupLockFromFH() gibt's eben erst seit V36.

Fazit:

- das Hauptproblem ist die Ermittlung von Dateigrößen oberhalb 2 GB (egal ob per Seek oder Examine)
- das zweite Problem ist die korrekte/konservative Verwendung der API im 4 GB-Fall
- das dritte Problem ist, dass 2 GB-Applikationen mit Dateien >2GB bzw. >4GB besonders umgehen können müss(t)en
- letzeres kann man vernachlässigen, da ohnehin nur bestimmte Applikationen 4GB-tauglich sind und speziell hierfür geschrieben werden müssen (Dateiformate wie TIFF, IFF, etc. sind ebenfalls nur bedingt oder gar nicht >4GB-tauglich, also müssen es die entsprechenden Anwendungen auch gar nicht sein)
- es gibt aber durchaus Dateiformate (TIFF) die bis zu 4GB gross sein können

Scheint für mich durchaus vertretbar zu sein, mit der alten API z.B. 4 GB ISO-Images für DVD-Brennprogramme auf HD zu schreiben, wenn man entsprechend konservativ programmiert.

Bei dem Versuch mit einem alten CD-Brennerprogramm eine DVD zu beschreiben ist aber Datenverlust oberhalb 4 GB (oder komplett) vorprogrammiert.

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

akl Nutzer

08.01.2008, 16:06 Uhr

[ - Direktlink - ]

Thema: Sharing von PPC-Amigas übers Web
Brett: Programmierung

@gni:

Die aktuelle Crosscompiler-Version ist AFAIR GCC 2.95.3-basiert (soweit ich weiss diese hier: http://www.zerohero.se/cross/mos.html). Mit GCC 2.95.3 erhält man unter MOS-native in einer Reihe von Fällen jedoch stellenweise kaputten Code (je größer -On mit n>=0, desto größer die Wahrscheinlichkeit). Mit dem inoffiziellen GCC 2.95.4 verschwindet das Problem teilweise (IIRC diese hier: http://www.tbs-software.com/morgoth/projects.html). In mindestens einem Fall lag es jedoch unmittelbar an der Größe einer .c-Datei (in zwei Files gesplittet und Problem verschwunden), was ich doch recht seltsam finde. Weiterhin stehen auch noch mehrere libnix-Varianten mit unterschiedlichen Bugs zur Auswahl, von denen zumindest die neueste(?) offensichtlich nicht mehr kompatibel zu den vorherigen ist. Ixemul will ich gar nicht thematisieren.

Wer garantiert mir also, dass - wenn ich später denselben Source nochmal unter MOS-native compiliere - alles noch läuft, insbesondere wenn der MOS-native GCC vermutlich mit sich selbst compiliert worden ist und noch mutmassliche Ixemul-Bugs mitschleift? Oder umgekehrt, wenn es nicht läuft, compiliere ich dann alles nochmal lokal um zu sehen ob es dann geht?

Wenn's nicht so schwer wäre, ein aufgehangenes MOS per VNC wieder neu zu starten und VNC per se nicht so imperformant(*) wäre, würde ich eher jenen Weg empfehlen... allerdings sehe ich den Use-Case von reinem Remote-Cross-Compiling ohne Testmöglichkeit auf dem Target sowieso nicht ganz, und hier braucht es entweder lokalen Zugang oder VNC oder eine Mischung verschiedener Zugänge.

Vielleicht bin ich altmodisch, aber für Entwicklung "zuhause" möchte ich gerne ein SDK was auf dem Target out-of-the-box fehlerfrei läuft mit einer stabilen und abwärtskompatiblen C-Library, die bei Bedarf (notfalls externe Semaphore und nur selektive Verwendung von Funktionen) auch in einer Library läuft. Am Besten ein aktueller GCC (4er-Serie) mit AltiVec-Support (nicht nur im Compiler sondern auch in der ABI bzw. im Exec). Wenn das stabil verfügbar ist, denke ich nochmal über Crosscompiling nach, vielleicht sogar für ein EFIKA oder dessen Nachfolger. (**)

Außerdem ist ein 1 GHz Pegasos ausreichend schnell für GCC. Mag auf dem EFIKA anders aussehen - aber damit sind wir wieder bei dem Punkt, dass MOS 2.0 und MOS/EFIKA bzw. das EFIKA selbst gar (noch) nicht (mehr) offiziell verfügbar sind. Macht auch nicht wirklich Spass, für Anwender um ein MOS 1.4.5 herum zu debuggen, was eingeweihte Entwickler ohnehin nicht mehr verwenden - macht es auch nicht einfacher, mit MOS-Entwicklern Bugs zu thematisieren. Weder die des OS noch die des Compilers oder des JIT.

(*) ok, und die Amiga-Tasten & Co. hat man ebenfalls nicht - da vergeht einem spätestens nach 15min der Spass, besonders beim Editieren oder Testen

akl Nutzer

07.01.2008, 15:42 Uhr

[ - Direktlink - ]

Thema: YAM 2.5 Installation
Brett: Amiga, AmigaOS 4

@AmigaHarry:

Ganz ehrlich: die Architektur von Dual-CPU-Software - und ganz besonders PUP oder WOS - ist so anfällig für Designfehler und dementsprechend fragil (wie auch die verwendeten Compiler), dass ich im Zweifel den Fehler eher immer dort suchen würde.

Du sagst ja selbst, dass bessere Kühlung die CPU-Taktrate oben hält - und dann ist das Zeitfenster für Race Conditions eben wieder kleiner.

Wäre der Fehler rein in der CPU, dann wären JPEGs nicht verzerrt, sondern der Decoder würde abstürzen. Verzerrungen deuten darauf hin, dass sich irgendwelche Cachezeilen an nicht-code-kritischen Stellen überlagern (also reine Daten).

Aber das ist natürlich pure Spekulation.

Ohne Not (z.B. bestimmte Anwendungen, die nicht mehr laufen) würde ich zu MOS oder OS4 raten - aufgrund des wegfallenden ständigen Cache-Flushings mit Sicherheit nicht langsamer.

akl Nutzer

07.01.2008, 13:59 Uhr

[ - Direktlink - ]

Thema: YAM 2.5 Installation
Brett: Amiga, AmigaOS 4

@AmigaHarry:

>Der PPC-status war oft, trotz laufender Anwendung (AMP) im Powersafe
>Mode mit zeitweilig unter 150Mhz! Sobald weniger als 233 MHz angezeigt
>wurde, traten diese unerklärlichen Probleme auf.

Sobald sich der Takt der CPU ändert, können sich auch Race Conditions stärker/weniger bemerkbar machen - in diese Kategorie fallen meiner Meinung nach bei PUP/WOS auch nicht korrekt abgefangene Cache-Seiteneffekte innerhalb von Anwendungen/Libraries/Datatypes.

Was aber das Handling der Alpha-Transparenz bei Grafiken angeht ist primär die Version des pic-dt entscheidend - eine der V45-Versionen kann damit nicht umgehen, auch wenn der verwendete png-dt das kann.

akl Nutzer

05.01.2008, 20:42 Uhr

[ - Direktlink - ]

Thema: WLAN Bridge ?
Brett: MorphOS

@p-OS:

>Den Thread hab ich nicht gekannt. [...] Eine Suche nach 'WLAN Bridge'
>hat also nicht funktioniert. Ich hätte 'WLAN UND Bridge' eingeben
>müssen.

Ich meinte auch nicht, dass Du ihn hättest kennen müssen - ich war nur so freundlich, den Link einzufügen ;-) bzw. tippfaul 8-)

[ Dieser Beitrag wurde von akl am 05.01.2008 um 20:43 Uhr geändert. ]

akl Nutzer

05.01.2008, 20:40 Uhr

[ - Direktlink - ]

Thema: WLAN Bridge ?
Brett: MorphOS

@Wishmaster:

>Funk ist mist.
>Da hast du andauernd Aussetzer.
>Das Einzige, dass es bringt, sind Gigabit-Ethernetkäbel.

Mag sein. Die Frage war allerdings:

>>Jetzt stellt sich die Frage, wie ich meinen Pegasos WLAN-fähig machen kann ?

akl Nutzer

05.01.2008, 20:39 Uhr

[ - Direktlink - ]

Thema: Sharing von PPC-Amigas übers Web
Brett: Programmierung

@p-OS:
Auf Crosscompiler würde ich mich nicht unbedingt verlassen wollen (z.B. MOS SDK).

akl Nutzer

03.01.2008, 12:01 Uhr

[ - Direktlink - ]

Thema: HTML: png
Brett: Programmierung

@Jinx:
Im Endeffekt erhält man durch die Mehrfarben-Teiltransparenz bei 8 Bit die Möglichkeit, einen Alphakanal auch bei 8 Bit-Grafiken anzufügen.

Bei exakt 0% oder 100% Transparenz per Farbe ist es auch kein Problem, das darzustellen.

Die Teiltransparenz bei 8 Bit ist jedoch teilweise nicht trivial zu rendern, wenn die Rendering-Engine einerseits display- und plattformunabhängig und gleichzeitig schnell sein soll - im Endeffekt kommt man letztlich nicht umhin, intern alles in 32 Bit zu rendern.

Irgendwo hakt es dabei oft bei den bekannten Browsern, insbesondere in Versionen vor 2006/2007 - Mozilla 2.x und IE7 können aber eigentlich alles korrekt darstellen. Zumindest, wenn man einen 24/32 Bit-Grafikmodus verwendet. Aber was ist mit Opera, den diversen Linux-Browsern und Camino?

Was alles schiefgehen kann, kann man hier gut testen:
http://entropymine.com/jason/testbed/pngtrans/
http://www.schaik.com/pngsuite/pngsuite_trn_png.html
http://www.youmustbejoking.demon.co.uk/pngtest/test/
http://www.w3.org/Graphics/PNG/inline-alpha-table.html

siehe auch:
http://www.schaik.com/pngsuite/

Fazit:
Man ist bis auf Weiteres gut beraten, bei 8 Bit nur eine Farbe volltransparent zu setzen oder lieber gleich 24 Bit mit Alphakanal (32 bit) zu verwenden, wenn mehrere Farben (teil-)transparent sein sollen.

akl Nutzer

30.12.2007, 20:59 Uhr

[ - Direktlink - ]

Thema: PPC Diagnoseprogramm
Brett: Amiga, AmigaOS 4

@MaikG:

Soweit ich das beurteilen kann, sollte man drei Dinge in Betracht ziehen:

- Hitze
- irreguläres Verhalten der RAMs (60/70ns)
- Race Conditions (*)

(*) nicht bei allen Programmen, aber aufgrund der Cache-Problematik dürfte nicht wenig formal kaputter Code existieren, der unter WarpUp/PowerUp deshalb sporadisch Probleme macht und unter OS4/MOS theoretisch einwandfrei läuft; da die jeweiligen APIs und Compiler sowieso aber sehr - sagen wir mal - schlicht sind könnte sich das am Ende die Waage halten

akl Nutzer

30.12.2007, 20:55 Uhr

[ - Direktlink - ]

Thema: PPC Diagnoseprogramm
Brett: Amiga, AmigaOS 4

@mistral:
Da PMPro die SV-Library verwendet, würde ich vorschlagen, die neuste verfügbare Version davon auszuprobieren - die findet sich hier:
http://aminet.net/search?query=sviv

Die Library befindet sich im SvIV-1 bis SvIV-8 und PPC-Module befinden sich in SvIV-PPC Archiv.

Heute habe ich außerdem noch SvIVFix930b.lha (30.12.07) hochgeladen, was sich jedoch eher anderen Problemen widmet.

Es ist auch richtig, dass ohne ppclibemu die PPC-Module unter WarpOS nicht richtig funktionieren - und das wurde mit v0.9 vermutlich auch von niemandem mehr getestet (ich erinnere mich an diverse Versionen im Bereich vor 0.8 die nicht gingen, aber einige spätere waren sehr stabil). Die letzte Version findet sich hier:
http://devnull.owl.de/~frank/ppcemu_e.html

Falls alles nichts hilft, würde ich vorschlagen, die PPC-Module zu deinstallieren (Verzeichnis LIBS:svppc löschen).

Der JIT von OS4 und MOS ist so gut, dass die alten PowerUp/WarpUp-Programme aufgrund ihrer Architektur keinen großen Vorteil mehr bringen dürften.

akl Nutzer

26.12.2007, 20:52 Uhr

[ - Direktlink - ]

Thema: DosBase ?
Brett: Programmierung

@Honitos:
Man findet die DOSBase als struct DosLibrary in dos/dosextens.h - ab V37 kann man eigentlich alles, was man von dort benötigt auch über AttemptLockDosList() erhalten. Unter V33 war das noch etwas anders.

akl Nutzer

25.12.2007, 14:15 Uhr

[ - Direktlink - ]

Thema: Erstellen einer CD-Bootdiskette mit OS3.1 klappt nicht
Brett: Amiga, AmigaOS 4

Was ist denn der Inhalt der Diskette und der startup-sequence?

akl Nutzer

25.12.2007, 12:18 Uhr

[ - Direktlink - ]

Thema: Infos an Commidities senden
Brett: Programmierung

@Ralf27:
Am sinnvollsten wäre ein ARexx-Port:

1. Über den können Daten übergeben werden, wenn er existiert.
2. Wenn der ARexx-Port noch nicht existiert, dann ist die neu gestartete Instanz auch die erste.

Ansonsten ginge im Prinzip auch ein eigener "Custom"-Port bzw. eine öffentliche Semaphore mit etwas "Zubehör".

akl Nutzer

18.12.2007, 09:10 Uhr

[ - Direktlink - ]

Thema: warpup oder phase5?
Brett: Amiga, AmigaOS 4

@Barthel:
MorphOS oder OS4.

akl Nutzer

12.12.2007, 23:01 Uhr

[ - Direktlink - ]

Thema: Picture datatype unter MOS
Brett: Programmierung

@Der_Wanderer:
Im Aminet gibt's dazu in Kürze die "dtimage.library", die alles per Datatypes lädt und als 32 Bit RGBA Puffer zurückgibt (inkl. Konvertierung von palettenbasierter Transparenz, z.B. bei GIF).

akl Nutzer

10.12.2007, 14:58 Uhr

[ - Direktlink - ]

Thema: MovieShop auf MOS PUP
Brett: MorphOS

@LordRover:
Ist eigentlich eine "svmovie.library"-Unterstützung bei MovieShop dabei?
Wird jemals versucht, diese zu öffnen (SnoopDOS)?

akl Nutzer

04.12.2007, 23:24 Uhr

[ - Direktlink - ]

Thema: maximale ide plattengroesse am amiga
Brett: Amiga, AmigaOS 4

KiB und MiB wurden erst sehr spät erfunden, weil man den den Mißbrauch der SI-Präfixe für Binärpotenzen eindämmen wollte. Geregelt wird das in der Norm IEC 60027-2:2000.

Viele Festplattenhersteller nutzen weiterhin "MB", worunter gemeinhin 2^20 verstanden wird (und nicht 10^6). Dabei suggeriert der größere Faktor eine größere Kapazität (ein Schelm, wer darunter Absicht vermutet). Das galt schon vor Einführung der neuen Norm, und gilt auch weiterhin.

Wie man überall sieht, verwendet außer der politisch korrekten Wikipedia und dem wissenschaftlichen Bereich alle Welt weiterhin kB und MB anstelle von KiB und MiB. Vielleicht weil "Gibibyte" irgendwie albern klingt. Vielleicht, weil sich per Federstrich alte Gewohnheiten eben nicht so einfach ändern lassen (siehe Rechtschreibreform).

Jedenfalls ist es ein Thema, über das man als Wikipedia-Leser wunderbar andere Leute belehren kann ;-) SCNR.

akl Nutzer

01.12.2007, 11:35 Uhr

[ - Direktlink - ]

Thema: OS4
Brett: Amiga, AmigaOS 4

@Michael_Mann:
Du vergleichst doch sicher auch nicht den Liebhaberpreis eines aufgemöbelten 1950er VW-Käfer mit dem eines Beetle von 2007.

akl Nutzer

28.11.2007, 20:22 Uhr

[ - Direktlink - ]

Thema: OpenFont - kein alternativ Font
Brett: Programmierung

@MaikG:
Wenn Du OpenFont() nimmst - und nicht OpenDiskFont() - dann wird die diskfont.library auch nichts laden. Wenn Du nicht willst, dass OpenFont() einen Font zurückgibt, der bereits per OpenDiskFont() geladen wurde, dann würde ich FPF_ROMFONT und FPF_DESIGNED als "Requirement" setzen.

Außerdem kannst Du mit AvailFonts() und AFF_MEMORY als Flag selbst überprüfen, welche Fonts schon im Speicher sind und passgenau die via OpenFont() anfordern, die nicht mehr geladen werden müssen.

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

akl Nutzer

28.11.2007, 11:05 Uhr

[ - Direktlink - ]

Thema: WLAN Bridge ?
Brett: MorphOS

@p-OS:

Hatten wir eigentlich HIER schon einmal in ähnlicher Form durchdiskutiert und gelöst - ein FAQ auf einer der Pegasos-Seiten wäre sicher nicht schlecht:
http://www.amiga-news.de/forum/thread.php?id=26675&BoardID=15

akl Nutzer

27.11.2007, 12:28 Uhr

[ - Direktlink - ]

Thema: Picture datatype unter MOS
Brett: Programmierung

@Holger:

>Müsste dann nicht so etwas wie <unbekannte Methode> zurückgegeben
>werden?

Nein, weil man den pic-dt V43 unter OS 3.1 (bis ca. 3.5 oder wann immer das Defaultverhalten eigenmächtig umdefiniert wurde) jeweils vorher erst explizit in "V43-Modus" umschaltet.

akl Nutzer

27.11.2007, 12:26 Uhr

[ - Direktlink - ]

Thema: Picture datatype unter MOS
Brett: Programmierung

@Der_Wanderer:
Man kann unter V43 für 8 Bit LUT anfordern, für 24-32 Bit entweder RGB oder ARGB/RGBA. Das Verhalten des picture.datatype unter MOS ist korrekt, denn die Applikation sollte natürlich vor dem Lesen die Tiefe der Bitmap im Bmhd überprüfen, und die ist in Deinem Beispiel nunmal <= 8. Meines Wissens unterstützt CyberGraphX für Screens auch nicht das Lesen von 24/32-Bit-Daten aus 8 Bit-Bitmaps und der picture.datatype ist einfach analog konstruiert. Technisch gesehen macht das auch Sinn, denn bei 24/32 Bit wird einfach die Bitmap ausgelesen (ggf. mit Byte-Offset/Reordering), wohingegen bei einer 8->24 Bit-Konvertierung der Inhalt des LUT (entweder des originalen oder des durch Remapping entstandenen) mit der Bitmap (entweder der originalen oder der durch Remapping modifizierten) verknüpft werden muss. Alpha ist immer nicht vorhanden. Bei Remapping wäre des Ergebnis suboptimal, ohne Remapping stellt sich die Frage, warum man die (ziemliche triviale) Konvertierung nicht selbst vornimmt...

akl Nutzer

26.11.2007, 09:06 Uhr

[ - Direktlink - ]

Thema: A-2091 Setup usw.
Brett: Amiga, AmigaOS 4

@HONI:
"Völlig wertlos" ist es dann, wenn man sich nicht ernsthaft bemüht, eine Lösung zu finden (GuruROM gebraucht kaufen, Autor kontaktieren, etc.)

Was die zweite Bemerkung angeht, kann ich nur wiederholen:
"Ansonsten ist nicht nur die Geschwindigkeit schlecht, sondern auch die Daten sind gefährdet."

Aber wenn Euch Eure Daten nichts wert sind...

akl Nutzer

23.11.2007, 14:22 Uhr

[ - Direktlink - ]

Thema: A-2091 Setup usw.
Brett: Amiga, AmigaOS 4

@Roter_Flieger:
Ohne GuruROM ist der A2091 nicht wirklich brauchbar. Das GuruROM - als Ersatz des A2091-ROMs - war kommerziell, ist aber inzwischen vom Autor zum Download (Rom-Image) freigegeben:
http://babel.de/amiga.html#omni

Ansonsten ist nicht nur die Geschwindigkeit schlecht, sondern auch die Daten sind gefährdet.

akl Nutzer

09.11.2007, 09:58 Uhr

[ - Direktlink - ]

Thema: Noch ne VNC Frage
Brett: Amiga, AmigaOS 4

@Lemmink:

640x480 in 8 Bit oder in 24 Bit? In 24 Bit sind das ca. 900 kb pro Bildschirminhalt. Du kannst Dir ausrechnen, wie stark das Deine 10 MBit (1,25 MB)-Verbindung belastet.

Falls AmiVNC Komprimierung unterstützt, bringt die schnellere CPU etwas (durch die Kompression wird weniger Bandbreite benötigt, und die CPU leistet das schneller), ansonsten eher nicht.

akl Nutzer

30.10.2007, 17:34 Uhr

[ - Direktlink - ]

Thema: TLSFMem und PAB
Brett: Amiga, AmigaOS 4

@Cego:

Prost Mahlzeit.

Wie inkonsequent, jetzt antworte ich doch zweimal. Nunja, egal.

Inkonsequenterweise schreibe ich - genau wie platon42 - auch Software für eine "Community", die das nicht unbedingt immer zu schätzen weiss.

Das ist aber genau der Punkt. Würde ich das nur für die "Community" machen, hätte ich schon vor 7 Jahren aufgehört...

Kommentare wie Deiner können das folglich nicht beschleunigen ;-)

Und genau die gleiche Einstellung kann ich anderen Entwicklern ebenfalls nur empfehlen.

akl Nutzer

30.10.2007, 17:23 Uhr

[ - Direktlink - ]

Thema: TLSFMem und PAB
Brett: Amiga, AmigaOS 4

Kompromissvorschlag:

- .readme und .lha korrigieren (Chris)
- Newsmeldung wieder online stellen (Senex)
- Kommentarbereich von Anfang an sperren (Senex)
- persönliches Gespräch suchen (PAB)

Ansonsten ist eigentlich schon alles gesagt worden.

Leider ist konstruktive Kritik in AN-Kommentaren ohnehin die Ausnahme, und wenn das Ganze noch durch persönliche Streitigkeiten/Antipathien überlagert wird, ist die spätere Eskalation vorprogrammiert.

Klar, das hier ist "Öffentlichkeit".
Aber wer will das wirklich alles nachlesen und nachvollziehen?

Von einer "Community" kann man wirklich nicht mehr sprechen, aber das hat unterschiedliche Gründe, und die meisten davon haben mit diversen Fehden zwischen OS4 und MOS zu tun - und hier schliesst sich der Kreis.

Erster und letzter Beitrag von mir.

akl Nutzer

21.10.2007, 15:40 Uhr

[ - Direktlink - ]

Thema: TIFF-Dateien
Brett: Amiga, AmigaOS 4

Derzeit liegen mir keine TIFF-Dateien mehr vor, die akTIFF v45.79 (bzw. SView5 >v2.33) nicht anzeigen könnte - ich bin mir aber sicher, dass es noch eine Menge davon gibt...

Falls jemand über entsprechende Dateien verfügt, bitte ich um Hinweise, von welchen Programmen sie erzeugt werden und ggf. Beispieldateien (einzige Ausnahme: "old-style TIFF-JPEG").

Bitte nur per eMail. Danke!

http://aminet.net/util/dtype/akTIFF-dt.readme

akl Nutzer

19.09.2007, 16:21 Uhr

[ - Direktlink - ]

Thema: Samba 2.0.7 und Vista
Brett: Amiga, AmigaOS 4

@thomas:
Entsprechende Aussagen konnte ich nicht finden. Siehe auch diese Seite hier (exemplarisch):
http://www.linux-watch.com/news/NS4434907782.html

Der einzige Unterschied ist, dass unter Vista Home Premium kein secpol.msc existiert, und man daher lediglich über die Registry die Policy ändern kann - was gleichwertig sein *sollte* ...

[ Dieser Beitrag wurde von akl am 19.09.2007 um 16:22 Uhr geändert. ]

akl Nutzer

18.09.2007, 11:12 Uhr

[ - Direktlink - ]

Thema: Commodities.library - Übersicht input description strings ?
Brett: Programmierung

@p-OS:

>Wenn die echt schon zu CDTV-Zeiten eingeführt wurden, sollten die doch
>irgendwo dokumentiert sein ?

Wie gesagt, einige davon entsprechen EXAKT den Definitionen unter Windows - einige andere sind vielleicht älter. Jedenfalls wurden die neuen offensichtlich unter MorphOS für den Zweck eingeführt, aktuelle Keyboards etc. zu unterstützen.

Frage: Macht OS4 etwas eigenes, oder hat man sich via AROS koordiniert?

Dass die Shortcuts nirgendwo definiert sind, ist übrigens auch ärgerlich - jede Applikation (ob 68k oder nicht) die als Commodity läuft, muss nämlich auch eine Default-Hotkey-Kombination festlegen können.

Erste 1 2 3 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