snesfreaks.com

Classic Kong wurde gerade frisch vom Bubble Zap Team veroeffentlich, inklusive aufgemoebelter Grafiken und originalgetreuen Gameplay!

http://blog.supergnes.com/?p=295

Edit: Version 2.0 mit allen Levels hier -> http://code.google.com/p/classickong/downloads/list


(Video ist von Version 1.0)

Gestern mal kurz auf Konsole angezockt - macht schon Laune! Schöne und gelungene Umsetzung des Klassikers.

(Level zwei (50m) ist poopoo... ~_~
Wenn die linke Flamme sich nicht zu schnell wieder auf den Leiter-Abstieg begibt, sind diese verkackten Sprungfedern schon viel zu schnell, alsdass man die Leiter zum Level Finish hochkommt...)

Insgesamt: Sehr cool und eine sehr beeindruckende Leistung. Würde mich interessieren, ob dieser Shiru an dem Ding gesessen hat, seit er mit Christmas Craze fertig gewesen ist.

Bin nur ich es, oder ist der Source Code nicht, wie im Blogpost beschrieben, auf der Seite findbar?

Ansonsten... was ist euer Highscore? Ich bin beim zweiten Durchlauf von Level zwei hängen geblieben, mit 15300 Punkten. Ich habe es auch erst im dritten Anlauf überhaupt bis und durch Level 3 (100m) geschafft.

Cooles Ding ... Dieser Shiru gefällt mir!

... nur die Cartridgeform ist IMHO etwas zu extravagant.

LOL Da muß ich aber noch bissl am Modulschacht feilen...

BTT: Schönes Teil und danke für den Tipp!

Ich finde es etwas schade, dass die Factory nicht integriert wurde, eig sind es im Original ja vier Level. Aber die Qualitaet des Spieles als Homebrew ist trotzdem herausragend.

Da wir im Dev bereich sind kann ich hier vielleicht auch meine Probleme loswerden
Ich bekomme schon beim kompilieren folgende Fehlermeldung.
Hier mal der entsprechende Stelle in der optimierten game.s (7. Zeile)
Mein System:
Windows XP 32Bit
Python Version: 2.7.3

Die ganzen PCSnes Dateien habe ich vorhin nochmal frisch aus dem repository gezogen.

Kennt einer das Problem und hat vielleicht eine Lösung ?

Hui, wo hast du denn den Sourcecode her?
Es gibt im offiziellen Post von supergnes einen Link zum Sourcecode, aber da finde ich den nicht...

... leider kann ich dir nicht wirklich helfen, weil das Programm in C geschrieben ist, und C ist mir zu hoch. (pun intended)

Ansonsten kann ich nur raten.
Was sind TAS und TSA? Transfer Accumulator to S...?
Bedeutet ".ifgr" "If greater"?

... Könnte es funktionieren, wenn du das SEC rausnimmst...?

Der Source ist bei Google Code ziemlich gut versteckt
Du müsst ganz rechts auf dem Tab auf Source. dann öffnet sich schonmal eine Seite mit dem svn repository. Das ist meiner Meinung nach die bequemste Art den Code zu Laden.Musst natürlich vorher svn installieren und bisschen Doku lesen wie es funktioniert.
Ansonsten kannst du dann unter den HauptsNavigationstabs auf Browse klicken. Dann in der Baumansicht die sich links öffnet und auf Trunk.

An dem Assembler Code würde ich ungern was ändern. Erstens verstehe ich ihn nicht und zweitens wird der schon nicht ohne Grund da sein
Das sbc, also der Befehl der den Fehler wirft ist wohl eine
Subtraktion mit Beachtung des carryflags. Was ich aber auch komisch finde ist, dass mir der Assembler sagt, dass der Wert den ich Subtrahieren möchte größer als 16 Bit ist ...
Ich werde mal versuchen den Entwickler anzuschreiben vielleicht hat er einen heißen Tipp für mich :/

Das wäre eine Möglichkeit, joa. Wenn du was rausbekommst, lässt du mich es dann wissen?

Der Assemblercode macht exakt das, was du sagst.

Wenn ich das .ifgr mit "wenn größer" richtig verstanden habe, heißt dein Codeauszug:

Wenn __rand_locals größer null, dann
transferiere S... in den Akkumulator
Setze den Carry Flag
Subtrahiere __rand_locals vom Akkumulatorinhalt (also diesem S...)
Transferiere den Akkumulatorinhalt zurück in S...

Zu SEC und SBC kannst du dir eine kurze Erklärung im 65816-Handbuch anschauen. Seite 395 bzw. 397 (das sind die PDF-Seiten, nicht die Seitenzahlen).

Der Carryflag muss vor einer Subtraktion gesetzt werden, da er hier als Übertrag fungiert. Falls man eine Zahl von einer kleineren abzieht und den Carryflag nicht gesetzt hat, geht das Ergebnis in die Binsen. Soweit die Theorie.

Hab gerade eine Antwort von Shiru bekomme

Alex Semenov
Hello. The problem is that the TCC816 compiler is quite broken. I ran into this particular problem during developing of the Classic Kong, and mic made a version that fixes the problem: http://jiggawatt.org/notmine/816-tcc-120507.zip

liegt also am Compiler. Leider kann ich das jetzt nicht testen weil ich auf Arbeit bin aber bis heute Abend werde ich das definitiv getestet haben.

Hmpf. Was für eine unbefriedigende Lösung.

Nur mal doof angefragt: Sollte dieser Compiler vielleicht lieber auf eurer SNES-Cloud archiviert werden? Sammelt ihr da DevTools u. ä.?

Also der Compiler scheint schon besser zu funktionieren.
Leider schaffe ich es immer noch nicht eine ROM zu erstellen ~.~

Neue Fehlermeldung, die jetzt immerhin vom letzen Build Schritt (wlalink.exe) geworfen wird. Die Recherche geht weiter

Btw. der neue Compiler hat auch eine neue Dependency und zwar braucht man die cygwin1.dll.
Ich habe mir einfach komplett cygwin installiert und die Batchdatei compile_c.bat um folgende Zeile erweitert, damit die neue Version des Compilers die DLL auch findet. Ihr müsstet den Pfad natürlich so anpassen das er eurer Cygwin Installation entspricht

Farbauti hat geschrieben:

Code: Alles auswählen

CHECK_HEADERS: The object files are from different projects.

Gut, da habe ich wieder mal keine Ahnung. Um die Lösung des alten Problems nochmal anzuschieben... hast du denn auch die aktuellste Fassung von WLA DX?

Ich kann dir nur sagen, dass object files auf ".obj" oder auch mal auf ".o" enden, und quasi zur Hälfte in Maschinensprache kompiliert sind (soweit ich das bei meinem Textbox-Programm sehen kann), nur z. B. die Labels ("Sprungmarken") noch drin stehen.
Diese Dateien wurden dazu eingeführt, dass man sein Projekt nicht immer komplett kompilieren muss, sondern nur einzelne object files, und diese dann "verlinken" muss. Ich schätze mal, verlinken heißt:
Nachdem in den object files die meisten ASM-Befehle in Binärzahlen für die Opcodes umgewandelt werden, wird mittels wlalink geguckt, welche Labels benutzt werden, und diese werden dann schlussendlich in Hexadezimalzahlen umgerechnet (nämlich die exakte Angabe, ab welchem Byte es weitergeht, quasi, wo der Opcode steht, der im ASM-Text der erste Befehl nach dem Label war).

Soweit dazu. Was er jetzt aber mit Headern meint, weiß ich nicht... :-/