Aha, alles nur Photoshop. Aber erst mal den Schreck einjagen.
Posts by Hobbyist
-
-
Ich glaube, der Absatz kann nicht klar übersetzt werden, weil er auch auf englisch schon nicht deutlich ist. Offenbar gibt es zum einen Bit-Werte, die für zwei (je einen) Finger anzeigen, ob das betreffende Tastereignis erst begonnen (Berührung erfolgte) oder schon abgeschlossen wurde (Berührung wurde wieder beendet), und zum anderen Werte, die schlicht anzeigen, ob gerade irgendein Finger den Bildschirm berührt oder nicht; wie das zusammenhängt, wird mir aber nicht klar.
Tja, das ist jetzt halt die Frage, ob man ein Exemplar des am laengsten erwartetsten Computers gekauft hat, oder ob man sich einen von mehreren moeglichen lang ersehnten Computern gekauft hat
Ja. Sicher so einige haben einen rechtzeitigen, abwärtskompatiblen, multimedia- wie büro-optimierten 16-Bit-Nachfolger des C64 schon lange vor dem Bekanntwerden der hoffnungslos verspäteten Pläne zum C65 erwartet.
Eine grundsätzliche Anregung zum Handbuch:
Der MEGA65 beinhaltet ja einen C64; ich finde, da sollte auch zu Beginn (zumindest für Interessenten des C64-Modus) eine Empfehlung zur Lektüre des C64-Handbuchs ausgesprochen werden. Zumal das nicht nur eine kompakte, gut verständliche Einführung in ein gut überschaubares BASIC bietet, sondern auch in einige zeitlose Computer-Grundlagen (vor allem das Sprite-Kapitel).
-
Wo wurde denn das Thema verlassen? Dürfen hier Film- und Fernseh-Beispiele nur verlinkt aber nicht diskutiert werden?
-
Satire assoziiere ich mit Intelligenz, Originalität und gesellschaftskritischen Impetus, also das halte ich eher für Comedy. Muss ja auch nicht immer schlecht sein, aber das erreicht mich einfach nicht.
-
Für mich ist die Sendung immer wieder, wenn ich davon etwas zur Kenntnis nehmen muss, ein Brechmittel. Hier mal wieder die billige "Computer-Nerds sind keine Frau abkriegende Witzfiguren"-Schiene. Seltsam beliebte Form von Intelligenz-Bashing.
-
Die Wortfolge "eines des" ist m.E. immer falsch, egal in welcher Konstellation.
Ist "Alles ist Zahl" ein Wort des Heraklit oder eines des Pythagoras? - Eines des letzteren.
(Ohne "e", also "eins" statt "eines", ist wohl üblicher, aber mit "e" geht es m. E. auch.)
Aber zugegebenermaßen musste ich eine Weile grübeln. (-:
-
Zumal man es erstmal schaffen müsste, "sinnvollere" Namen überhaupt zu finden.
Dir fällt nichts Sinnvolleres ein als Begriffe mit den Assoziationen Schleim, Kotze und Kannibalismus?
Anleihen an der Vegetation bieten sich doch z. B. an: gras-, blatt-, minz- moosgrün.
Wenigstens auf froschgrün hättest du kommen können. (-;
-
Die Namen für die Grüntöne gehen ja direkt ins Eklige (seekrank, Schleimer, Menschenfleisch) - jedenfalls davon würde ich abweichen.
-
Die Beschleunigung von BOSS-Kompilaten im Vergleich zum interpretierten BASIC soll ("nicht selten") bis zu 100-fach sein, das käme von der Größenordnung in die Nähe von handgeschriebenem Assembler (100-1000-fach).
Der C64 ist einfach zu langsam. Für gute Sachen kommst nicht an Assembler vorbei.
Also ich hab grad mal ein BASIC-Spiel von mir mit BasicBOSS kompiliert, und komme auf ca. doppelte Ausfuehrgeschwindigkeit.
"Die Beschleunigung von BOSS-Kompilaten im Vergleich zum interpretierten BASIC soll [!] ("nicht selten") [wie selten?] bis zu 100-fach sein [...]"
Solche Aussagen von Compilerherstellern würde ich immer mit Vorsicht genießen und selbst austesten. Streng genommen ist auch ein Faktor 0.5 im Bereich "bis zu 100".
Derselbe Quellcode oder an BOSS angepaßt?
Nee ohne Anpassungen
Also ich habe nun mal Basic-Boss an meinem obigen Programm getestet, erst ohne, dann mit Anpassungen:
Zunächst ohne Anpassungen, das erbrachte eine Beschleunigung der zeitkritischen Stelle (Unterprogramm zur Umwandlung der Strings in Sprite-Daten) von 942 Jiffys (Sechzigstelsekunden) = 15,7 Sekunden auf 291 Jiffys, also um den Faktor 3,19. Die Dauer der Sprite-Bewegung am Programmende verkürzt sich von 186 auf 24 Jiffys, da ist der Beschleunigungsfaktor 7,75.
Dann schaltete ich in einer REM-Zeile mit Compiler-Direktiven auf schlankere Datentypen. Damit brauchte das Unterprogramm noch 77 Jiffys, also etwas über 1 Sekunde, das bedeutet eine Beschleunigung um den Faktor 12,23. Die Sprite-Bewegung verkürzt sich auf 1 Jiffy, ist also nicht mehr wahrnehmbar - der Beschleunigungsfaktor ist 186.
Dann fügte ich die Direktive FASTFOR für optimierte Schleifen hinzu, das verkürzte das Unterprogramm auf 69 Jiffys, Faktor 13,65. Bei der Sprite-Bewegung steht der Jiffy-Zähler wieder auf 1.
Um noch aussagekräftig messen zu können, habe ich dann im Code die Sprite-Bewegung verlängert, so dass X- und Y-Koordinate kleinteilig in 1er-Schritten von 0 bis 255 (also über den Bildschirmrand hinaus) laufen; dies dauert unkompiliert 540 Jiffys. Kompiliert mit schlanken Datentypen und FASTFOR: 2 Jiffys, also 270-fache Geschwindigkeit.
Weitere Versuche mit Optimierungs-Maßnahmen (z. B. Deklarierung von FAST-Variablen, die in der Zeropage abgelegt werden), brachte für das Unterprogramm höchstens noch 1-2 Jiffys - ich denke, bei diesem Unterprogramm ist der Flaschenhals die String-Verarbeitung, die der Compiler nur begrenzt beschleunigen kann.
Also mit wenigen Direktiven in einer REM-Zeile wurde der Beschleunigungsfaktor für das stringlastige Unterprogramm zweistellig (13,65), für die Sprite-Bewegung dreistellig (270).
Der aus beiden Abschnitten gebildete Durchschnitt ist 141,83.
Nach Durcharbeitung des gesamten Handbuchs ist mit ausgefeilteren Optimierungen vielleicht noch mehr drin.
-
Sicher sind Herstellerangeben das eine, aber auch in mehreren Testberichten schnitt BASIC BOSS als schnellster Compiler ab. Und für ein maximales Ergebnis bedarf es wie gesagt einiger Anpassungen wie genauer Typ-Deklarationen.
Der Ansatz, das selbst zu testen, ist natürlich richtig, aber mich wunderte halt die Entschlossenheit, nicht mal die Möglichkeit zur Kenntnis zu nehmen.
-
Die Beschleunigung von BOSS-Kompilaten im Vergleich zum interpretierten BASIC soll ("nicht selten") bis zu 100-fach sein, das käme von der Größenordnung in die Nähe von handgeschriebenem Assembler (100-1000-fach).
Für gute Sachen kommst nicht an Assembler vorbei.
Aber was soll ich mich beklagen, bei einem Selbstgespräch werde ich vom Gegenüber immerhin verstanden.
-
Dieses klare Ende des Unterprogramms
Aber wer hat's erfunden? - RETURN.
daß es in Basic durchaus üblich ist, die hauptsächlich verwendeten Variablen zu Beginn des Programms zu nennen, dort auch Arrays zu dimensionieren und "konstante" Variablen wie z. B. einen Zeiger auf den VICII-Chip oder Soundchip zu deklarieren. Im Grunde genommen sind es nur die kleinen Basic-Programme, die darauf verzichten.
Ja, das dient bei größeren Programmen auch der Optimierung, insbesondere sollten alle Einzevariablen am Programmanfang initialisiert werden, weil eine später nach einem Array initialisierte Einzelvariable den Interpreter zu zeitraubenden Verschiebungen im Variablenspeicher veranlasst.
Wenig bekannt ist, dass dies bequem in Kurzschreibweise möglich ist, indem Einzelvariablen einfach am Anfang dimensioniert werden. Richtig gelesen: DIM lässt sich auch auf Einzelvariablen anwenden mit der Folge, dass sie automatisch im Speicher mit Default-Wert angelegt werden. Also es muss statt i=0:j=0:x=0:y=0:a$="":b$="" ... lediglich geschrieben werden dim i,j,x,y,a$,b$ ...
Zur Optimierung können zudem Arrays auch dann explizit dimensioniert werden, wenn sie absehbar weniger als den Default-Wert von 11 Elementen benötigen, um Speicherplatz zu sparen.
Auch hier kann ich Dir aus eigener Erfahrung sagen, daß für einen Anfänger ein "x := x + 1" wesentlich einleuchtender ist als ein "x = x + 1". Letzteres sieht nämlich viel zu sehr nach einer aus der Mathematik bekannten Gleichung und damit einer Gleichsetzung aus
Ja, aber jede gute Einführung weist darauf zur Vermeidung von Verwirrung frühzeitig hin, das C64-Handbuch auf Seite 37.
Übrigens noch mal zum Thema "Wer hat's erfunden": Das ist nichts anderes als Operatoren-Überladung (andersartige Funktionsweise von Operatoren in speziellerem Kontext, hier Gleichheit und Zuweisung), was dann später etwa in C++ als große neue Errungenschaft gefeiert wurde.
Ein anderes Beispiel dafür in BASIC ist der Operator "+" (Addition und String-Konkatenation). Die Überladung ist in beiden Fällen unproblematisch und intuitiv.
Es ist auch der Grund, warum Compiler wie der Basic Boss große Eingriffe in das Basic vornehmen (Zur FOR-Schleife gehört nur das folgende NEXT, Variablen werden deklariert und bekommen einen festen Datentypen usw.), um den Code vollständig übersetzen und in eine schnelle Form gießen zu können.
BASIC BOSS kompiliert auch ohne genaue Typ-Deklarationen, aber mit denselben effektiver. Das leuchtet auch unmittelbar ein, zum Beispiel können etwa reine Zählvariablen, die nicht größer werden als 255, als Typ "Byte" deklariert werden und brauchen dann auch nur ein Byte im Speicher. (Oder vielleicht gar keinen Speicherplatz, weil das Kompilat dann etwa bei Schleifen direkt ein schnelleres CPU-Register verwendet.)
Außerdem bitte ich zu bedenken, daß man auf dem C64 selbst bestenfalls einen p-Code erzeugen könnte, der dann interpretiert wird. Das wäre zwar immer noch um ein Vielfaches schneller als Basic (auch der p-Code Übersetzungen z. B. vom Austrocompiler)
BASIC BOSS erzeugt anders als Austro keinen Zwischencode, sondern sehr wohl (natürlich schnelleren) Maschinencode. Die Beschleunigung von BOSS-Kompilaten im Vergleich zum interpretierten BASIC soll ("nicht selten") bis zu 100-fach sein, das käme von der Größenordnung in die Nähe von handgeschriebenem Assembler (100-1000-fach).
-
Keine Rechenpower für Verzögerungsschleifen verstehe ich nicht.
Aber in diesem einen Thread hier ist das Thema die Konzeption eines NEUEN Rechners
Und en passant wird auf den C64 geknüppelt, dass die Augen tränen.
-
Ein langsamerer Ablauf dürfte bei der Entwicklung sogar oft hilfreich sein, um Fehler zu analysieren. Aber wie gesagt, bis zur Turbo-Reihe war Entwickeln mit Compiler zu Hause ohnehin gar keine sinnvolle Option.
Ich verstehe halt nicht, warum in einem C64-Forum der C64 oft so lustvoll einseitig in den Keller geschrieben wird. Da habe ich dann den Reflex, in die Gegenrichtung zu argumentieren, um das Bild zu vervollständigen.
-
Ich hab noch kein offizielles Statement vom BASIC-BOSS Autor gesehen das er das als Freeware raus gibt, demnach könnte er immer noch Leute verklagen wenn diese seinen Compiler nutzen wenn sie keine Lizenz besitzen, in dem Fall die Originaldiskette mit Buch.
Mir ist auch unwohl bei Abandonware, deshalb schnappe ich mir nach und nach das mich Interessierende bei Ebay, BASIC BOSS liegt heir auch. Waren um die 10 Euro.
Das tolle am BASIC V2 ist ja, dass es im Rechner eingebaut und sofort verfuegbar ist. Wenn da jedesmal zusaetzliche Schritte notwendig sind, egal ob Compiler
Von "jedesmal" kann ja keine Rede sein, entwickelt wird flüssig mit dem Interpreter, deshalb waren die im ROM und keine Compiler; bis zur "Turbo"-Reihe von Borland im PC-Zeitalter waren ständige Kompilierphasen auf heimischen Rechnern nicht zumutbar. Also kompiliert wird natürlich erst zum Schluss zur Beschleunigung.
Als ich aber die 7 Sprites über den Bildschirm bewegen wollte brauchte ich schon keine Verzögerungsschleife mehr so lahmarschig
Äh, sieben Spritebewegungen gleichzeitig sind flüssig genug, und das Armageddon sind dann die einsparbaren Verzögerungsschleifen? Was für ein Jammer-Niveau ist das denn. (-;
-
Hast Du auch mal Compiler getestet (wenn ja, auch BASIC BOSS)?
-
Grundsaetzlich hat der C64 aber auch das Problem, dass das Programm sehr langsam ist.
Das Einlesen und Umwandeln der String-Sprite-Daten, aber sowas wäre einmal am am Anfang. Der Flug über den Bildschirm ist doch recht flott.
Also bei einem statischen Hintergrund geht es eigentlich, wenn auch mit Joystick-Abfrage usw. wohl keine Hektik aufkommt. (-; Im Autoschleichen aus meiner Jugend lief die Strecke mit Zufalls-Biegungen und -Hindernissen am Bildschirm ab und dazu bewegten sich die Sprites, das war dann ein Gezuckel.
-
-
sowas waere in meinen Augen das Ziel - dass man einfache, Arcade-maessige Spiele mit wenig Code hinbekommen kann, die dann auch in einer Geschwindigkeit ablaufen, die man von den Originalen gewohnt ist. Das geht auf dem C64 mit reinem BASIC definitiv nicht.
In interpretiertem BASIC - es wird aber gern vergessen, dass es auch Compiler gibt. Der nach Testergebnissen mit Abstand beste, BASIC BOSS, kam recht spät auf den Markt (1988, als der Zenit des C64 schon überschritten war), deshalb kennen den womöglich viele gar nicht.
Ich komme die nächste Zeit wohl nicht dazu, aber ich will den selbst mal testen. Ich habe hier auch noch ein Auto
rennschleichspiel aus den 80ern in BASIC, das damit hoffentlich spielbar wird. (-:Es muss ja aber auch nicht immer schnelle Action sein. Ein entschleunigtes und entschleunigendes, fantasievolles Adventure o. ä. ohne Geballer ist auch mal schön.
-
Dafür ist das kein Pseudocode, sondern läuft. Auf einem Rechner, der existiert. (-;
Wäre natürlich auch kürzer gegangen, ohne das "Gerüst", aber dann ohne die bequemere Sprite-Handhabung im Hauptprogramm. In dem kurzen Demo hat das "Gerüst" einen großen Anteil, in einem größeren Programm würde sich das relativieren.
Und auf einem neuen Rechner mit umfänglicherem BASIC mit mehr Befehlen, auch für Sprites, wäre es wahrscheinlich kürzer und intuitiver als mit einer Pascal-artigen Sprache.
