amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 -3- 4 5 6 7 8 >> Letzte Ergebnisse der Suche: 2156 Treffer (30 pro Seite)
whose   Nutzer

06.10.2010, 21:30 Uhr

[ - Direktlink - ]
Thema: AOS4: 320er Screenmodes mit Radeon 9200
Brett: Amiga, AmigaOS 4

@Reth:

Äh... liest Du auch, was man schreibt? Welche "Hertzzahl" verträgt Dein Monitor denn so? Welche Vertikalfrequenz hast Du da eingetragen bei "Hz"? Wenn diese Zahl niedriger als die 100Hz der Screenmodes ist, ist es kein Wunder, daß die Modi nicht erscheinen, denn dann filtert P96 OS4 diese Modi aus (weil der Monitor das laut Deinen Angaben im Screenmode Prefs gar nicht schafft).

Probiers doch auch mal spaßeshalber erst einmal mit 75Hz für die Screenmodes, das schaffen die meisten 19-Zöller locker.

Und es sollte mich wundern, wenn auf dem 4000er die PAL-Modi auch mit den LoRes-Auflösungen im Screenmode Prefs erscheinen. Das taten sie nämlich noch nie und das tun sie bei mir auch nicht ;)
--
---

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

05.10.2010, 23:32 Uhr

[ - Direktlink - ]
Thema: AOS4: 320er Screenmodes mit Radeon 9200
Brett: Amiga, AmigaOS 4

@ZeroG:

Ich schätze, das weiß er bereits alles.

Hilfreicher wäre es gewesen, ihm den möglichen Fehler etwas deutlicher aufzuzeigen.

@Reth:

Gib im Screenmode Prefs mal die exakten Daten Deines Monitors ein. Wahrscheinlich hast Du vergessen die Vertikalfrequenz anzupassen und dann erscheinen "unmögliche" Modi (z.B. 100Hz Vertikalfrequenz bei einem Monitor-Maximum von 75Hz) nicht im Auswahlfeld. Hier taucht ein 320er Modus auf, nachdem ich ihn entsprechend den Monitor-Daten definiert hatte.

P.S.: Hatte ich vergessen: Es ist gut möglich, daß der Modus dann etwas "seltsam" dargestellt wird, je nach Radeon, die bei Dir verbaut ist. Modernere Radeons unterstützen 320er Auflösungen nicht mehr und faken dementsprechend in einem Modus mit 640er Auflösung.

@Holger:

Ja, der erscheint auch in Screenmode-Prefs. Der Screenmode-Filter ist bei den OS4-Prefs aus irgendeinem Grund nicht aktiv bzw. nur für die Fake-native-Modi wirksam. Bei den Fake-PAL-Modi erscheinen die LoRes-Auflösungen z.B. nicht.
--
---

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


[ Dieser Beitrag wurde von whose am 05.10.2010 um 23:38 Uhr geändert. ]
 
whose   Nutzer

26.09.2010, 22:05 Uhr

[ - Direktlink - ]
Thema: YAM 2.6p1
Brett: Amiga, AmigaOS 4

@tploetz:

Ah, dann hat sich meine Vermutung nicht bestätigt. War dann wohl die 68k-Version der codesets.library, die da bei Dir installiert worden ist. Nicht nett vom Install-Script...

Und ich hab wieder was gelernt: Die Glue-Code-Geschichte ist wohl für den umgekehrten Fall gedacht, PPC-Programm öffnet 68k-Library... verwirrend :D
--
---

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

26.09.2010, 21:56 Uhr

[ - Direktlink - ]
Thema: YAM 2.6p1
Brett: Amiga, AmigaOS 4

@tploetz:

Öhm... Du hast nicht zufällig die OS3-Version von YAM installiert?

Das Snoopy-Log zeigt, daß da versucht wird, den sog. "Glue-Code" für die Codesets-Library zu öffnen ("codesets.l.main"), der bei Dir vermutlich nicht vorhanden ist, da Du sehr wahrscheinlich die native OS4-codesets.library ohne den sog. "Glue-Code" installiert hast. Normal wird der sog. "Glue-Code" nur dann geladen, wenn ein 68k-Programm eine PPC-Library zu öffnen versucht.

Versuchs also nochmal mit dem Download und der Installation und vergewissere Dich, daß Du tatsächlich die OS4-Version beim Download erwischst.

Eventuell ein Mal etwas näher an den Monitor gehen, falls der Link-Text schwer zu lesen ist...
--
---

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

25.09.2010, 18:56 Uhr

[ - Direktlink - ]
Thema: Amplifier spielt mp3 zu leise ab
Brett: Amiga, AmigaOS 4

Zitat:
Original von tploetz:
@whose:
PlayList kann ich von Amplifier laden mit dem rechten Knopf unten mit Replace.


Ja, genau. Also alles fein und es steht der Verwendung von AmigaAMP eigentlich nichts mehr im Weg.

Zitat:
Die Knöpfe bei AmigaMP sind sehr klein, lassen sich schlecht erkennen.

Ist im Grunde das gleiche "Skin" wie bei Amplifier. Falls bei Dir bei Amplifier die Knöpfe "besser erkennbar" sind, so verwendest Du ein anderes Skin. Eigentlich sollten die Skins von Amplifier auch mit AmigaAMP verwendbar sein, aber dazu kann ich nichts sagen.

Hier bei mir ists mit der Lesbarkeit ganz gut. Ich bin allerdings von 17" TFT auf 21" Röhre (zurück-)umgestiegen, wird wohl daran liegen :D
--
---

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

25.09.2010, 17:49 Uhr

[ - Direktlink - ]
Thema: Amplifier spielt mp3 zu leise ab
Brett: Amiga, AmigaOS 4

@Maja:

George Lucas? :D

@tploetz:

Ich hab noch was vergessen:

Soweit ich weiß, kann AmigaAMP sogar WinAMP-Playlists laden. Playlists laden geht (wer hätte es gedacht) mit Klick auf "Load List". Wenn ich mich nicht sehr irre, sind die Amplifier-Playlists ebenfalls im WinAMP-Format und somit auch von AmigaAMP verwertbar.

Es spricht also nichts gegen AmigaAMP, der ja bei Dir auch die MP3 aus dem Internet in der "richtigen" Lautstärke wiedergibt.
--
---

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

25.09.2010, 15:27 Uhr

[ - Direktlink - ]
Thema: Amplifier spielt mp3 zu leise ab
Brett: Amiga, AmigaOS 4

@tploetz:

