Kleiner Tipp: Schau mal in levelcode.asm, ob du da nicht irgendeine Abweichung von der Norm in Level 105 entdeckst.
Im Klartext: Das ist Beispielcode, der soll da sein, als Demonstration. Wäre hilfreich gewesen, das Readme zu lesen und nicht blind dem Tutorial zu folgen.

Mechalonisch? Ich auch nicht.

x)

Wenn sich Reggi verletzt fühlt, dann bitte sehr, entschuldigung. Abwertend hab ich das jetzt aber wirklich nicht gemeint - nirgendwo hab ich ihn beleidigt. Darfst ruhig locker bleiben.

Gibt's komischerweise als Patch.

Joa, wenn du die Sprechblase noch etwas verschönerst. Wenigstens ein t sollte raus.

Wenn sonst keiner will...

Wir können über jeden, der sich beteiligt, froh sein.

http://en.wikipedia.org/wiki/2.5D

Klasse Arbeit jedenfalls. Ich frage mich, wie die Plattformen aussehen würden, wenn du sie im Verhältnis zu Mario noch ein paar Pixel weiter runter schiebst.

Das steht doch im 16x16-Editor selbst? Wenn du mit der Maus über ein Teil fährst, siehst du am unteren Rand des Fensters die Nummer des Teils, und die gibst du einfach im "Act as"-Feld an.

Weiß nicht, ich find's im Map16-Editor einfacher. Glaube auch nicht, dass es eine Liste gibt doch, die gibt's.

Im Original-SMW ist entweder alles rutschig oder gar nichts; nur bestimmte Blöcke rutschig zu machen ist überraschend schwer. Sollte es aber auf SMWC geben, solche Blöcke.

Tun das nicht alle Blöcke?

Wenn du einen brauchst, der beim Berühren verschwindet, probiere das hier:

Hast du außer dem Semikolon noch was geändert? Das war Absicht. JMP M : M: ist Byteverschwendung.

Damit man merkt, dass das Auskommentieren Absicht war.


Nur das letzte JMP kann man getrost weglassen (natürlich immer vorausgesetzt, das Label, zu dem man springen will, steht gleich danach).
Weiß du noch, das alte Blocktool? Bei dem man Offsets als Zahlen angeben musste? Wenn man beispielsweise bei "Below" die Zahl 0 eingegeben hat, hieß das "Wenn man den Block von unten berührt, führe den Code aus." Gab man zum Beispiel "3" ein, hieß das "Wenn man den Block von unten berührt, überspringe die ersten drei Bytes des Codes und führe den Code von dort aus".

Das ist in BTSD praktisch genau so - nur siesht du die Zahlen dort nicht, die sind fest. Eigentlich sind die Offsets folgendermaßen: Below 0, Above 3, Sides 6, SpriteVert 9, SpriteHorz C, Cape F, Fireball 12, Corner 15, HeadInside 18, BodyInside 1B. Das sind genau die Stellen, an denen die JMPs stehen - und die springen dann weiter zu dem eigentlichen Code.
Und dann ist es auch egal, ob an Stelle 1B ein Sprung zum Label M steht oder gleich das Label selbst. Der Code, der ausgeführt wird, ist derselbe. Mehr als das letzte kann man aber nicht weglassen: wenn du die letzten beiden JMPs weglässt, dann führt zwar das HeadInside-Offset an die richtige Stelle (nämlich 18), aber die Stelle 1B ist dann mitten im Code, und wenn du dort hinspringst, crasht das Spiel.

Weil BTSD zu der Stelle, an der das jeweilige JMP steht, ein JSL ausführt.

Einfach erklärt:

Mit Hex-Edits änderst du den Code des Spiels, der schon da ist. Um eine Änderung aber nur für ein Level gelten zu lassen, musst du eine Überprüfung einbauen ("ist dies das gewünschte Level?"), und dazu musst du neuen Code einfügen. Das wiederum ist nicht das, wofür Hex-Edits gemacht sind. Dazu solltest du ASM können und dir einen Patch schreiben.

Wieso, geht doch? Mit dem Map16-Editor kannst du ein neues Teil erstellen, das dieselben Grafiken benutzt wie der normale Block, aber eine andere Palettenreihe.

Schon mal mit CMP.w probiert? Vielleicht weiß der Assembler nicht, dass du einen 16-Bit-Wert nehmen willst.

Na ja, einfach das gewünschte Teil per Rechtsklick über das alte drüberkopieren. Der originale Zement-/Steinblock ist Teil 0x130.

Bedenke aber, dass das für das ganze Spiel gilt.

Wo bitte hast du explizit CMP.w geschrieben?

REP #$20 reicht für den Assembler nicht aus, um zu wissen, dass er 16-Bit-Zahlen benutzen soll. Er kann nur Vermutungen anstellen, und die macht er manchmal bis oft falsch. Hier, was soll der Assembler mit folgendem Code machen?


Das REP #$20 kann auch übersprungen werden, wie du siehst, also ist es für den Assembler kein hinreichendes Kriterium, 16-Bit-Werte zu verwenden. Probier doch wirklich mal CMP.w aus.

Ach ja, und wenn du sagst "irgendwas ist schief", hilft das nicht gerade weiter. Die beste Vermutung, die ich anstellen kann, ist, dass der Code falsche Daten lädt? Das dürfte daran liegen, dass du das Data Bank Register nicht richtig eingestellt hast. Entweder du benutzt PHB : PHK : PLB, oder du machst es dir einfach und benutzt LDA.l. Siehst du, was Längenangaben für Probleme lösen können?

Du korrigierst doch auch gerne Dinge, die eigentlich nebensächlich sind? Müsstest doch eigentlich resistent dagegen sein.

Und eine potentielle Lösung hab ich im letzten Absatz ja schon angegeben.