Geht mir ähnlich. Aber einige haben ja gerade erst angefangen...
Auch mir geht es so. Gerade dachte ich noch: Naja, eben noch ein paar Tage warten. Aber dann wurde mir bewusst: DAS IST JA NOCH FAST EIN GANZER MONAT!
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Haubitze am
Geht mir ähnlich. Aber einige haben ja gerade erst angefangen...
Auch mir geht es so. Gerade dachte ich noch: Naja, eben noch ein paar Tage warten. Aber dann wurde mir bewusst: DAS IST JA NOCH FAST EIN GANZER MONAT!
Ich gehe jetzt einfach mal davon aus, dass man das nicht regeln muss, sondern dass jeder Teilnehmer seine Lösung mit Sourcecode von sich aus einreicht
Bin dabei! Sollte aber noch ein paar mehr Kommentare einfügen.
So jetzt aber.
So jetzt aber.
Ich denke mal, das sieht gut aus
Bin dabei! Sollte aber noch ein paar mehr Kommentare einfügen.
Bin auch dabei, sollte aber noch ein paar Bytes entfernen.
So jetzt aber.
Sieht bei mir auch so aus.
Hm, wenn wir jetzt die Sache mit den initialen Werten der Register und der Zero-Page noch klar definieren könnten, würde ich mir noch ein paar Bytes sparen. Wie machen das denn die anderen? Ininialisiert ihr alle Werte vorher?
Wenn es nach mir ginge, dürfte die Compo jetzt enden, denn ich bin so gespannt auf die anderen Lösungen, dass ich es kaum noch abwarten kann
Nix da, bin noch nicht fertig.
Hm, wenn wir jetzt die Sache mit den initialen Werten der Register und der Zero-Page noch klar definieren könnten, würde ich mir noch ein paar Bytes sparen. Wie machen das denn die anderen? Ininialisiert ihr alle Werte vorher?
Ich dachte das wäre klar. Alle ZP-Werte sind Default nach Reset und Load. Außerdem gilt: A = X = Y = 0
Darauf basiert (teilweise) meine Lösung und die hat Ulli akzeptiert.
jeder Teilnehmer seine Lösung mit Sourcecode
Ich kenne vielversprechende Kandidaten, die solche Dinge in SMON zusammenstöpseln. Der Gewinnereintrag der Textkompressionscompo hat mir einiges Kopfzerbrechen verursacht, weil ich ihn verstehen und kommentieren wollte
Ist eigentlich das Original-ROM drin? Das, was Vice so nach dem einschalten hat?
Ich dachte das wäre klar. Alle ZP-Werte sind Default nach Reset und Load. Außerdem gilt: A = X = Y = 0
Darauf basiert (teilweise) meine Lösung und die hat Ulli akzeptiert.
Bei mir irgendwie nicht, zumindest im A hat sein Test 255 übergeben. Aber ob die 5 Bytes weniger dann letztendlich entscheidend sind? Unter den Besten werd ich sowieso nie sein, und dann ist mir ein stabilerer Code, der nichts kaputt macht und auch immer wieder ausführbar ist, doch irgendwie lieber.
Hauptsache dabei gewesen, hat Spaß gemacht, und man hat wieder was gelernt
Bei mir irgendwie nicht, zumindest im A hat sein Test 255 übergeben. Aber ob die 5 Bytes weniger dann letztendlich entscheidend sind?
Ich dachte auch das wäre klar, aber:
Hmm, stimmt, da ich ja ein Programm vorher aufrufe mit "sys" aufrufe, bevor ich das Programm mit "run" starte ...
Also doch nich so klar.
Müsste Ulli am Besten mal was zu sagen.
Für meine Lösung bringt es sowieso 0, wenn die Register 0 sind.
Also von mir aus muß man nicht davon ausgehen.
Aber MIT Doppelpunkten!
Roland ist Crossbow/Crest, ihm passieren schonmal seltsame Dinge in seinen Programmen. Da war doch mal was in einer Compo vor 5-10 Jahren, wo Xmal fast der ganze Speicher "irgendwie" durchgenudelt wurde. Lief 1000mal länger als die anderen Lösungen, erinnert sich wer?
Eigentlich war's eine Art "verstecktes" Kompliment. Roland hat doch auch mal einen Sprite-Multiplexer in BASIC(!) gebaut und ist generell recht fit, was den C64 betrifft
Nur so für's Protokoll: Roland ist Crossbow/Crest und hat 2005 in der "Mini Competition für Grid-Problem" am Ende eine extrem kurze Lösung mit ca. 10 Sekunden Laufzeit abgeliefert.
Der "Sprite-Multiplexer in BASIC" (CSDb release id 91459) ist aber nicht von Roland, sondern von mir: ssdsa = S.E.S./Crest.
Roland und ich haben allerdings beide schon seit sehr langer Zeit eine Verbindung über das Thema Sprite-Multiplexer. Weiß jemand, welche?
Basicstand zur Motivation: <135 Bytes. Ich bin zufrieden
Hab jetzt laut printpeek(45)+256*peek(46)-peek(43)-256*peek(44) 53 Bytes, laut Windows-Explorer 55 Bytes.
Aber da geht bestimmt noch was Schmutziges.
ssdsa: Hoppla, sorry!
Wenn Leute den Source mitliefern, wäre schönes Kommentieren klasse. Ich komme zwar ums Verrecken nicht so weit runter, aber ich habe auch ein paar Lustige Konstanten, die ich nicht ausgerechnet reinsetze, sondern die Berechnung stehen lasse, damit man sieht, wie die zustande kommt.
Im Prinzip schon. Ein paar kleinere Aufgaben sollte man imho aber doch vorher mal gelöst haben: Bildschirm mit einem Zeichen füllen, eine Sinus-Tabelle in 40*25 plotten, vielleicht ein Byte als Binärzahl fest oben links auf dem Schirm ausgeben... Dann hast Du schon ein bisschen was mit Tabellen, Schleifen und Bits gemacht, was hier nützlich wird.
Hmmm... kann mich noch nicht aufraffen. Aber den Hinweis will ich versuchen mir zu merken und es dann irgendwann mal so angehen. Andererseits sind ja noch 4 Wochen...
Zum Warmlaufen, habe ich es in Excel VBA gelöst. ca. 12 Zeilen Code ohne "Optimierung".
Ja, lacht nur...
Und wieviel Bytes? Wie gut, dass der C64 serienmäßig VisualBasic kann
Basicstand zur Motivation: <135 Bytes. Ich bin zufrieden
Meine nachgebesserte Basic-Variante zur Motivation: <<120 Bytes, md5: 24a0de4647cf1180c6437cb0a87b5df9
Glaube, jetzt ist da nicht mehr viel für mich rauszuholen.
...
Meine nachgebesserte Basic-Variante zur Motivation: <<120 Bytes, md5: 24a0de4647cf1180c6437cb0a87b5df9Glaube, jetzt ist da nicht mehr viel für mich rauszuholen.
Respekt! Dann sollte ich doch nochmal schauen, ob ich nicht noch was kürzen kann...
Doch noch was gefunden...
md5: 2a04a030f61ef549b197c253228ea841