Zitat:

---

Original von Der_Wanderer:
Man bräuchte eigentlich eine moderne API, die auf allen Systemen in gleicher Version verfügbar ist.
Z.B. sowas

code:

---

Import Amiga.CImage

CImage img = new CImage("DH0:myImage.jpg")
img.Resize(800,600,CIMAGE_INTERPOLATION_CUBIC);
img.Save("DH0:myImage_in800x600.png","PNG");

---

Das entspricht so in etwa der API von Amiblitz3 und was in in A/A++ vorhabe, wenn ich das jemals realisiere.

Alles andere ist viel zu kompliziert, mit Datatypes, richtige Tags setzen etc. Und das speichern geht schonmal gar nicht.

---

Zitat:

---

Das Problem ist halt nur, dass jedes System das versucht, aber nicht mit den anderen kooperiert. Deshalb bleibt der Amiga auf 3.x stehen, und ein neues Projekt in C anzufangen ist gleich eine Mammutaufgabe mit viel Trial and Error.

---

Zitat:

---

In Eclipse+Java funktioniert der Code meistens fast auf Anhieb. Unter C auf dem Amiga braucht man zig Compiler Läufe bis dann alles klappt. Und wenns dann auch noch zur Laufzeit funktioniert, fliegt es einem mit hoher Wahrscheinlichkeit um die Ohren wenn jemand das auf einer anderen Plattform ausprobiert.

---

Zitat:

---

Das liegt nicht an C, sondern am schwachen IDE, was einem nicht zur Tip-Zeit auf Fehler hinweist, an einem schwachen SDK was nur eine Plattform berücksichtigt und an einer schwachen API die einem für (aus heutiger sicht) triviale Sachen wie ein Bild laden viel zu viel OS Internas vor den Latz knallt wo man massig Fehler machen kann (auch als erfahrener Progger) und ein vielfaches mehr Code braucht als man heutzutage erwarten würde.

---

Zitat:

---

Und wie gesagt, das kann man nicht durch Enthusiasmus ausgleichen. Und gerade wenn Entwickler Man-Power knapp ist, muss man sich auf eine gutes IDE+SDK+API gespannt konzentrieren, das passiert aber nicht, sondern alle backen ihre eigenen, kleinen Brötchen.

---

Zitat:

---

Aber ich schweife langsam vom Thema ab, das wäre ein anderer Thread...

---

Och, die eigentliche Frage ist doch geklärt. Im Prinzip schon, aber nicht so simpel, wie Du gehofft hast Da können wir ruhig weiter über Grundsätzliches reden, denke ich
--
---

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

Zitat:

---

Original von Der_Wanderer:
Mir war nur nicht ganz klar, dass selbst in C es recht schwer ist eine etwas komplexere Library zu erstellen, vor allem wenn es sich um nicht-notwendigerweise-auf-den-Amiga-maßgeschneiderten Code handelt.

---

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.

---

Zitat:

---

Die Bereitschaft der Amigafans, mehr Zeit zu investieren für das Gleiche was auf anderen Plattformen viel einfacher ist kann das nicht ausgleichen.

---

Zitat:

---

Z.b. habe ich verzweifelt nach einer Video Codec Library gesucht, nach einer MOD player library oder einer mp3 Encoder Library. Unter Windows ist das alles in 5min erledigt, FFMPEG als DLL, MikMOD als DLL oder LAME als DLL. Gibts alles. So kann man sehr schnell tolle Multimedia Apps zusammenstellen. Angesichts diesem Überflusses bin ich sogar oft sehr enttäuscht, wie "schwach" viele Windows Soft doch ist.

---

Zitat:

---

Auf dem Amiga gibt es von den o.g. Dingen zwar Commando Zeilen Ports, aber keine Libraries. Um da das gleiche zu erreichen muss man quasi alles selbst machen, vom Video Encoder bis zum MOD player. Das ist 1000x so viel Code und Arbeit, und das Ergebnis sehr viel schwächer.
Zumindest ist das so, wenn man keine Statischen Linker Libs hat und oder verwenden kann.

---

