Naja, das kommt daher, dass die da, um zu verhindern, dass im Speicher was überschrieben wird, wenn zu hohe Picture IDs verwendet werden, die ungefähr sowas drin haben:
Das sollte normalerweise in einem fertigen Programm nicht stehen, es dient nämlich eher dazu, so einen Fehler abzufangen und dem Programmierer zu berichten, welches "assert" in seinem Code das ausgelöst hat, damit der herausfinden kann, warum diese "Schutzbedingung" (id <= 20) nicht erfüllt war. Dazu wird Zeilennummer und Dateipfad in die EXE reingeschrieben.
Da da aber eben der Fall 0 zugelassen wird (0 ist ja <= 20), kommt, wenn man per PicPointerPatch und eine Variable mit Wert 0 versucht, ein Picture #0 anzuzeigen, eine hässliche Access Violation (bzw. ???????????????, bei japanischen Fehlermeldungen).
Naja, es sind mehrere Bytes, nämlich lauter Stopbedingungen in Schleifen (und eben dieses assert), und dass es bis 126 geht, liegt daran, dass der Indexwert ZUERST um 1 erhöht wird und DANN verglichen. Wenn du also 20 Pictures hast, wird da mit 21 verglichen und im false-Fall die Schleife verlassen*. Da der Vergleich aber vorzeichenbehaftet stattfindet und nur ein Byte verglichen wird (kein DWord), kann ich als höchsten Wert nur 127 (also 126 Pictures) einstellen, weil der Bereich eines vorzeichenbehafteten Bytes von -128 bis +127 reicht. Für höhere Zahlen braucht man dann mehr als ein Byte, dazu muss aber auch der Befehl, der für den Vergleich zuständig ist, umgeschrieben werden, sodass er ein DWord (32 Bit) abfragt, und nicht ein Byte (8 Bit). Da ein DWord aber 4 Bytes Platz braucht, und natürlich nur 1 Byte Platz ist, muss ich dafür eigenen Code schreiben und in einen unbenutzten Platz in der EXE auslagern, und dann bei den Vergleichen jeweils dorthin springen. Das kann - im Gegensatz zum Suchen und Ändern dieser einzelnen Bytes vorhin - nicht automatisch vom Programm erledigt werden, weil das nicht so intelligent ist wie ich^^ Also muss ich das für jede Version extra machen, und das hab ich nur für RM2k v1.07. Das ist der Grund, wieso man im Hyper Patcher 2 nur für diese Version 9999 Pics einstellen kann und für die anderen nur 126. Und warum 9999? Wegen des PicPointerPatches, der ja ab 10000 in Aktion tritt, und ich nicht Verwirrung stiften wollte. Theoretisch könnte man 2 Milliarden Pictures einstellen, was aber dann nie in den Arbeitsspeicher passen würde.
*: Die Schleifen kann man sich ungefähr so vorstellen: Im Quellcode steht wahrscheinlich etwa dies:
Das ist in Assembler im Endeffekt äquivalent zu:
Ja, ich weiß, dass der Maker in Delphi geschrieben ist, aber C verstehen wahrscheinlich mehr Leute.
mfG Cherry