Zitat:

---

Original von AxleJackPad:
Also mal ganz ehrlich. Das was die Privaten senden ist doch eigentlich
nur total flaches Mainstream Programm. Egal was man davon betracht,
Nachrichten, Wisssenschaftssendungen, Serien, es handelt sich
doch nur noch um inhaltslosen Scheiß.
Ok, nach der 2000. Folge Unter uns muß man ja auch verblöden.
Dann benötigt man auch keine vernünftigen Nachrichten mehr.
Also für ein anständiges und unabhängiges Programm, ich sag nur
Berlusconi, zahle ich doch gerne was.

---

Zitat:

---

Und wenn man betrachte was
die Bundesliga bei Arena im Monat kostet, und was ich dafür
bekommen, dann sind die Öffentlichen doch eigentlich spottbillig.

---

Zitat:

---

Und weder die Polizei noch die GEZ haben einen Durchsuchungsbeschluß,
dafür benötigt man in unserem Lande noch immer einen Richter.
Für die Polizei gilt nur die Ausnahme, bei Gefahr im verzug. Und das
kann niemant mit einem laufenden Fernseher begründen.

---

Das ist Gott sei Dank auch immer noch der Fall (Änderung wurde Mitte der 80er einmal ernsthaft erwogen)... was die GEZ aber nicht davon abhält, die Mahnung und Vollstreckungsbescheide zuzusenden, selbst wenn Du denen gut verständlich darlegen kannst, daß die überhaupt keinen Anspruch auf die darin erhobenen Beträge haben.

Meiner Meinung nach ist es an der Zeit, diesen Gebührentopf endgültig abzuschaffen, da er immer stärker zu einem Selbstbedienungsladen verkommt. Die Gebühren sind zwar gestiegen, aber eine Verbesserung der Programmqualität war irgendwie nicht zu bemerken. Eher das Gegenteil.

Das hält die ÖR aber nicht davon ab, nach noch höheren Gebühren zu schreien und sogar Internet-Nutzer, die das Angebot der ÖR überhaupt nicht nutzen können, abzukassieren (was ist denn mit den Amiga-Nutzern, die keinen Windoof-PC besitzen? Sie können das Angebot (Dank Streaming im WMV-Format) gar nicht nutzen, müssen aber dafür zahlen. Sehr gerecht irgendwie. Normal sollte man die ÖR dazu verdonnern, auch diesen Leuten die Nutzung zu ermöglichen, sprich: WMV-Abspieler für AmigaOS "von der GEZ geproggt". Das wär doch mal was )

Grüße

--
---

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

Zitat:

---

Original von bubblebobble:
Ich plane damit auch ein Spiel, so ähnlich wie Feary Tale Adventure v(geht das in Richtung Ultima?),

---

Naja, irgendwo ähneln sich die Spiele dieser Art alle ein wenig

Zitat:

---

aber natürlich wesentlich aufwendiger, z.B. mit transparenten Leucht-Effekten, durchsichtiges Wasser und höherer Auflösung (evtl. 800x600) usw.
Das lässt sich damit auf jeden Fall realisieren, sodass es unter OS4, MOS, Amithlon und WinUAE läuft. Für den Classic wirds aber wohl zu langsam, dafür müsste man eine "Light" Version machen, ohne solche Transparenz Effekte, dann ginge es aber auch.

---

Zitat:

---

Das war auf dem Classic vor zehn Jahren nicht möglich, und ist heute auch nicht möglich, da die Hardware nicht durch ein Wunder über Nacht schneller wurde. Das sowas einfach Rechnepower braucht, sieht man an den SDL Games, und die sind sogar oft nur 320x240.

---

Zitat:

---

AsteroidsTR dagegen läuft auf einem Classic mit Graka sogar flüssig, obwohl es 640x480 ist und somit 4-fache Blit Power braucht.
(Anm: AsteroidsTR läuft mit den Routinen aus der image.inlcude)

---

Zitat:

---

Du wirst ja an den Demos sehen, ab wann Schluss ist. Die Demos in dem AB2 Archive steigern sich, vom simplen Ball-Hüpf Demo, über Scrolling, Alpha Blending bis zum rotierenden, texturierten 3D Cube.

Ich bin auch dabei, eine ISO Tile Engine zu schreiben. Evtl. wäre das was für dich.

---

Ja, die Demos werde ich mir mal genau ansehen. An eine ISO-Tile-Geschichte denke ich auch, aber das liegt derzeit erstmal hinten. Ich habe eine nette Kleinigkeit in Arbeit, die aber bisher wegen Zeitmangel etwas liegen geblieben ist. Das muß erst einmal fertig werden

Grüße

--
---

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

Zitat:

---

Original von bubblebobble:
@whose

Ja, sollte in der aktuellen distri drin sein.