Ich fürchte, mit diesem Unterschied wirst Du Dich abfinden müssen. Was spricht eigentlich dagegen, AmigaAMP (welcher auch noch aktiv weiterentwickelt wird) als Standard-MP3-Player einzusetzen? Nur Deine Ahnungslosigkeit, was Playlisten angeht?

Also, schau mal in die AmigaAMP-Prefs (wahlweise das Piktogramm oder im Menü als "Config..."), dort unter "Visual", und dann wirst Du einen Punkt namens "Show Playlist" finden. Den hats garantiert nicht ohne Grund. Mach da mal ein Häkchen hin und schau, was passiert.

Wahlweise kannst Du aber auch im Player-Fenster den Knopf namens "Pl" betätigen, das hat den gleichen Effekt.

Ach ja, was die Bedienung des Playlist-Fensters betrifft: Die wird Dir etwas ungewohnt vorkommen, ist jedoch sehr simpel: Auf dem jeweiligen Knopf einfach die linke Maustaste gedrückt halten, dann bekommt man noch mehr Auswahlmöglichkeiten zu sehen. "+" und "-" sollten im jeweiligen Kontext eigentlich selbsterklärend sein. "File" ist für Dateien, "Dir" für ganze Verzeichnisse und "URL" für, der Name sagts schon, Internet-Streams zuständig.

Also "+ File" anklicken, eine MP3-Datei auf Deiner Festplatte auswählen, "Ok" klicken und *schwups* ist die Datei in der Playlist.

Die man selbstverfreilich auch speichern kann, wenn man das will. Mit dem Knöpfchen "Load List" (denk an das Halten der Maustaste) kommt man an die entsprechenden Funktionen.

Eventuell kommt Dir das alles bekannt vor... das liegt daran, daß AmigaAMP in Sachen GUI gar nicht so sehr anders funktioniert als Amplifier.

Alle Klarheiten beseitigt?
--
---

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


[ Dieser Beitrag wurde von whose am 25.09.2010 um 15:45 Uhr geändert. ]
 
whose   Nutzer

29.08.2010, 17:32 Uhr

[ - Direktlink - ]
Thema: Welche Programmiersprache
Brett: Programmierung

@Sprocki:

Jo, und wenn dem so ist, kann man nur sagen: Seit 4.1 gehört Python mehr oder weniger dazu, kein Port aus dem os4depot mehr nötig.
--
---

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

26.08.2010, 02:18 Uhr

[ - Direktlink - ]
Thema: RGB16 lesen
Brett: Programmierung

@Ralf27:

Interpretiert wärs eine gute Zeit I-)
--
---

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

23.08.2010, 23:50 Uhr

[ - Direktlink - ]
Thema: RGB16 lesen
Brett: Programmierung

@Ralf27:

Hm, das mit den Farben müßte man mal sehen, um es beurteilen zu können... "nicht richtig" ist ein ziemlich dehnbarer Begriff ;)

Eine Möglichkeit wäre, daß der "Farbraum" noch angepaßt werden müßte. Das ist z.B. eins der Probleme bei einem Palette-Modus (256 Farben).

Bei HAM wiederum mußt Du bedenken, wie der HAM-Modus funktioniert. Ich kann jetzt aus Deinem Code nicht direkt erkennen, ob Du das "Nachbarpixel-Problem" korrekt behandelst. Paßt Du jeweils den richtigen Farbanteil in Bezug auf den vorhergehenden Pixel an oder wandelst Du die Farbwerte "einfach so"? Bei letzterem müßte es auch horizontales "Tearing" geben, nicht nur "nicht richtige" Farben...
--
---

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

13.08.2010, 22:03 Uhr

[ - Direktlink - ]
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4

Zitat:
Original von Ralf27:
Zitat:
Original von MaikG:
Genesis hat zwar Bugs aber das im alltäglichen gebrauch Hits auftauchen ist nicht der Fall. Bei einem USB->Ethernet adapter kann das vorkommen.

Am auffälligsten ist es, wenn man Genesis beendet und das ganze System instabil wird. Es kann dann auch sein das mit dem beenden von Genesis sich auch das System verabschiedet.

Hm, offen gesprochen: Das ist mir noch nie passiert. Auf zwei Rechnern mit OS3.9 nicht. Welche Hardware verwendest Du, um ins Netz zu kommen?

Zitat:
Zitat:
UnArc läuft hier ebenfalls ohne hit. Es gibt fälle da entpackt
UnArc Zip dateien welche klein viel größer also trash datei.
Ansonsten hab ich letztens ein 1 GB Archiv mit UnArc entpackt, kein Problem.

Nun, wenn ich ein LHA-Archiv doppelklicke und sich UnArc öffnet, dann entsteht beim öffnen von UnArc ein Hit (Read/Write auf Null).

Das wiederum kenne ich nur von den ersten beiden 3.9-UnArc-Versionen... ab BB2 hatte ich keine Probleme mehr. Davor gabs einen Hit, wenn Dateinamen bestimmter Länge ein Leerzeichen enthielten. In der ersten Version gabs auch Streß mit dem Unterstrich... entweder wurde der als Leerzeichen ausgegeben oder Leerzeichen wurden in einen Unterstrich gewandelt. Genau weiß ich das nicht mehr...

Zitat:
Wären Programmierer unfehlbar, dann bräuchten wir keinen Speicherschutz. :)

Ich glaube, dieses Thema sollten wir nun endgültig ausklammern. Reicht doch, wenn sich zwei Leute deswegen die virtuellen Schädel einschlagen ;)

--
---

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

11.08.2010, 19:40 Uhr

[ - Direktlink - ]
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4

Zitat:
Original von Holger:
Zitat:
Original von whose:
Und wie ists bei Dir? War es da auch Absicht, daß Du Dich eingeschaltet hast, obwohl Du genau weißt, daß es dadurch noch mehr ausartet?

Ich habe mich, als ich diese Bemerkung gelesen habe, zurückgehalten. Ich habe erst am nächsten Tag geantwortet, als Thore bereits vier Beiträge geschrieben hatte, in denen er seine Meinung noch weiter auswalzte, und das Resultat meiner Beiträge ist nicht, dass es noch mehr ausartet, sondern dass er die Diskussion jetzt beenden will. Also alles bestens.

Ach so, und weil ER die Diskussion beenden will, mußt DU schnell nochmal nachtreten? So beendet man Diskussionen? Indem man denjenigen, der schon nachgegeben hat, noch einmal herausfordert? Bestechende Logik.

Also alles beste Absicht, ok.

