Posts by Bytebreaker

    @ gi joe


    bitte nimm die aktuelle version aus beitrag nummer 11.
    ich hatte da vorhin murks im options screen gemacht.


    edit:


    äh nein doch nicht.
    hier extra für gi joe: es heißt jetzt <= 3. ;)

    Files

    • vyap.prg

      (3.8 kB, downloaded 12 times, last: )

    @ Mac Bacon


    Danke für dir Tips.
    Bzgl Joytick-Abfragen: Er peekt ja pro Schleife immer nur einmal, fragt dabei aber alles ab was möglich ist:


    In der "Vorrunde":


    - Linker Spieler fire?
    - Linker Spieler fire+up?
    - Linker Spieler Fire+down?


    - Rechter Spieler fire?
    - Rechter Spieler fire+up?
    - Rechter Spieler Fire+down?


    Nach dem Startschuss per Feuerknopf:


    - Linker Spieler up?
    - Linke rspieler down?


    - Rechter Spieler up?
    - Rechter Spieler down?


    Natürliche habe ich es auch mit Verunden und Verodern versucht, gerade bei den Firepress-Abfragen aber es gelang mir nicht.
    Benutzt habe ich Abfragen nach dem Schema if peek(register) and maske = 111
    Dass da 111 rauskommen muss stimmt sogar, aber es passiert dann nichts. Ich hab es nicht geschafft und dann resigniert Einzelabfragen von Zahlen gemacht.


    Das Out of Memory hast Du gut entlarvt:


    Ich mache goto Sprünge aus Unterprogrammen, die zuvor mit Gosub aufgerufen wurden. Das ist wohl die Schwäche an der es liegt. Mehr als 6 Durchläufe packt er dadurch nicht.


    Zum Thema Basic-Baukasten:
    Ja ich weiß, es stammt von Evil Microsoft und wer wirklich was vom Coden versteht sieht auch die vielen Schwächen.
    Trotzdem ist das Baukasten-Prinzip hochmotivierend für einfache Spiele und kleine Erfolgserlebnisse, finde ich.

    Die größte Schwäche im Spiel ist momentan das Timing. Ein Spieler kann den anderen "lähmen" durch ständiges Bewegen. Die Abfragegeschwindigkeit ist so langsam, dass das möglich ist.
    Ich werde mal schauen was der Basic Compiler an Speed-Zuwachs bietet und ob das Problem dann noch besteht.


    Wobei sich das im 2 Spieler Modus aktuell ausgleicht. Man ist abwechselnd an der Reihe und so könnte jeder den anderen "blocken". Daher würden sich zwei menschliche Spieler also einigen, nicht "asozial" zu spielen. Die KI dagegen putzt man mit diesem "Bug" leicht weg wenn man will.

    Ich habe leider aus Performance-Gründen alle REMS entfernt und das Programm so weit es geht gestrafft. Nur manuelles Renumber hab ich sein lassen und Leerzeichen im Befehlscode drin gelassen (dafür aus den Print-Befehlen mit SPC herausgenommen). Daher dürfte sich die Lesbarkeit in Grenzen halten.
    Die KI besteht eigentlich nur aus einer einzelnen Formel in Zeile 564.

    Danke Dir. :-)


    Die KI ist übrigens doch zu schlagen. Hab ich grad festgestellt.
    Tja und die Langsamkeit ist eben das was durchs BASIC kommt. Es sei denn jemand zeigt mir wie das ohne Assembler schneller geht.

    Hallo zusammen.


    Ich hatte zwar angekündigt, Assembler zu lernen um Old School Intros machen zu können, aber V2 Basic ließ mich dann doch nicht los.
    Anbei findet ihr meinen neuen Pong-Klon. Ich denke mir immer, "das muss doch auch in Basic gehen" - auch wenn hier ein Raster Interrupt bestimmt beim Timing geholfen hätte.


    Features:
    - Verwendet Get anstelle von Input. Habe aus Euren Tips gelernt. Die Mühe, Backspace-Taste für Eingabekorrekturen abzufangen habe ich mir aber nicht gemacht. Jetzt weiß ich auch, warum String-Felder in Fenstern so eine sinvolle Erfindung sind.


    - Man hat im Optionsmenu nur die Wahl zwischen einer Runde und 3 Runden pro Spiel. Ich wollte bis zu 9 Runden möglich machen, aber mehr als 3 Runden (d.h. 5 Durchläufe bis ein Sieger feststeht) klappen nicht ohne Out of Memory Meldung. Default-Rundenzahl ist 3.


    - Ich hatte die Wahl zwischen einer Super-KI und einer Dumpfnuss-KI. Wegen der Langeweile hab ich mich für die Super-KI entschieden, auch wenn sie momentan eher schwer zu besiegen ist.


    - Dafür gibt es noch einen 2 Spieler Modus, Steuerung erfolgt per Joystick in Port 1 und 2.


    - Die Ballkalkulation ist vergleichsweise primitiv. In meinem Basic-Konstrukt habe ich aber keine Möglichkeit gesehen, zufallsgesteuerte, unterschiedlich "flache" Bälle zu verwenden ohne dass das Spiel noch langsamer geworden wäre oder Out of Memory Meldungen gekommen wären. Mein erster Gedanke war ja, beim Aufprall auf den Schläger einen unterschiedlich flachen Streckenverlauf auszuwürfeln, diesen in ein Array zu schreiben, der KI zu sagen wo der Ball landen wird und dann den Ball das Array abfahren lassen. Pustekuchen. Ich habe es in Basic nicht hinbekommen.


    - Die einzige Variation die man anstelle von Flachheitsgraden hat: Zu Beginn jeder Runde klebt der Ball am betreffenen Schläger, während man ihn bewegt. Bei Feuerknopf wird der Ball weggeschossen. So kann man den Streckenverlauf zumindest durch unterschiedliche Startpunkte beeinflussen.


    Wer etwas besser weiß, kann, oder sonstige Tips für mich hat: Immer her damit. :-)


    Jetzt muss ich aber Assembler lernen. Es sei denn ich mache noch ein BASIC-Kartenspiel oder einen BASIC-Scrolltext der sich anhand von Sinusdaten bewegt. Muss doch auch in BASIC gehen.. argh! C64 BASIC ist deshalb so fesselnd, weil das alles so ein gut durchdachter Baukasten ist. Ich denke so oft "Ach, auch daran haben sie also gedacht". Das Zusammenspiel ist gut von dem, was man mit BASIC, Kernel-ROM, Sprites, SID, Registern und Petscii-Bausteinen alles kombinieren kann. BASIC macht auch eigentlich nur Sinn ohne Grafikmodus finde ich.

    Das 10Liners-Konzept ist sehr gut geeignet für Anfänger und Leute, die mit der Zeit besser werden wollen und auch die Faszination für 8 Bit stärker ausleben wollen als nur indem man alte Spiele spielt.


    Denn besser programmieren lernen kann man nicht. Die Quellcodes sind offen, jeder Wettbewerb bringt neue Inspiration für neue Ideen und Variation, durch die 10 Zeilen hat man auch eine Begrenzung, die das Ausufern verhindert und bei überschaubarem Aufwand zur Effizienz zwingt.


    Es ist eine sinnvolle Beschäftigung nicht nur für "alte Retro-Säcke", sondern auch für ganz junge Menschen, die durch solche volldokumentierten Systeme wie den C64 alles über den Grundaufbau von Programmiersprachen, Rechnerarchitektur, Registern usw. lernen können. Heute hat man Multithreading, Mehrkern-CPUs, pervers ausgestattete Grafikkarten und endlos mehr schnelleres RAM. Trotzdem versteht man die heutige Welt leichter, wenn man die alte kennt. Vor allem angesichts dessen, dass die heutige (kommerzielle) Welt nur noch aus proprietären, "boxed systems" besteht, in die man gar keinen Einblick mehr hat, nicht mal, wenn man Einblick haben will. Sogar als Entwickler schickt man nur noch Parameter an eine fertige Grafik- oder Game Engine und die macht dann den Rest - ohne dass man selber wissen muss, wie man ein Polygon auf dem Bildschirm darstellt.


    Der Open Source Bereich ist da zwar offener, aber der erste Einstieg fällt schwerer. Ein C64 ROM Listing und ein bisschen Basic wuppt man denk ich leichter als den Quellcode einer Linux Distribution. Einzig der Raspberry Pi scheint mir ähnlich wie 8 Bit Systeme geeignet zu sein, Computer und Software wirklich vom Inneren her in den Grundzügen verstehen zu lernen.

    Hallo,


    das Kniffel Spiel vom Januar wurde ja recht häufig runter geladen, daher dachte ich, dass dieses Update von Interesse ist:


    Ich habe in Zeile 1 eingefügt:


    x=rnd (-time)


    Damit wird der Zufallsgenerator für die Würfel an die Variable für die Systemzeit gekoppelt, die sich ja ständig verändert.


    Dadurch erwürfeln wir endlich echter Zufälle. Wer das Kniffel vom Januar mal gespielt hat wird feststellen, dass die Würfe sich wiederholen, wenn man immer dieselben Wurf-Entscheidungen trifft.


    Das ist jetzt gegessen und man kann das Kniffel im Tablet auf Reisen mit nehmen und über Frodo Emulator hochkant zocken und kein Kind meckert dass sich was wiederholt.


    Gruß Byteb.

    Files

    • VKNIFFEL.D64

      (174.85 kB, downloaded 1,311 times, last: )

    Hexworx Code ist klar und effizient. Man muss nur etwas mehr von BASIC verstehen.


    Ich will das prog auch haben und fände es gut, wenn wir uns in diesem Thread auf ein Referenz d64 einigen können was den schlanksten Code enthält und die ganze Musik.

    Bin ich bloß blind oder gibt es keinen C64 Emulator für iOS? Evtl. merkt der Appstore auch, dass ich mit einem Iphone verbinde und zeigt mir keine C64 emulatiren an, weil die nur für iPads angeboten werden?

    Ach Gott. Schifahren! Was für ein kryptischer Code.
    Ich glaube, der Zeilenzitterer hätte in der Wertung gar nichts ausgemacht, das Spiel war auch so schon sehr gut. Aber so ist das eben. Noch Platz frei also feilt man mit viel Aufwand an Sachen, die wenig bemerkt werden vom Spieler. Nur einen selber wurmt es. ^^

    @ Tommes


    Schluchz. Dir sei vergeben. Es dient ja einem guten Zweck.


    @ all


    Hat irgendjemand Renderings herumliegen die am C64 und/oder Amiga entstanden sind und kann sie posten? Wäre doch mal ein interessanter Vergleich der Generationen. Außerdem doch sicher schön Bilder zu sehen, die auf der Ur-Hardware wirklich entstanden sind.

    @ Tommes


    Wow. Wenn ich Deine gerenderten Amiga Tastaturen und Gehäuse sehe kriege ich Speichelfluss und kriege Lust reinzubeißen, so gut, vertraut und neu sieht das aus. Ich riech direkt das Plastik. Wie frisch nach dem Auspacken.


    Hast Du eigentlich schonmal auf einem echten Amiga gerendert und hast Du davon Bilder?
    Ich sehe, Du arbeitest aktuell mit dem Mac und nicht mit Feindes-Windows x86. Tröstlich, dass so tolle Bilder an einem Mac entstanden sind und nicht im Reich des Bösen. ;)

    Soo...
    also ich merke schon, ich muss Assembler lernen. Am Amiga hatte ich das mal, aber da hatte ich keine so gute Lehrbuch/Praxis-Umsetzung wie heute am C64. Ich hatte dann irgendwann die Motivation verloren weil ich mit der Assembler-Bedienung nicht klarkam weil Includes aus Beispiel-Sourcen sich nicht einbinden ließen und ich dann irgendwann aufgab.


    Ich mache jetzt am CeVi weiter und mache ein Online Tutorial durch zur Demo Programmierung in Assembler. Irgendwann danach wende ich mich wieder dem Amiga zu. Heute sind Handbücher und Software besser zu beschaffen als vor 10 oder 15 Jahren und ich kann für eine lückenlose Doku sorgen so dass ich diesmal dann nicht frustriert aufgebe weil ich mich im Assembler nicht zurechtfinde, bzw. Lehrinhalte nicht "auf die Straße bekomme", weil der Assembler den Sourcecode nicht versteht und ich nicht blicke, wie ich die Syntax ändern muss damit es geht.


    Zum (zeitweisen) Abschied aus der Basic-Welt habe ich noch ein Programm geschrieben was schöne Linien plottet. Da ist bei weitem kein Tribar a la Mike, dafür hab ich mir etwas einfacheres ausgedacht das trotzdem gut aussieht. Unbedingt in VICE mit Alt-W vorspulen, am Anfang denkt man sonst echt, der hängt, aber tut er nicht, er allokiert bloß VIC Adressen, löscht die Bitplane und setzt Vorder- und Hintergrundfarbe im Video RAM. Das dauert gefühlte 37,5 Jahre. Das Linien zeichnen habe ich auch ein bisschen als Effekt aufgebaut von der Reihenfolge her, aber auch das dauert eben seine Zeit.


    Anbei der kommentierte Source:



    Die PRG-Datei enthält keine Kommentare wegen Geschwindigkeit. Anbei auch ein Bild vom fertigen Ergebnis, erstellt an einem G4 Powerbook mit dem Amiga-Betriebssystem MorphOS und der dafür erhältlichen VICE-Portierung. Sobald die Zeichnung fertig ist wartet das Programm auf einen Tastendruck und kehrt dann in den Textmodus mit Befehlsprompt zurück.


    @ BIF


    Ich mach Dir auch gar keinen Vorwurf und denke immer noch nicht schlecht von Dir. ^^ Ich bin ja auch noch zu doof um frustriert zu sein, ich muss erstmal nachschlagen worüber die versierten Herren da überhaupt sprechen, sowohl was Garbage Colelction angeht als auch prozessorunabhängige Assembler-Syntax. Ich versteh das eher so wie Blade Runner. Es mag Standardisierungen geben in den Entwicklungsumgebungen für bestimmte Befehlsmuster, aber letztlich versteht der Prozessor nur ein LDA und nicht irgendein Fantasiewort. Das standardisierte Fantasiewort wird immer von der Entwicklungsumgebung abgefangen und übersetzt.