Aber besser direkt von meiner HP:

http://www.hd-rec.de/Archive/TK_AB2_Sources.lha

Ok, aber für Classic könnte es doch etwas langsam sein.
Ich hatte das bisher nur unter WinUAE und Amithlon probiert.

In der Demos Schublade findest du einige Game-Demos, auch mit Aplha Channel. Aber sowas wie der 3D Cube wird auf jedenfall zu langsam sein.

---

Danke, das sehe ich mir dann mal an. Für ein Spiel ala Ultima sollte die Geschwindigkeit dann eigentlich reichen, selbst, wenn das betreffende Objekt ständig in Bewegung ist. Mein Ansatz war da anscheinend nicht wirklich gut, das schlich auch auf dem WinUAE eher vor sich hin...

Grüße

--
---

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

Zitat:

---

Original von bubblebobble:
In meiner image.inlcude (Amiblitz Befehlsbibliothek) habe ich das alles schon längst implementiert, also z.B. ein .png mit Alphachannel laden und in ein Fenster blitten mit Alpha Channel.

Es ist nur nicht Hardware beschleunigt. Es ist aber schnell genug für ein paar Sprites in Spielen oder für GUI Knöpfe.

---

Das würde mich interessieren... ist die aktuellste include schon in der letzten AB-Distri drin? Ich hatte mal Versuche in der Hinsicht gemacht, das war aber auf "richtigen" 68Ks doch etwas zu langsam für Spiele...

Grüße

--
---

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

Zitat:

---

Original von bubblebobble:
Ich evaluiere nur die Möglichkeiten. Bis jetzt bleibt mir nur das Schlupfloch, dass die Text Operationen grundsätzlich funktionieren, nur eben schwarz. Für meine speziellen zwecke reicht mir schwarz, aber da ich alles in Funktionsbiblitheken packe (Wiederverwertbarkeit!) wäre es schön, wenn alles so funktioniert wie es soll.

---

Ah, jetzt habe ichs... nun ja, der Weg steht wohl nicht für alle Systeme offen. Spätestens beim Thema Alpha-Channel mußt Du für 68K (bzw. OS2.x/3.x) eigene Wege gehen, da P96/CGFX sowas dort nicht direkt unterstützen. 8Bit-Alpha bietet meines Wissens derzeit auch nur CGFX für MOS an, OS4 bekommt das erst noch. Wie dort die Implementation aussieht, wissen vorerst aber wohl nur die Beta-Tester, wenn überhaupt.

Die Arbeit mit Paletten für Offscreen-Bitmaps ist ähnlich gelagert. Penoperationen waren für Offscreen-Bitmaps >8Bit (bzw. für Bitmaps ohne direkten Bezug zur graphics.library/Intuition) einfach nicht vorgesehen, dort sollten die 16/24Bit-APIs der RTG-Systeme dienen.

Für 68K siehts also in der Hinsicht etwas düster aus, leider. Ich könnte Alpha-Channel-Unterstützung >1Bit fürs Blitten auf 68K-Maschinen auch ganz gut gebrauchen, aber da ginge das Theater leider bei den älteren GraKas weiter, die sowas nicht unterstützen, selbst wenn es gute Alpha-Channel-Unterstützung durch P96/CGFX eines Tages gäbe...

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 22.08.2006 um 18:40 Uhr geändert. ]

Zitat:

---

Original von gni:

Zitat:

---

whose:
Man ging damals davon aus, daß sich für Modi >8Bit eins der P96/CGFX-eigenen APIs durchsetzt.

---

IMO hat sich das CGFX-API "durchgesetzt".

---

Zitat:

---

Zitat:

---

Blöderweise hat das nicht so wirklich funktioniert, weshalb u.A. die P96-Macher auf die Idee der Emulation der cybergraphx.library gekommen sind.

---

Denen blieb gar nichts anderes übrig als diese Emulation anzubieten. Zum Zeitpunkt von P96 war CGFX bereits ein Standard (da von "offizieller" Seite nichts mehr kommen konnte), für den es schon eine gewisse Zahl an Programmen gab. Den aussen vor zu lassen wäre reichlich dumm gewesen.

---

Ja, die "offizielle" Seite war das Problem, weshalb es immer noch zwei leicht unterschiedliche APIs gibt. Meiner Meinung nach war die Emulation nicht zwingend notwendig (auch beim RTG-System gabs ja zwei Lager, nicht nur bei PUP/WOS), aber, wie Du schon sagtest, es wäre reichlich dumm gewesen, diese Nutzer nicht auch noch "mitzunehmen".

Grüße

--
---

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

Zitat:

---

Original von bubblebobble:
@whose

Was schlägst du nun konkret vor ?

---

Zitat:

---

Was meinst du mit eigener Palettenverwaltung ?

---

Zitat:

---