Wieder so eine Sache: Alles, was Du aufzählst, IST auch nur als Kommandozeilen-Tool gedacht. ffmpeg z.B. ist eine Tool-Sammlung zur Behandlung unterschiedlicher Bild- und Videoformate, aber keine Link-Library an sich. Für das Bauen dieser Tools existiert jedoch immer auch der Satz an zugehörigen Link-Libraries (libjpeg, libpng, libmpeg und wie sie alle heißen. Ich kriege immer wieder Zustände, wenn ich AmiUpdate auf OS4 starte, weil die Litanei der Link-Libraries, die ich nicht benutze, so irre lang geworden ist und in Wochenabständen länger wird).

Was glaubst Du, wie ffmpeg für Amiga (ja, sogar 68k!) portiert wurde? Alles "selbst gemacht" und unter Verwendung selbst gebauter shared libraries? Oder LAME? Diese Tools sind im engeren Sinne portabel, weil sie nicht auf dynamisch zu ladende Objekte angewiesen sind. Es gibt sie im Original statisch oder dynamisch gelinkt, aber geplant waren sie bisher immer für statisches Linken. Und da es fast immer eierlegende Wollmilchsäue sind, ist dynamische Linken im Grunde auch überflüssig für diese Tools. Was wohl auch der Grund dafür sein dürfte, daß für die meisten der für diese Tools verwendeten Link-Libraries keine Gegenstücke in Form einer Amiga shared Library vorliegen. libmad ist hier eine Ausnahme (mpega.library).

avcodec existiert übrigens sogar als shared library. Du müßest sie im Grunde "nur mal eben" auf 68k bringen (was nicht wirklich schwer ist). Über den Sinn dieser Aktion kannst Du Dir ja dann immer noch Gedanken machen, wenn die Besitzer echter 68k Amigas ihr Befremden darüber in diversen Foren zum Ausdruck bringen

Zitat:

---

Lohnt es sich also, ein paar Bytes und CPU Cylces zu sparen, wenn dadurch das Erstellen mächtiger Software fast unmöglich wird?

---

Was heißt "mächtige" Software? Mächtig groß? Mächtig funktions- und fehlerbehaftet? Mächtig mit selten bis nie genutzten Spezialfunktionen überfrachtet? Mächtig schwerfällig sogar auf schnellsten Maschinen?

Das Problem, das Du da beschreibst, ist kein vom verwendeten Bibliothekssystem verursachtes Dilemma, sondern schlicht Folge der etwas unglücklichen Geschichte des Amiga. Wäre diese Geschichte nur ein wenig positiver verlaufen, würdest Du sicherlich über die unüberschaubare Menge der erhältlichen shared Libraries für einen bestimmten Zweck stöhnen.

Und um auf Dein eigentliches Problem zurückzukommen: Dieses wiederum ist eher eine Designfrage. Gründe für ein Überdenken Deines Designs wurden Dir hier einige aufgezählt.

Wie gesagt, wie Du damit letztendlich umgehst ist allein Deine Entscheidung. Niemand will und kann Dich zwingen, Deine Lib auch für AOS 68k zu entwickeln, wenn es Dir zu aufwändig ist. Aber denk mal darüber nach, was man Dir hier in Sachen C-Standardfunktionen und deren Verwendung in Bibliotheken gesagt hat. Wirklich clever ist dieser Weg nämlich nicht. Simpel und schnell gemacht, ja, aber nicht wirklich clever.
--
---

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

Zitat:

---

Original von Der_Wanderer:
Danke für die vielen Hinweise.

Alles hat natürlich seine Gründe.

Was bleibt ist aber, Windows DLL luppt, AmigaOS luppt nicht.

---

Zitat:

---

Die C Runtime zu benutzen sollte ja gerade dahin führen, dass der Code portabel ist. Ist mir schon klar dass ich es machen könnte direkt mit AmigaOS, nur ist das eine Zeit frage, wieviel man in die AmigaOS version stecken kann.

---

Zitat:

---

Eine Shared library will ich aus verschiedenen Gründen machen.

---

Die Pro/Contra-Argumente sind doch lange bekannt.

Fakt ist aber, "mal eben" Code, der die C-Standardfunktionen nutzt, in eine Amiga-shared-Library packen ist nicht drin. Aufwand wirst Du so oder so haben, wann immer Du Code fabrizierst, der vom Standardvorgehen bei der Programmierung in C abweicht (geteilter Code ist so ein Abweichung).

