Posts for Hâthor


Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Samsara wrote:
TAG wrote:
why is lullaby skip only on JP?
Slowking, literally in the post directly above yours, wrote:
Lullaby Skip is not J-only. Grunz did it in his TAS, which was done on U.
So we can say: Lullaby skip in "human" only (J) :p. It confirms what I though, it can be done on (U) but it's really harder (from human point of view). To answer you TAG: As you an see here, the player mash the sword to avoid blowing. If you try it on (U) version, it won't work. So the only way to avoid blowing is to perfom an ISG just after you exit from fairy fountain (like Slowing mentionned). @arandomgameTASer: So many glitches... I'll ever be impressed to see what players find :). PS: RTA runners sounds for "non-TAS"; the ones who play on a console, is that it? I've never heard it but it's a cool turn of phrase :D PS2: Really sorry if my english is bad, I do my best... :/
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Woups, I notice this only now :/ Sorry.. I remeber another point about difference between (J) and (U). Power Crouch Stab is fixed on (U) version. It can make a big difference on some fights (I think about Odolwa and Majora).
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Route seems to be cool :) But I've a question for you: Why do you clip after getting the last egg on pinnacle rock? I think using the Ocarina Items trick should be faster; you don't even need to set the cursor as Great Bay Coast is the default location. (You can also use it for the last egg in PF; it allows you to not equip the Ocarina). There are actually (J) only tricks. For example, Lullaby skip. On the (J) you just have to mash the sword and you won't be blown but it doesn't work on (U)... (But... I've heard that it could be possible if we can perform an ISG before the first blow... I've never seen it)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
A bit too late but... I'm really happy to see the Japanese version. Dude, what you've done is very cool! I loved it :) Nice work!
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
TASvideo wrote:
When human skills jokes are just not enough
Everything is said :p I just loved it!
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
C'est tout à fait ça. Le principe de rerecord, c'est de recommencer un morceau du jeu (un saut par exemple). Mais au final, le fichier qui contient la séquence de touches (.pjm pour psxjin par exemple) lui est "parfait". Exemple, tu essaies de sauter à la frame 225; ça passe pas. Tu load un state et tu essaies à la 226, ça passe. Et ainsi de suite. Le fichier final ne gardera que le saut à la frame 226. Ensuite, tu "joues" le fichier et tout se passera d'une seule traite; c'est à ce moment là que tu capture une vidéo. Ce que tu dois garder en tête, c'est qu'un jeu vidéo est déterministe à l’extrême.; les mêmes inputs aux mêmes frames donneront TOUJOURS le même résultat (même pour ce qui semble aléatoire).
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Et bien tu fais le niveau 2, 3 etc... Si éventuellement tu "découpes" ta run en plusieurs partie. Il te faudra hexedit pour qu'au final tu n'aies qu'un seul fichier. Quand à la vidéo, il y a normalement une option de l'ému qui te permet de capturer (généralement File -> record avi/wav)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Très franchement, je n'ai pas cherché :D. J'ai juste lu cette page. Et le script :
Language: lua