P.S.:Für den Fall, daß Dir durch das bereits angesprochene Problem wieder weggeblendet wird, was Du geschrieben hast:

Zitat:
Zitat:Original von Thore:
und fast jedesmal, und immer wenn die Leute wissen daß es zu sowas ausartet. Langsam glaube ich das ist Absicht von bestimmten Personen...

Da ist was wahres dran.
Du wusstest es ganz genau, aber musstest trotzdem unbedingt diesen nicht zum Thema gehörenden Schwachsinn schreiben.

Und?
Ist es Absicht?

--
---

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

11.08.2010, 18:55 Uhr

[ - Direktlink - ]
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4

@Holger:

Und wie ists bei Dir? War es da auch Absicht, daß Du Dich eingeschaltet hast, obwohl Du genau weißt, daß es dadurch noch mehr ausartet? Ach nee, war bestimmt nur Zufall, oder? Quatsch, weils "Schwachsinn" war, mußtest Du Dich einschalten, richtig? Um diesen "Vollhonks" zu zeigen, was ne Harke ist :)

@Ralf27

Eigentlich ist alles gesagt. Zu 2 ist zu sagen: Nein, eine neuere Version gibt es nicht mehr und RoadShow 68k ist ja quasi abgesagt. Wobei ich das Gefühl habe, daß auch dieser Stack einige Bugs in sich trägt. Die, trotz partiellem Speicherschutz, noch nicht zu gravierenden, aber leicht nervenden, Problemen führen (SCNR).

Zu 3. ist zu sagen, daß das nicht zwingend an UnArc selbst liegen muß. Das LHA-Modul z.B. hat Probleme mit manchen Dateinamen (gehabt). Da ist es nicht auszuschließen, daß andere Module (zip zum Beispiel) und auch das lha-Modul noch Probleme in sich tragen.

@cgutjahr:

Das mit den Ports ist nicht Dein Ernst, oder? Nenne mir bitte einen größeren Port, der keine Bugs in sich trägt und unter OS4 nicht absturzgefährdet ist. Bisher ist mir nur 1941 Extreme als einigermaßen stabil aufgefallen, der Rest ist, gelinde gesagt, wenig stabil.
--
---

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

09.08.2010, 22:35 Uhr

[ - Direktlink - ]
Thema: Flachbettscanner am SAM
Brett: Amiga, AmigaOS 4

@cygnusEd:

Ach, SANE wars... ich werf das immer mit dem Vorgänger/"Onkel" durcheinander.

Ich glaube allerdings nicht, daß er sich extra dafür nen anderen Scanner besorgt (die sowieso nicht so einfach zu beschaffen sind. Die meisten in der Liste aufgeführten Geräte sind "alte Gurken"). So wirklich leicht ist sein Problem wohl nicht zu lösen.
--
---

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

09.08.2010, 21:34 Uhr

[ - Direktlink - ]
Thema: Flachbettscanner am SAM
Brett: Amiga, AmigaOS 4

@analogkid:

Ach, hast Du denn für alle denkbaren erhältlichen Scanner nen Treiber? ;)

Welche Gründe es genau hat, daß die meisten USB-Scanner keinen Treiber bekommen... geschenkt. Tatsache ist, daß die allermeisten marktfrischen Scanner zur Zeit nicht unterstützt werden (können).
--
---

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

09.08.2010, 17:34 Uhr

[ - Direktlink - ]
Thema: Flachbettscanner am SAM
Brett: Amiga, AmigaOS 4

Zitat:
Original von ZeroG:
@whose:
Zitat:
sobald isochronous transfer ins USB-Subsystem integriert wird,
Mir fällt irgendwie kein Grund ein warum ein Scanner diesen Modus benuzen sollte - das Ding ist eher für sowas wie Webcams gedacht, d.h. möglichst verzögerungsfreie Übertragung auf kosten der Datenintegrität.

Aber nicht nur... es gäbe viele Gründe, warum ein Scanner diesen Modus benutzen könnte... unter anderem der "möglichst wenig Hardware im Scanner verbauen"-Grund.

Technisch gesehen ist ein Scanner nichts anderes als eine hochauflösende Webcam mit variabler Zeilenfrequenz. Es sollte mich wirklich wundern, wenn dieses Feature bei vielen USB2.0-only-Scannern nicht genutzt wurde. Was dann auch die leichte Treiber-Armut z.B. unter Linux erklären würde.

100% genau weiß ich das (Scanner und Isochronous) allerdings nicht. Wenn ich es wüßte, hätte ich auch Information, um entsprechende Treiber zu bauen ;)
--
---

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

09.08.2010, 16:01 Uhr

[ - Direktlink - ]
Thema: Flachbettscanner am SAM
Brett: Amiga, AmigaOS 4

@netrot:

Ja, Massenspeicher gehen... inzwischen gibts sogar weniger Probleme mit FAT-formatierten Medien. Zumindest ist es mir seit Update 2 immer gelungen, fehlerfrei auf FAT-formatierte Medien zu schreiben, was vor Update 2 eher Glückssache war. FFS/SFS machte hingegen nie Ärger.

@tploetz:

Dann siehts vorerst düster aus mit Scannen. Ich schätze, sobald isochronous transfer ins USB-Subsystem integriert wird, dürfte sich die Lage ändern und zumindest Betascan sollte dann "machbar" sein. Dieses Paket bringt zumindest für ein paar noch erhältliche USB-Scanner Treiber mit, die portierbar sind. Und wer weiß, vielleicht tut sich dann auch bei ScanQuix wieder etwas... sag niemals nie ;)
--
---

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

09.08.2010, 04:52 Uhr

[ - Direktlink - ]
Thema: Flachbettscanner am SAM
Brett: Amiga, AmigaOS 4

@netrot:

Nein, tut es nicht, weil die entsprechende "Class" im USB-System bisher fehlt.
--
---

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

01.06.2010, 02:02 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von Holger:

Zitat:
Original von whose:
Spätestens in Sachen 68k würdest Du damit vor eine Wand rennen. 3rd level API auf die sich alle einigen können schön und grün, aber die Hardware und die unter der High-Level-API liegenden Schichten müssen da auch mitspielen.

Kannst Du auch mal Belege für Deine Theorie, Highlevel bedeute zwangsläufig schlechte Performance, bzw. mit den alten APIs würden alle Entwickler automatisch die Lowlevel-Funktionen zur Optimierung nutzen, bringen?

Wozu? Habe ich denn gesagt, daß das zwangsläufig zu schlechterer Performance führen müßte?