Ok, manchmal übernehmen die Entwickler des Betriebssystems den Aufwand für Dich und basteln, naja, interessante, Lösungen dazu, aber für AOS 68k fällt das auf alle Fälle flach, da passiert in dieser Richtung wohl eher nichts mehr.

Da mußt Du Dir dann die Frage stellen, ob Du den Aufwand (der bei gut durchdachtem Aufbau wirklich nicht gewaltig ist) treiben willst oder eben nicht. Hier kann Dir diese Entscheidung niemand abnehmen, nur Wege aufzeigen, wie Du Dein Ziel eben doch erreichen kannst. Allerdings niemals ohne zusätzlichen Aufwand im Gegensatz zur Windows-DLL-Variante.
--
---

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

Zitat:

---

Original von Der_Wanderer:
Ok, also ich fasse zusammen:

Plain C verwenden, ohne jegliche Runtime. Also absolute Askese, das habe ich befürchtet.

Das lädt nicht gerade zum Entwickeln für den Amiga ein. Ich verstehe eigentlich gar nicht warum, steckt doch hinter einem fopen() letztendlich ein Open() der dos.library, was re-entrant ist. Irgendwo beim "einpacken" hat da doch jemand Bockmist gebaut.

---

Was hat es denn mit Amiga zu tun, daß die C-Runtimes oftmals nicht wirklich für Systementwicklung (und zu diesem Themenbereich gehören shared libraries auch) taugen und ein ziemlicher Aufwand drumherum betrieben werden muß, damit das doch "irgendwie" funktioniert?

Das Problem ist die Abhängigkeit der C-Standardfunktionen von bestimmten Kontexten des Runtime-Teils (startup code), die sich im AmigaOS halt nicht so einfach "mal eben teilen" lassen, wie schon erwähnt.

Es ist dabei ziemlich unerheblich, ob zum Schluß ein Aufruf einer OS-Funktion daraus kondensiert oder ob der Entwickler der C-Runtime wirklich alles selbst macht. Die Abhängigkeit der C-Standard-Funktionen von bestimmten Kontexten ist erst auf einer höheren Ebene gegeben, nicht zwangsläufig auf Ebene des Betriebssystems.

Kurz gesagt: AmigaOS kann nix dafür, daß C-Standardfunktionen so funktionieren, wie sie funktionieren

Du könntest aber zum Beispiel, wenn Du für Windows schon eine DLL bauen willst, für die Amiga68k-Fassung Linker-Libraries bauen, damit umgehst Du das Problem mit den vom Startup-Code abhängigen Funktionen quasi im Spaziergang. Nachteil ist halt, daß dann jedes Programm, daß Deine Funktionen nutzt, diese im Code mitschleppen muß. Wobei das für 68k-Code nicht wirklich ein Problem darstellen dürfte, da der Code oft recht klein ausfällt. Gerade bei so simplen Funktionen wie die, die Du hier gezeigt hattest. Kleiner als die Windows-Pendants dürften die Programme daher alle Male sein

Oder eben halt ein wenig #ifdef-Akrobatik und Verzicht auf printf() und Konsorten. Machbar ist das durchaus.

Davon mal ab, für OS4 z.B. hat man einen den DLLs extrem ähnlichen Mechanismus eingeführt, und irgendwo ist das ja immer noch ein bißchen Amiga...
--
---

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

Zitat:

---

Original von Der_Wanderer:
@whose
> So triviale Sachen gehen ohne Probleme,
Also laut Holger geht das dann wohl doch nicht ohne Probleme?

---

Erst, wenn Du das in eine Amiga shared library "verpflanzt". Aber auch hier gilt, was akl schon ausführte. Kurz gesagt: "Hängt davon ab"

Ich dachte, es ginge erst einmal primär um das Funktionieren dieses Codes an sich, ohne Spezialitäten wie "ich bastel eine Amiga shared library daraus". Dazu habe ich aber auch was gesagt Spätestens, wenn Du eine shared library/DLL daraus machen willst, wirst Du um die #ifdef/makefile-Orgien nicht herum kommen. Das geht ja schon bei Dingen los, die erst einmal gar nichts mit Deinem Code zu tun haben, Init usw.

Bei Libraries, die systemabhängig sind, gibt es eigentlich immer Probleme mit den Funktionen der C-Linker-Library, sofern diese bestimmte Voraussetzungen nicht erfüllt. Es gibt Gründe für die "Erfindung" von clib2/newlib und wie sie alle heißen...
--
---

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