Ich brauche 24bit Grafik Funktionen auf eine Bitmap, die nicht mit einem Viewport verbunden ist.

---

...und leider auch die anderen benötigten Zeichenfunktionen selbst implementieren oder so etwas wie ttf.library z.B. benutzen. Bietet guigfx eigentlich keine anderen Zeichenfunktionen? Ich hab mich damit noch nicht tiefer beschäftigt.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 22.08.2006 um 17:40 Uhr geändert. ]

Zitat:

---

Original von Ralf27:
Hm, stimmt schon. Hab hier auch im Handbuch was von"Garbage Collection" gefunden.

Ich sollte wohl wirklich in Zukunft solche Konstrukte lieber vermeiden.

---

Naja, die "Garbage Collection" gehört eigentlich zu jedem BASIC-Dialekt. Das Teil räumt einfach nur den Variablenspeicher auf, wenn selbiger knapp wird. Da wird bei Interpretern z.B. der ganze Kram nur neu geordnet (defragmentiert, sozusagen), um am Ende des Variablenbereichs wieder Platz für z.B. einen längeren String zu bekommen. Bei GFA war das Problem, daß auch temporäre Variablen im Variablenspeicher statt auf dem Heap landen (lokale Variablen hingegen nicht), so daß die temporären Variablen Speicher "geklaut" haben, den man nicht ausdrücklich freigeben konnte. Da kam die Garbage-Collection bei Programmen mit vielen temporären Variablen halt sehr oft zum Einsatz, was sich sehr negativ auf die Geschwindigkeit auswirkte. Beim Compiler war das kein Thema mehr, da dieser ja "voraussehen" kann, was mit verschiedenen Variablen gemacht wird und bei Bedarf einfach wieder Speicher vom System anfordern kann.

Das Konstrukt, was Du da verwendest, ist im Prinzip eigentlich schon nützlich, aber Du mußt darauf achten, wo Du es anwendest und wie es sich im weiteren Verlauf des Programms verhält (siehe das vorherige Posting). Da solltest Du also nochmal im Handbuch nachschlagen. Bei AmigaBASIC z.B. geht das irgendwann schief, auch wenn es da ab und an verwendet wurde (wenn auch eher selten in diesem Zusammenhang).

Grüße

--
---

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

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von Holger:
buffer1&=SADD(SPACE$(size&))
buffer2&=SADD(SPACE$(size&))

---

Hab es eben getestet und etwas interesantes festgestellt:
1. Die Daten werden wirklich hintereinander im Speicher abgelegt. Wenn z.b. size&=10 ist, dann ist buffer2&=buffer&+size&, um es mal so zu tippen. Laut Handbuch belegen die Strings einen Tabelle und von da aus geht dann wohl ein "Link" zu einem anderen Speicherbereich.

---

Ja, das ist normal. In BASIC werden Variablen halt in einer "Label-Tabelle" festgehalten (da ist auch der Speicherbedarf festgehalten), der eigentlich belegte Speicher einer Variablen befindet sich meist in einem gesonderten Bereich, dem Variablen-Bereich. Das ist u.A. der Grund dafür, weshalb die wenigsten Interpreter Strings von unbegrenzter Länge akzeptieren.

Daß bei Deinem Test die beiden Adressen schön geordnet hintereinander liegen, sagt aber noch nicht viel. Es ist halt die Frage, wo genau der Speicher dafür angefordert wurde und für welchen Abschnitt Deines Programms dieser Speicher "gültig" bleibt. Ist es der Variablenbereich, weiß der Interpreter/Compiler immer, wie lang der angelegte String ist, auch wenn der "Gültigkeitsbereich verlassen wird" (ich meine hier den Gültigkeitsbereich lokaler Variablen, temporäre Variablen, die in der Label-Tabelle erfaßt und im Variablenspeicher abgelegt sind, gelten für das ganze Programm oder global). Werden die beiden Strings auf den Heap geschmissen, weiß er das spätestens am Ende des Gültigkeitsbereichs nicht mehr und einer oder beide Strings werden irgendwann durch andere Werte überschrieben.

Da MB auch CONST unterstützt, gehe ich aber davon aus, daß es auch lokale Variablen unterstützt, die einen beschränkten Gültigkeitsbereich haben. Das dürfte dann auch auf die temporären Strings zutreffen. Genau das ist dann das gefährliche. Solltest Du den "Gültigkeitsbereich" dieser Strings verlassen und z.B. weitere temporäre Variablen anlegen, ist der Inhalt der beiden Strings für Dein Programm tabu bzw. Du kannst nicht sagen, was sich bei einem erneuten Zugriff darin befindet.