Du bist anscheinend zu lange aus der aktiven Amiga-Programmierung raus, um die aktuellen Probleme, die sich mit der Zeit und den diversen Spaltungen ergeben haben, noch sicher zu erkennen.

Und in Sachen Textverständnis hast Du auch nachgelassen.

Zitat:
Schau Dir doch mal MUI an: die normale MUI-Anwendung interessiert sich nicht die Bohne dafür, ob die eingebetteten Icons 24 Bit TrueColor oder 8 Bit Planar sind oder ob die Buttons nun mit Farbverläufen gefüllt sind oder nicht.

Den Benutzer eines herkömmlichen 68k-Systems wiederum interessiert es nicht die Bohne, ob sich MUI überhaupt für irgendwas interessiert. Wenns anfängt zu lahmen, fängt der Benutzer an zu mosern. Vor allem wenn er vergleichen kann und sieht, daß es auch anders geht.

Du hast meinen Standpunkt nach all der Zeit immer noch nicht verstanden, dabei ist es ganz einfach: High Level, schön und grün, aber nicht um jeden Preis. Wohin das führt, sieht man an diversen Druckertreibern in 100MB-Größe.

Zitat:
Und auch bei 99% aller GUI-Anwendungen, die kein Toolkit wie MUI benutzen, wird nicht für einen planaren oder truecolor Bildschirm optimiert. Und "performanter" sind nur die Anwendungen, die Fenster fester Größe mit topaz/80 öffnen, na danke.

Wieso kommst Du jetzt mit "Optimierungen für planar/chunky"? Das hat in unserer Diskussion ziemlich wenig verloren. Oder würdest Du etwa solche Optimierungen erst in der High Level API einführen wollen?

Zitat:
Zitat:
Mir ist z.B. zu Ohren gekommen, daß mindestens 2 der neueren Vertreter AHI ablösen wollen. Dann die Druck-Problematik, da ist ja bei den einen CUPS im Gespräch (hoffentlich nicht!), bei den anderen ein aufgebohrtes printer.device...
Ist doch schön, sollen sie sich mal alle austoben. Ist auch kein Problem, wenn man bei einem der beiden Systeme die Funktionstabellen der Libraries erst noch via "GetInterface" holen muss.

Yay, und mal wieder eine schöne Bestätigung für meine Theorie, daß irgendein ***** immer ein Haar mit der unpassenden Farbe in der Suppe finden wird...

Zitat:
Wenn es einfach ein Highlevel-API geben würde, bei dem man beispielsweise "Drucke RAM:foo.txt" sagen könnte.

Wenn, hätte, könnte, würde. Und was bringt das? Tatsache ist doch, daß keiner den Anfang machen will, aus den unterschiedlichsten Gründen. Aber haben wollen irgendwie alle.

Zitat:
Zitat:
Ja, und dann ist da noch dieser bald zwanghaft-manische Wunsch, das Ganze auch noch auf Winblows, Linux & Co. auszuweiten...
Ich sehe da eigentlich eher den zwanghaft-manische Wunsch einer einzelnen Person, diesen Wunsch nach Ausweitung den anderen in den Mund zu legen.

http://www.amiga-news.de/forum/thread.php?id=32899&BoardID=7#337121

Mehr muß ich nicht dazu sagen, oder? Du solltest echt mal Urlaub machen...

Zitat:
Zitat:
Ich schätze, der einzige Weg, da etwas zu erreichen ist, eine API zu entwerfen, zu implementieren und Referenzanwendungen dafür zu bauen. Dazu sollte das Ganze, wie Du schon sagtest, "aus einem Guß" sein und wirklich gute, neue Features bringen. Wenn sich dann noch genug Entwickler finden, die das wirklich und ausführlich benutzen, ...
Ja genau.
Drei unterschiedliche Teams beschäftigen sich damit, eine 1:1 Kopie eines OS aus den achtziger Jahren mit ein paar minimalen Verbesserungen und etwas Eye-Candy zu entwickeln, aber dann soll ein einzelner als einziger konzeptionelle Arbeit liefern, natürlich gleich mit vollständiger Implementierung, die so überzeugend ist, das möglichst alle Anhänger, die sich über die Wahl eines der drei Betriebssysteme uneinig sind, sich bei diesen Bibliotheken einhellig positiv äußern, obwohl diese bislang nicht den offiziellen Stempel tragen.


Blödsinn! Hast Du Deinen Sarkasmus auch nicht mehr unter Kontrolle? Niemand verlangt von dem "Einzelnen" das, was Du hier aufzählst. Aber ich z.B. erwarte von jemandem, der etwas haben will, wirklich konkret umsetzbare Vorschläge und nicht so ein Gestammel wie "... ich hätte aber gern sowas wie Eclipse, noch besser Eclipse... und so ein API wie Java, besser noch Java...". Das führt zu exakt

Nichts

Zitat:
Klar, da stimme ich Dir vollkommen zu. Wenn das vollbracht wurde, wäre der Druck tatsächlich hoch genug, dass alle drei OS-Entwickler diese Arbeit bereitwillig für lau abgreifen, äh... übernehmen und als "offiziell" adeln würden.

Ernst nehmen kann man Dich momentan nicht, das steht fest. Wann bist Du wieder in der Lage, halbwegs sachbezogen und ohne schwachsinnige Übertreibungen zu diskutieren?

Eine entsprechende Lizenz würde dem "Abgreifen für lau" einen Riegel vorschieben.

Abgesehen davon, wie kommst Du eigentlich darauf, daß die aktuellen OS-Entwickler aus kaum vorhandenen Resourcen ein güldenes Schloß bauen müßten? Ist es nicht schon ein kleines Wunder, daß die überhaupt etwas auf die Beine bekommen haben?

Ich finde es sehr interessant, daß ausgerechnet Du jetzt an die Produzenten schön hohe Ansprüche stellst, obwohl Du ihnen vor nicht allzu langer Zeit die Fähigkeit abgesprochen hast, selbst geringste Hardware-Ansprüche zu erfüllen.

Man könnte meinen, Du würdest es am liebsten sehen, daß jedes der momentan verfügbaren Systeme den Bach runtergeht. Abgesehen von AROS natürlich, das kannst DU ja für lau abgreifen...

Zitat:
Wobei...100% sicher bin ich mit doch nicht, dass nicht der eine oder andere Anhänger von Reduktion auf Low-Level Schnittstellen ein Haar in der Suppe finden würde.

Der erste, der ein Haar aus der Suppe zaubern würde, wärst Du. Erst dann kommen die anderen üblichen Verdächtigen.

