Zitat:

---

Primax:
Habs mehrmals probiert und keine Idee mehr, warum es nicht klappt

---

Zitat:

---

Kaesebroetchen:
Ich habe immer den g++ Aufgerufen.

---

Zitat:

---

Ich vermute mal dass das Installer-Script was bei dem Compiler dabei war, das ganze irgenwie nicht richtig installiert hat.

---

Zitat:

---

Einige Standard-Header wie CSTRING oder FSTREAM kennt der g++ gar nicht.

---

Zitat:

---

Und eigentlich müsste der Amiga-G++ doch alles was der Linus-G++ fehlerfrei compiliert, genauso fehlerfrei compilieren (So lange es keine Betriebssystemspezifischen Sachen sind) oder ?

---

Zitat:

---

Vielleicht sollte ich das ganze komplett neu installieren (Wie bei der Windows-Problemlösung FORMAT C: )

---

Zitat:

---

snorry:
Das mit des schlechteren Qualität ist ein subjektives Gefühl, wenn ich Bilder über Multiview anzeigen lasse, bzw. die Geschwindigkeit lässt zu wünschen übrig.

---

Zitat:

---

snorry:
Oder halt Multiview mit den Datatyes von OS 3.9 da habe ich nur immer das Gefühl das die Qualität nicht so doll ist, und der Chip-RAM geht ziemlich ihn die Knie, trotz Graka.

---

Zitat:

---

alexw:

Zitat:

---

gni:
Dann sind auch Deine Includes zu alt...

---

Können sie zu alt sein, wenn das Projekt ohne Fehler kompiliert?

---

Zitat:

---

Mad_Dog:
Das Assign gg: ist physikalisch GNU:gg/

---

Zitat:

---

gcc bzw. g++ liegen in BIN:, das ist wiederum ein Assign (add path)
GNU:gg/bin/

---

Zitat:

---

Sind das jetzt nur die Frontends, oder ist das der gesamte Compiler?

---

Zitat:

---

alexw:
Die ...A()-Funktionen habe ich auch schon probiert. Geht nicht.

---

Zitat:

---

Mad_Dog:

Zitat:

---

gni:
Kann ich beim Cross-Compiler auch nicht sehen. Vieleicht verhält sich das nativ anders.

---

Die Executables des Compilers (gcc, g++, etc.) scheinen hier auf einer anderen Platform für m68k amigaos compiliert worden zu sein.

---

Zitat:

---

Zitat:

---

Bei crt0.o fehlt der Pfad. Wie sieht Deine GCC Installation aus? Ist gg: bei Dir ein Multi-Assign? Wo genau liegt bei Dir crt0.o?
Muß ich am Amiga g++ noch mal prüfen.

---

Das sieht folgendermaßen aus: Eine Partition GNU: , darin ein Verzeichnis gg/ , auf das dann ein Assign gesetzt ist.

---

Zitat:

---

Der vollständige Pfad von crt0.o ist bei mir GNU:gg/lib/crt0.o .
Das stammt allerdings noch von der älteren gcc Installation.

---

Zitat:

---

Original von Mad_Dog:
<...>/cc1plus -v -iprefix ../lib/gcc-lib/m68k-amigaos/3.2.2

---

Zitat:

---

ignoring nonexistent directory <...>

---

Zitat:

---

.../gg/lib/gcc-lib/m68k-amigaos/3.2.2/collect2 -o Hello_World crt0.o

---

Zitat:

---

OMad_Dog:

code:

---

/*  Makro zur Erzeugung einer Zufallszahl
 *  im Bereich min..max
 */
#define random(min,max) ((rand() % int((max+1.0)-min))+min)

---

---

Zitat:

---

Zitat:

---

bei scsi-3 (uw-scsi) liegt der fall etwas anders. hier sind von haus aus 16 geräte am bus möglich (15 nutzgeräte + hostadapter), mit dieser

---

Stimmt leider nicht ganz. UltraWide hat zwar das zusaetzliche
Adresssbit von FastWide geerbt, unterstuetzt aber laut *Standard*
wegen der Busfrequenz offiziell nur max. 8 Geraete (inkl SCSI-Host).

---

Zitat:

---