Zitat:

---

Original von Der_Wanderer:
In dem Code sind erstmal keinerlei OS Abhängigkeiten drin.
Das einzige was ich brauche ist Datei I/O und Speicher allocieren.

---

Zitat:

---

code:

---

/* free a string */
void str_free(str &string) {
  if (string) {
    free(strH(string));
    string=NULL;
  }
}

---

Geht das unter Amiga ohne Probleme? Ich möchte auch keine rießen Makefile Orgien, damit kenne ich mich gar nicht aus. Unter Windows benutze ich Visual Studio, da wird man von sowas gottseidank verschont.

---

Zitat:

---

Am Ende soll das auf dem Amiga eine Shared Library werden. Unter Windows eine DLL.

---

Zitat:

---

GCC habe ich gcc version 2.95.3.

Wenn ich C++ nehme, dann sollte ich am besten alle source files C++ machen und nicht mischen, oder? Unter VS ist das kein Problem, aber "per Hand" wäre das wohl komplizierter zu linken(?).

---

Hängt davon ab, wie Du das compilierst. Schau Dir mal die Doku zu gcc/g++ an. Da findest Du auch einiges über das "Mischen" von Code und die Linkerproblematik.
--
---

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

Zitat:

---

Original von Reth:

Zitat:

---

Original von whose:
Layer helfen Dir dabei, indem sie ... in bestimmten Fällen die Restaurierung des betroffenen Bereiches selbständig durchführen.

---

Das würde schon helfen! Wie kann ich das nutzen? Zur Erhaltung des Hintergrundes würde das schon viel bringen, da dieser am häufigsten restauriert werden muss. Andere Objekte überdecken sich gegenseitig seltener!

---

Wie das genau funktioniert habe ich noch nicht erforscht... im Endeffekt ist es aber das, was bei SmartRefresh-Fenstern den Refresh besorgt (Kopieren des betroffenen Bereichs in eine temporäre Bitmap und Wiederherstellung des Hintergrunds aus dieser).

Es wird Dir nur "helfen", wenn Du (wie schon erwähnt) rechteckige Bereiche zu restaurieren hast. Allerdings glaube ich, daß Du die gleiche Funktionalität schon in Deinem Code hast, nur für nicht-rechteckige Bereiche.

Ich kann es nur nochmals betonen: Die Feststellung der Überdeckung dürfte höchstwahrscheinlich nicht das eigentliche Problem sein. Auch die Restauration (sprich: Ermittlung zerstörter Bereiche und Auslösen des Neuzeichnens) als solche kannst Du vermutlich nicht entscheidend beschleunigen, selbst das OS kocht nur mit Wasser

Du mußt Dir wohl noch einige Gedanken darüber machen, wie Du möglichst viele rechteckige Blits bekommst statt der maskierten Blits.

--
---

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

Zitat:

---

Original von Reth:
@whose:

Das Einzige, was mir noch einfällt wäre "Zusammenfassen".

Z.B. den Hintergrund immer als Ganzes Bild irgendwo vorzuhalten (es ändert sich während einer Spielrunde ja nicht) und dann entweder immer einen rechteckigen Ausschnitt daraus zu blitten (ohne Maske), oder das ganze Bild (was aber wieder viel zu viel wäre).

---

Zitat:

---

Daher auch meine Frage, ob Layer und ClipRegions nicht eine Art Schutz bieten, so dass ich den Hintergrund nicht immer neu blitten muss, wenn sich ein darüber befindliches Objekt ändert, einfach weil beide in unterschiedlichen Layern liegen!?

---

So einfach ist die Sache leider nicht. Dein Screen ist eine große Bitmap. Eine einzige. Das bedeutet, was immer Du auch an Grafik auf diesen Screen bringst (Fenster, BOBs), es hinterläßt Spuren in der Bitmap des Screens. Sobald Du an dieser Stelle erneut etwas änderst, zum Beispiel die vorher eingebrachte Grafik wieder rausnimmst, mußt Du die Bitmap des Screens restaurieren, um das ursprüngliche Aussehen zurückzuerhalten.