So, können wir jetzt vielleicht mal zu den Sachlichkeiten zurückkehren? Weitere praktische Vorschläge für das gewünschte API zum Beispiel? Mehr Vorschläge für die erfolgreiche Umsetzung? Ich habe bisher die Probleme aufgezeigt, die ich sehe. Wo bleiben die Vorschläge, wie man diese Probleme erfolgreich vermeiden/umgehen könnte? Da könntest gerade Du eigentlich eine Menge zu beitragen. Ok, wegen des Sarkasmus-Flashs bleibt Dir da wenig Kapazität für, aber versuchen könntest Du es ja wenigstens...
--
---

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


[ Dieser Beitrag wurde von whose am 01.06.2010 um 02:16 Uhr geändert. ]

[ Dieser Beitrag wurde von whose am 01.06.2010 um 02:17 Uhr geändert. ]
 
whose   Nutzer

29.05.2010, 13:38 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von Thore:
Du kannst anhand meiner dargelegten Funktionsnamen erkennen, was dahinterstecken soll? Ui große Gabe, Verneigung :D

Mal als Hilfestellung eine mögliche Schnittstelle (Beispiele):
TextW(RastPort, x, y, WideString); // Ausgabe eines Unicode Texts an Pos x,y
ScaleImage(RastPort/Bitmap, x, y, w1, h1, x2, y2, w2, h2); // Scalieren eines Bildausschnitts Formatsicher mit Pos x,y und Maße w1,w2 nach Pos x2,y2 mit Maße w2,h2

Wie soll es denn noch einfacher gehen? Je weniger Infos man der Routine mitgibt, umso unflexibler wird das ganze.

Oder was genau meinst du? Konkretes Beispiel. Ich denke Du bist grad der einzige der weiß was er will.


Nein, ich weiß auch in groben Zügen, was er will ;)

TextW() zum Beispiel wäre auf einen String beschränkt. Eine 3rd level API nach seinen Wünschen würde z.B. auch ganze String-Arrays zulassen und den Krempel auf Fensterbreite automatisch formatieren. Im Groben das, was die ganzen "Bildschirmausgabe-Engines" ala Quartz oder auch Klamotten wie PostScript machen, eben mit einer einzigen aufzurufenden Funktion den ganzen Segen verwursten.

Beim Skalieren ging es vor allem darum, wie das Ganze z.Z. im Zusammenspiel mit den Datatypes gehandhabt wird. Das ganze Geraffel könnte man ja relativ problemlos in eine einzige Funktion packen, deshalb sagte ich anfangs ja auch, daß ich da kein Problem sehe. Einmal ne entsprechende Funktion schreiben, ab in ne Linker-Lib und fertig.

Sein Wunsch zielt halt darauf ab, entsprechende Funktionen auf allen Amiga-Plattformen (und evtl. darüber hinaus) offen zur Verfügung zu haben. Theoretisch kein Thema, nur machen muß es jemand. Und dann muß es natürlich auch von Dritten genutzt werden. Gerade bei letzterem sehe ich einige Probleme. Die gäbe es aber auch bei den "Offiziellen". Ich erinnere in diesem Zusammenhang immer wieder gern an ReActor. Schöner Ansatz, aber von allen Seiten (sogar von den Entwicklern selbst!) direkt totgequatscht worden. Daher dürfen wir die GUIs wieder schön brav von Hand bauen...
--
---

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

29.05.2010, 13:25 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Der_Wanderer:

Um beim Android-Beispiel zu bleiben:

Spätestens in Sachen 68k würdest Du damit vor eine Wand rennen. 3rd level API auf die sich alle einigen können schön und grün, aber die Hardware und die unter der High-Level-API liegenden Schichten müssen da auch mitspielen.

Ok, man kann jetzt wie üblich argumentieren, daß 68k-Liebhaber ja wegen der Geschwindigkeit auf WinUAE & Co. umsteigen könnten. Aber wer von denen macht das? Und ich verstehe die auch sehr gut, daß die ihre Hardware nutzen möchten, neue Programme dafür bekommen möchten usw. Und dann ist da ja noch die Systemsoftware...

Deswegen sage ich, daß sich da jemand hinsetzen und eine entsprechend zugeschnittene API zaubern muß, sonst wird das so oder so nichts. Klar, bei ner One-Man-Show besteht die Gefahr, daß das einfach untergeht. Die Gefahr besteht aber auch bei einer One-Dozen-Men-Show, und zwar aus den gleichen Gründen. Es hilft einfach nichts, ein API aufzubauen, wenns hinterher nicht einmal die Entwickler selbst voll nutzen. Dagegen hilft auch Open Source als Allheilmittel nicht. Wie viele Open Source Projekte gibt es, bei denen gar nichts mehr passiert? Und das, obwohl sie anfangs vielversprechend waren und schicke Funktionen mitbrachten?

Von dem Gedanken, daß es für alle Amiga-Abkömmlinge die gleiche API ohne Zwang geben kann, wird man sich auch verabschieden müssen. Es wird immer im Detail haken, weil sich die einzelnen Plattformen schon recht weit auseinanderentwickelt haben. Dazu kommt, daß jedes Trüppchen seine eigenen Vorstellungen hat, wie man was umsetzen sollte. Mir ist z.B. zu Ohren gekommen, daß mindestens 2 der neueren Vertreter AHI ablösen wollen. Dann die Druck-Problematik, da ist ja bei den einen CUPS im Gespräch (hoffentlich nicht!), bei den anderen ein aufgebohrtes printer.device...

Ja, und dann ist da noch dieser bald zwanghaft-manische Wunsch, das Ganze auch noch auf Winblows, Linux & Co. auszuweiten... wieso eigentlich? Wozu soll das gut sein? Hilft dem Amiga nicht wirklich. Höchstens dabei, eben diesen Plattformen immer ähnlicher und damit immer überflüssiger zu werden.

Ich schätze, der einzige Weg, da etwas zu erreichen ist, eine API zu entwerfen, zu implementieren und Referenzanwendungen dafür zu bauen. Dazu sollte das Ganze, wie Du schon sagtest, "aus einem Guß" sein und wirklich gute, neue Features bringen. Wenn sich dann noch genug Entwickler finden, die das wirklich und ausführlich benutzen, baut das Druck auf die OS-Teams auf. Das könnte manche Leute eventuell dazu bewegen, diese API als Quasi-Standard anzuerkennen und zu übernehmen. Garantie gibts allerdings keine.