local CharacterPointer = 0x02097490 local pointer local Vars = {} Vars["Character"] = 0 --byte Vars["X"] = 0 --DWord Vars["Y"] = 0 --Dword Vars["Z"] = 0 --Dword Vars["modelAngle"] = 0 --Word Vars["motionAngle"] = 0 --Word Vars["speed"] = 0 --DWord Vars["xVelocity"] = 0 --DWord // x and z derived from speed + direction Vars["yVelocity"] = 0 --DWord // Always -32k on the ground Vars["zVelocity"] = 0 --DWord Vars["status"] = 0 --12Byte // Swimming, walking,.... Vars["BowserRevolutionSpeed"] = 0 --Word Vars["BasementWaterLevel"] = 0 --DWord Vars["RNG"] = 0 --DWord Vars["cameraX"] = 0 --DWord Vars["cameraX"] = 0 --DWord Vars["cameraX"] = 0 --DWord Vars["upDownAngle"] = 0 --Word local VarsAddr = {} VarsAddr["Character"] = 0x8 VarsAddr["X"] = 0x5C VarsAddr["Y"] = 0x60 VarsAddr["Z"] = 0x64 VarsAddr["modelAngle"] = 0x8E VarsAddr["motionAngle"] = 0x94 VarsAddr["speed"] = 0x98 VarsAddr["xVelocity"] = 0xA4 VarsAddr["yVelocity"] = 0xA8 VarsAddr["zVelocity"] = 0xAC VarsAddr["status"] = 0x370 VarsAddr["BowserRevolutionSpeed"] = 0x0217B1D4 VarsAddr["BasementWaterLevel"] = 0x02176464 VarsAddr["RNG"] = 0x0209CDF0 VarsAddr["cameraX"] = 0x12C VarsAddr["cameraX"] = 0x128 VarsAddr["cameraX"] = 0x124 VarsAddr["upDownAngle"] = 0x3A dofile "../../../_Tools/Lua Libs/HexConversion.lua" --[[ UI ]] function Coord() Vars["X"] = LibHex.ToFixedPoint(string.format("%X", memory.readdwordsigned(pointer + VarsAddr["X"])), 20) Vars["Y"] = LibHex.ToFixedPoint(string.format("%X", memory.readdwordsigned(pointer + VarsAddr["Y"])), 20) Vars["Z"] = LibHex.ToFixedPoint(string.format("%X", memory.readdwordsigned(pointer + VarsAddr["Z"])), 20) Vars["modelAngle"] = memory.readword(pointer + VarsAddr["modelAngle"]) Vars["modelAngle"] = (Vars["modelAngle"] / 65535) * 360 Vars["motionAngle"] = memory.readword(pointer + VarsAddr["motionAngle"]) Vars["motionAngle"] = (Vars["motionAngle"] / 65535) * 360 Vars["speed"] = LibHex.ToFixedPoint(string.format("%X", memory.readdwordsigned(pointer + VarsAddr["speed"])), 20) Vars["xVelocity"] = LibHex.ToFixedPoint(string.format("%X", memory.readdwordsigned(pointer + VarsAddr["xVelocity"])), 20) Vars["yVelocity"] = LibHex.ToFixedPoint(string.format("%X", memory.readdwordsigned(pointer + VarsAddr["yVelocity"])), 20) Vars["zVelocity"] = LibHex.ToFixedPoint(string.format("%X", memory.readdwordsigned(pointer + VarsAddr["zVelocity"])), 20) gui.text(5, 25, string.format("X: %.2f Y: %.2f Z: %.2f", Vars["X"], Vars["Y"], Vars["Z"])) gui.text(5, 35, string.format("Xv: %.2f Yv: %.2f Zv: %.2f", Vars["xVelocity"], Vars["yVelocity"], Vars["zVelocity"])) gui.text(5, 55, string.format("Angle: %.2f mdlAngle: %.2f", Vars["motionAngle"], Vars["modelAngle"])) gui.text(5, 75, string.format("Speed: %.2f", Vars["speed"])) end function RNG() Vars["RNG"] = memory.readdword(VarsAddr["RNG"]) gui.text(100, 5, string.format("RNG: %d", Vars["RNG"])) end function UI() pointer = memory.readdword(CharacterPointer) Coord() RNG() end gui.register(UI)
Donc en gros, tout ce qui est LibHex.untruc c'est dans un fichier que je lis grâce à la fonction dofile. Ce sont des fonctions de conversions. Dans la fonction UI, j'affecte la variable pointeur (stockée dans une adresse connue); ensuite dans Coord() je vais lire la valeur "speed" -par exemple- qui est toujours à pointeur + une valeur (dans point de vue programmation, j'ai envie de dire que le pointeur contient l'adresse de l'objet perso et que donc, il est logique toute les infos nécessaires soient côte à côte dans la mémoire). Comment trouver ce pointeur? Hummm... Si je reprends cet exemple: On est dans une zone X où on a notre vitesse. On change de zone et tout a changé en RAM mais... On sait que si on appuie sur avant pendant 5 frames, notre vitesse sera de 8 (par exemple) il suffira de chercher cette valeur précise pour trouver la nouvelle adresse de la vitesse. On va dire que pour la zone X, l'adresse de la vitesse est 0x100 et pour la zone Y 0x150. Si il y a pointeur, il existe en RAM une adresse qui contient la valeur 0x100 (256 en décimal) quand on est dans la zone X et 0x150 (336 en décimal) quand on est dans la zone Y. MAIS La valeur speed n'est qu'une valeur; pas un objet. L'objet (parfois nommé head ou header) avoisine ces valeur (vers le bas) c'est peut-être 0x99 (dans la zone X) et donc il faudra chercher une adresse qui contient 0x99. Etc... C'est comme ça que j'approcherais le problème pour ma part (en espérant que le jeu fonctionne ainsi). PS: Pour ceux qui se demande pourquoi j'ai passé mon temps à créer un tableau avec mes variables, c'est parce que si je crée mes variables dans la fonction, mon PC pédale à mort dans la choucroute à cause des milliers de créations à la seconde (et bonjour le memory leak) je limite la casse en faisant comme ça. C'est beaucoup moins problématique quand on utilise:
Language: lua

while true do UI() emu.frameadvance() end
car la fonction n'est appelée QUE si on avance d'une frame.
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Y'a rien de ridicule :) (Pour ma part, j'arrive pas à reproduire l'Inverse Camera Angle de Majora's Mask)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Comme quoi, les apparences sont trompeuses :D
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
C'est un bon début :) Très bon choix pour comprendre comment ça fonctionne tout ça! Tu as créé une bonne base, je t'encourage à la travailler d'avantage. Il existe un "warpless" fait par HappyLee en 18:48 (bon lui, il prend les champis / fleurs). Donc il y a moyen de s'approcher de ce temps. Par exemple, tu pourrais te baser sur ses routes (au premier niveau, il prend le tuyau pour arriver plus vite à la fin). Ensuite, tu pourrais essayer de démarrer comme lui le fait (de mémoire, il appuie sur gauche + droite simultanément et le saut est dosé pour une accélération maximale). Ce sont des petites choses "simples" qui te feront gagner pas mal de temps. Je pense que sub 19 est faisable "aisément". Enfin, si tu te sens d'attaque, tu peux essayer de reprodruire le glitch du drapeau à la fin des niveaux qui fait gagner quelques frames. Bon courage !
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
^^ Ca fonctionne comme ça pour Mario 64DS -j'y ai jeté un oeil par curiosité-, du coup j'avais un script qui lisait le pointeur et de là, j'allais lire les adresses (en convertissait les nombres en un truc lisible au passage).
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Si le jeu réutilise les adresses, il doit y avoir un pointeur quelque part qui indique où elles se trouvent. Ensuite, un peu de lua et hop, on a ce qu'il nous faut en permanence. Bon après, c'est qu'une théorie... Un jour si j'ai le temps, je testerai :p (même si je suis pas un grand fan des RPG)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
1,189033832614855848623324980224e+63
Ici on dit 0x4D071F8025073543 (64 bit floating point norme ieee 754; c'est trop gros pour du 32 bit) :p
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
L'idée du zipping: Placer ton personnage de façon à ce que le décor le pousse littéralement. C'est une question de hitbox, ainsi le décor va pousser ton personnage mais sa hitbox sera toujours a un endroit "anormal" d'où l'éjection. Ce qu'il se passe dans sonic: C'est bien un zipping mais le jeu éjecte sonic à des coordonnées improbables, elles deviennent négatives. MAIS En programmation, tu peux décider de faire un sorte qu'un nombre soit signé ou non (c'est à dire utiliser le négatif ou non). Ca change beaucoup! Un byte non signé a une valeur comprise entre 0 et 255; un byte signé aura une valeur comprise entre -128 et 127. La représentation en hexa est identique! 0xFF vaudra 255 non signé et -128 signé. Je reviens à sonic, si l'éjection t'emmène vers des coordonnées négatives mais que celles-ci sont codées sur un nombre non signé; tu "fais le tour" au lieu de passer de 0 à -1, tu passera de 0 à 255, la fin du stage. En gros, ça fonctionne ainsi, naturellement tout les zippings ne provoquent pas ce résultat et souvent, ça demande un angle précis. J'ai vu un speedrunner faire du zipping sur sonic 1, mal exécuté il tombait dans la lave au lieu d'arriver à la fin du niveau. J'espère t'avoir un peu éclairé :)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Did you try to disable rewind feature? It can really help to run a game normally
Post subject: Re: Kingdom Hearts: Chain of Memories (GBA)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Tounet01 wrote:
Et suis-je le seul Belge sur le site ? :p
Nop :) Sinon j'ai regardé la run, c'est assez chouette :). Ceci dit, je ne connais absolument pas le jeu donc j'ai du mal à percevoir les subtilités. Donc moi je dis: Continue sur ta lancée :D
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
I tried to import MrGrunz's The Legend of Zelda: Majora's Mask but I failed :( It desync for about 9frames at the beginning and it increase to about 25 frames while the first cutscene; like it was slower... I didn't try to sync first input yet. Anyway, the game seems to be well emulated (better than with the old mupen ? that's THE question)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Tu prends le fichier movie (le .bkm pour Bizhawk, .fm2 pour fceux, .pjm pour psxjin etc....) et tu le zip. C'est tout. A part les très très gros fichiers (genre 1h30 de run) ça passe.
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Ce qui ne veut pas dire qu'il faut en faire pour le plaisir :p Mais c'est en effet un synonyme de travail acharné^^ Après ça dépend du jeu aussi. Je n'ai pas encore regardé tes runs, je tacherai de le faire :)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Je confirme, je me le suis fait dire par feos :p Selon ses conseils à lui, il est préférable de stopper au dernier input non nul. Celui qui encode comprendra assez vite qu'il doit laisser tourner :p. Un example de cas spécial? Pour le seul que j'ai fais jusqu'à présent, il faut aller dans les options pour voir les temps IG, j'ai choisi de le faire en TAS afin de justifier le temps IG annoncé; ça rajoute facile 5 minutes au temps réel. (Bon en même temps, c'est pas un jeu ultra célèbre non plus donc j'ai pas eu trop de débat)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Language: lua