Sprocki:
Viele Programme, z.B. YAM, laufen bei mir auf separaten (MUI- )Screens. Wenn ich in YAM z.B. eine Anlage öffne, wird auf der WB ein Fenster von Multiview, Apdf etc. geöffnet. Wenn ich dieses Fenster schließe, gelangt der Fokus zwar wieder an das Mailfenster von YAM zurück, es wird aber nicht auf den aktiven Bildschirm zurück geschaltet, sondern die WB bleibt vorn. Ich möchte, daß entweder der Screen wieder nach vorn geholt wird oder - noch besser - daß die entsprechenden Fenster auf demselben Screen geöffnet werden. Wie kann ich das erreichen?

---

Zitat:

---

OMad_Dog:
Habe soeben gcc 3.2.2 über meine alte gcc Installation drüberinstalliert, d.h. auch gcc und g++ über die alten files in BIN: kopiert.

---

Zitat:

---

Jetzt meldet der Compiler, daß ld das file "crt0.o" nicht finden kann.

---

Zitat:

---

Hat jemand von Euch ähnliche Erfahrungen gemacht und ne Problemlösung parat?

---

Zitat:

---

DOM:
Weil wir uns auf ein PC-Programm einigen mußten.

---

Zitat:

---

Der_Gote:
habe da ein Problem: habe einen ZX81 (!!) - Emulator, der auf meinem A4000 viel zu schnell läuft. Wie kann ich den Task auf nur 25% laufen lassen? Gibt es da ein nettes Tool (welches idealerweise unter OS3.9 läuft ;-) ) ....

---

Zitat:

---

R-TEAM:
Mußte aber mal ziemlich feine grafiken zu einem freund mitnehmen ..
und der konnte kein png lesen

---

Zitat:

---

nur haben mir alle probierten prg auch bei 100% qualität
die feinen strukturen verblurt ... nur der AdPro JPG saver hat bei Max
(ist dort 1000) die feinste auflösung gezeigt .. zwar immer noch ein
bissl blur aber minnimal .. weit weniger als andere saver (JPEG-Box/jpegtool/TV-Paint/Photogenics5/Xi-Paint/pnm-jpg-saver).

---

Zitat:

---

Dann transformiere das JPEG nachträglich mit jpegtran(1). Das ist Bestandteil der libjpeg.
Dann würde es doch wieder umgerechnet .. oder ????? Hab da jetzt keine ahnung...

---

Nein Aus der Man-Page:

jpegtran works by rearranging the compressed data (DCT coefficients),
without ever fully decoding the image. Therefore, its transformations
are lossless: there is no image degradation at all

Zusammengefaßt: da steht das die Tranformationen von jpegtran verlustfrei sind.

Zitat:

---

R-TEAM:
Und speichert die JPEG files in einer qualität die kein anderes von mir getestetes prg (Amiga und PC) erreicht.(natürlich nur bei Max. qualität)

---

Zitat:

---

Leider kann es (wegen dem alter) nur normale JPEG .. nix progressiv

---

Zitat:

---

Falcon:
Und was den Kopierschutz angeht... Ok, da mag ich 'n 6'er im Lotto gehabt haben, aber mein Pioneer Slotin CD-Rom liest alles

---

Zitat:

---

Bingo:

Zitat:

---

Falcon:
Wenn ich von CD aufnehmen will, dann kopiere ich die Audiofiles via SCSI direkt auf die Platte.

---

welches CDFile System nimmst Du dafür ?

---

Zitat:

---

Bluebird:
wer ne merlin im z2 modus pica 2 /2+ oder picollo mit nur 2 mb hat wird wissen das bilder groesser 1280x1024 nicht mehr dargestellt werden koennen!

---

Zitat:

---

Palgucker:
quote:
Das unterstützt wohl keine DTs?
Doch, macht es. Aber nicht bei JPEG's.

---

Zitat:

---

quote:
Von welchem Datatype sprichts Du? Dem vom System?
Speziell meine ich den jpeg.datatype (V 44.4 vom 26.09.00), aber ein
paar andere Versionen zeigten die selben Symtome. [dithern]

---

Zitat:

---

quote:
Das ist nur ein Gimmick, den man nicht unbedingt braucht.
Auf einem AGA Rechner kann man da aber ganz anderer Meinung sein!

---

Zitat:

---

Multiview hält durchaus während der Anzeigedauer "Kontakt" zu den 24 Bit Orginaldaten.