Layer helfen Dir dabei, indem sie die Verwaltung der Koordinaten des von einer Zeichenoperation betroffenen Bereichs für Dich übernehmen und sogar in bestimmten Fällen die Restaurierung des betroffenen Bereiches selbständig durchführen. Sie können aber nicht verhindern, daß die Bitmap des Screens verändert wird. Oder das "darüber" liegende Objekte, die von einem weiteren verdeckt werden, nach Löschen des weiteren Objekts ebenfalls "zerstört" sind. Im Endeffekt ist ja alles nur eine einzige Bitmap, die Du auf dem Bildschirm siehst.

ClipRegions wiederum verhindern nur, das Bereiche außerhalb eines von Dir definierten Bereichs von Änderungen betroffen werden. Sie begrenzen schreibende Pixel-Operationen auf von Dir bestimmte Koordinaten. Innerhalb dieser Koordinaten wird die Screen-Bitmap durchaus verändert, so daß Du sie ebenfalls wieder restaurieren mußt.

Das ist auch der Grund, weshalb ich meinte, daß Dein Algorithmus zur Ermittlung der zerstörten Bereiche und der Blit-Reihenfolge zur Restauration u.U. schon ziemlich optimal ist. Oder zumindest geschwindigkeitsmäßig ausreichend.
--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Da bringt es ihm dann nicht viel, wenn er den Flaschenhals in der Tiefensortierung seiner Grafikobjekte vermutet, obwohl er eigentlich ganz woanders steckt und sein eigener Algorithmus zur Objektsortierung möglicherweise schon effizient genug ist, oder?

---

Es geht ja nicht um den Algorithmus zur Sortierung (die Objekte müssen so oder so sortiert vorliegen), sondern darum, dass man mit dem richtigen Algorithmus unterm Strich möglicherweise weniger Pixel transferieren muss, wovon man gerade dann profitiert, wenn der Transfer so langsam ist.

---

Hm, entschuldige, ich habe verdrängt, daß Du das Projekt von Reth nicht ganz so gut kennst.

Die Grafik setzt sich eigentlich hauptsächlich aus Bitmaps zusammen, die maskiert geblittet werden müssen, weil sie eben nicht rechteckig sind und zusätzlich sehr viele Überlagerungskombinationen bestehen.

Deswegen meinte ich, daß er, wie ausgefuchst der Algorithmus für die Blit-Reihenfolge auch sein mag, kaum Geschwindigkeitsgewinn bekommen wird. Die Möglichkeiten, maskierte Blits einzusparen, sind einfach an Zahl viel zu gering.

Ich habe mir dazu schon Gedanken gemacht heute, aber ich kam nicht auf sehr viele Einsparmöglichkeiten. Das Beste, was mir einfiel, war, bei den Hex-Tiles mit rechteckigen Unterteilungen zu arbeiten.

Da die Hex-Tiles selbst unterschiedlich in der Farbgebung sind und sich teilweise überlappen (Tile-Transition), wird das Blitten dann zwar etwas leichter, dafür der Rest doch arg kompliziert. Er müßte alle möglichen Transition-Kombinationen vorhalten, die einzelnen Rechtecke, die diese Kombinationen dann darstellen, extra verwalten usw. usw.

Meiner Meinung nach ist es daher sinnvoller, mehr Denk-Aufwand in die Übertragung der Grafiken ins Bild zu investieren. Sprich, eigene "Blit"-Funktionen zu entwickeln, die die beschriebenen Schwächen der graphics.library-Funktionen eben nicht haben.

Ist auch nicht wirklich einfacher, ich weiß... ist das Beste, was mir bisher dazu einfiel.

Ich bin mir sicher, wenn jemand mit einer anderen, brauchbaren und trivialen, Idee um die Ecke kommt, wird Reth ihm nicht böse sein
--
---

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

Zitat:

---

Biologisch gesehen ist Selbstbefriedigung nach Kastration natürlich noch möglich, stimmt.

---

...und spätestens ab jetzt zieht die Argumentation mit dem Oxymoron nicht mehr. Wundert mich eigentlich, daß die zahlreichen Gebildeten hier noch nicht darauf gekommen sind.

Du versuchst, aus welchen Gründen auch immer, die, in Anbetracht der Geschichte der letzten 10 Jahre durchaus vorhandene, Möglichkeit der Herabwürdigung der potentiellen Posterkäufer mit Hilfe von (höchstwahrscheinlich unwillentlicher) Ignoranz zu verneinen. Christoph tat das Gleiche.

