BizHawk

BizHawk copied to clipboard

AFAIK, the console doesn't have the ability to rotate the screen. So I guess it was added in mednafen.

My observation is that the game kinda switches between 2 states which also makes no sense and it shouldn't cost any time / affect a TAS.

The console is a HANDHELD. The user has the ability to rotate the screen; it makes sense for the game to switch between two states. The system is thoroughly designed to facilitate rotating.

I can't believe there are any issues caused by any of this. It should be purely cosmetic. Let us know when you find an actual issue, instead of what we have here which appears simply to be your disbelief.

I'm not sure if I understood what you write.

My primary problem is that pressing the rotate button will make a requirement of appending a frame to sync the TAS.

However, this can be abused by pressing the rotate button again, returning back to the original state and the TAS stays in sync with original length.

I have no idea what is he logic behind this. You can try any game, this is an emulator thingy.

Regarsing again to your post, do you mean there is a button on the console, or just the "physical ability" to rotate, which absolutely shouldn't have a single button devoted which justs rotates only between 0 270 or 0 180 whatever.

I dont understand "sync the tas". You're right that it requires a frame to rotate the console. Which can be combined with any other input that frame so it costs no time.

The single button devoting is a great idea. Think about it until you understand it.

Okay, so I assume I'm also right about it's actually not an emulated part of the console (not a real button) but a "helpful" button for casuals/playing.

I can't help you, man. Look at a picture of the console and see if

1. there's a rotate button
2. it's in someone's hand

I think he means that if there's no such button on the console, only an emulator option (like in desmume), it shouldn't affect sync.

It doesn't matter anyway. Add the frame. Merge the frame with other input. Either way, do it, see what happens, and deal wit hit.

AFAIK:

1. There is no rotate button on pictures
2. Using the rotate button ALWAYS costs 1 frame in a unlogical way as I already described. I'm asking why does this happens, but since it looks like I don't need to manipulate it, I won't research this.
3. You can't merge it with another button, I don't know how could you.

1. OK, now you see it's not a real button
2. It requires one frame; it does not cost one frame, because you can "combine with any other input that frame". If the wonderswan core had a unlogical button called 'make a honking sound" it would not cost one frame to make a honking sound. You would simply issue the Honk button in any frame you wanted to trigger a honk. What does that have to do with any other button? Nothing.
3. see number 2.

I can't stress this enough.

The rotate button costs 1 frame. Feel free to upload 2 movie files, 1 with rotate, 1 without rotate. The movie file will desync or the movie with rotate will be 1 frame longer. Feel free to use any wswan game.

This isn't going anywhere so far :D

@zeromus, if someone makes a pull request that removes the sync dependency from that button, will it be accepted?

My final wording of this issue. Currently the rotate button affects TASes, the severity is unknown (I only reported the 1 frame difference in 1 rotate state and the 2 state abuse)

In the future, the rotate button should be 100% unrelated to syncability.

A game needs to be rotated, or it doesnt. If it needs to be rotated, tas it rotated. If it doesnt need to be rotated, dont tas it rotated and dont press the rotate button.

I don't understand "abuse" or "original length". I guess you're importing an old tas, (would it sync anyway?) but I still don't understand "abuse".

I just tased WSD mr. driller to optimize the start button press to the main menu, and it was frame 186 regardless of whether I had a rotate in frame 0. It doesn't cost any time, and the only way it could is if the emulator SKIPPED a frame when it rotated, which it clearly does not.

Test 1:

• load Buffers Evolution
• to start the game, you can press the A button at the 3rd (2 on the hud / tastudio) frame Pressing the rotate button at 0th, 1st or 2nd frame will requires you to append 1 frame, resulting your movie 1 frame longer Pressing the rotate button after the 3rd frame will requires you to append 1 frame after your sequential inputs (pressing A at frame 58)

Test 2:

• load Final Fantasy
• to start the game, you can press the A button at the 11st (10 on the hud / tastudio) frame Pressing the rotate button at 0th, 1st ... 11st frame will requires you to append 1 frame, resulting your movie 1 frame longer Pressing the rotate button after the 11st frame will requires you to append 1 frame after your sequential inputs (pressing A at frame 17)

1. Pressing rotate on frame 0 in tastudio does not affect pressing A on frame 2 to start the game
2. Pressing rotate on frame 0 in tastudio does not affect pressing A on frame 10 to start the game using bizhawk 2.2

I rechecked and I think now I understand it. I didn't included my full input log in this issue, because I've thought its irrelevant... however I pressed the same button (A) on both "P1" and "P2", leading me to add an extra frame. As zeromus wrote, you need to press only one of the same button.

The R button acts like a P1/P2 switcher, that is the frame you press R will also press those buttons you have. For this reason, this issue is not a real issue (everything works correctly).

Now my "concerns" are still remains:

• Nearly every other core I have checked so far doesn't have a special button dedicated as an input to the core that doesn't affects gameplay. That's also the reason I've thought the R button is actually exists on the console.
• It's much easier to calculate button bits if only the relevant controllers buttons are displayed (example ABSTUDLR at NES ranging from 76543210 (maybe this is from fceux?)) (edit: well I could uncheck that button in TAStudio)

Rotate should be a non-sync setting, not a button, and unlike the Lynx there aren't two sets of buttons so I don't see why that should be duplicated either.

In Rockman & Forte it's necessary to switch orientation during the game (a single stage uses a vertical layout). When rotated, the X buttons that were used as the d-pad take the function of the A/B buttons, and the previously unused Y buttons become the d-pad.

I don't know how common this is among other WonderSwan games, but for casual play a single set of buttons would require remapping the controls multiple times during the game to be playable. Unless there was a single set of logical buttons with two separate sets of bindings, but I'm guessing the input and UI code doesn't support that.

There are 2 copies of each of the X and Y buttons.

I may have misunderstood your previous comment.

Currently there are two copies of the buttons to (I presume) allow the user to have different bindings for the two orientations without having to rebind controls, and I read your comment as wanting to remove the second copy?

Yes. No other handheld is implemented like this edit: including Handy for the aforementioned Lynx.