Ich wette aber, daß es, egal wie gut es tatsächlich ist, von den "üblichen Verdächtigen" direkt oder auf lange Sicht wieder totgequatscht wird. Aus den unterschiedlichsten Gründen, manche davon vielleicht sogar berechtigt, je nach dem, wie diese API gestaltet wird.

Leicht wird das Ganze sicher nicht.
--
---

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

27.05.2010, 13:57 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
> Wie ich schon öfters sagte. Nicht lange fackeln, handeln.
Eben nicht. Das ist ja genau das, was ich versucht habe zu veranschaulichen. Liest (und kognitiv verarbeitet) jemand (ausser Holger) mein Geschriebenes überhaupt?


Ja, das tue ich. Gilt das aber umgekehrt auch?

Zitat:
Jeder für sich alleine kann nicht viel erreichen. Jede Lib oder Linkerlib wäre nur ein kleiner Baustein dessen was benötigt wird.

Ja, Himmelherrg... dann sag doch mal detailliert, was genau Du benötigst. Bisher kamen nur so extrem spezifische Sachen wie "das API ist schlecht". In Bezug auf AmiBlitz kommt dann wiederum "ist genau das, was ich benötige". Also, was spricht dann dagegen, Deine AmiBlitz-Includes in C-Code zu gießen? Das "schlechte shared library API"?

Du solltest wirklich mal darüber nachdenken, wie viel "Plattformunabhängigkeit" technisch überhaupt realisierbar ist, ohne daß die Geschichte ausartet.

Zitat:
Wenn die Bausteine nicht wie Lego aufeinander passen, wird ein Programm zur Flickschusterei mit viel fehleranfälligem Glue-Code und es gibt keine wiederkehrenden Mechanismen, die einem die Einarbeitung so sehr erleichtern.

Das ist ja aber genau das Problem beim Amiga. Egal, welches der verfügbaren Toolkits man vorschlägt (Ja, Holger, es gibt noch weit mehr als nur GUI-Toolkits! Schau einfach mal ins Aminet und guck Dir genau an, was da so in den ReadMes steht!), es ist nie "gut genug".

Aber bitte wie soll ein der Flickschusterei abholdes Toolkit zustande kommen, wenn die "Kunden" sich nicht mal darüber einig sind, welche Eigenschaften es genau haben soll? Wenn die "Kunden" nicht einmal eine leise Ahnung haben, was es "auf dem Markt" schon alles gibt, geschweige denn bereit sind, sich erstmal zu informieren? Und wenn immer wieder mit Toolkits verglichen wird, die z.B. unter AmigaOS nur eingeschränkten Gebrauchswert haben?

Fakt ist, es existieren mehrere Ansätze solcher Toolkits, die schon bei ihrer Entstehung aus Agenda-Gründen rundweg abgelehnt wurden. Jeder bevorzugte "seinen" Weg, keiner war zu den notwendigen Kompromissen bereit.

Heute wiederum ist niemand mehr bereit, in eine dieser "Flickschustereien" Arbeit zu investieren, um sie auf den neuesten Stand zu bringen und den Status der "Flickschusterei" zu beseitigen.

"Haben" wollen jedoch recht viele.

Zitat:
Ausserdem ist es sehr gefährlich, wenn man 3rd Party Software (zumindest auf Binary Basis) einbindet, das ist wie ungeschützer Sex.

Hm, wieso ist das dann für Dich unter Windows kein Problem? Da gibts auch etliche Toolkits, die Du nie im Sourcecode zu sehen bekommst...

Zitat:
Die meisten Libs machen auf irgendeiner Plattform Zicken, alleine wegen dem wenigen Testen bei so vielen verschiedenen Libs.

Ich denke, das Stichwort "Plattform" ist das eigentliche Problem, weniger das AmigaOS API... (@Holger: Das ist der heiße Brei, um den immer gern herumgeredet wird. "Plattform".)

Zitat:
Also der Weg zum Glück liegt selten auf dem gierigen Pfad.

Amen.
--
---

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

23.05.2010, 17:13 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Reth:

Du liebe Güte, hört das eigentlich nie auf? Ihr redet um den heißen Brei herum. Weder Java noch Windows hatten "von Geburt" an die "API", von denen ihr hier berichtet. Beide sind immer noch genau so "low level" wie AmigaOS. Der Knackpunkt sind die (mehr oder weniger) fehlenden Toolkits, Linker-Libraries, DLLs oder AmigaOS shared libraries für eure Zwecke, nicht das AmigaOS API an sich.

Blättert einfach mal durchs Aminet, wie viele Toolkits sich dort befinden, die keine S** (tschuldigung!) außer dem Entwickler selbst je benutzt hat. Es finden sich sogar mehrere Bibliotheken für OOP-Fans da. Wer hat die bisher genutzt? Und wenn die nicht genutzt wurden, aus welchen Gründen? Welche Ausrede findet ihr, um die auch nicht zu nutzen?

Ich kann diese "aber das API ist soooo schlecht"-Jammerei echt bald nicht mehr lesen. Nutzt endlich mal das, was zur Verfügung steht und verbessert es ggf., statt ständig nach neuen Toolkits zu brüllen, die dann doch wieder kein Mensch nutzt.

Oder macht die von Euch so dringend benötigten Toolkits selbst. Da zeigt sich dann auch ganz nebenbei, ob es wirklich sinnvoll ist, die von Euch bevorzugten API-Erweiterungen/-Vereinfachungen per Toolkit für AmigaOS zu benutzen. In den meisten Fällen dürfte auf Euch die eine oder andere nicht so positive Überraschung warten, was z.B. Performance angeht...

--
---

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

20.05.2010, 22:21 Uhr

[ - Direktlink - ]
Thema: SDI-Makros und vbcc-m68k
Brett: Programmierung

@gni:

So, wie sich das für mich liest, ist sein Problem das, daß es möglicherweise Compiler geben könnte, die blöd genug gebaut wurden, um Host und Target nicht eindeutig trennbar anzugeben.

Z.B. folgender (wenn auch sehr unwahrscheinlicher) Fall, daß ein Compiler auf __M68K__ läuft und dies als Host so angibt und für das Target z.B. __PPC__ angibt. Würde er dann nur auf __M68K__ testen, gäbs Bruchlandung, weil das Target halt __PPC__ ist.

Mir ist allerdings kein Compiler bekannt, der so dusslige Infos von sich gibt. vbcc gibt meines Wissens nach den Host auch gar nicht explizit an, nur das Target. Wie das bei z.B. gcc gehandhabt wird, weiß ich gar nicht, habe mich nie groß darum gekümmert ;)