Es spielt letztendlich keine Rolle, ob der Schreiber sein exzellentes Wissen über Rhetorik ausspielen wollte oder nicht, er hat schlußendlich durch seine (möglicherweise vorgetäuschte) Unwissenheit in Sachen Biologie eine Herabwürdigung Dritter produziert und damit objektiv gesehen keineswegs nur ein Objekt bezeichnet. Auf gut Deutsch: rhetorisches Eigentor. Oder tatsächlich Beleidigung Dritter. Wir wissen ja nicht wirklich, was uns der Autor damit sagen wollte

Unter normalen Umständen hätte der Post ebenfalls gelöscht werden müssen. Auf Nachfrage hätte man diesem brillianten Rhetoriker dann sagen können: "Dumm gelaufen, Du hast Dir selbst ins Knie geschossen, Rhetorik-Ass und Biologie-Unwissender. Nimm das nächste Mal ein weniger provokatives Oxymoron aus einem Gebiet, in dem Du Dich wirklich auskennst".

Meiner Meinung nach hätte das selbst dann geschehen müssen, wenn der Moderator möglicherweise selbst Biologie-Unwissend ist. In vielen, vielen anderen, ähnlich zweischneidigen, Fällen hat Christoph contra den Poster moderiert, wieso nicht auch hier?

Nach meiner Meinung passierte dies vor allem deswegen nicht, weil Christoph im Grunde der gleichen Meinung ist. Seine Ansichten über das Produkt, dem das Poster gewidmet ist, als auch über die potentiellen Käufer hat er in den letzten Wochen des öfteren zum Ausdruck gebracht. Halt nur nicht in dermaßen provokanter Form.

Ich will ihm die Meinung keineswegs in Abrede stellen, falls das jemand vermuten sollte. Ich sage nur, daß er sich nun von seiner Meinung in der Moderationstätigkeit beeinflussen ließ.

Kann passieren, aber er sollte diesen Thread hier auch mal als bedenkenswerte Kritik betrachten und nicht einfach wie gewohnt abbügeln.

Zitat:

---

Diese Unwissenheit des Autors des Spruches ändert aber IMHO nichts daran, dass es ihm nicht um das Sexualleben der Posterkäufer ging, sondern um die "blumige" Darstellung seiner Meinung zum Poster, also auch nicht offtopic. Überlege dir einfach mal, was die Formulierung "Wichsvorlage für Kastrierte" von beispielsweise "Wichsvorlage für Idioten" semantisch unterscheidet, dann fällt hoffentlich der Groschen.

---

Wie gesagt, da "Wichserei" Kastrierten durchaus möglich ist und "Kastrierte" gar kein soooooo seltenes Schimpfwort ist, mußt Du schon eine arg rosa gefärbte Brille auf haben. Erst Recht, wenn man die altbekannten Diskussionverläufe zum Thema "X1000", "OS4", "Hyperion" usw. usw. usf. mit in Betracht zieht. In Anbetracht dieser Geschichte nicht von einer Böswilligkeit des Autors auszugehen ist irgendwie päpstlicher als der Papst

Könnte natürlich auch sein, daß Du vor lauter Freude, ein so tolles Oxymoron entdeckt zu haben, den Rest übersehen hast, ähnlich wie der Urheber dieses Schein-Oxymorons. Blöd nur, daß es, vollständig betrachtet, halt kein Oxymoron ist sondern, wenn überhaupt rhetorisch gemeint, ein rhetorischer Unfall.

Eine Löschung mit evtl. folgender Begründung hätte diesem Rhetorik-Künstler vielleicht sogar dabei geholfen, seinen Fertigkeiten noch mehr Feinschliff zu geben.

Ist zumindest eine Überlegung wert, finde ich...
--
---

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

Zitat:

---

Original von Reth:
@whose:

Hmpf! Na toll! Heisst das, ich sollte ne Fallunterscheidung programmieren für Amiga-native Screens und RTG-Screens oder 2 Executables machen?

---

Zitat:

---

Dann sollte ich die BitMaps nicht auf diese Weise anlegen, auch wenn der Nutzer mal einen AGA-Screen nutzen will?

---

Zitat:

---

Zitat:

---

Original von whose:
Meiner Meinung nach solltest Du Dich mehr darauf konzentrieren, so wenig wie überhaupt möglich durch Masken zu blitten.