Richtig haarig wirds dann, wenn Funktionen "von außen" darauf zugreifen müssen. Du mußt diesen Funktionen mit Deinem Programm garantieren, daß sich gültige Werte in diesem Speicherbereich befinden. Bei temporären Variablen mit eingeschränktem Gültigkeitsbereich kannst Du es aber nicht, wenn der Gültigkeitsbereich vor dem Aufruf der "Funktion von außen" verlassen wurde.

Grüße

--
---

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


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

Zitat:

---

Original von bubblebobble:
Ich glaube, ich weiss warum es nicht geht.
Wenn mich nicht alles täuscht, funktioniert Bernds AfA Penless Mode so:
Er merkt sich den RGB Wert irgendwo, den man mit SetRPAttrs() setzt.
Wenn jetzt eine Zeichenfunktion kommt, setzt er flux den Pen #1 auf den RGB Wert, zeichnet, und stellt den ursprünglichen RGB Wert des Pens #1 wieder her.
Bei 24bit Screens kann man diesen Trick machen, da sich eine Paletenänderung nicht auf die bestehenden Pixel auswirkt. Während der ganzen Zeit hält er den RastPort dann gelockt, so kann nichts passieren.

Ich denke das macht er so, weil ich keine andere Möglichkeit sehe. Wie soll AfA das sonst machen ? Für "echte" 24bit Grafikoperationen müsste man Picasso96 geändert werden, das kann man aus AfA heraus nicht machen.

Und weil eigentlich nur mit einem ganz normalen Pen gezeichnet wird, funktioniert das logischerweise auf einer Bitmap ohne Paletteninformation nicht.

Unter AROS, MOS und OS4 könnte es aber funktionieren.

---

P96/CGFX waren auch ursprünglich nicht dafür ausgelegt, voll kompatibel zum Paletten-System zu bleiben, daß bis dahin aktuell war. Man ging damals davon aus, daß sich für Modi >8Bit eins der P96/CGFX-eigenen APIs durchsetzt. Blöderweise hat das nicht so wirklich funktioniert, weshalb u.A. die P96-Macher auf die Idee der Emulation der cybergraphx.library gekommen sind.

Dieser Weg bliebe Dir auch noch offen, was aber mehr Arbeit mit sich bringen würde (u.A. eigene Verwaltung der Palette für Screens > 8Bit). Allerdings wärst Du damit auf einer relativ sicheren Seite, denn nicht jeder wird sich auch noch AfA installieren wollen (OS3.9-User z.B.). Unter MOS/OS4 funktionieren die RTG-APIs ja weiterhin wie in alten 68K-Zeiten, was Modi >8Bit betrifft.

Grüße

--
---

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

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von Holger:
Ja, perfekt, wenn Du einen String in a$ gespeichert hast. Wir reden hier aber von buffer&=SADD(SPACE$(size&)), einem String, der in keiner Variablen gespeichert ist. Du kannst ihn nicht durch eine erneute Zuweisung freigeben, weil es gar keine zugehörige Variable gibt. Dieser String ist bereits freigegeben, oder aber Du hast ein Speicherloch.

---

Hm, sorry, aber erst jetzt versteh ich das Problem. Stimmt, das kann ich nicht zweifelsfrei belegen. -> merken und umbauen. Danke.

Ich werd da bald mal ein testprogramm schreiben und mal sehn was da abgeht. Also die zeile wie sie da oben steht und dann wild variablen anmelden, etc. und dann mal nachsehn was da noch im buffer& steht.

---

Ich denke, mit dem Test wirst Du nicht viel Erfolg haben. Die meisten BASIC-Dialekte trennen Variablenspeicher und Heap (also den Speicher für temporäre Variablen und anderes "unwichtiges" Zeugs wie Stringkonstanten, die existierenden Strings zugewiesen werden. BASIC-Compiler arbeiten meist aber gar nicht mit einem Heap im klassischen Sinn sondern nur mit Variablenbereich und Stack).

Erzeuge mal nen Haufen Strings, denen laufend andere Stringkonstanten "zugewiesen" werden (BASIC kopiert Strings meist), damit dürfte eher sichtbar werden, was mit Deinem temporären String passiert. Sollte Dein temporärer String weiter intakt bleiben, darf man davon ausgehen, daß MB für diesen Zweck einen "unsichtbaren" String im Variablenbereich anlegt, der bis zum Ende des Programms Gültigkeit besitzt (und dessen Speicher somit nicht ausdrücklich vom Programm selbst freigegeben werden kann -> dumme Sache). GFA hat z.B. auch so gearbeitet.

In AmigaBASIC ist so ein Ding (temporärer String ohne Bezeichner) meist geplatzt.

Grüße

--
---

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


