The "X button to enter surf" needs a better input check about tic-80 HOT 6 CLOSED

Making some progress, I successfully distinguished against a freshly pressed down button vs on being used or held. It didn't fix the issue though which I thought confusing. It was like the inputs weren't being dropped between changing states, and that was exactly it. tic_api_reset in core.c seems to handle dropping inputs when a game crashes, or a screenstate changes entirely. Turns out, gamepads were not yet included lmao.

I added the gamepad ram reset in the same structure that the keyboard is treated and it works! However I noticed this function shares space with the tick start and tick end, also it features some messages. So in the name of security I'm going to leave my fix to this function commented out until I finish working on the tic_api_btnd and btnu functions, then commit it last. That way redactions can be made a bit easier.

You can see some progress here : https://github.com/LettucePie/TIC-80-launcher/commits/btnd-btnu/

from tic-80.

@LettucePie Could you have a look at that?
Sorry to add work ^^'

from tic-80.

Hello! Thank you for the report.

I'll start looking into more precise ways to distinguish the button input. If there already are flags designed for pressed, released, and held then it will be painlessly easy to fix.

I am busy for the next couple of days however, so it may be a bit until I get to it.

from tic-80.

I tried this but it did not work, the issue is still there.
You can find documentation on how this API should work on the wiki: https://github.com/nesbox/TIC-80/wiki/btnp but I would have expected 6, -1, -1 to be the best option.

from tic-80.

Hello again, did a quick search into the button press command before going to work. It's located in the io.c file at 43 (

I then searched for different ways that function is being used since I don't yet understand what it's doing. I found a bunch of results where along with the input command is passed a Hold and Period value. (

I went to do a quick build, but unfortunately my system isn't ready for the newest build instructions and my internet is very very slow, so my quick morning investigation ends here. I have no way of testing it right now, but in theory you can edit my line of tic_api_btnp(tic, 6, -1, -1) into tic_api_btnp(tic, 6, 20, 3) in console.c (

from tic-80.

I'm starting to have a slight idea of what is happening with tic_api_btnp. Inside that alien looking ternary thing, it is asking if the previous ticks game_pad data (referred to in the header file core.h) has the same button being held as the current game_pad data. That way it can check against the Hold and Period requirement.

So, the groundwork for checking if a button was freshly pressed or released is technically all there, it's just missing the functions to wrap it all together... Which has me cautious on how to proceed. There may be a solid reason these were passed up on. Currently you can emulate this functionality when programming a cart by using boolean flags to store the held status of a button, so it's probable it was seen as just unnecessary. I really don't know. The Occam's Razor approach would be to setup my own boolean flags in console.c the same way a user would when making their own cart, however that would be silly/messy lol.

For now I'm going to attempt to expand on the api in io.c... I'll try to stick with naming conventions:

• tic_api_btnd = TIC API Button Down - Checks against previous game_pad data to see if provided button wasn't active, returns boolean
• tic_api_btnu = TIC API Button Up - Checks against previous game_pad data to see if provided button was active, returns boolean

from tic-80.