---

Üblicherweise wird die Source-Bitmap nach dem Konvertieren der Daten ins Ausgabeformat freigegeben. Ich glaube kaum, das Multiview das anders macht. Wenn man beim Speichern eine HAM-Bitmap erhält, dann sind das wohl keine Originaldaten mehr

Zitat:

---

Jinx:
bei den ppc-karten kann man doch im bootmenu was mit cd-roms einstellen. kann man damit was anfangen?

---

AFAIK, ja. Ausprobiert habe ich es aber noch nie, da ich noch nie Bedarf sah

Zitat:

---

Askane:
Ich habe hier eine Version 2.3 mit 30808 byte und die neue Version 1.3
mit 23604 byte.

---

Zitat:

---

Palgucker:
quote:
Dieser jpeg.codec ist _obsolete_,da er keine progessiven JPEGs
dekodieren kann.
Nun ja, dieser Codec ist aber immer noch nützlich, wenn man Fastview
das anzeigen von Jpeg's "beibringen" will.

---

Zitat:

---

Im übrigen kann ich nicht vor allem, was obsolete ist oder erscheint,
einen grossen Bogen machen. Dann könnte ich wohl gleich den ganzen
Rechner vor die Tür stellen.;)

---

Zitat:

---

quote:
Vermutlich ein Bug im DT-Support von Visage (welche Version von Visage, welcher Datatype?
Hab mir mal die Versionen angeschaut. Und, oh Graus, ich hab die ganze
Zeit mit der alten Version (39.5 vom 21.01.96) getestet.

---

Zitat:

---

Mit der neuen Version (39.22 vom 31.10.98) klappt es mit dem jpeg.datatype - aber auch nur gedithert. Vielleicht ist auch der Datatype einfach nicht hamfähig.

---

Zitat:

---

Hab mir nun mal probeweise den AKjfif.datatype installiert und gestaunt. Zum 1., weil er jetzt Freeware ist, und zum 2., weil er wirklich genau so schnell ist, wie die codecs.

---

Zitat:

---

Und hamfähig ist er natürlich auch.

---

Zitat:

---

Kann mich noch erinnern, das ich ihn irgendwann mal von der Platte
verbannt hatte, da irgend eine Version mich mit Nervrequester quälen
wollte.

---

Zitat:

---

Im Fall der JPEG's braucht man dann nur ein kleines Script, was in
einem kurzen Vorabcheck erstmal testet, um was für ein JPEG es sich
handelt (sequentiell,proggressive oder lossless), und die
entsprechenden Programme startet.

---

Zitat:

---

quote:
Noe, es ist ein aus HAM erzeugtes 24bit ILBM.
Hast Du das unter AGA Bedingungen rausgefunden? Aber danke für den
Hinweis, denn das hätte ich wohl nicht so einfach rausbekommen.

---

Zitat:

---

Palgucker:
Jetzt hast Du mich vielleicht erwischt, aber ich kann einfach nicht
das Gegenteil beweisen. Visage arbeitet einfach nicht mit meinem
jpeg.datatype zusammen. Während Multiview und VT über diesen Datatype
mir ein 320x256 grosses JPEG nach einigen Sekunden als FS-gedithertes
Bild anzeigen, bricht Visage mit DT-Option nach ca. 5 sec mit der
Meldung "nicht genug Speicher vorhanden" ab. Obwohl noch genügend frei
ist.

---

Zitat:

---

Auch wenn ich Multiview auf einen Ham-Schirm umlenke, dithert der
datatype fleißig weiter. Speichere ich dieses Bild ab, ist es wieder
ein "normales", soll heißen ungedithertes 24 Bit ILBM.

---

Zitat:

---

Mario_II:
Visage funzt bei mir (OS 3.9) nicht. Fehlermeldung beim Aufrufen des Programms: "Fehler beim Parsen der Agumente: Pufferüberlauf" Auf meiner 2. Bootpartition (OS 3.1) läuft Visage ohne Probleme. Was sagt die Fehlermeldung aus?

---

Zitat:

---

Palgucker:
Wenn Fastview JPEG's anzeigen soll benötigst Du die Tower.library
und, wenn ich nicht irre, die codec.class in Classes/ sowie
picture- und jpeg.codec in Classes/Codecs/.

---