[ Dieser Beitrag wurde von whose am 22.08.2006 um 15:17 Uhr geändert. ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von Ralf27:
Es ist gut beschrieben wie der Compiler mit Strings umgeht. Der Amigabasic-Interpreter läuft da auch so. Bzw. war es früher eine "unart" es genau so zu machen wie ich das da oben mach. Mir ist klar das es eine Unart ist, aber diese Vorgehensweise ist bei den beiden gennannten Dialekten "legal". Aber das frist dann Stack, was mir auch klar ist. AllocMem ist da eleganter...

---

Ich glaube Dir ja, dass es gut beschrieben ist. Du sagst aber nicht, wie es nun funktionieren soll. Dass Strings auf den Stack gelegt werden, kann ich Dir so nicht glauben. Oder aber Du hast bei der Beschreibung etwas nicht richtig verstanden. Auf den Stack werden temporäre Werte gelegt. Die werden normalerweise direkt nach Abschluss der Operation freigegeben, d.h. wenn Du den Rückgabewert von SADD() an buffer& überweist, ist der temporäre String, dessen Adresse Du gerade ermittelt hast, schon Geschichte.

So funktioniert ein Stack. Daten auf den Heap können eine längere Lebenszeit haben, aber dass Basic unbenutzte String nie freigibt, ist genauso unwahrscheinlich. Also versuche, die Frage zu beantworten:
Wann wird dieser String, der in keiner Variablen gespeichert ist, freigegeben?

---

Soweit ich mir das noch in Erinnerung rufen kann, dürfte dieses Konstrukt platzen. Der temporäre String, den Ralf da verwendet, müßte im Heap landen (die meisten BASICs legen Strings nie auf dem Stack ab, Ausnahme BB) und direkt nach Ermittlung der Adresse wieder dem freien Bereich des Heaps zugeordnet werden. Das das ne Weile funktioniert, liegt schlicht daran, daß in BASIC eher selten temporär Speicher benötigt wird (normal landen Strings/Variablen in BASIC auch nicht im Heap). Irgendwann knallt das aber. Daher hat Ralf mit "Unsitte" gar nicht so Unrecht. Es ist eher Zufall, daß das funktioniert

Grüße

--
---

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

Zitat:

---

Original von gni:

Zitat:

---

whose:
Das man sich den GCC "kaputtpatchen" kann, steht außer Frage. Das geht allerdings nicht nur mit der clib2, das geht auch schon prima beim Bau eines Crosscompilers. Noch schlimmer, wenn selbiger mit einem Crosscompiler erzeugt wird.

---

Komm zurück auf den Teppich. Hast Du das von Dir beschriebene Szenario schon mal durchexerziert?

---

Zitat:

---

Zitat:

---

Die Formalismen-Geschichte: Schau Dir an, wie der GCC funktioniert und wie die ganzen C- Perl- und was was ich noch alles für Dateien aufgebaut sind, die letztendlich einen (hoffentlich) funktionierenden GCC ergeben, dann weißt Du, was ich meine.

---

Seit wann braucht es Perl um den GCC zu bauen? Am besten Du verkneifst Dir Aussagen zum Erstellen des GCCs. So schwer kann es nicht sein, da es meines Wissens funktionierende Versionen für AmigaOS/m68k gibt. Auch für dessen PPC Aufsätze soll es welche geben.

---

Man beachte das "was weiß ich". Perl ist nur ein Beispiel.

Das es schwer bis unmöglich ist, habe ich nie behauptet. Schwierig bis kompliziert ist es, das wirst Du wohl nicht abstreiten können. Oder woher kommen die vielen Fragen zu dem Thema?

Grüße

--
---

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

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Hm, also vbcc übersetzt das ohne zu mosern, gcc auch (C99 Modus).

---

Darum geht es ja. Es gibt keinen logischen Grund, auf die Features des C99-Standards zu verzichten. Auch wenn noch nicht alle unterstützt werden. Die wesentlichen von Solar genannten Punkte können schon heute <auch auf dem Amiga> verwendet werden.

---

Sorry, ich hab das wohl ein wenig fehlinterpretiert. Zeitweise klang es so, als wäre C99 auf dem Amiga nicht in der vom GCC gewohnten Form möglich (daß der nicht alles brav nach Standard unterstützt ist ja ein anderes Thema).

Das man sich den GCC "kaputtpatchen" kann, steht außer Frage. Das geht allerdings nicht nur mit der clib2, das geht auch schon prima beim Bau eines Crosscompilers. Noch schlimmer, wenn selbiger mit einem Crosscompiler erzeugt wird. Da den Überblick zu behalten ist sicher nicht jedermanns Sache, da es ja eigentlich darum geht, etwas anderes mit dem Werkzeug Compiler zu machen.

Manchmal kommt beim gcc aber das Gefühl auf, daß der reiner Selbstzweck ist bzw. man erst Compilerexperte sein muß, um ein recht simples C-Programm (wahlweise alle unterstützten Sprachen hier einsetzen) damit schreiben zu dürfen.

Die Formalismen-Geschichte: Schau Dir an, wie der GCC funktioniert und wie die ganzen C- Perl- und was was ich noch alles für Dateien aufgebaut sind, die letztendlich einen (hoffentlich) funktionierenden GCC ergeben, dann weißt Du, was ich meine.

Grüße

--
---

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

Zitat:

---

Original von Holger:

Für mich reicht es, wenn z.B. vbcc folgenden code im C99 Modus korrekt übersetzt.

C code:

---

#include <stdint.h>
#include <stdio.h>

inline void out(char const * const txt, int8_t const num)
{
  printf("%st%dn", txt, num);
}

int main(void)
{
  for(int8_t i=0; i<10; i++)
    out("hello ", i);
  return 0;
}

---

Man kann sich natürlich auch noch die nächsten Jahrhunderte selbst kastrieren, weil es irgendwo da draußen einen compiler gibt, der irgendetwas nicht kann. Während die compiler-Entwickler, falls denn dieser compiler noch weiterentwickelt wird, auch weiterhin nicht an der Standard-Unterstützung arbeiten, weil ja keiner diese features benutzt...

---

Hm, also vbcc übersetzt das ohne zu mosern, gcc auch (C99 Modus). Irgendwie finde ich es verdreht, über solche Klamotten zu diskutieren, so zu tun, als ginge das alles nicht mit den AmigaOS-Compilern, die noch verfügbar sind und immer noch weiterentwickelt werden, und darüber das eigentliche Problem völlig zu übersehen.

GCC ist und bleibt ein echtes Monster, dessen Wartung, Anpassung an "desolate" Plattformen und Verbesserung alles andere als eine simple Aufgabe ist. Wenn dann noch eine (mehr oder weniger) eigene Laufzeitumgebung ins Spiel kommt, wird die Geschichte noch viel unübersichtlicher. Da helfen einem Sprachstandards und neckische Möglichkeiten derselben relativ wenig. Das bleibt Sache der Compiler-Plattform, nicht des Systems, auf dem diese dann laufen soll.

Wenn man dann nur über die "Unzulänglichkeiten" von AmigaOS diskutiert bringt das echt wahnsinnig viel. Wenn man dazu in der Lage ist, möge man sich hinsetzen und die entsprechenden Anpassungen für gcc machen, das bringt wesentlich mehr, oder nicht?

Was mich aber etwas erstaunt: niemand meckert darüber, daß für das Bauen des GCC so viele der hier angesprochenen "Tricksereien" notwendig sind, um die Formalismen, auf denen GCC basiert, an die Realität anzupassen...

Grüße

--
---

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

Zitat:

---

Original von Daniel01:


Ha, habe nochmal alles mit Genesis (OS3.9) mit dem Wizzard neu eingerichtet und wieder getestet.

Hey, das geht auf einmal echt supi ab.

Habe wieder mit IBrowse (Vollvers) über http://www.wieistmeineip.de (das soll laut Telekom Störstelle der beste und genaueste online Speedtest sein) den Speed getestet und als Ergebniss nun folgendes erhalten.

Sage und schreibe 4.790 kbit/s = 598kBytes/s.

Na das ist doch schon besser als vorher und man merkt es auch wirklich sofort im Internet an der Geschwindigkeit.

Aber man ist ja nie zufrieden da ich ja DSL 6000 habe, da müßte doch eigentlich noch ein kleines bissel was mehr drin sein

---

Unwahrscheinlich. So ein klein wenig ist die Bremse bei den meisten DSL6000 dann doch angezogen Ich kenne jedenfalls sehr wenige Anschlüsse, die tatsächlich die vollen 6MBit herausgewürgt kriegen.

Zitat:

---

Vieleicht experimentiere ich mal noch ein bissel mit Genesis rum und versuche, das ich das eine oder andere Byte/s noch rausholen kann.

Frage mich allerdings nur, warum Genesis da so reibungsloß funktioniert wo doch bei den Router eindeutig steht, das ich darauf achten muss, das IP- und DNS-Server-Adressen automatisch über DHCP bezogen werden.

---

Zitat:

---

Ich habe da bei Genesis in den Prefs nichts dergleichen gefunden, wo ich das einstellen kann oder macht das Genesis automatisch?

---

Zitat:

---

Auf jeden Fall brauche nun nur einen Browser zu öffnen und auf einen Fastlink zu klicken oder eine URL einzugeben und der Router geht sofort online. Das selbe wenn ich Yam öffne und auf holen oder senden klicke.

Glaube jetzt schon, das da MiamiDX die ganze Zeit schon die Bremse war selbst als ich noch mit der X-Surf unterwegs war und dann mit der PCI-10/100 Ethernetkarte.

---

Zitat:

---

Ist wohl doch schon zu alt das Prog. und wurde ja nie großartig weiter entwickelt weil wohl gerade zu beginn der DSL-Zeit aufgegeben obwohl er damit heute sicherlich den einen oder anderen Euro hätte mit machen können.

Nun ja, wie dem auch sei, da kann man nur noch hoffen, das bald die OS4.0 für BPPC raus kommt. Da soll ja ein PPC-TCP Stak mit bei sein.

---

Ja, Roadshow. Der ist sehr flott.

Grüße

--
---

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

Zitat:

---

Original von MaikG:
>Diese Erfahrung mußte ich gestern jedenfalls machen: Meinen PC
>hat's erwischt.

Sollten PCs sich bei übertemperatur nicht abschalten?

---

Naja, wenn die Übertemperatur tatsächlich die CPU betrifft, tun die meisten PCs das auch. Wenns die Kisten dahinrafft, ist es meist das Netzteil. Bei nem abfallenden Kühler stehen die Chancen für ein gesteuertes Abschalten natürlich schlecht

Grüße

--
---

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

Zitat:

---

Original von Daniel01:
@whose:

nun, in der Anleitung des Routers steht, "Vergewissern Sie sich, dass die Netzwerkeinstellungen des Computers korrekt sind.Mit dem Router verbundene Computer müssen so Konfiguriert sein, dass IP- und DNS-Server-Adressen automatisch über DHCP bezogen werden" .

Wollte mir eigentlich zuerst den Router Teledat 800 kaufen weil da auch das Modem gleich mit drin ist.

Na mal schauen, vieleicht mache ich das ja doch noch einfach mal um es tu testen.

---

Hab ichs doch gewußt, daß die wieder an sinn- und planlosen Stellen mit dem Sparen anfangen Normalerweise ist DHCP bei Routern ein Komfort-Feature für kleinere Netze, welches in größeren Netzen durchaus Ärger bereiten kann. Daher ist es in älteren Routern durch die Bank so, daß DHCP extra zugeschaltet werden muß, wenn überhaupt gewünscht (ja, es gibt tatsächlich Fälle, wo sowas unerwünscht ist. Wechselnde, netzinterne Webserver zum Beispiel).

Daß die jetzt damit anfangen, feste IP-Bereiche in der Routerverwaltung abzuschaffen, konnte ich allerdings nicht ahnen, bisher hatte ich mit einem NetGear noch nicht zu tun (was unter anderem damit zusammenhängen könnte ).

Nun ja, Du weißt ja jetzt, wo der Hase im Pfeffer liegt und für Deine Zwecke dürfte der Router trotz der Anlaufschwierigkeiten ausreichend sein. Die erreichbare Geschwindigkeit ist ja mehr eine Frage der verwendeten CPU, wie bereits erwähnt. Der Router sollte es schaffen, 10MBit als Mindestleistung darf man wohl auch bei so einem seltsamen Gerät vorraussetzen, das langt für DSL6000, sofern nicht ständig andere Rechner dazwischenfunken. Daran könnte aber auch ein anderer Router nichts ändern

Grüße

--
---

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

Zitat:

---

Original von Ivanhoe:
@whose:

>Sieht so aus, als meintest Du etwas völlig anderes.
>Hier geht es nun in der Hauptsache um die Hardware,
>alles andere ist quasi erledigt.

Du willst doch nicht damit sagen, das AOS4 derzeit fertig in der Schublade verstaubt? ;-)

