Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Zurreco wrote:
Warepire wrote:
My no vote was not arbitrary if you read my previous post.
It is arbitrary in the sense that you think there is an arbitrary definition of "properly" defeating the final boss. You've literally stated that the entire run is great, but you take enough umbrage with where he ended his input to vote No, rather than Meh (we have that option for cases exactly like this). The fact of the matter is that the submitter found a loophole to end input as soon as possible while still ensuring the completion of the game, which is what this entire site is predicated upon.
Consider watching an action movie, any action movie, and when the final part of the showdown is about to start, the protagonist just stops and says "That's it, I'm going on strike!", and then there is footage of him just standing still for several minutes ... then roll credits. Would you not feel cheated from such a movie?
That's the feeling I got from the final boss battle in this TAS. I am not hiding that I thought it was an impressive achievement to do it this way, but for me, personally, it completely ruined the enjoyment of the TAS, hence the no vote.
One could even argue that the thing we vote on is arbitrary since there is no defined set of laws for what everyone thinks is entertaining or not. It's all personal opinion.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
This TAS was hilarious until the moment where you cheaply let the boss time out.
I will vote no due to that completely killing the entertainment and pace of the run. It's a nice technical achievement however, so I'd be fine with it going to vault.
I would however immediately vote yes on a TAS that actually fights and defeats the final boss properly.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Carcinogen: Did you use hotkeys or the file-menu to save & load states? Using the file menu can cause huge problems. I had one game soft-lock if I used the file-menu but work fine if I used hotkeys.
Looks like they (zeromus) just barely started with working on PSX support, that is not even close to "it's in alpha stage" or even "PSX support is there". It just means work has started on it. Not that there's anything workable yet.
Since there had been updates to the GUI to reflect PSX I figured games could be loaded, sorry then. BizHawk runs really slow for me so I don't always open it to check (CPU's too old).
Also I may have gotten it wrong, but alpha to me is "launches, no guarantees after that"
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Are you sure the ISO is truly working? I found ISOs that appear to work and then fail later on.
Verify your game against the redump database. If the ISO verifies as good, then it's probably an emulator bug, in which case you may try a recent SVN revision of BizHawk, PSX support is added but it's in alpha stage right now. It should be stable enough for testing though.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
It's possible the RNG gets re-seeded with something like "time elapsed", or the RNG is affected by time and old actions in other ways that makes it undeterministic for copy-pasting frames :( That's unfortunate. I am not familiar with the inner workings of Resident Evil, so I can't say exactly why the RNG is undeterministic.
There are 3 ways to go now:
a) Continue copy-pasting and re-TAS more sections to re-manipulate the RNG whenever it desyncs.
b) Restart the TAS from where you left off after the improvement
c) Ignore the improvement
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Dimon12321 wrote:
P.S: What features has 64-bit Dolphin? How much memory it takes? Why do 2 GB (I personally have 3,28 GB) can't cope its full workability?
This explanation will require basic understanding of CPUs, unfortunately I cannot describe it simpler, someone else might though.
The 64 bit dolphin is for 64 bit CPUs, which you might very well have even if you have 32 bit Windows, depends on how old your computer is. If you have a 64-bit CPU, I advice you to update your Windows to 64 bit, and also installing up to 8 GB of RAM (RAM is pretty cheap these days, I know Ukraine isn't doing so well right now though due to all the conflicts, but hopefully that should settle)
The reason for 32 bit being dropped is best explained here:
https://dolphin-emu.org/blog/2014/05/19/obituary-32bit/
In short: 32 bit CPUs and 32 bit operating systems don't have the necessary prospects to emulate a GameCube or Wii really well and the more accurate Dolphin got the harder it was to maintain the 32 bit version, to the point where the developers decided it was better to drop it as the 32 bit version kept ending up broken.
The reason for the difficulty to maintain 32 bit was that the 32 bit architecture lacks several useful CPU instructions in combination with being limited to ~3.5 GB of RAM (the Wii uses more RAM than that) making most of the 32 bit version require complicated solutions to work around those issues.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Yeah, Xinput seemingly works a bit sketchy. Don't have any ideas on how to fix that right now, Xinput is not my strong side.
Did you try applying the same fix as I suggested Zanoab to try? Probably won't do anything but worth a shot.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Alyzeej wrote:
I downloaded NotePad++ and opened the PSXjin movie file there. Are the lines to the left the ones you are talking about?
[image]
Yeah, remember to check at the top how many lines the header is (the stuff before the first frame of input). If the header is 20 lines, then frame 1 is on row 21 instead of 1.
Alyzeej wrote:
Let's see if I understand the process correctly. First I need to create a backup file of my PSXjin movie which contains all of my progress. Then, go to the part with the boss fight which I wish to remake and record and overwrite the original file.
Now I have two files. The starting point of the part I want to replace should be the same for both of them since they are identical - and I'll be using the door loading animations before the boss fight as a reference. Let's call it the first frame and pretend it's frame 101102 for both files.
The second frame (the part which ends the remade segment) that I'll pick up from the original file and the new file will obviously be different because the segments will have different lengths. This means that I need to find the exact frame (using frame advance) where both files can be matched (such as the door loading animation on the way back I previously used for reference point). If, say, it's frame 110120 in the original file but frame 110000 in the new file, I'll copy everything from 101102 to 110000 from the new file over 101102 to 110120 to the original file. Is this correct?
It's better to copy everything after frame 110120 in the original over to the new file. That way you have a movie guaranteed to play back in-case the edit would desync. Otherwise you got it correct. Obviously use names for the files so you can tell them apart.
Regarding optimization, if you deem it optimized enough you could always try to submit it, but it may end up rejected if it's considered too in-optimal. Submission is no requirement though, it's entirely up to you to choose if you want to or not.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
One line represents one frame of input. You might have an easier time editing the files using a program like Notepad++ which can display line numbers.
So the way to find the right place to start copying frames from one file to another is to find the frame-number (using the emulator for example) in the movie your editing from where you want to add input from the other file. Use the same procedure on the other file to figure out the frame-number to start copy from.
Remember to consider the lines that make up the header data when you "convert" the frame numbers to line-numbers, I forgot once and it took a while to figure out why it didn't behave like I expected.
We also accept rule-restrictions and superplays, it's not all speedruns. (Examples: SNES Family Feud and N64 Super Mario 64 "70 stars, no BLJ") If it's optimized enough (not using frame advance suggests that it unfortunately may not be) and an interesting concept, it could very well be accepted if it's considered entertaining.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I was writing a how to on how to edit movie files using HxD when I opened a PSXjin movie file, and lucky you, PSXjin movie files are text-based. You should be able to use notepad. Unless you ticked "Binary format" when you created the movie.
Regarding dumping, I think most encoders use the Camstudio lossless codec. But if you submit here and the TAS gets accepted, it will be encoded by an encoder-member for you. You are welcome to provide a temp-encode if you feel like it, but it's not necessary. Temp-encodes can basically be of any quality. But if you want to make a quality encode (for any reason), have a look in the Encoders corner, should be a lot of information there on dumping and encoding.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
jlun2 wrote:
Scepheo wrote:
nathanisbored1 wrote:
idk why people care whether RTA wins or not
Because it's an indication that the TAS needs an update.
Well, not always, since that would mean runs like Ocarina of Time would always be beaten by RTA. :P
Don't forget to adjust the timing method. ;)
Zelda-RTA timing makes the TAS sub-17 minutes.
If an RTA and a TAS is timed using the same method and the RTA comes out on top, then, as Scepheo said, the TAS definitely needs a revisit.
EDIT: This topic really needs to stop derailing.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Pokota wrote:
You need to have at least two tiles of walkable space at both the entry point and the exit point, otherwise you'll just fall into a pit. The reason is that you're switching back and forth between tiles as you pitwalk, which makes the game try to pull you into the other pit. If there's an obstruction to where there's a pit of width 1 you can't fool the game into trying to pull you into the other pit because there is no other pit.
I see. Thanks for explaining that. Reviewing the dungeon that takes the key pitwalk out of the question. I guess the already existing bridge for the other pit counts as an obtrusion and not ground while pitwalking?
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
The following comments may be stupid because I am not that knowledgeable in this game, but:
In level 1, is there something special about those pits that you activated the bridges for? Pitwalking would be faster in both cases?
