Wo finde ich die nochmal?
Normalerweise in seiner Signatur der mittlere Link "C64 Studio (WIP!)".
Posts by atomcode
-
-
Goodwell Für welches BASIC? Für BASIC V2 funktioniert es jedenfalls noch in Version 7.2. Gerade getestet.
-
1. The Great Escape, 1986, Dat
2. Labyrinth, 1986, Dat
3. Krakout, 1987, Dat
-
Worms Revolution Marsmission 4. Die Longplayer auf Yt brauchten dafür ca. 15-20min. Hab es in 5min geschafft und bekomme trotzdem nicht mal 'ne Bronze-Medaille dafür, und das nennt sich dann Langzeitmotivation.
Wahrscheinlich gibt es bei 4:40-4:59 Bronze, 4:20-4:39 Silber und darunter Gold, m.E. eine viel zu komprimierte Aufteilung.Außerdem schafft man das in der Regel nur mit viel Glück, weil niemand die genaue Bewegung des Wassers oder einer Granate voraussagen kann. Der KI-Gegner kann das interessanterweise: Die werfen die Granate genau so gegen irgendwelche Polygonflächen, die ja genau betrachtet alle eben sind und einen bestimmten Winkel haben, dass sie wieder im exakten gewünschten Winkel abprallt, und das über zig Wände und Ecken, sodass das Teil am Ende genau vor Deiner Nase landet und zwar auf der richtigen Seite, sodass man dann durch die Wucht in eine Schlucht befördert wird. Nur ist in Wirklichkeit eine Felswand kein Polygon, sondern bis ins kleinste unregelmäßig.
Über KI hatten wir uns hier irgendwo neulich noch unterhalten, wo ich sagte, dass man die heutige Rechenpower in einem Spiel dafür nutzen könnte, den NPCs Starke KI zu implemtieren, um ihr Verhalten realistischer zu machen. Jemand meinte darauf, dass das nicht schön wäre, weil die dann ja viel zu stark wären (darum ist ja auch jeder Mensch auf der Welt ein Genie und unfehlbar
). Dieses Spiel zeigt wieder gut, dass es genau umgekehrt ist und man mit purer, perfekter und damit unrealistischer Berechnung viel kaputt, nervig und langweilig machen kann. Wenn überhaupt auf diese Weise, dann muss man da immer einen Mindestzufall einwirken lassen.<edit> So, trotzdem geschafft ..
-
P.S.: Statt "Line, Row" müsste es doch eigentlich "Line, Column" heißen, oder?
Seit x Jahren steht das so drin, und keinem ist es bisher aufgefallen.Bei mir steht analog zum Visual Studio seit langem schon Line und Char. Manche Editoren schreiben auch (BASIC-like) Line und Pos. Char gefiel mir am besten, weil beides 4 Buchstaben hat. Ich leide da unter gewissen Zwängen.
-
Wäre es eigentlich möglich, dass bei reinem Maschinencode das Studio optional einen Aufruf desselben veranlasst? Endurion
-
• Kenne nur DKC1. Wenn ich die Musik von DKC2 höre (obwohl sie hier geSIDet ist), würde ich annehmen, dass es noch derselbe Musiker ist, der das kreiert hat.
• Ich hab im Forum mal vorgeschlagen, "Rock'n'Roll-Racing" vom SNES auf den C64 zu portieren. Ließe sich auch diese Musik nach gleichem Verfahren nachbauen?
-
Oder geht das nur ab 0801?
genau, beim C64 zumindest
Als SYS-Adresse das erste Label angeben, "Anfang" oder whatever.
Wenn Code nach $c000 soll, kann der dort mit einer kleinen Schleife hingeschoben werden; erst dann dort hinjumpen.
-
Ich kann BASIC V7 auch nicht, aber wenn BEGIN/BEND ein Block sein soll, dann dürfte dieser nach Auswertung des Ausdrucks im false-Fall nicht ausgeführt werden. Eigentlich auch dann nicht, wenn man das mit der THENIF-Verkettung macht. Klar, wenn das erste oder zweite IF schon nicht erfüllt ist, sieht er kein BEGIN (wird von der REM-Routine überlesen) und macht in der nächsten Zeile weiter, weil er nicht weiß, dass das ein Block ist, in dem er ohne BEGIN nichts zu suchen hat. Ich würde, wie in C, dabei immer Klammern benutzen, dann passiert einem die ganze Konstruktion erst gar nicht. Und ja, nur mit AND sollte es auch so klappen, weil es dann ja nur ein IF ist.
BASIC V2 prüft in der Routine des AND-Operators nicht, ob der erste Ausdruck 0 ergab, sondern führt die Operation immer durch.
Der IF-Befehl prüft wiederum auch nur den gesamten Ausdruck. Darum ist die THENIF-Konstruktion schneller, hier allerdings dann wohl unangebracht.
-
So was wie den "Multisound Synthesizer" meinte ich ..
Programme, die eine virtuelle Tastatur hatten und in Kombination mit dem SID-Chip einen vollständigen Synthesizer im Sinne eines Keyboards darstellten, hier "Synthimat 64":
Das erste Programm dieser Art, mit dem ich damals etwas herum gespielt hatte, hieß "Synthesizer 64".
Und hier noch ein hörbares Beispiel mit dem "Kawasaki Synthesizer" von 1983. Hätte man denen damals schon die heutigen Produktionen aus Goat-Tracker oder SID-Wizard vorspielen können, hätte man nicht schlecht gestaunt und wahrscheinlich zunächst einen anderen Soundchip dahinter vermutet.
[External Media: https://www.youtube.com/watch?v=3vDl_0xPyyc] -
IF [Aussage 1 = wahr] THEN IF [Aussage 2 = wahr] THEN IF [Aussage 3 = wahr] THEN [...]
ist logisch gesehen das gleiche wie ..
IF ( [Aussage 1 = wahr] AND [Aussage 2 = wahr] AND [Aussage 3 = wahr] ) THEN [...]
Es müssen also alle Bedingungen erfüllt sein, um die Anweisung nach dem letzten THEN auszuführen.
-
Wenn man das so hört ... Die Sound-Evolution auf dem C64 ist auch der Hammer, denkt man mal an die allerersten BASIC-Spiele und -Software-Synthesizer mit schnöden ADSR-Tönen zurück.
-
Mich würde in diesem Zusammenhang interessieren, woher die Cracker ihr Wissen und ihre Fähigkeiten hatten. Das Wissen über die Systeme war ja noch nicht weit verbreitet in den frühen 80ern.
Es steht in diversen Büchern über Tipps und Tricks auch, wie man einen Kopierschutz erstellen kann. Dieses Wissen ist natürlich gleichzeitig eine Anleitung, wo man ansetzen muss, um es zu umgehen oder zu entfernen. Ganz neue Techniken mussten sicherlich anfangs mithilfe guter Grundfähigkeiten erforscht oder vielleicht aber auch geleakt werden. Ich habe das Buch "DAS ANTI-CRACKER BUCH", da steht schon viel drin, aber es ist auch erst 1987 erschienen. Wie genau das ganz zu Anfang lief, das müssten mal Ehemalige aus den damaligen Top-Gruppen selbst erzählen. Ich vermute aber, dass die Mechanismen anfangs auch noch nicht so kompliziert bzw. nicht so schwierig zu entfernen waren.
-
Zum Ruckeln hatte ich vor ein paar Wochen auch was darunter geschrieben. Dass man alles richtig machen kann und es am Ende trotzdem dann noch an YouTube oder am Endanwender liegen kann, wenn sein Monitor z.B. auf 60Hz eingestellt ist. Ich hatte zwei Interlace-Bilder da hochgeladen, eines mit 50Hz und eines mit 60Hz. Beides funktionierte anfänglich, wie es sollte. Nach ein paar Monaten wurde aus dem 60Hz-Video durch YouTube einfach mal 30Hz, und man sah nur noch jeden zweiten Frame bzw. ein starres und nicht mehr gemischtes Bild. Auf so was kann natürlich der Ersteller und seine Software keinen Einfluss haben.
-
check i ned ? worum gehts jetzt ?
ULA => ooh la la
Übrigens, es gibt im Frühjahr immer diesen 10-Zeiler-Wettbewerb. Leute aus aller Welt, alle mit BASIC, aber auf verschiedenen 8bit-Systemen. Hab auch schon mal mitgemacht. Teilweise enorm, was die herausholen. Hier ein Bericht bei golem: https://www.golem.de/news/basi…gewinner-2204-164573.html
-
Damit kann man IMO überhaupt keine "guten" Programme schreiben
Definiere "gute Programme".
Das hatte ich in dem von dir rausgekürzten Teil versucht.
Sorry, war undeutlich, die Aufforderung sollte eher rhetorisch sein und an den Schlaumeier (und seinen Vertretern) gerichtet, von dem das Zitat ist, um das es hier ging. ("gutes Programmieren").
Aber wer sagt, dass jeder, der etwas entwickelt, mit anderen zusammenarbeitet, die daran mit- oder weiterarbeiten? Wenn ich im C64-Studio jede Menge Anmerkungen und Erklärungen habe, reicht mir das doch. Da steht dann an jedem Abschnitt und jeder Unterroutine, was da passiert. Sehe da kein Problem.
Da muss man dann eben noch die Perspektiven unterscheiden. Als Anwender oder Spieler reicht mir, wenn das Programm für mich gut ist. TrueCrypt ist so ein Beispiel, das zwar gut war, aber aus einem schrecklichen Frickel-Code besteht. Umgekehrt kann es zwar gut organisierte Projekte von einem Team geben, aber dann dennoch Murks, oder zumindest in Teilen. Schau Dir mal die KI in "Worms Revolution" vom Team17 an und denke mal darüber nach, was da der komplette (extra programmierte!) Schwachsinn ist, der einfach nur nervt. Können wir uns gern mal im KI-Thread drüber unterhalten. Wäre auch für den "Zufall"-Thread geeignet.
Nicht alles was hinkt, ist ein Vergleich
Ich weiß, ich könnte 138000 Analogien aufzählen, und selbstverständlich hinkt alles. Kenne ich.
Menschen die zweisprachig aufwachsen, lernen später weitere Sprachen viel schneller.
Und wo hat der Schlaumeier gesagt, dass es nur um eine BASIC-Variante ging? Und selbst, wenn Du Pascal oder Fortran dazu hattest, hat das nichts mit OOP und dergleichen zu tun, analog zu EN/FR/NL etc. vs. Chinesisch oder gar Finnisch.
Der hatte überhaupt keine Gewissheit.
Auf einmal. Vorher hieß es von Dir selbst noch, dass es genauso sei, wie er sagt. Genau wie derjenige, der sich nach langer Zeit hier extra anmeldet, obwohl er ja nicht viel Zeit hat, nur um hier diesen deplatzierten Quark reinzuhauen, anstatt was Sinnvolles zum Thread-Thema beizutragen. Was will man damit bezwecken, außer den BASIC-Liebhabern durch die Blume mitzuteilen, dass sie alle rückständig und dumm sind und niemals ein gescheiter Programmierer werden können bzw. konnten? Wofür genau brauchen wir das? Du siehst ja an der Diskussion schon, die dadurch wieder entbrannt ist, dass das vielen eben nicht am A... vorbei geht und/oder sie das anders sehen, und alles ist mal wieder off-topic dadurch. Einfach nicht darauf eingehen? Damit Initiator und Zustimmende sich bestätigt fühlen können? Man könnte es alternativ auch einfach mal lassen. Leben und leben lassen! Nicht zu verwechseln mit .. Kleben und kleben lassen!
-
Damit kann man IMO überhaupt keine "guten" Programme schreiben
Definiere "gute Programme". Windows und dessen Anwendungen z.B.? Wo man auch auf einem riesigen Monitor Dialogfenster absichtlich starr und winzigklein macht, damit man sich darin wie mit Scheuklappen 'nen Wolf scrollt (um nur eine von unzähligen Idiotien zu nennen)? Ist das die Errungenschaft "guter strukturierter Programmierung"? Und stattdessen war "Die Fugger" also einfach nur Mist, allein weil es in BASIC geschrieben wurde?
Ich kann z.B. CNC für Entspanungsmaschinen, eine lineare Sprache, die genau darauf zugeschnitten und dafür angemessen ist. Genauso ist es mit allen anderen Systemen. Und bei allen kann damit etwas Gutes oder auch Schlechtes herauskommen. Oft liegt es gar nicht an der Sprache, sondern an Ideen und ihrem Sinn. Die Möglichkeit der Strukturierung allein macht noch kein gutes Programm. Und unter "gut" verstehe ich eben, dass es den Bedürfnissen des Anwenders oder Spielers gerecht wird.
-
Ich habe zuerst Radfahren gelernt, darum werde ich nie ein guter Autofahrer. Und wenn ein Rennfahrer in seiner Privatzeit einen Smart fährt, kann er im Rennen auch nur schlecht sein. Menschen, die zuerst Deutsch lernen, werden nie Englisch oder Französisch lernen können, weil die Grammatik ganz anders ist, von Chinesisch ganz zu schweigen. Ein Zeichner, der am Reißbrett gelernt hat, wird niemals ein guter CAD-Zeichner. Jemand, der in der Jugend Fastfood gegessen hat, kann kein guter Koch werden. Und wer in der Schule Blockflöte lernte, wird niemals richtig Piano spielen können.
... weil ja grundsätzlich kein Mensch in der Lage ist, mehrschichtig zu denken und dazu- oder umzulernen. Ich frage mich nur, woher die Leute, die so was behaupten, ihre Gewissheit haben. Gibt es dazu Umfragen oder Langzeitstudien, die das belegen, oder ist es einfach nur eine Behauptung aufgrund der eigenen Vorstellung, weil es "doch ganz klar" sein muss? Können die sich nicht vorstellen, dass jemand, der zuerst BASIC lernte, sich dabei vielleicht selbst schon strukturierte Features wünschte, die das BASIC nicht hat? Wie kann das sein, wenn er doch durch BASIC ein Brett vor dem Kopf hat und nicht darüber hinaus denken kann?
Im Zitat stand zwar nichts von "gutes *strukturiertes* Programmieren" für PC, aber gut, wahrscheinlich war das gemeint. Nur dann ist das Zitat hier komplett off-topic und fehl am Platz. Laut TE geht es ihm um die Heimcomputer, um Spieleprogrammierung dafür. Und wer Lust hat, eines in BASIC zu schreiben oder wie ich, dieses als Quelltext für die manuelle Assemblierung zu benutzen, der tut das eben. Dabei spielt es hier in diesem Thread keine Rolle, ob derjenige deswegen niemals ein genialer Anwendungsentwickler für moderne Systeme wird oder werden konnte. Zumal diese Überlegung vom Alter her hier sowieso für viele langsam müßig ist, denn entweder schon lange am Arbeiten oder sogar in Rente. Um etwaige Kinder ging es hier auch nicht.
Mir wäre auch neu, wenn es für den C64 ein fettes echtes C++-Paket gibt, mit IDE und Compiler. Selbst wenn, könnte ich es für meine Bedürfnisse gar nicht gebrauchen. Einfache Strukturbefehle à la Pascal, ja, aber OOP für ein 8bit-Jump&Run oder 'nen popeligen Mazer? Ach ja, ich glaube, Endurion lässt das C64Studio in Wirklichkeit von seiner Oma stricken, denn so, wie er BASIC kann, kann er unmöglich strukturiertes C# können.
-
Danke für die ausführliche Antwort.
-
Wie funktioniert das Fast GOTO/GOSUB eigentlich?
Vermutlich wird da auch eine Tabelle für Zeilenadressen angelegt. Eine handvoll davon gleichmäßig verteilt reicht, um ab diesen die gewünschte Zeile zu suchen. In meinem QuickNum sind es maximal 32 Zeilenadressen, die (im Stack) gespeichert werden, sodass das Listing in bis zu 32 Teilen aufgeteilt wird. Dann wird durch Zeilenvergleich geprüft, in welchem Teil die gesuchte Zeilennummer liegt und ab der entsprechenden darunter liegenden Adresse gesucht. Man befindet sich also immer schon in der Nähe und muss nicht jedes Mal bei $0801 anfangen, zu suchen.