---

Was wäre dann die Alternative?

---

Gute Frage... das hängt von Deinen Grafiken ab. Bei den Sechsecken ist allerdings schon Essig mit ohne Maske...

Zitat:

---

Vom direkten Programmieren des GraKa-Speichers hab ich keinerlei Ahnung, v.a. nicht, wie dabei solche Dinge wie maskiertes Blitten umgesetzt werden sollen.

---

Zitat:

---

Zitat:

---

Original von whose:
Erwarte aber keine Wunder auf Z2-Systemen

---

Ich habe bei meiner ersten Version Performanceprobleme auf einer CSPPC mit 060 und CVPPC gehabt. Also mehr geht ja für AOS3.x auf Amigas schon nicht mehr!

---

Schon richtig. Aber bedenke auch, daß Du enorm viel maskierte Blits laufen hattest, die durch die Verwendung des "normalen Weges" schon nicht gerade rekordverdächtig schnell waren. Eher im Gegenteil.

Bei Amijeweled paßt die Geschwindigkeit noch so eben gerade mit dieser Konfiguration, selbst unter OS4 ists gerade noch schnell genug, damit keine Langeweile aufkommt. Ich bin mir aber sehr sicher, daß da noch einiges zu holen wäre, wenn man auf die maskierten Blits der graphics.library verzichtet und statt dessen bspw. RLE-codierte Grafiken verwendet.
--
---

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

Zitat:

---

Original von Holger:
@whose:
Was Du schreibst, ist ja alles richtig. Aber ändert letztendlich nichts daran, dass ein Spiel, das nunmal nicht nur rechteckige Objekte besitzt (wie sähe das denn aus...), diese Objekte irgendwie zeichnen muss. Und egal, ob die Routine zum Zeichnen eines Objekts den Blitter oder die CPU, Chip-, Fast- oder VideoRAM verwendet, ändert das nichts daran, dass um diese Routine herum ein Algorithmus gebaut werden muss, der alle Objekt zeichnet, bzw. aktualisiert und das möglichst effizient.

---

Das will ich Reth ja auch gar nicht ausreden Er und ich haben uns schon vor längerer Zeit mal über das Thema unterhalten, nur war mir damals noch nicht bewußt, wie bescheiden RTG in Sache Blitten arbeitet.

Da bringt es ihm dann nicht viel, wenn er den Flaschenhals in der Tiefensortierung seiner Grafikobjekte vermutet, obwohl er eigentlich ganz woanders steckt und sein eigener Algorithmus zur Objektsortierung möglicherweise schon effizient genug ist, oder?

Ist aber sicher nicht verkehrt, wenn Du ihm da ein bißchen Hilfestellung gibst bzw. über die Schulter schaust
--
---

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

Zitat:

---

Original von McFly:
@Dennis_50300:

Moin Dennis,

danke für das Angebot
Wie sieht es aus wenn mein WLan mit TKIP+AES verschlüsselt ist, da weiß ich nämlich auch nicht wo man das in Genesis bzw. Miami einstellen kann?

---

Schlecht, weil das bedeutet, daß Dein WLAN mittels WPA/WPA2 verschlüsselt ist und das prism.device nur WEP beherrscht. Einstellen kann man das über die Konfiguration des prism.device, nicht über den TCP/IP-Stack. Leider haben wir da nichts wirklich aktuelles zur Zeit

Zitat:

---

Daher wäre mir lieber eine schnurgebundene Karte, da der Rechner am Schreibtisch direkt neben dem Router steht.

---

Du hast Post
--
---

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

Zitat:

---

Original von AndreasM:
Wenn ich sage ich habe das wegen Grund A gemacht und dann kommt jemand und sagt dass das gar nicht stimmt, ich hätte andere Gründe gehabt... werde ich dann etwa nicht der Lüge bezichtigt?

---

Nicht zwingend. Es ist auch möglich, daß Dir dieser Jemand andeuten will, daß Du Deinen eigenen roten Faden verloren hast.

Du wärst nicht der erste, dem das passiert.

In manchen Zeiten kommt so viel krudes Zeug über einen, daß man schnell den eigentlichen Auslöser eines großen Ärgernisses verdrängt und/oder schlicht vergißt, sich, quasi der Masse der aktuell erdrückenden Negativ-Erlebnisse ergebend, auf die aktuell entstehenden Ärgernisse konzentriert und diese dann als "Auslöser" irgendeiner Aktion betrachtet.