---

Wenn man sich die Roadmap ansieht und mitbekommt, was die Betatester bereits laufen haben, könnte man das so sagen, in der Tat

Zitat:

---

>Bei der Hardware warten wir noch gar nicht so lange.

Es sei denn, man war bereit für viel Geld eine Hardware zu
kaufen mit einem Beta OS damals!
Also für Endanwender war der AOne ja nur bedingt tauglich
bez. machte es wenig Sinn AOS4 zu besitzen oder?

---

Das ist eine Frage des Standpunkts. Hier bei mir läuft der µA1 öfter und länger als alle anderen Maschinen. Sogar öfter als WinUAE, weil bedeutend schneller beim Compilieren

Für meine Situation kann ich ruhigen Gewissens behaupten, daß der µA1 für Endanwender-Zwecke bestens geeignet ist.

Zitat:

---

Heute sind doch genau die User für mich die "Dummen".
Ihre Hardware wird nicht mehr produziert, laut allen
Gerüchten wird es ja neue Hardware geben, ich hoffe die ist "besser" oder steht im Preis/Leistungverhältniss "besser" da,
als die, die den AOne im guten glauben gekauft haben.

---

Zitat:

---

>Das liegt in der Hand der Entwickler der Programme.
>Darauf haben Hyperion & Co. derzeit wenig bis gar keinen Einfluss.