while true do gui.drawstring(0, 5, string.format:("Rerecord: %s", emu.rerecordcount())) emu.frameadvance() end
Y'a cette solution là aussi si tu les veux en permanence :) (A tester, je ne connais pas l'API de fceux)
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
RingRush wrote:
The reason I care so much about the intro synching is that is the best way to tell if the game is emulating the lag and climbing physics properly, something previous versions of mupen did not. There is a hacked version of mupen specifically for DK64 that fixes these issues, so maybe the fix is simply applying those patches? Edit: Tree glitch still happens, where when you are climbing the game either freezes or warps you out of bounds. So physics are definitely busted.
I also reproduced the tree bug (this is the first thing I test :p) and the desync while DK rap; I think it can be fixed "easly" fixed but I don't have enough programmation skills to do that :(
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Just amazing :D. Very nice work! It's so sad that it cannot be submitted. Damn you random loading frame :(
Experienced Forum User, Published Author, Player (104)
Joined: 1/4/2013
Posts: 117
Location: Belgium
Ca à l'air fun en effet. Le btest me plait déjà :p. Maintenant, comme dis grincevent, y'a plus qu'a.... faire le plus dur :p. Mais l'idée y est, bonne continuation ! PS: Si tu ne t'en sors pas avec l'encodage, tu peux me faire signe (et au pire, je te le ferai avec grand plaisir).