Ich glaube allerdings, daß keine Compiler-Truppe so dusslig arbeiten würde, Host und Target nicht eindeutig trennbar als Symbol anzugeben. Ok, sicher sein kann man sich da nie, aber das würde doch ziemlich schnell auffallen, oder?
--
---

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

19.05.2010, 22:17 Uhr

[ - Direktlink - ]
Thema: SDI-Makros und vbcc-m68k
Brett: Programmierung

@jolo:

Danke für den Tip. Ich habe noch die ältere Aminet-Version hier, damit gehts. Ich werde mir aber mal die aktuellere saugen und dann nach Deinen Angaben vergleichen/korrigieren, falls nötig.

Grüße

--
---

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

06.05.2010, 03:03 Uhr

[ - Direktlink - ]
Thema: Sporadische Lesefehler...
Brett: Amiga, AmigaOS 4

Zitat:
Original von Evil:
Hallo!

Ist es egal, an welchem IDE-Stecker ich die Platte und das DVD-Laufwerk anklemme? Momentan hängt die Platte am Ende, und das DVD-Laufwerk in der Mitte.
Wenns am IDE-Kabel liegen solle, könnte ich die beiden ja mal andersherum anschließen, sodaß das dvd-laufwerk hinten ist.
Weil DVD läuft ja einwandtfrei.
Die sind übrigens beide auf CableSelect gejumpert. Hat das was aufe Hacksen?? So ist ja die Platte Master, weil sie am Ende des Strangs hängt. Sollte ich die vielleicht besser explicit auf Master und Slave jumpern?


Das kannst Du eigentlich halten, wie Du magst. Cable Select ist zwar unter OS4 nicht gerade empfohlen, funktioniert an einem MicroA1 aber.

Zur Sicherheit kannst Du die Geräte ja explizit jumpern, so wie Du sie jetzt am Kabel hast (Platte Master, DVD Slave).

Zitat:
Obwohl... Ich hab schon 3 verschiedene IDE-Kabel ausprobiert.. Bei allen die gleichen Probleme. Waren zwar alle nicht neu, aber wenn bei allen nur die Platte ärger macht, ists doch sonderbar...

In der Tat, und somit kannst Du Dir weitere Kabelexperimente sparen.

Zitat:
Jo. Stromkabel werd ich auch mal probieren. Ich hätte hier auch noch ein "Bastel"-Netzteil rumfliegen. Da könnte ich das eingebaute ja mal wenigstens etwas entlasten...
Dabei ist das noch gar nicht soooo alt...


Muß nicht unbedingt am Alter liegen. Probier mit Deinem eingebauten Netzteil doch einfach mal folgendes: Steck die Stromstecker einfach mal anders, als sie jetzt sind. Zum Beispiel Festplatte und DVD an jeweils einen eigenen Strang (da sind meist 2 "getrennte" Stränge am Netzteil dran).

Zitat:
Ach ja. Der Memtester war heute morgen fertig mit der ersten Runde. Hab ihn dann abgebrochen. Der Durchlauf war fehlerfrei. Somit kann man das RAM als Fehlerquelle wohl ausschließen.

Denke ich auch.

Zitat:
Ähh. Und auf die Gefahr hin, daß ich nerve...
Könntens nicht doch irendwelche Dummen Einstellungen sein???
Was muß alles konfiguriert sein? MediaToolbox. Was meinen die genau mit "SFS darf nicht im RDB stehen."? Hab ich da was verbockt??
War da nicht mal irgendwas mit irgendwelchen Env-variablen im UBoot???
Ich hab letztens die Batterie gewechselt. Somit waren alle Einstellungen futsch.. Und ja. DMA könnte doch auch noch verkehrt sein?! Was muß da stehen bei nem MicroA1???


Also, solange Du in der MediaToolbox nicht ausdrücklich SFS in den RDB installiert hast (Du wüßtest das, wenn Du es getan hättest ;) ), ist alles in bester Butter.

DMA ist mehr abhängig vom jeweiligen Gerät. Hier bei mir läuft die Festplatte problemlos mit UDMA5, DVD-Brenner mit UDMA3. Wird allerdings bei mir automagisch eingestellt.
--
---

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

06.05.2010, 02:24 Uhr

[ - Direktlink - ]
Thema: NewWPA8
Brett: Amiga, AmigaOS 4

@sun:

Versuch es mal, nachdem Du

protect C:BlazeWCP +E

in der Shell eingegeben hast.

Klingt, als wäre beim Entpacken das E-Bit "flöten gegangen".
--
---

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


[ Dieser Beitrag wurde von whose am 06.05.2010 um 02:25 Uhr geändert. ]
 
whose   Nutzer

06.05.2010, 01:20 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Der_Wanderer & Holger:

Schon mal auf die Homepage von thomas geschaut? Jede Menge Beispielcode zum Thema Datatypes.

Im Groben (bis auf die Dinge, die "drumherum" vorbereitet werden müssen, die gibts aber bei den diversen Toolkits und Link-Libraries auch, und manchmal noch viel schlimmer), läuft Laden (wahlweise incl. Skalieren) und Anzeigen in 3, max. 4, Schritten ab. NewDTObject(), DoMethod(), GetDTAttrs() und ggf. BltBitMapRastPort(). Selbst das Speichern sieht so aus:

code:
DoDTMethod (o,NULL,NULL,DTM_WRITE,NULL,fhand,DTWM_IFF,TAG_END);


Jetzt erklär mir bitte mal jemand, was daran so fürchterlich kompliziert ist? Außer vielleicht, daß man die Tags kennen sollte?

Diese Form von API ist nicht komplizierter als die, die Der_Wanderer gezeigt hat. Anders, ja, aber nun wirklich nicht komplizierter. Und wer unbedingt möchte kann, wie ich schon erwähnte, den ganzen Krempel noch weiter vereinfachen, häufige Nutzungsarten in eine Funktion einer Link-Library packen, usw. Es muß halt nur mal einer tun und andere Entwickler sollten das Zeug dann auch nutzen, selbst wenn u.U. irgendein Detail nicht ganz so ist, wie mans sich wünscht, aber dann doch eher selten bis gar nicht benutzt.