Also einige Entwickler haben Rechner gestellt bekommen,
da sollte Hyperion doch Einfluss haben oder?

---

Zitat:

---

Andere Entwickler haben zudem mehr Zeit als Eigentlich vorgesehen war,
Soft ala IBrowse,ArtEffect,CandyFactory etc. müssten, wenn die Aussagen der Entwickler Teilweise stimmen von vor 2 Jahren, so gut wie fertig sein. ;-)
Sind Sie aber bestimmt immer noch nicht.

---

Zitat:

---

Mal Abgesehen von den ganzen Progs die Hyperion veröffentlicht will/wollte.

---

Zitat:

---

Es ist doch wohl im Interesse von Hyperion das Soft zum Release fertig ist, keiner kauft sich einen neuen Rechner um dann SDL Ports
nutzen zu dürfen oder?

---

Ich weiß nicht, irgendwie scheinst Du da etwas sehr viel zu erwarten. Soll Hyperion gleichzeitig mit dem OS auch das gesamte Software-Spektrum arbeitsmäßig abdecken? Es wäre mir neu, daß Hyperion ähnlich großzügige Resourcen zur Verfügung hat wie MicroSchuft...

Zitat:

---

>Dort spielen auch Faktoren wie persönliche Vorlieben, Verärgerung, >Neid und Mißgunst eine Rolle.

