Druckbare Version
Kann ich nur zustimmen. Wer sich trotzdem das ganze ansehen will und nicht unbedingt seinen PC schrotten will, der kann mal "SPIM" und "MIPS" googlen, bzw. "MARS" gibts da auch noch. Ein Handbuch (PDF) müsste unter Umständen noch als "spimdoku" (oder so ähnlich) zu finden sein. Hierbei handelt es sich einfach nur um Assembler- Simulatoren, allerdings würde ich es mir nicht noch einmal antuen wollen. :DZitat:
Zitat von MagicMagor
Ja und nein, also ein klares Jein ;) "Eine Programmiersprache beherrschen" ist etwas unglücklich ausgedrückt, finde ich. Man kann eine Programmiersprache bis in ihre tiefsten Tiefen kennen, und trotzdem ein sehr schlechter Programmierer sein. "Programmieren lernen" funktioniert weitgehend unabhängig von den Sprachen die man dazu benutzt. Dabei geht es darum, ein Problem exakt zu analysieren, es möglicherweise in seine kleinsten Bestandteile zu zerlegen, um dann mit dem zur Verfügung stehenden Werkzeug, also der Programmiersprache, die man gerade da hat, einen Algorithmus zu entwickeln und zu einer Lösung zu kommen.Zitat:
Zitat von R.F.
Fast jede Programmiersprache ist nach den gleichen Regeln aufgebaut. Auch wenn in Ruby nahezu Alles und Jedes ein Objekt ist, gibt es doch viele Gemeinsamkeiten mit Sprachen, die vermutlich bereits vor der Geburt eurer Eltern ausgestorben waren. Ich erwähne nur mal COBOL. Variablen, Schleifen, Kontrollstrukturen, Bedingungsabfragen, und so weiter, wirst du in jeder Sprache finden, auch wenn es manchmal etwas schwer zu erkennen ist. (Brainfuck, anyone?) :D
Wenn jemand eine Programmiersprache "beherrscht", sagt das nicht wirklich viel. Wer hingegen das Programmieren gelernt hat, kann seinen Quick-, Heap-, Bubble- Sort-oder Sonstwas-Algorithmus in kurzer Zeit in nahezu jeder Sprache umsetzen.
Modernere Sprachen kommen allerdings mit umfangreichen Funktionsbibliotheken daher, die einem erfahrenen Programmierer schon einen Großteil der alltäglichen Arbeit abnehmen.
Jeder, der gelernt hat, zu programmieren, sollte in der Lage sein, sich in wenigen Stunden mit einer neuen Umgebung vertraut zu machen - ob die IF-Abfrage nun in C++, Python, Ruby, oder sonstwas da steht, macht keinen Unterschied. Um aber herauszufinden, wie eine bestimmte Programmierumgebung ihre Standard-Objekte handhabt, und welche Methoden sie zur Verfügung stellt, braucht man etwas mehr als 'n verkürztes Wochenende.
Wann also "beherrscht" man eine Programmiersprache? Wenn man 'ne WHILE-Schleife ohne Syntaxfehler abtippen kann? Oder ist es doch erst, wenn man alle Standard-Funktionen, -Methoden und -Objekte schon mal zum Essen (Incl. Vor- und Nachspiel) eingeladen hat?
Wenn der Aufruf einer Standard-Funktion in bspw Python nicht so funktioniert, wie ich es erwarte, schaue ich in den Sourcecode wo diese Funktion deklariert ist, und sehe meistens sehr schnell, warum das Ding sich nicht so benimmt wie erwartet, und meistens habe ich dann auch bald eine Idee, wie ich die gewünschten Ergebnisse bekomme. Falls es doch mal länger dauert, liegt es meistens daran, dass ich ich irgendwo einen Denkfehler und/oder ein Logik-Problem habe.
Anyway, man KANN mit einer (nahezu) beliebigen Sprache fast jedes Programmierproblem lösen - es bleibt nur die Frage, ob es die dafür aufgewändete Zeit Wert ist. Mit Grausen erinnere ich mich daran, wie unser Dozent erwartet hat, dass wir eine größere Sammlung von C++-Standard-Funktionen nachprogrammieren und nach unseren (seinen) Wünschen modifizieren können. Aber: das daduch erlangte Wissen und die Erfahrung möchte ich heute nicht mehr missen - auch wenn ich nur noch selten programmiere..
Nein. Nicht, so wie ich es sehe. Einer Sprache beherrschen bedeutet für mich, dass man wirklich mit jedem Standad-Objekt und jeder Standard-Funktion oder Methode, die die Sprachumgebung zur Verfügung stellt, auf Du-Und-Du steht. Aber wer tut das schon? Wie ich Eingangs erwähnte, dauert es vielleicht einen oder zwei Nachmittage, um sich mit einer neuen Sprache vertraut zu machen - WENN man programmieren gelernt hat. Wenn man das gelernt hat, ist die Sprache wirklich egal, oder nicht?Zitat:
Es gibt allerdings einen Unterschied zwischen "eine Programmiersprache lernen" und "eine Programmiersprache beherrschen", letzteres erlaubt nämlich, dass dir auch andere solche Sprachen leichter fallen.
Um zum Threadstarter zurückzukommen: Es ist egal, mit welcher Sprache du anfängst - du wirst immer mal auf Verständnisprobleme stoßen - da wird sich durchgebissen, das gehört sich so.:D
Wenn du allerdings glaubst, es braucht nur ein paar Zeilen Code, um alle deine Wünsche zu erfüllen, irrst du dich - um diese paar Zeilen schreiben zu können, musst du nämlich auf die Erfahrungen und das Wissen zurückgreifen können, die du dir in vielen tausend vorhergehenden Zeilen erarbeitet hast. Ja, ich habe auch schon mal 2000 Zeilen Code geschrieben um ein Problem zu lösen, welches sich nach Klärung eines Verständnisproblems und Aufbesserung einer Wissenslücke mit 15 Zeilen lösen ließ. So ist das Leben.
Eine kurze Google-Anfrage ergibt, daß du hier wohl etwas verwechselt. Unter dem Begriff "MIPS" finde ich eine Mikro-Prozessor-Architektur, was sich mit den Simulatoren decken würde, da man hier einen Mikroprozessor simulieren muss.Zitat:
Wer sich trotzdem das ganze ansehen will und nicht unbedingt seinen PC schrotten will, der kann mal "SPIM" und "MIPS" googlen, bzw. "MARS" gibts da auch noch. Ein Handbuch (PDF) müsste unter Umständen noch als "spimdoku" (oder so ähnlich) zu finden sein. Hierbei handelt es sich einfach nur um Assembler- Simulatoren, allerdings würde ich es mir nicht noch einmal antuen wollen.
Mikroprozessor-Programmierung ist kein Assembler. Mikroprozessor-Programmierung liegt eine Ebene tiefer unter dem Assembler und ist gewissermaßen die Schnittstelle zwischen Assembler und Hardware.
Assembler braucht man nicht simulieren, man kann es direkt zu einer binary assemblieren und ausführen. (für die in heutigen PCs verwendete x86-Architektur wäre das zB mit NASM möglich)
Mal ein direkter Vergleich von Hochsprachen und Assembler:
Einspruch! µPc ist sehr wohl Assembler, nur halt mit einem etwas anderen Befehlssatz, als man ihn vom PC her kennt - aber was soll's? Der 286er hatte auch einen ganz anderen Befehlssatz und eine andere Register-Struktur als moderne Prozessoren, trotzdem ist beides Assembler. Unterschiedliche Dialekte will ich gerne zugeben, aber immer noch Assembler - genauso wie das, was ich für meine ATMEL-Chips fabriziere.Zitat:
Zitat von MagicMagor
Vielleicht meinen wir hier jeweils mit Assembler nur etwas anderes. Bei uns wurde in Info2 Mikroprozessor-Programmierung seperat von Assembler behandelt und eben eine Ebene tiefer angesetzt. Vermutlich kann man das auch als Assembler bezeichnen, ich habe hier im Thread aber mit Assembler implizit die x86-Architektur gemeint und dessen Befehlssatz wie er eben von NASM erzeugt wird.Zitat:
Einspruch! µPc ist sehr wohl Assembler, nur halt mit einem etwas anderen Befehlssatz, als man ihn vom PC her kennt - aber was soll's? Der 286er hatte auch einen ganz anderen Befehlssatz und eine andere Register-Struktur als moderne Prozessoren, trotzdem ist beides Assembler. Unterschiedliche Dialekte will ich gerne zugeben, aber immer noch Assembler - genauso wie das, was ich für meine ATMEL-Chips fabriziere.
Denn hier im Thread geht es nunmal immer noch um Patches für den Maker und demzufolge mMn um das Verändern der Maker-Exes, der nunmal in x86-Code vorliegt.
Kann gut sein. Hamburger glauben auch nicht, dass Bayern Deutsch sprechen können. ;)Zitat:
Zitat von MagicMagor
Da würde mich echt mal interessieren wieso? Ob ich meinen MOV AX Sonstwas nun auf 'nem X86 oder auf 'nen ATMEL ausführen lasse, ist doch Wurscht - beides ist Assembler.Zitat:
Bei uns wurde in Info2 Mikroprozessor-Programmierung seperat von Assembler behandelt und eben eine Ebene tiefer angesetzt.
Allein bei den X86ern gibt's -zig Dialekte die auch auf Verlangen von NASM passend erzeugt werden können. Im Standardfall nimmt er halt den kleinsten gemeinsamen Nenner - aber IIRC, kann er sogar für ATMEL, PICaxe und sonstwas passenden Maschinencode erzeugen. Alles Assembler, in meinen Augen, aber ich will mich da nicht streiten.Zitat:
Vermutlich kann man das auch als Assembler bezeichnen, ich habe hier im Thread aber mit Assembler implizit die x86-Architektur gemeint und dessen Befehlssatz wie er eben von NASM erzeugt wird.
In welchem? Dem von Intel, oder dem von AMD, oder gar ganz rustikal in dem von CYRIX? http://www.multimediaxis.de/images/s.../old/s_044.gifZitat:
Denn hier im Thread geht es nunmal immer noch um Patches für den Maker und demzufolge mMn um das Verändern der Maker-Exes, der nunmal in x86-Code vorliegt.
OK, ich will mich wirklich nicht streiten, aber für mich ist Assembler eine Suppe, die jeweils passend für den Prozessor zugeschnitten (gewürzt) wird/wurde, auf dem sie ausgeführt (gekocht) werden soll. Ob der Topf nun Intel, AMD, Atmel, oder sonstwie heißt, interessiert mich nicht. Zumindest so lange nicht, wie es nicht um Zeit-kritische Anwendungen geht, wo zB der AMD 1 bis 2 Prozessorzyklen mehr für einen Assembler-Befehl braucht als der Intel - oder umgekehrt, je nach Situation.
Ein Assembler ist einfach nur ein Übersetzungstool für beliebige Befehlssätze (MIPS, x86, ARM, PowerPC, usw, wobei es in der Regel noch weiter zwischen Dialekten unterschieden wird, wie Das 'O' bereits bemerkte).
Was MagicMagor wohl mit "Mikroprozessor-Programmierung" meint, ist die Implementierung eines Befehlssatzes mittels des Mikrobefehlssatzes der zugrunde liegenden Hardware, was jedoch vom Hardwarehersteller selbst vorgenommen wird. Der Begriff "Mikroprozessor-Programmierung" ist hier anscheinend nur unglücklich gewählt.
Mit Mikroprozessor/-controller-Programmierung verbinde ich, wie auch Das 'O', die Programmierung eines Mikroprozessors/-controllers mittels eines Befehlssatzes, oder einer höheren Programmiersprache wie etwa C.
Das liegt daran, dass der Server von meiner Seite zurzeit offline ist, wegen technischen Problemen. Sollte morgen Mittag eigentlich wieder gehen.Zitat:
Zitat von Rayo
@MagicMagor:
Vielen Dank für deine PM, die meine Frage beantwortet hat. :) Ich finde, du hättest es ruhig hier im Thread schreiben können. Auch wenn es ein weiterer kurzer Ausflug ins Off-Topic-Land gewesen wäre, hätte der eine oder andere Leser vielleicht davon profitieren können.
@Rayo:
Wenn du eh gerade Python lernst, warum installierst du nicht Ruby und versuchst deine Programmieraufgaben parallel in beiden Sprachen zu lösen? So lernst du gleich etwas über die verschiedenen Konzepte, aber auch die Gemeinsamkeiten, die den beiden Sprache zugrunde liegen.
Die Ruby-Kenntnisse kannst du dann später dazu benutzen, deine Maker XP Spiele aufzupeppen.
Was das Entwickeln von Patches angeht, wirst du dann in einigen Jahren über deine heutige Naivität grinsen. Denn auch wenn es relativ leicht ist, einen Patch-Generator in Python, Ruby, oder sonst einer Sprache zu schreiben, ist es ungleich schwerer erstmal herauszufinden, welches Byte dieser Generator dann "verbiegen" soll, und wohin.
Wenn ich mich recht erinnere, haben Cherry und Andere Anleitungen veröffentlicht, wie man mit 'nem HEX-Editor der RTP_RT.exe 'n paar neue Kunststückchen beibringen kann. An deiner Stelle würde ich mich mal an denen versuchen und glücklich sein, wenn es klappt.
Aber erst wenn du genau verstehst, was du da tust und vor allem warum, kannst du daran denken, selbst mal sowas zu entwickeln.
Um selbst zu patchen brauchst du also 'nen HEX-Editor und das Wissen, welche Bytes wie geändert werden müssen. Der HEX-Editor ist leicht zu beschaffen :D
Ich mache meine Spiele zurzeit im RPG Maker 2000 und hatte einen Laufpatch für mein Spiel geplant, aber mal sehen ob ich was draus machen kann.
Und zu Phyton: Lieber eine Programmiersprache lernen, nicht gleichzeitig zwei.
Ich wollte ja nur kleine Dinge ändern, aber das wird wohl auch eine Herausforderung werden, wie ihr das hier bescheibt.
Dann schau ich mal den HEX-Editor oder was anderes zum Patchen an und sehe mir mal das ganze mal genauer an. ;)
Aber irgendwie geht Cherrytree immer noch nicht??! Naja, Abwarten...
Wie sollte dann dieser Laufpatch aussehen?
Oder meinst du evtl ein Renn-Script, wie es viele Spiele mehr oder minder erfolgreich verwenden?
Nein, der Laufpatch soll die Auswahl der Geschwindigkeit verdoppeln/verdreifachen..., sodass man z.B. zwischen 1 und 2 auch 1.5 wählen kann. Sowas hatte ich mir immer schon gewünscht.
Auu, das wirst du sicher nicht hinbekommen, das sag ich dir gleich. Ganz so einfach ist das nämlich nicht, wie etwa irgendeinen Text verschieben oder irgendwas überspringen.
Sonst hätt ich das schon gemacht.
Das stützt sich nämlich auf die 60 Frames pro Sekunde und einigen anderen Kram.
EDIT: Hm, obwohl, mir fällt da grade was ein. Mal sehen. Aber Rayo sollte es trotzdem lassen - bzw. versuchen kannst du es ja, aber du wirst gar nicht wissen, wo du suchen sollst.
EDIT²: Aber Cherry Tree ist wieder online, die RM Interna.cue könntest du dir also saugen. Fraglich ist nur, ob sie dir nützt.
Ich denke RM Interna.cue wird mir viel weiterhelfen.
Ich schau mal wie das ganze ist.
(Nachdem ich die letzten Noten geschrieben habe) ;)
Ich bin mit dem Patches usw nicht so bewandert, da ich mich gerne an das halte, was ich habe.
Aber es gibt natsächlich einen Patch der mich interessieren würde.
Ich benutze den RM2k3 und das standart KS.
Ist es möglich einen Patch zu entwickeln, der die LP des Gegners anzeigt ?
Z.B. während ich den gegner für einen angriff / zauber anvisiere ?
Danke im Vorraus.
Mit dem PicsInBattle-Patch, an dem ich gerade arbeite, könnte sowas vielleicht sogar gehen.
Das klingt genial. Ich habs das ja schon ansatzweise in Davias Gamethread mitbekommen.Zitat:
Mit dem PicsInBattle-Patch, an dem ich gerade arbeite, könnte sowas vielleicht sogar gehen.
Wann kommt mein heissgeliebter Patch zum ändern der Event IDs?! xD