Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Atma wrote:
A side note is that this run syncs on Tenchi Souzou (J), which isn't a bad dump, compared to the Tenchi Souzou (J) [h1C] that it was recorded on, so I don't know what the underlying differences are.
If I remember correctly h1C means the header was hacked. Probably to make the game run with crappy emulators.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
RachelB wrote:
Warepire wrote:
RachelB wrote:
I cannot say I am too keen on accepting altering the memory card's state through the movie. As others have said it will become a very big hassle to verify the validity of the run, also in my opinion it is making things really fuzzy regarding what should be considered input to the game. When input is starting to depend on hypothetical secondary consoles it doesn't really feel like valid input anymore to me.
Why?
It's not input to the game, but neither is swapping discs, or inserting/removing memory cards, or hard resets.
Ok, I probably expressed myself a bit fuzzy and I am sorry for that, but my main point is in my last sentence, when "input" (as in commands / actions the console will accept) becomes dependent on theoretical secondary hardware like a second GameCube used to copy the data around on the memory cards as the first one is playing a game, this is where I think it goes a little too far in the lengths of how input shall be produced.
What exactly is the destinction between this, and say, using a GBA to connect to a gamecube (for tingle tuner in zelda ww, etc)? Surely we would allow that?
I will try again to make it clearer.
Do note that I am distinguishing between hypothetical consoles and actual ones, I am not against connecting a GBA to the GameCube/Wii to use the tingle tuner in Wind Waker, or linking two GBCs to have a joint Oracle of Ages/Seasons TAS. Because here the GBA is another controller, and the linked up GBCs communicate between each other like 2 computers on a LAN.
But we're discussing, as far as I understand it, that the movie will contain commands that behind the scenes will move around save data between memory cards. This is not a legal GameCube operation since it cannot be booted into it's memory card manager, and run the game at the same time. So we are left with a hypothetical second GameCube that exists only within the movie file. And that is what I think is a problem with the legitimacy of the movie.
If I am understanding your idea entirely wrong, please make it clearer for me.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
RachelB wrote:
I cannot say I am too keen on accepting altering the memory card's state through the movie. As others have said it will become a very big hassle to verify the validity of the run, also in my opinion it is making things really fuzzy regarding what should be considered input to the game. When input is starting to depend on hypothetical secondary consoles it doesn't really feel like valid input anymore to me.
Why?
It's not input to the game, but neither is swapping discs, or inserting/removing memory cards, or hard resets.
Ok, I probably expressed myself a bit fuzzy and I am sorry for that, but my main point is in my last sentence, when "input" (as in commands / actions the console will accept) becomes dependent on theoretical secondary hardware like a second GameCube used to copy the data around on the memory cards as the first one is playing a game, this is where I think it goes a little too far in the lengths of how input shall be produced.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Regarding reason number 1: Let the ignorant people live in their little ignorant bubbles. The ones who are aware of what things really are, are all laughing at them silently inside. It isn't really your fault if they are too lazy or stupid to read the title or description of your video. Nothing great was ever achieved by listening to the negativity crowd.
I cannot offer any input on reason 2 or 3 though.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
RachelB wrote:
Because a new memory card would need to be formatted, which takes far longer than just going through the extra prompt.
And it's not possible to pretend that they are all pre-formatted?
I cannot say I am too keen on accepting altering the memory card's state through the movie. As others have said it will become a very big hassle to verify the validity of the run, also in my opinion it is making things really fuzzy regarding what should be considered input to the game. When input is starting to depend on hypothetical secondary consoles it doesn't really feel like valid input anymore to me.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
That's what I meant with "clear memory card", this is going to become a massive mess that no one will enjoy verifying.
It's a lot more clever to use a swap memory card type of function that ejects the current memory card and puts in a new one. It would just become another input like disc changing.
This method also becomes easily verifiable by playing back the movie, if it needs predefined saves that the game does not create during playback the movie will just desync for everyone.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
If the system allows hot-swapping memory cards, perhaps it should be allowed, but it should be considered a memory card swap and not a "clear memory card" operation.
Which means you would need enough empty memory card files for each swap to be possible.
Example:
Let game save to Memory Card A, before another save occurs where you will be asked to overwrite etc, swap to Memory Card B, let the game save... and so on.
If the system needs to be powered off to remove the memory card or has an internal hard drive which it stores saves on, this must not be possible, as it would violate the representation of the actual system.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
That was a very nice route test TAS Lemon. I liked how much more spread out the grinding has become.
One question: You lost the hell of time when leveling during the Parasite boss fight, is this time-loss something that can be avoided in an optimized TAS? It looks kinda bad when a TAS misses a split with 40+ seconds when I assume the splits are based on a real-time run.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
elitist_jerk wrote:
It'll take me a while to set up a VM and get Hourglass running, but sure. I'm not sure how much of a movie file it would be, though, since I still won't be able to bypass Guest.
Also I love you dude, thanks for being willing to help/translate this.
The movie file does not need to be playable, I wanna examine it in a hex-editor, so if the mouse works but isn't recorded, just click past Guest and record input for 10-30 frames, just so I will have something to look at.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Warepire wrote:
Thanks for this information, gonna see what I can do with it. Currently mouse-input is a bit of low priority for me but I do have plans to add it after a couple of save-state and movie-structure improvements.
The function Dustforce uses to read keys is this Windows API function: SHORT WINAPI GetAsyncKeyState(_In_ int vKey); ( http://msdn.microsoft.com/en-us/library/windows/desktop/ms646293(v=vs.85).aspx )
Hooking this may get tricky as it feels like it can be VERY desync-prone. (In playback we'll "press" the key when the function is called but not executed yet)
When TASing I think an FPS of 60 would be accurate, since the game will read input 60 times per second.
I checked the code again, this function is hooked, and IWBG uses the same input method for the keyboard, so keyboard input for Dustforce should be recorded. This is very interesting, can you supply a log and a movie file of attempting to TAS Dustforce on build r81?
You can PM the link to me if you don't want it shared publicly.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Thanks for this information, gonna see what I can do with it. Currently mouse-input is a bit of low priority for me but I do have plans to add it after a couple of save-state and movie-structure improvements.
The function Dustforce uses to read keys is this Windows API function: SHORT WINAPI GetAsyncKeyState(_In_ int vKey); ( http://msdn.microsoft.com/en-us/library/windows/desktop/ms646293(v=vs.85).aspx )
Hooking this may get tricky as it feels like it can be VERY desync-prone. (In playback we'll "press" the key when the function is called but not executed yet)
When TASing I think an FPS of 60 would be accurate, since the game will read input 60 times per second.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
At this point I am not sure if XNA input functions are caught by Hourglass, I'm gonna look a bit more at XNA and then the Hourglass code to see if that is supported, may take a few days though, the Hourglass code is quite hard to follow.
So even if the game works at this point, I am not sure if recording would work.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Svimmer wrote:
I was trying to use JPC-RR in conjunction with Cheat Engine to find some memory locations and store them. However, it seems that the program assigns the game's data to a different place in memory each time so it's not enough to find the correct addresses once. Is it even possible to do what I'm trying to do?
If you mean that the memory block used by the game is in a different location every time (by this I mean that the memory has the same structure, but the addresses are never the same) this can be "solved". I don't remember exactly how but look at the Cheat Engine tutorial for Dolphin in the Dolphin Emulator section, it describes how to do it for Dolphin but the principal should be the same for any program that has the same behavior.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Nahoc wrote:
Yay!! Awesome!
I like this screenshot the best:
I second this screen shot suggestion.
A lot more entertaining than previous run due to the extended variety and seemingly random crazy-ass things that all prepare the glitch. Yes vote.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Are you familiar with GTA Stunting? If not, check out some of the videos on YouTube.
I am sure those kind of antics open up all kinds of crazy-ass shortcuts that no one would ever dream of using in a real-time speedrun.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
speedrunner wrote:
I downloaded the new version, but I... I cannot even lauch the emulator... Need some help, I don't find any tutorial... :/
Did you download both the BizHawk program and the installer? You need both, run the installer which will install all the necessary Microsoft programs that BizHawk depends on.
After running the installer, try to run BizHawk again.
This is all I can help, if you still have problems after this refer to the BizHawk section.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
MAYBE the latest Snes9x versions (v1.54 or newer) will work, but to be on the safe side you should use an emulator where the game is known to work, like Higan (get at www.byuu.org), BizHawk or lsnes.
Higan, BizHawk and lsnes are emulators, just like zsnes and Snes9x, but they are a lot better than zsnes and Snes9x.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
PikachuMan wrote:
2.0 is released, but this and other OoT hacks won't play.
If it's playable in 1.7, then WHY THE BLOODY HELL WON'T IT PLAY? We are implementing 2.0 to Bizhawk, but to hell with that, HOURGLASS IS OUR LAST RESORT. (at least until it can work in a future version)
a) It could be that the hack was made against inaccurate emulators and now that the emulator is more accurate the hack breaks because it is doing something not allowed OR there is a fault with the new version of the emulator, and if this is true you should let the devs know so they can look into fixing it.
b) Is there an official wording from the BizHawk devs on adding PJ64 2.0 into BizHawk because I have not seen one?