Ich beziehe mich auf die bekannten AOS4 Progger, die für AOS4 schon
vor mittlerweile Jahren, Ihre Soft angekündigt haben.

---

Zitat:

---

>Die Verantwortung dafür kannst Du getrost noch weiter nach hinten
>schieben, würde ich sagen. Das ging zu Escom-Zeiten schon los und
>Gateway hat das keineswegs besser gemacht.

Und wenn man will kann man bis zu C= zurück gehen.
DAS ist aber nicht Richtig!!
Zu dem Zeitpunkt als AOS4 angekündigt wurde, war die Amiga Community noch halbwegs intakt, es gab noch keine Alternativen dazu und
wäre AOS4 wie angekündigt Anfang 200 und? erschienen, brauchte man heute hier nicht Diskutieren. ;-)

---

Zitat:

---

>Ich denke, so ziemlich jeder, der auch für kleinere Hobbies
>entsprechende Energie aufbringen kann. Das ist mehr eine Frage des
>Wollens, weniger der wirtschaftlichen Voraussetzungen im Vergleich
>zum PC-Markt.

Sicher?
Schau Dir doch mal heute an was so für AmigaOS 3.x und 4.x
noch gemacht wird!?
Glaubst Du wirklich mit dem Erscheinen von AOS4, besinnen
sich User und Entwickler und unterstützen den Markt?

---

Zitat:

---

>Das will Dir auch niemand nehmen. Allerdings solltest Du dann auch
>die Füße still halten, falls es neuere und bessere Programme nicht >mehr für OS3.x geben sollte...

Für OS 3.x gibt es heute schon nichts mehr, es muss erstmal AOS4
Software geben, die meine AOS 3.x Software ersetzen kann oder
besser ist.

---

Zitat:

---

Dazu die Konkurrenz zur Win Soft die Alternativ auch noch auf ein und dem selben Rechner zur Verfügung steht.

---

Wenns danach ginge, bräuchte man überhaupt nicht mehr zu diskutieren. Die Konkurrenz ist da, sie ist übermächtig etc. pp. Trotzdem benutzen die Leute noch AmigaOS, und viele davon sehr gern. Sogar die, die OS4 bereits nutzen können. Warum machen die das, wo die Konkurrenz doch so überzeugend und erdrückend ist?

Grüße

--
---

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

Zitat:

---

Original von Daniel01:
@whose:

Hallo, Du, ich habe mal alle Settings durchschaut aber ein AutoConnect nicht gefunden.

Das ist ein mißt sage ich Dir.

Aber ich habe mal in MTU den Wert von freenet angegeben und nun kann ich wenigstens wieder Texte hier einstellen über den Router


Das mit dem umständlichen online gehen des Routers nervt mächtig das ich wohl, wenn ich das nicht besser hin bekomme lieber wieder normal ohne Router über Modem online gehen werde und den Speedverlußt dann halt hin nehme.

Grüße,
Daniel

---

Naja, ich hab mir mal dieses Modell notiert, falls wieder mal jemand mit dem Ding Ärger haben sollte. Aber das wäre wirklich der erste Router, bei dem man das nicht abschalten könnte (und natürlich auch wieder anschalten).

Daß das mit DHCP auf einmal funktioniert, kann eigentlich nur bedeuten, daß die von Dir gewählte IP in einem "freizuhaltenden" Bereich liegt. Auch sowas kann man recht häufig konfigurieren (das allerdings nicht bei jedem Router).

Aber wer weiß schon, was sich die Industrie alles lustiges einfällen läßt, "um Kosten zu sparen"

Grüße

--
---

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