Let's restart the highscore thread again, people are saying it got too long. End of the previous thread: https://mk.nyaa.place/notes/9zoixlwqn6tv1myv
So I figured out how to keep touchpads working in gamepad mode ^^ It involved reverse engineering the payload for the ID_SET_DIGITAL_MAPPINGS feature report - neither SDL nor kernel driver do it, so I didn't have any reference this time.
Anyway, now touchpads are fully working, with the same behavior as for Steam's gamepad action set - right touchpad moves pointer and does a left click on press, left touchpad does a right click on press and that's it. I'm not sure why it doesn't also scroll, but I wanted to keep it consistent (steam's desktop action set scrolls it and middle clicks on press instead, tho it does mean you have to use L2 to right click)
When Steam is running, you still have to switch to gamepad action set or you'll have double input, but I don't think I have any way of mitigating that - oh well. When Steam is not running, it will switch everything automatically at least, so at this point it's probably good enough. I'm yet to find an example of any app doing it well, so I don't think libmanette apps would stand out in a bad way here.
So, at this point I mostly just need to clean up the code and think again about what the public API should look like.
That said, I want to rework libmanette API entirely. It's not in a very good state right now, it's a lot more convoluted than it needs to be.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Blogged about this as well now: https://blogs.gnome.org/alicem/2024/10/24/steam-deck-hid-and-libmanette-adventures/
Mostly I wanted to keep the ID_SET_DIGITAL_MAPPINGS structure, as well as general steps documented somewhere online, as it would have helped me a lot. ^^
=> More informations about this toot | More toots from alice@mk.nyaa.place
Ok, to take a break from input: a Recently Played view. This has been a huge annoyance for me when testing, needing to find/open the same games over and over again.
=> More informations about this toot | More toots from alice@mk.nyaa.place
And DS mic input is finally supported.
This one is weird. Libretro DeSmuME core fixed one upstream bug with mic input (the "mic off" level they had was not really off but middle value), but it still didn't work, neither with the internal noise nor white noise. So, I took one of the samples from desmume/micsamples that's never used outside of Windows port, converted it to raw samples and made a header out of it - it works fine. And so we have working mic emulation now, finally.
Unfortunately, this also means we now have too many buttons in the header bar and it doesn't fit on mobile. I need to redesign this area entirely, but probably not before the first release - for now I instead moved the swap screens etc button to the menu. It was convenient, but we also have a very accessible shortcut for it both on keyboard and gamepad, AND the new keyboard/gamepad friendly menu, and the menu/button is only there for discoverability.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Honestly, at this point it's fairly close to a beta release. I think the only feature that's a hard blocker is input cheatsheet/remapping, and probably making paddle input work - since I already have code for paddles, it's just uhh broken.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Atari 2600 paddles are fixed now, and I added support for NES paddle/vaus controller as well.
I also refactored how platform-specific metadata in snapshots is stored/accessed, and made cores report the region themselves instead of guessing it from aspect ratio (and store the region in snapshots) - while it's a bit more complex, it's more reliable.
Then I started looking at Atari 2600/7800 switchers and well, the way we handle reset atm doesn't make a lot of sense. Not sure how to fix it, but it's probably not a blocker.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Ok, libhighscore now has api for soft/hard reset, implemented by atari 2600, 7800, nes and n64. The ui looks the same so far, but now it can be easily changed later.
I also landed the steam deck support mentioned in the blog post earlier.
And I found a bug with nes accessories already... Duck Hunt assumes you have both a controller and zapper, while arkanoid assumes you have a controller (for menu) and 2 paddles for 2 players... This is a bit annoying because now I need to potentially support multiple controllers per player
=> More informations about this toot | More toots from alice@mk.nyaa.place
TBH in this particular case I could just still provide specifically select and start buttons for these controller types. It's not ideal, but it's an option. I do worry tho that later I'll have controller types where it won't be enough.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Yeah, that works fine.
Meanwhile, I have a really good inspiration for input cheatsheet/remapping: Steam Input ui is really good and (!!!) provides the same time of mapping as what I'd be using here - physical button -> virtual button, not physical button -> game action like 99% of UIs out there.
=> More informations about this toot | More toots from alice@mk.nyaa.place
I started working towards that, but first it needs refactoring. For N64 the R2+face buttons -> C buttons mapping I implemented as a modifier system: you can map a button with modifier. Then the input handler will only activate it when both the button and the modifier button are pressed (and you can have the same button doing different things with other modifiers or no modifeirs too)
Problem is, this is very hard to show in the UI. Instead, I reworked it into a layer system: now C buttons are a layer with 4 button mappings, activated when holding R2.
As a bonus, sticks can be mapped in layers as well.
This is both simpler and is much easier to show in the UI, so that should be a bit closer now ^^
I also watched a video about weird DS games (well ok, I'm like 70% through) and discovered 3 games that used both screens as a single viewport assuming no gap between it. Added all 3 to overrides.
=> More informations about this toot | More toots from alice@mk.nyaa.place
I finally started implementing the input cheatsheet.
So far made progress on the gamepad one. The layout needs a lot of work, I also need to draw lots of icons, and PlayStation is being annoying as hell with its :ps_triangle: :ps_circle: :ps_square: :ps_cross:.
I also had to update most of the button names, because the ones we had before uhh weren't very accurate. For example, I learned that no one calls d-pads d-pads. Instead:
And Atari 2600, Atari 7800, SG-1000 ones are obvously just joysticks.
For PlayStation I have to make a system like fedi custom emoji, and substitute e.g. @ps_triangle@ with an image showing :ps_triangle: and so on. This is gonna be a nightmare.
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Ok, I drew a lot of icons, so no more missing icons in the overlay.
Unlike with the gamepad shapes themselves, I did not try to precisely follow the button shape this time, it's more symbolic so you can tell what's being referred to. An exception is the select/start button and their analogs - there isn't a lot of choice here, other than just drawing them as is.
I also implemented a few more layouts for this, so it's now (mostly) adaptive). Still need to fix a few bugs tho.
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
And PlayStation buttons show up nicely now as well. Yes, these are icons embedded into the text. Well, "embedded" - the code chops up the original string and creates a series of labels and images instead + nice alt text for screen reader ("Triangle Button" etc).
=> More informations about this toot | More toots from alice@mk.nyaa.place
Been a while, some more updates now.
I have a fully working overlay, with gamepad and keyboard cheatsheets. At this point the only thing left is to integrate them, really.
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
And landed, at least for the menu - not as a separate overlay yet.
A challenge was to make it reasonably obvious how to close it with keyboard/pointer. I initially tried a menu-like row at the top to use as a back button basically, it didn't work super well. Instead, I implemented a keyboard hint bar - same as for gamepad - and menu now permanently shows that. When the controls page is open, it serves as a button/hint for how to close it.
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Also yes, the menu got darker. In some games with busy background the controls overlay wasn't visible enoguh - it's fine for the menu with large bold text, but less so here.
Ideally we'd have blur here, but GTK blur is way too slow for this. I experimented with a faster blur shader, actually got pretty very decent framerate, but I'm not gonna bother with extending the game view rendering pipeline for this, no.
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
No big changes this time, but a bunch of bugfixes and refinements from the past few days.
For the most part it's input-related bugs, in both highscore itself and libmanette.
After landing the input cheatsheet, I tried it again on steam deck and noticed a few regressions:
Next, other input bugs.
First, I discovered a game that used zapper + full gamepad - The Adventures of Bayou Billy. Well, zapper controller type is not used anymore (pointer is currently handled separately), for now. Later I'll have to allow multiple at a time ig, or have inheritance. We'll see, dunno yet.
Second, sometimes when quickly flipping dpad when left to right or right to left, it just got stuck. That was a bug in libmanette, a really old one actually, and there was a checks notes 3 years old MR fixing it. I landed the MR, so that's fixed.
Third, with analog stick->dpad mapping it was easy to get dpad stuck in a pressed state by quickly flinging the stick in some direction and not holding it. Fixed too.
When holding a key for player 1 and then plugging in a gamepad, that key would get permanently stuck until you unplug the gamepad and press that key again. Funnily enough I did have code for preventing that, but uhh I forgot to actually only enable keyboard for that player's PlayerHandler and it was enabled for everyone. Oops.
Finally, when controlling a dpad this way, it was way too easy to accidentally press diagonals when you want to hold it in a cardinal direction. I reduced the area for diagonals a bit, now it's π/5 instead of π/4.
=> More informations about this toot | More toots from alice@mk.nyaa.place
I also tweaked a few icons. When making the "no controller" icon for the input overlay the one from icon library really didn't work well, so I made my own, with some help from @kramo@fosstodon.org
I also tweaked sg-1000 icon a bit, to emphasize the buttons more. Nothing significant tho.
=> More informations about this toot | More toots from alice@mk.nyaa.place
I ported a more advanced NTSC shader (still based on themaister's shader but that can detect phase automatically) (tho it needed a fix for 160px wide game support (atari 2600/7800), in the previous shader it worked ootb) and now it e.g. detects phase for Mega Drive accurately.
Meanwhile I reverted BlastEm to output 480i for sonic 2 2-player mode, and instead made it interlace it in a shader, with added frame blending to reduce flicker. This also works for SNES and PSX high-res mode. No more 480 scanlines at once with this filter, but other filters still have the full 480 lines and look crisp.
I still need a better CRT filter on to use on top of interlacing+NTSC/PAL, but one thing at a time.
Edit: yes, the top scanline is broken, I fixed it in main
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice Wow, great work! Does the NTSC shader use a comb filter?
=> More informations about this toot | More toots from brouhaha@mastodon.social
@brouhaha@mastodon.social I think so, but to be clear I only ported an existing shader and am not the best person wrt explaining how it works :neocat_laugh_sweat:
=> More informations about this toot | More toots from alice@mk.nyaa.place
@brouhaha@mastodon.social I can talk about the monochrome LCD and interlacing parts, since I wrote those - otherwise I'm just porting existing stuff
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice OK, thanks! I'm interested in deinterlace algorithms as well, but I don't have specific questions. I look forward to any future posts.
=> More informations about this toot | More toots from brouhaha@mastodon.social
@brouhaha@mastodon.social interlace, not deinterlace ^^
I don't need to deinterlace anything - the input is already 480p (or in case of megadrive pre-deinterlaced 480i). I just need to take all even/odd scanlines (depending on the phase), blend it with the previous frame a bit to reduce flicker, and call it a day, then I have 240 scanlines (less in practice becaues overscan but close enough) which I can feed to the ntsc/pal and then crt shaders. If the input was already 240p, it's a passthrough, tho unfortunately that means I have to have padding in the output texture in the interlaced case, and remove it in the final pass.
=> More informations about this toot | More toots from alice@mk.nyaa.place This content has been proxied by September (ba2dc).Proxy Information
text/gemini