Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Patashu wrote:
Mothrayas wrote:
Kurabupengin wrote:
Expecting some good shit from Yong Yong this time.
Prepare to be disappointed, then. The game is severly broken, has all kind of (bad) glitches, but most importantly, is so broken that it is completely unplayable in every emulator (except hhugboy), so it isn't even possible to make a TAS of it as of yet.
How can a game be so broken that cycle-accurate emulators can't emulate it? That is impressive.
It probably uses some special cart logic that is unimplemented anywhere else.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
ALAKTORN wrote:
Warepire wrote:
Open it with Ctrl+C
I think they disabled the cheat editor menu item because I've had it crash the emulator in rare cases.
How do I use “Add Cheat” from RAM Search, though? That’s a really really important feature, and clicking it does nothing for me. Edit: I mean for mass-cheating, I normally select 100 or so results from the search and freeze them all at once when needing to pin-point an address, I can’t do that from the Ctrl+C menu.
As far as I know that function does not work in PSXjin unfortunately.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
PJ ranted during one casual play-through that 3 player on the hardest mode makes the game almost impossible to 1CC due to the damage dealt.
If the game is completable in this mode, I'd for one love to see a TAS of it.
I personally think that this is the most entertaining version of Battletoads when played with speed in mind.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Scepheo wrote:
I never noticed that x360ce is open source, despite having used it often myself (until I bought a 360 pad for Windows, that is). They managed to correctly hook the Xinput calls, so there's a good chance there's some useful stuff in their code.
Due to license stuff we're not allowed to just merge that code though, but we might be able use it as a reference to fix up our own code.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
If they hook some of the same functions as us, there could be hook-races. But feel free to give it a try, if it works fine, then it's a temporary solution until I can get around to fix the Xinput problem.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Patashu wrote:
Whatever MURPHAGATOR is emulating it in does the music fine
MURPHAGATOR!'s twitch page wrote:
Arcade Hardware Info
I do not use MAME or other emulators when doing attempts on arcade games. Instead, I use hardware known as a SuperGun to play then on the actual hardware. Superguns effectively do 3 things:
1. Provide power to the arcade board
2. Convert the video output from the arcade board to more useful formats
3. Transfer the inputs from the controller to the arcade board.
Since none of these things influence the way the board runs, the boards function exactly as they would in a standard arcade cabinet.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
I vote for frame-timing á la 1.6.x
I'm not sure if one can really count the CPU cycles either, if I remember correctly the CPU fully and entirely stops during the HALT (or STOP?) instruction. Though if I am wrong here, that would be the ultimate solution. (Number of cycle counter roll-overs + cycles passed since last roll-over)
I don't think there is any fully accurate way to track time in the gameboy without running into issues where time might not be represented 100% accurately. I do however not see this as a major issue, compared to the issue that it might not be possible to provide input during certain situations.
What is the purpose of more accurate emulators if we botch the timing? That is potentially as bad as using emulators of less accuracy.
I've always wondered, why are the movie formats frame based and not input poll based? Wouldn't it be stronger against desyncs and more true to hardware emulation? Like, if you're to build a TASBot, it has to work off of the polling.
Some consoles have interrupt-based input as well as poll-based.
Though systems that are purely poll-based should definitely work with a poll-based format.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
t0ast wrote:
Warepire wrote:
Quarantine II - Road Warrior
Would love to see this or even the original. I don't remember how well they flow from start to finish, but I DO remember the amusing premise and manic combination of fast, floaty movement with short draw distances. Assuming it's not too much of a grind fest, it could make for a pretty good run.
I've never played the first game in the series, but I did play Road Warrior a lot in my youth, and Road Warrior is entirely mission based, so no grinding should be necessary.
Joined: 3/2/2010
Posts: 2174
Location: A little to the left of nowhere (Sweden)
Scepheo wrote:
A frame is marked as a lag frame at the start of the frame, then unmarked whenever the game polls for input (although this INPUT_NOTIFY message is never sent to the client by the performance core, the other core works fine). If no frame is ever marked as a lag frame, that means the game is polling for input all the time, so no frame is actually a lag frame. I find it hard to imagine a way in which this system could yield false negatives, honestly.
