Hallo Besucher, der Thread wurde 18k mal aufgerufen und enthält 140 Antworten

letzter Beitrag von BIF am

Plot-Routine für Basic V2

    Zitat von Bytebreaker

    [...]das kriecht arg, ist halt BASIC.


    Na, ja, wenn man dann ausgerechnet in der Punktsetz-Routine noch "2^" benutzt, um den Bitwert auszurechnen, wird's auch nicht gerade schneller. ;) Tabellen sind da das Mittel der Wahl (auch in MCode).


    Zitat von BIF

    Dafür muß man erst einmal rausfinden, was der Programmierer überhaupt bezweckt.


    Muahaha! Das sagt gerade der Richtige!


    ...


    Ich hab' hier gerade mal ein kleines Grafikdemo vom VC-20 herübergeholt. Auf dem VC nutzt es die BASIC-Erweiterung MINIGRAFIK und darum konnte ich mich dort auf die Mathematik konzentrieren. Ohne BASIC-Erweiterung auf dem C64 sieht's halt *etwas* umständlicher aus. Ja, und wegen der Zeilen 31 bis 36: ich weiß, wie Bresenham geht. ;)


    [offtopic]

    Zitat von BIF

    Programme anderer Programmierer zu optimieren ist nicht immer ganz einfach.

    100% ACK. Die meisten Programmierer hassen es, einen grösseren Umfang von bestehendem Code von anderen zu übernehmen um diesen zu verbessern/erweitern. Sich in eine fremde Codelogik einzudenken, ist nicht immer so banal, wie es sich Aussenstehende immer denken ("Du kann doch C++, da ist es doch kein Problem, dieses Feature im Code von Deinem Vorgänger einzufügen. Ist ja nur eine kleine Erweiterung. Kann nicht schwer sein, wieso dauert es so lange?!? Ich dachte, Du kannst C++ programmieren!!!")


    Wenn es keine Kommentare im Code hat, die erklären wieso etwas gemacht wird so wie es gemacht wird, macht es die Sache nicht einfacher. Oder sinnfreie Kommentare wie:

    Code
    1. Dim bSwitch As Boolean
    2. ..
    3. bSwitch = True 'sets switch to true


    Auch Möchtegern-"Optimierungen" haben heute einfach nichts im Code zu suchen, wenn sie keine wirkliche Funktionalität verbessern oder Anforderung erfüllen.
    Wenn es um performancehungrige Applikationen oder Teile davon handelt, machen Optimierungen Sinn. Wenn es sich um allgemeine Desktop Anwendungen handelt, wo die CPUs eh nur Däumchen drehen, ist es kontraproduktiv für vermeintliche "Optimierungen" auf Sourcecode Lesbarkeit zu verzichten. Oft sind aber Optimierungen möglich, ohne die Lesbarkeit des Codes zu reduzieren. Es liegt aber eher an den (faulen) Programmierer, warum es aber nicht gemacht wird.


    Fünf undurchsichtig zusammengewurstelte Operationen in einer Zeile durchzuführen statt diese in übersichtliche 3 Zeilen aufzusplitten ist einfach nur dumm. Das mag früher unter knappen Ressourcen seine Daseinberechtigung gehabt haben, aber heute ist einfach nur noch kurzsichtig gedacht und ist oft der egozentrischen Persönlichkeit des Programmieres geschuldet.


    Ich war schon oft selbst froh, wenn ich den Code gut strukturiert und dokumentiert habe, wenn ich diesen ein paar Jahre später selbst wieder pflegen musste. Aber es ist mir auch schon passiert, dass ich mir an den Kopf fassen musste und mich fragte "was habe ich mir damals denn gedacht?!? Wohl gar nichts!".


    Zitat von BIF

    Dafür muß man erst einmal rausfinden, was der Programmierer überhaupt bezweckt.

    Ja, das Problem habe ich auch bei Deinen Snipplets.... :whistling:


    Zitat von BIF

    Mike:
    Daß sich einige Leute dadurch überfordert fühlen, weil sich meine Listings meist nur auf einen einzigen Effekt beschränken, dafür hab ich natürlich Verständnis.

    Ach so, Wasser predigen und Wein saufen?


    Darf ich noch ein Mal daran erinnern, wofür das Akronym BASIC steht? Beginner's All-purpose Symbolic Instruction Code, also eine einfache, für Anfänger geeignete Programmiersprache. Das impliziert in meinen Augen auch eine einfache Lesbarkeit, was wiederum impliziert, dass der Code zum Zwecke der besseren Verständlichkeit geplegt werden muss.
    Oft erinnern mich Deine Beispiele an Perl being written by a programmer eating steroids.[/offtopic]

    Zitat von BIF

    Daß sich einige Leute dadurch überfordert fühlen, weil sich meine Listings meist nur auf einen einzigen Effekt beschränken, dafür hab ich natürlich Verständnis.


    Du hast dich da um eine Einheit vertan. Deine Programmfragmente beschränken sich in der Regel auf 0 Effekte.


    Zitat von Schlachtwerk

    Habe den Code nur schnell mal durch denn Basic Boss Compiler gejagt unter Windows, das Compilat is etwa doppelt so schnell wie das Original im Warp Modus von Vice, habe es nun nicht gemessen aber so pi mal Auge. ^^


    In anderen Fällen mit einer Fließkommaintensiven Anwendung (aber immer noch mit den Routinen im BASIC) geht im Regelfall der Faktor 3. Da macht sich der wegfallende Overhead der Ausdrucksauswertung im Interpreter gut bemerkbar.


    Evtl. bremst hier noch die SQR()-Funktion, wenn BASIC Boss die nicht mit dem Heron-Verfahren optimiert hat.

    Grundsätzlich gibt es ja immer verschiedene Kenntnisstände.
    z.B.
    -die einen können lesen, die anderen können nicht lesen.
    -die einen können rechnen, die anderen können nicht rechnen.
    -die einen können Basic, die andern können nicht Basic.
    -die einen können Maschinensprache, die anderen können keine Maschinensprache.


    Also, wenn jemand etwas nicht versteht, dann kann er ja auch mal fragen.


    Schönen Gruß.

    Tolles Tribar!


    Auch wenn das jetzt OT ist:
    Wie kann man denn Textausgabe im Grafikmodus bewirken?
    Dann könnte man Mikes Scroll-Routine nehmen und zugleich den Cevi etwas Schönes zeichnen lassen wie das Tribar. Der Scrolltext würde dadurch auch lesbarer werden, da verlangsamt.
    Idealerweise noch ein SID dazu und schon hätte man ein Intro.


    Ich befürchte aber dass man da wohl Assembler braucht weil es zuviele Routinen sind, die zyklisch angesprungen werden müssen. Aber ohne Ton müsste es in Basic doch hinkriegbar sein - ohne dass da bunte Rechtecke scrollen sondern lesbare Buchstaben während sich das Tribar zeichnet.

    Zitat von Bytebreaker

    Wie kann man denn Textausgabe im Grafikmodus bewirken? Dann könnte man Mikes Scroll-Routine nehmen und zugleich den Cevi etwas Schönes zeichnen lassen wie das Tribar.


    Zugegeben, das gemütliche Zeichnen der Linien hat schon irgendwie einen meditativen Effekt. :)


    Wenn man die Textausgabe in die Grafik hineinschreibt, dann müssen für jeden Schritt 320 Bytes bewegt werden. In BASIC geht das nicht gescheit. Alternativ kann man über Rasterinterrupts eine Zeile in den Textmodus schalten und darin die Laufschrift laufen lassen. Wenn man aber ohnehin schon soweit ist, kann die Rasterroutine das Scrollen der Laufschrift gleich mit übernehmen.


    In der BASIC-Erweiterung geht das Einschalten der Grafik (incl. Bildschirmlöschen) und das Zeichnen der Linien dann so schnell, daß für einen Scroller wiederum nicht viel Text herumkommt, bis das Programm fertig ist. Ich hab die originale Version mal unten angehängt, nötig ist ein VC-20 mit mind. 8K Speichererweiterung.


    BTT: Um herauszufinden, wie viel die SQR()-Funktion ausmacht, hab' ich sie mal durch meine Heron-Implementation ersetzt, und im Raytracer alle 4 Vorkommen von SQR() durch USR() ausgetauscht. USR() wird durch den nachfolgenden DATA-Loader neu definiert:


    Code
    1. 1 FORT=679TO753:READA:POKET,A:NEXT:POKE785,167:POKE786,2
    2. 2 DATA 32,27,188,32,43,188,240,66,16,3,76,72,178,165,97,133,251,41,1,9,128,133
    3. 3 DATA 97,169,4,133,252,162,242,160,2,32,212,187,169,188,160,185,208,18,162,247
    4. 4 DATA 160,2,32,212,187,169,242,160,2,32,15,187,169,247,160,2,32,103,184,198,97
    5. 5 DATA 198,252,208,229,165,251,74,105,64,133,97,96



    Tja, letztendlich brachte das dann doch nicht soviel. Statt 30 Stunden waren es nur noch 28. :P


    Ich hab' die beschleunigte SQR-Routine trotzdem auch mal mit angehängt.

    Zitat von Bytebreaker

    Tolles Tribar!


    Auch wenn das jetzt OT ist:
    Wie kann man denn Textausgabe im Grafikmodus bewirken?
    Dann könnte man Mikes Scroll-Routine nehmen und zugleich den Cevi etwas Schönes zeichnen lassen wie das Tribar. Der Scrolltext würde dadurch auch lesbarer werden, da verlangsamt.
    Idealerweise noch ein SID dazu und schon hätte man ein Intro.


    Ich befürchte aber dass man da wohl Assembler braucht weil es zuviele Routinen sind, die zyklisch angesprungen werden müssen. Aber ohne Ton müsste es in Basic doch hinkriegbar sein - ohne dass da bunte Rechtecke scrollen sondern lesbare Buchstaben während sich das Tribar zeichnet.


    Oder Du bleibst bei BASIC und verwendest eine BASIC Erweiterung, die sowas kann. IRQ BASIC scheint sowas zu können. Ausprobiert habe ich es nicht.

    IRQ Basic und Handbuch hab ich mir runtergeladen.
    Mal sehen was ich damit anfangen kann.


    Ich werde aber, sobald ich das Buch "Wunderland der C64 Grafik" durch habe, mit Assembler anfangen. Man stößt imme röfter an Grenzen je mehr man sich beschäftigt.
    Aus methodischen Gründen mach ich aber das eine Buch noch zu Ende. Sogar da drin fängt der Autor dann mit Assembler an und stellt seine eigene Grafik-Erweiterung vor.

    [offtopic]Weil wir gerade zu den BASIC Optimierungen und ASM-Aufsteiger eingegangen sind, etwas Halb-OT:
    Heute im Buch BASIC 7.0 auf dem Commodore 128 (Markt & Technik), Seite 12/13 gelesen und gelacht:


    [/offtopic] :thumbsup:


    Zitat von Schlachtwerk

    Gibts dafür nen Compiler?

    Jetzt lass doch den Mann das Ding mal ausprobieren, ob's denn sein Problem löst (würde mich auch interessieren), bevor wir mit BIF'sche Optimierungen und Compilate anfangen. :bgdev

    Zitat von Schlachtwerk

    Aber Aber Aber Compiler sind doch WICHTIG ^^ :bgdev


    Wenn IRQ BASIC Rasterzeilen-Splits beherrscht, um den Bildschirm zu teilen, wird es wohl nicht gerade wie eine V2 Schnecke sein.
    Ist dann fraglich, wieviel man mit einem Compiler noch rausholen kann.
    Dann kann man ja gleich alles in ASM anfangen. Aber Bytebreaker will es ja mal so ausprobieren und es interessiert mich, was dabei rauskommt. :thumbsup: