search

Javanaise / mrboom-libretro

Mr.Boom is an 8 player Bomberman clone for RetroArch/Libretro
http://mrboom.mumblecore.org
MIT License
204 stars 61 forks source link

How to get tri-bomb to work reliably? #98

Open SimpleTease opened 3 years ago

SimpleTease commented 3 years ago

I have an extremely hard time getting tri-bomb powerup to work. How fast should one tap the bomb button to drop all of them? I only got it working once and thinking my technique is wrong.

frranck commented 3 years ago

You need to double tap quickly. Btw are you interested in back porting the asm changes to the original assembly code? I would need to push some missing files, but first you would need to compile https://github.com/frranck/asm2c. stupidly I coded it in swift, but It's running fine on an ubuntu linux...

SimpleTease commented 3 years ago

You need to double tap quickly.

If I turn on autofire, it works easily. With it off, my timing is always wrong. Guess I need more practice.

Btw are you interested in back porting the asm changes to the original assembly code? I would need to push some missing files, but first you would need to compile https://github.com/frranck/asm2c. stupidly I coded it in swift, but It's running fine on an ubuntu linux...

I tried compiling but couldn't get it working yet. I would've started by adding the unaligned casts and work forward on mismatches.

frranck commented 3 years ago

OK I never tried with the autofire. We may have an issue there. I will push more tooling for the conversion soon: Fell free to create an issue in asm2c if you need help with the compilation.

SimpleTease commented 3 years ago

Are you using gamepad or keyboard for tri-bomb?

frranck commented 3 years ago

pad lately, but I always play the SDL2 version, that don't use auto-fire

frranck commented 3 years ago

I guess we should check how it's implemented in assembly.

SimpleTease commented 3 years ago

Strangely I'm having no problems anymore with tri-bombs. Seems easy to pull off now. I think it was some Retroarch problem as some recent updates has cured my frustration.

frranck commented 3 years ago

Will try but the autofire seems to be broken in SDL2...

frranck commented 3 years ago

actually autofire is always on in SDL2 even if you use -n: when you have multiple bombs but keep the B button on, it will keep dropping bomb when moving to a different cell without releasing and repressing B.

frranck commented 3 years ago

I can't test the libretro now; so I made a SDL2 only change to fix the autofire; but it is breaking the tribomb... https://github.com/Javanaise/mrboom-libretro/blob/master/common.cpp#L1278

frranck commented 3 years ago

I don't think having an optional auto fire option can work with netplay, if two players have a different setting it will break the determinism.

SimpleTease commented 3 years ago

I did some research on netplay. The server controls the important values:

If a client sets a value, it gets overwritten by server. Tried many times to break the system but always rejected.

Options like these appear to be per player.

SimpleTease commented 3 years ago

I did tests before libretro autofire option was forced always.

frranck commented 3 years ago

Did you read https://docs.libretro.com/development/retroarch/netplay/ ?

frranck commented 3 years ago

Could you please check that before 277e7db0d77a87559f7e0beafa760b37462c9bee in the libretro version:

SimpleTease commented 3 years ago

Did you read https://docs.libretro.com/development/retroarch/netplay/ ?

I did read. Autofire is baked into the savestate. When a desync happens, server re-transmits back to clients and thus indirectly re-applys the 4 game settings mentioned above. Because the game settings are stored in there.

I have to use low network latency settings and other switches because my jitter is terrible and otherwise unplayable. 5-10 seconds can go by before I hit a state reset. But I did notice that (Server) had monsters off, (Client) had monsters on. It took several seconds before Client got rewind state and monsters went from on -> off.

Same with autofire. Server (on), Client (off). I could not run around freely dropping bombs until the state reset. Then the tribomb worked.

Sometimes it gets so bad that I die, hit the victory screen, start new stage. To find out we're still playing the previous stage. Then I die for real! 😆

Even if Client changes settings in-game, Server will send that rewind handshake and wipe out any cheats Client was using.

I found that autofire was baked into savestates, which was messing with my test results. So I went clean.

autofire off would work like this: when you have multiple bombs but keep the B button on, it will keep dropping bomb when moving to a different cell without releasing and repressing B.

autofire off = drop bomb, walk around still holding button. Only 1 bomb dropped. autofire on = drop bomb, walk around still holding button. Drops bomb at each cell visited.

tribomb was possible with autofire off

autofire off = could not get tribomb to work. Smashing the bomb button did not work. autofire on = I drop a bomb, release, wait maybe 1-2 frames, then press.

frranck commented 3 years ago

The save state should be saving all variables from the mem struct from the "master" variable to the "replayer_saver" one according to https://github.com/Javanaise/mrboom-libretro/blob/master/common.hpp#L42 So even if autofire is not included; but it could create different states for the same input when computers have a different configuration; so that will generate some resynch.

I guess there's gonna be resynchs with the level selection too. Shall we remove this?

There was quite a debate with the autofire option :) If we want to reimplement it; that's gonna be quite tricky; it should be done totally inside the assembly code; forced to false for retrolib except during the demos... This is happening around there: https://github.com/Javanaise/mrboom-libretro/blob/master/tools/asm/src/mrboom.asm#L6676

SimpleTease commented 3 years ago

I guess there's gonna be resynchs with the level selection too. Shall we remove this?

To be completely netplay safe, I agree.

There was quite a debate with the autofire option :) If we want to reimplement it; that's gonna be quite tricky; it should be done totally inside the assembly code; forced to false for retrolib except during the demos...

For the back burner I guess.

frranck commented 3 years ago

I guess there's gonna be resynchs with the level selection too. Shall we remove this?

To be completely netplay safe, I agree.

No monsters and the team mode selection are problematic too. I asked @twinaphex on Discord if there was an option to get core settings shared.

frranck commented 3 years ago

@jdgleaver Could we get your input on that? We would need certain core options to be selected by the server.