C++ ... was zum Geier passiert hier?

[Kyuu]

Gelöst: Kein open() gemacht, aber trotzdem ein close() notwendig, Thema bitte schliessen/löschen/whatever

...

Wenn du einen Dateinamen an den Konstruktor übergibst, wird die Datei im Konstruktor automatisch geöffnet, wenn möglich. Genaueres: http://www.cplusplus.com/reference/i...ream/ifstream/

Aber ich verstehe auch nicht, wieso du die Datei erst schließen musst, damit loadFromFile() die Datei erfolgreich laden kann, da man Dateien gleichzeitig mehrmals geöffnet haben kann. Um das nachzuvollziehen, müsste man wohl wissen was genau loadFromFile() macht.

[Corti]

It's magic because cherry is a wizard!

[Cherry]

Nicht ganz:

Code:

void Image::loadFromFile(std::string filename, bool throwErrors, bool autoResize) {
	this->autoResize = autoResize;
	DStringPtr s(filename);
	asm volatile("call *%%esi" : "=a" (_eax), "=d" (_edx), "=c" (_ecx) : "S" (0x467ABC), "a" (this), "d" (s.str), "c" (throwErrors) : "cc", "memory");
}

Das ist der Source Code von RPG::Image::loadFromFile. Warum das geöffnete Dateien nicht mag, müssen dann wohl eher die Enterbrainer wissen!
(Wie man sieht, callt das, wie die meisten DynRPG-Funktionen, nur eine RPG-Maker-interne Funktion, in diesem Fall 0x467ABC)

Btw: Ich finde die GCC-Asm-Syntax einfach nur extrem strange.

[Corti]

You no ...wizard?

[Cherry]

Genaugenommen ist DynRPG relativ unspektakulär.

Ich hab jetzt keine Zeit, einen Artikel zu schreiben drüber, aber im Prinzip besteht die Magie im Wesentlichen aus zwei Dingen:
1) Den Callbacks - An den entsprechenden Stellen in der RPG_RT.exe hab ich Code reingepatcht, der eine entsprechende Funktion in dynloader.dll callt, die dann alle Plugins callt usw.
2) Den RPG-Klassen - Im Prinzip einfach "nachgebaute" RPG-Maker-Klassen (die also dasselbe Memory Layout haben wie die originalen Delphi-Klassen des RPG-Makers) mit ein paar Methoden, die Hauptsächlich Wrapper für Methoden originalen Klassen sind (wie hier eben RPG::Image::loadFromFile)