Ich glaube, Psycho-Leute bezeichnen das als "teilweisen Verlust der Selbstwahrnehmung". Ist keinesfalls beleidigend gemeint, nicht, daß Du mich hier mißverstehst. Mir ist das auch schon widerfahren und ich habe nicht schlecht gestaunt, als es mir klipp und klar von Dritten vor Augen geführt wurde.

Von selbst hätte ich das aber nie erkannt, denn meine Selbstwahrnehmung war ja teilweise gestört.
--
---

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

Zitat:

---

Original von Maja:

Zitat:

---

Original von Holger:
Allerdings habe ich auch schon von Autoren gehört, die null (in Zahlen: 0) positives Feedback für ihre Arbeit bekommen haben. Das allerdings auch schon vor und sowieso vollkommen unabhängig von Amiga-News.

---

Das Optimum ist erreicht, wenn der Support vor Langeweile eingeht.

Aber im Ernst. Wenn keiner sich meldet, gibt es wohl auch nichts zu meckern. Kann es positiveren Feedback geben als die vollkommene Abwesenheit von Beschwerden?

---

Na klar: positives Feedback

Zitat:

---

Klar, wenn jemand etwas primär macht, um gelobt zu werden, hat er natürlich auch dann ein mentales Problem, wenn keiner Danke sagt. Es ist aber leider meistens so, dass sich hauptsächlich Unzufriedenheit artikuliert.

---

Bei dieser Gelegenheit sollte man aber auch mal darauf hinweisen, daß selbst hier, auf der "pauschal bösen Diskussionsplattform AN", positives Feedback lesbar ist. Sogar für die hier "Betroffenen".

Ich denke, Sven hatte schon den Punkt getroffen. Man sollte, sofern psychologisch möglich, sich doch eher auf die positiven Ergebnisse seiner Arbeit konzentrieren. Wenn einem das nicht mehr möglich ist (aus welchen Gründen auch immer), sollte man ernsthaft darüber nachdenken, sich diese positive Sichtweise von jemandem zeigen zu lassen bzw. einen Weg, wie man wieder da hinkommt, die positiven Ergebnisse der eigenen Arbeit als Ziel aufzufassen.

Ist m.E. jedenfalls sinnvoller, als sich an den negativen Äußerungen (die allgemein ziemlich zugenommen haben aber oftmals keine wirklich bestimmte Richtung haben) festzubeißen und darüber die "dankbaren User" völlig aus den Augen zu verlieren. Von denen gibt es wesentlich mehr, als es scheint.
--
---

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

Zitat:

---

Original von j_heinrich:

Zitat:

---

Original von whose:
... sieht so aus, als wäre die Route nicht in Prefs/Internet geändert (unter Routes) worden

---

Das ist richtig. Ich frag mich nur, ob das so Konzept ist, dass man an mehreren Stellen herumschrauben muss, oder doch eher ungluecklicher Zufall bis schlecht ueberlegt? Wozu gibt es denn die Moeglichkeit eine neue Verbindung automatisch zu erstellen und DHCP zu verwenden, wenn er dann hinterher nicht den per DHCP vermittelten Router verwendet? Ueberseh ich irgendwas?

---

Zitat:

---

Aber sei's drum, wir werden die Hintergruende der Programmierer hier wohl nicht eroertern koennen. Ich spiel jetzt erst mal mit meinen beiden frischen NG-Amigas und schaue mal, ob ich damit Spass haben kann.

---

Och, ich glaube schon. Mit dem Peg vor allem. Ich habe nen MicroA1 und viel Spaß damit, läuft wirklich prima mit Update 1, sobald man die USB-Klippe umschifft hat. Sehr flott unterwegs, der Kleine
--
---

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

Zitat:

---

Original von j_heinrich:
Bingo! Jetzt lueppts!

Aber warum uebernimmt der Gute beim Anlegen einer neuen Verbindung mit DHCP eine feste Route von irgendwo anders her? Ist das ein Bug und einen Report Wert?

---

Eher nicht... sieht so aus, als wäre die Route nicht in Prefs/Internet geändert (unter Routes) worden
--
---

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