Druckbare Version
Äh, was genau hast du da gemacht? Banenen-Joe hat extrem viel umändern müssen weil ja überall die Palettengröße auf 16 Bit zugeschnitten ist, die Logik die Paletten anpasst, etc... also inwiefern kann das jetzt mit DynRPG gehen? Besonders weil ja die Headerfiles und die Library auch von 16 Bit ausgehen.Zitat:
Zitat von bugmenot
Bitte erklär mal... Danke
@goldenroy
Ähh, warum das lange Gesicht? Obwohl, ich kann es mir schon vorstellen...
Da ich nichts von Framebuffern verstehe, kann ich darauf nicht wirklich - im Sinne des Fragenden - antworten.Zitat:
Zitat von Cherry
Nur ca. 400 Adressen. Ich dachte mir da:Zitat:
Zitat von Cherry
1) die RPG_RTs von 2k und 2k3 zum größten Teil auf der selben Software beruhen
2) die 32bit-Einstellung von Destiny auch unabhängig vom restlichen Destiny Patch auf dem 2k laufen kann
3) die Auflösung des Framebuffers auch verändert werden kann, ohne extern was machen zu müssen
...könnte man das, was Bananen-Joe für den 2k gemacht hat, auch für den 2k3 nachbauen, die restlichen Zugriffe auf Bildeigenschaften anpassen und zumindest mal durchtesten.
Verdammt... Plugins, die irgendwelche Grafiken laden führen zu Crashes.Zitat:
Zitat von Cherry
Soviel zum Thema null Ahnung haben und einen ganzen Abend mit dem Kram verschwenden.
Oh, du hast das nur geportet, verstehe.
Naja, verschwendet ist nix, es ist sicher hilfreich für Leute die keine Plugins verwenden. Erzeugt halt leider eine "entweder-oder"-Situation, und es ist nicht leicht oder fast nicht möglich, das vernünftig zu beheben.
(Und ich muss jetzt wohl doch Support für diese "komischen" Framebuffer in UniDebug einbauen. Pöh. ;) )
Läuft die Anzeige von Bildern über Plugins etwa über diese beiden dll files die... irgendwo sind? Oder über die kompilierten Plugins, welche die Bilder einfach nur in den Framebuffer injizieren?
Kann man wirklich nirgendwo umschreiben, dass bei Fund von 8B 92 08 06 00 00 an offset 45D02D header und lybrary nicht von 16bit ausgehen?
Die kompilierten Plugins.
Nein, 1. weil Header die Datenstrukturen definieren und die müssen zur Compile-Time bekannt sein. Man müsste sonst 2 Strukturen definieren und jeder Pluginentwickler müsste überall Abfragen einbauen, welche verwendet wird. Und die Library ist ja auch statisch gelinkt und daher kann man das nicht vernünftig ändern, besonders nicht die existierenden Plugins. Außerdem können Plugins direkt mit dem 16-Bit-Bildpuffer arbeiten, das ist auch so vorgesehen, was natürlich nicht funktioniert wenn der nicht 16 Bit hat.
@bugmenot:
http://i.imgur.com/kP9EFCx.png
Zumindest damit ist es jetzt kompatibel ;) (kommt in nächster Version)
EDIT: Ja, es sollte "bits" heißen. Ich ändere den Screen jetzt aber nicht mehr.
Hey Cherry,
wollte mich mal hier im Thread erkundigen, ob es möglich wäre, mit einem Plugin eine Art "Filter" über den Maker zu werfen (oder wie man das nennen kann),
mit dem man zumindest ähnliche Effekte erzielen kann wie bspw. in Max Payne 3 (bei Einnahme von Painkillern etc.)?
In diesem Video sieht man diese "Bildverzerrungs- und verfärbungseffekte" öfters mal: https://www.youtube.com/watch?v=SlP7hKLhsaE
Ich bräuchte solche Effekte (wenn auch in niedrigerer Anzahl und Intensität) für mein Spiel, aber wie ich es mir hätte denken können ist das mit dem "Vanilla-Maker" ohne halbwegs ordentliche Filter kaum bis gar nicht möglich.
Ob es mit einem zusätzlichen Plugin (auch DynRPG Plugin) geht, weiß ich selber leider auch nicht so genau, aber deshalb frage ich ja.
Wenn es bereits ähnliche Anfragen gab, entschuldige ich mich, aber ich habe keine Lust mich um diese Uhrzeit noch durch 106 Threadseiten zu buddeln..
Ich hoffe du kannst mir helfen :)
lg/ aleksy
Ich hab dazu jetzt keine Zeit, aber man (= jemand anderer) kann dafür sicher ein DynRPG Plugin schreiben. Mit DynRPG kann man nämlich auf den Bildschirminhalt zugreifen.
Das hört sich ja gut an :) Dann müsste ich ja jetzt nur jemanden finden der sowas kann.. Oder ich lerne, selber DynRPG Plugin zu schreiben ^_^
Kazesui hat ein Plugin für Blendmodes gemacht. Damit kannst du Verfärbungen umsetzen. Wie du aus den Blendmodes aber etwas künstlerisch Wertvolles machst, musst du selbst rausfinden.
Kurioserweise bringen .lua Skripte das Spiel nicht zum Abstürzen. Das Bild ist zumindest schonmal verzerrt und verfärbt, so we got that.Zitat:
Zitat von BDraw
Also könnte DynRPGSS da potentiell noch was aus Bananen-Joe's umgeschriebenem Framebuffer rausholen, falls der Zugriff auf den Framebuffer seitens DynRPG auf einen 32bit-Mode umgestellt werden könnte - hat doch auch mit unidebug funktioniert? (weil keine inflexiblen header und so)
Ich vermute, dass DynRPGSS "funktioniert", liegt daran, dass es nicht Bildpuffer für einzelne "Bildobjekte" verwendet (wie es der Maker und andere Plugins normal tun), sondern direkt auf den Framebufer zugreift. Das hat zur Folge dass es nur dasselbe Problem hat wie UniDebug es hatte. Bei UniDebug war es deshalb leicht lösbar, weil meine Grafikbibliothek bei nicht-indizierten Bildmodi (also 16-Bit und 24-/32-Bit) sowieso immer RGB mit 8 Bit pro Farbe verwendet hat im seinem Interface (die intern halt auf 16-Bit-Farben reduziert wurden). Ich musste also nur der Grafikbibliothek die andere Farbtiefe mitteilen (und meiner Methode, die Zeugs auf dem Puffer der Grafikbibliothek in den Framebuffer vom Maker kopiert oder andersrum, und es lief.
Es wäre also tatsächlich für DynRPGSS möglich, sich da anzupassen, ich aber nicht was Kyuu dafür intern alles tun müsste. (Und es ist natürlich immer noch blöd dass nix anderes damit funktioniert.)
GuardRevamp
download GuardRevamp
Gleich mal alles in den DynPatch-Ordner geschmissen =)
Nur der 32-Bit-Patch ist mir schleierhaft. Hab die DynRPG-Variante im Ordner und wollt gleich mal ein beliebiges PNG-Bild als Panorama benutzen. Unsupported PNG Image sagt er mir dann.
Den kann man wohl nur für ganz spezielle Sachen benutzen, oder?
Alle Plugins, die irgendetwas auf den Bildschirm zeichnen führen zu einem Absturz. Mal so... nebenbei.
Soll ja auch Farbschleier und Ähnliches verhindern. Der Image Loader (oder wie auch immer das Ding heißt) vom 2k(3) ist bisher immernoch nur in 8bit.Zitat:
Zitat von Davy Jones
Der 32bit Patch erhöt die Anzahl der Farben in der Farbpalette des 2k(3), das heißt es gibt:
A) bei irgendwelchen Farbverläufen (zB. default Menühintergrund oder 8bit Bilder mit Farbverläufen) keine auffallenden, abweichenden Verfärbungen.
B) bei Transparenzen oder Änderung der Farbe/Tint weniger milchige Schlieren oder diese sich bildenden Farbbereiche, welche sich scheinbar hin- und herbewegen (probier einfach mal ein <TintScreen> mit irgendeinem detaillierteren Panorama aus. Bevorzugt eines, welches einen Farbverlauf drin hat).
@Davy: Da kommen einige Sachen zusammen.
Die Grafiken die wir im Maker benutzen haben nicht 8 Bit Farbtiefe, sondern eine 8Bit Palette mit 24Bit Farbtiefe. Jeder Pixel enthält einen Wert zwischen 0 und 255 ( 8 Bit ) , dieser entspricht dem Index der Farbe in der Palette. Die Farben in der Palette haben für Rot,Grün, Blau jeweils einen Wert von 0 bis 255, wieder 8 Bit, also in Summe 24 Bit.
Wenn der RPG Maker diese Grafiken lädt, dann erstellt er intern eine weitere Palette mit einer Farbtiefe von 16 Bit, damit diese in den 16Bit Bildbuffer geschrieben werden können. In 16 Bits bleiben nur 5/5/6 Bit für die einzelnen Farbkanäle. Der z.B. Rot-Wert von 0 bis 255 wird in einen Wert zwischen 0 und 31 konvertiert. Dadurch werden Farbwerte, die vorher nur gering unterschiedlich waren, z.B. 254 und 250 zu dem selben Farbwert, und Farbverläufe werden dadurch unsauberer.
Dieses Verkrüppeln der Farben ist es, was der Patch angeht.
Hey!
ich habe folgende Fixes rumliegen, alle mit dem Zweck das Standardmenü zu beenden und irgendwas zu setzen.
- SA Switch -> Beendet bei Status und Atb
- SOA Switch -> Beendet bei Status, Order und Atb
- SROA Switch -> Beendet bei Status, Order, Row und Atb
- RowVar[2+] -> Beendet bei Row mit Variable des gewählten Helden
Gibts auch einen Fix, der nur Atb zum Switchbefehl macht, falls ich Status wie gewohnt benutzen möchte?
Deaktiviert sich die Funktion der Hacks, wenn man die SwitchID mit 0 parametriert? Die Readme sagt dazu nichts und ich möchte ungern Bomben ins Projekt anderer Leute einbauen.
download A SwitchZitat:
Zitat von Corti
Zitat:
Zitat von DynRPG.ini
und Order und Switches werden gesetzt.Zitat:
Zitat von Corti
Bei ID = 0 werden zwar keine Switches oder Variablen verändert, aber die ursprünglichen Funktionen werden auch nicht wieder hergestellt.Zitat:
Zitat von Corti
Ich könnte da eine Abfrage reinpacken, sodass bei ID = 0 der ursprüngliche Code ausgeführt wird, aber das ist irgendwo kontraproduktiv auf zwei oder mehr Ebenen.
Gibt es da nicht bereits seitens DynRPG die Möglichkeit, dies über Plugins zu regeln? Z.B. Quit Switch Plugin (da ist eine dokumentierte(?) source Datei mit bei) oder du fragst PepsiOtaku selbst.Zitat:
Zitat von Corti
Edit:
Ich sehe gerade, dass das einfach nur ein Patch ist.
Da hätte ein callback an loc_4A24EE (bool onMenuOption (int OptionID)) und ein "jl short loc_4A2545" dahinter irgendwie mehr gebracht. Bei positiver Pluginaktivität ein call sub_4A1054 sowie [[4CDC1C]+0C] = 1) und ein return -1
Planst du zufällig Plugins an Patches zu binden?
Ich habe ein paar Sachen auf Eis gelegt (Zugriff auf die Condition- und Attribute-Arrays; Zugriff auf das Setzen und Ausführen von BattleCommands; etc.), weil die Initialisierung irgendwann nicht mehr funktionieren würde (zB. durch das Ändern von Variablen) oder es sich auf 1 mal je Frame eingrenzen würde.
Und weil es für den Endnutzer mehr Sachen gibt, auf die er/sie achten muss = höhere Wahrscheinlichkeit Mist zu bauen.
Und es würde eine Eingrenzung von Plugins auf nur ein paar bestimmte zusätzliche Funktionen bedeuten.
Und am Ende würde niemand mehr damit hinterherkommen, wer was wo benutzt und wo Bomben oder Eier eingebaut wurden... ugh, Entschuldigung.
Kann man per C++ einen Pointer auf den Ort im RAM der laufenden RPG_RT Applikation erhalten und zur Laufzeit damit interagieren? Es fehlen bisher noch zu viele Zugriffe auf Objekte, Klassen und interne Funktionen.
Noch 'ne Anfrage: elvissteinjr hat hier für den 2k3 einen patch gemacht, mit dem man Item- und Ausrüstungs/Skill-Menüs direkt aufrufen kann. Funzt das auch für den 2k, bzw. kanns jemand darauf umbiegen?
Originalpost & Patch - Item & Equip
Originalpost & Patch - Items, Skill & Equip
__________________________________________________________________
@bugmenot: Die Dark Sword Crew dankt für den Patch! :)
Sowas gehört mit zu meinen Traumwünschen bisher *gZitat:
Ich habe ein paar Sachen auf Eis gelegt (Zugriff auf die Condition- und Attribute-Arrays;
Man kann in DynRPG Adressen beschreibenZitat:
Kann man per C++ einen Pointer auf den Ort im RAM der laufenden RPG_RT Applikation erhalten und zur Laufzeit damit interagieren? Es fehlen bisher noch zu viele Zugriffe auf Objekte, Klassen und interne Funktionen.
Oder auslesen:Code:// im NormalPlay eine Zeile sofort anzeigen
*reinterpret_cast<unsigned short *>(0x4C7C42) = 0x9090; // Default: 0x1074
// im NormalPlay alle Zeilen sofort anzeigen
*reinterpret_cast<unsigned short *>(0x4C7C88) = 0x9090; // Default: 0x1074
Wenn du also sagen kannst, wo die Conditions und Attribute rumliegen, könnte man Funktionen basteln, die das komfortabel handlen.Code:int getMenuScreen()
{
return ( **reinterpret_cast<char ***> ( 0x4CDC60 ) ) [12];
}
Mal schauen, was sich zusammenpuzzeln lässt...
Ein Problem vorweg: ich bin mir nicht sicher, wann die Arrays für Attribute bereits vorliegen, weswegen man unter Umständen das Zeug manuell initialisieren muss:
Code:int getAttributeAmount () //gibt Anzahl der Einträge in der Database aus
{ return ( **reinterpret_cast<char32_t ***> ( 0x4CDE44 ) ) [8] [8]; //Kann man eigentlich mehrmals hintereinander dereferenzieren? }
int getConditionAmount ()
{ return ( **reinterpret_cast<char32_t ***> ( 0x4CDE84 ) ) [8] [8]; }
void initACArrays (int BattlerID)
{
int A = getAttributeAmount ();
int C = getConditionAmount ();
int BattlerPtr;
//RPG:: Battler gibt doch einen Pointer auf ein Array aus? Dieser wird als Parameter für eine interne Funktion der RPG_RT benötigt.
//über " RPG:: Battler (BattlerID); " an den BattlerPtr herankommen[...]
call RPG_RT.004BFE1C (BattlerPtr, A); //mal angenommen die calling convention ist: Param1 = %EAX, Param2 = %EDX
call RPG_RT.004BFF5C (BattlerPtr, C);
//deswegen (unter Anderem) wird der Zugriff auf die laufende RPG_RT-Instanz benötigt
}
int main ()
{
initACArrays (BattlerID);
}
Die Pointer für die Arrays von Attributen und Conditions sollte man eigentlich über RPG:: Battler ansteuern können (die selben Ptr gelten für Actor und Monster).
Ehrlich gesagt steige ich noch nicht ganz durch bei der ganzen Re- und Dereferenzierung von C++. Kann also sein, dass da ein paar & oder * fehlen.Code://Attribute_ID als Parameter ID angeben
int getAttribute (int BattlerPtr, int ID)
{
int ArrayPtr = BattlerPtr [48]; //Ptr auf das AttributeArray
return ArrayPtr [ID*2-1];
}
//Condition_ID als Parameter ID angeben
int getCondition (int BattlerPtr, int ID)
{
int ArrayPtr = BattlerPtr [56]; //Ptr auf das ConditionArray
return ArrayPtr [ID*2-1];
}
Schreibzugriff sollte eigentlich auch möglich sein(?).
Die ArrayStruktur sieht wie folgt aus (IDs starten nicht bei 0):
[ID*2-1] die zweiten 8bit für die Resistenzangabe (0=A, 1=B, ...) und
[ID*2-2] die ersten 8bit für zusätzliche Information (-1|+0|+1 Modifier für Attribute oder die Uptime von Conditions)
Arraygröße ist 2 x 8-bit x get[xyz]Amount