Schon mal zlib benutzt? DAS ist kompliziert. Puffer hier, Zwischenergebnisse dort, getaggte Speicherbereiche, die man selbst überprüfen muß usw. Und alles nur, um ein paar Kilobyte zu packen. Darüber beschwert sich aber komischerweise niemand. Das wird benutzt, weils vorhanden ist. Ist ja auch aus dem Unix-Bereich stammend. Nur beim Amiga ist es immer wieder ein Problem, vorhandenes zu benutzen. Nur, weil dieses oder jenes "nicht richtig" oder "zu kompliziert" ist.

Was die Angelegenheit API beim Amiga kompliziert macht ist die (ideologisch) bedingte Vielfalt an z.B. Datatypes, die eigentlich den gleichen Zweck erfüllen sollen, dies aber unterschiedlich gut (oder schlecht) erledigen.

Wie Der_Wanderer schon anmerkte (aber nicht BEmerkte): Es gibt immer wieder Ansprüche, die z.B. kein Datatype erfüllt. Dem einen ist die Qualität der Skalierung nicht ausreichend, der andere stört sich daran, daß es Probleme mit evtl. Remapping auf AGA gibt und so weiter und so fort. Nicht zu vergessen diejenigen, die ein z.B. JPEG Datatype nur dann akzeptieren, wenn es mit Hilfe der libjpg entwickelt wurde.

Was wirklich fehlt ist das Bestreben und der Ehrgeiz, aus dem bereits Vorhandenen gute Software zu produzieren und auch mit anderen Entwicklern aktiv zusammenzuarbeiten. Sich auf das Vorhandene wirklich einzulassen und auch die Gegebenheiten (4 immer wieder leicht unterschiedliche Systeme) einfach mal anzuerkennen, statt ständig eine Angleichung zu fordern, die nicht erreichbar ist, das fehlt. Der Rest ergäbe sich von allein, wenn diese Haltung sich endlich einmal durchsetzen könnte.
--
---

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

05.05.2010, 20:47 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Der_Wanderer:

Du machst mit dem Code aber auch etwas mehr spezielleres, als "nur ein Bild laden und auf den Schirm bringen". Der Code, den Du als Beispiel dafür brachtest, wie Du Dir "ein Bild laden und auf den Schirm bringen" vorstellst, ist in C ungefähr gleich. Und in Blitz sicher auch. Und bisher kenne ich keine Plattform, wo dieser Code (Bild laden und auf den Schirm bringen) nicht läuft.

Ich verstehe Dein Problem ja, aber es hilft rein gar nichts, sich über die Unzulänglichkeiten zu ärgern und eine Menge Code "drumherum" zu schreiben. Wenn Datatypes nix taugen, weil sie im API festgelegte Funktionen nicht oder falsch unterstützen gibts eigentlich nur zwei Dinge: Knochenhart sagen "Leute, mit dem Datatype läufts nicht, benutzt den oder den". Und sich dran setzen, einen Datatype zu entwickeln, der tut, was er soll.

Manchmal gibts allerdings auch Situationen, wo "selbst machen" unmöglich ist. Ging mir bei Amijeweled mit bestimmten P96-OS3.x-Systemen so. Da bleibt einem nicht viel mehr als zu sagen: "Tut mir leid, Leute, ich kanns auf Euren Systemen nicht zum Laufen bringen und es ist ziemlich unwahrscheinlich, daß der Fehler in P96 oder Eurem GraKa-Treiber noch gefunden und beseitigt wird". Kann man sich dann höchstens Notizen zu machen und schauen, ob eines Tages ein ähnlich gebautes Programm plötzlich funktioniert. Vielleicht findet man dann das Problem und kann es umgehen.

Fakt ist, die Plattformen streben inzwischen deutlicher auseinander. Kompatibilität gibt es untereinander nur noch auf dem kleinsten gemeinsamen Nenner und gerade der krankt an früher eingeführten Problemen. Die kannst Du aber nur dann für alle Plattformen kompatibel umschiffen, wenn Du deutlich mehr Arbeit in den Code steckst. Oder die Plattform OS3.x + RTG zu Gunsten einer der anderen fallen läßt. Mit OS3.x allein kommst Du heutzutage jedenfalls nicht mehr weit. Und es besteht wenig Aussicht darauf, daß OS3.x noch Weiterentwicklung erfährt. Bei den anderen Plattformen sieht das anders aus.
--
---

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

05.05.2010, 15:20 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Zitat:
Original von Holger:
Zitat:
Original von whose:
Zitat:
Ich bin in letzer Zeit beruflich mit einigen Plattformen in Berührung gekommen. Da merkt man deutlich, wenn man mal die Ideologie beiseite lässt, dass der Komfort und Qualität von IDE, SDK und der API der Schlüssel sind ob eine Plattform gute Software bekommt oder nicht.

Das würde ich so nicht unterschreiben...


Was außer Komfort und Qualität von IDE, SDK und der API soll denn noch eine Rolle spielen?


Gute Ideen und das Bestreben, Software in wirklich hoher Qualität abzuliefern. Heutzutage herrscht dagegen der Trend Featuritis und "schnell, schnell!" vor. Und das trotz hohem Komfort und gewisser Qualitäten von IDE, SDK und API.

Zitat:
Der Enthusiasmus?
Dann müsste der Amiga ja in guter, aktueller Software schwimmen.


Erinnere Dich mal daran, wie oft Du hier bestrebt warst, Enthusiasmus abzuwürgen, weil Du der Ansicht warst, daß der jeweilige Enthusiasmus Zeitverschwendung wäre. Und dann erinnere Dich daran, daß Du nicht der Einzige mit diesem Bestreben bist ;)

Viele gute Ideen sind in den vergangenen 10 Jahren den Bach runter gegangen, weil sie schlicht totdiskutiert wurden, statt sie einfach zu nutzen.

Zitat:
Die Performance?
Dann hätte der Wechsel von 68k auf ppc einen ordentlichen Anstieg von verfügbarer Software verursachen müssen, den ich nicht wirklich erkennen kann.


Hm, also in Sachen "verfügbarer" Software hat PPC durchaus einiges gebracht. Für die Marktverhältnisse sogar erstaunlich großen Anstieg. Und das trotz Grabenkämpfen, übermächtiger Konkurrenz x86, teilweise seltsamem Verhalten der User (Stichwort Ideologie) und Problemen im Bereich der Kernentwickler (gleiches Stichwort).

Die Qualität der zusätzlich verfügbaren Software ist ein anderes Kapitel, aber solange die Ideologie des "Portieren auf Teufel komm raus" vorherrscht, wird sich daran wohl wenig ändern...
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233
 
 
1 2 -3- 4 5 6 7 8 >> Letzte Ergebnisse der Suche: 2156 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

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.