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
Aaand override phase manually for N64, SMS and SG-1000 anyway, because the shader detects it wrong. E.g. SG-1000 and SMS both have very aggressive overscan crop,so end up with 256px width ,even tho they are drawing 320px, just with a lot of overscan.
I also dropped the tv mode preference. Composite was inaccurate - not all platforms do the dot flicker (e.g. Atari or Sega ones don't) and e.g. PC Engine allows games to turn it off... There's no way I could replicate this as a shader, so let's not even bother. We defaulted to S-Video anyway + it wasn't supported for PAL + it looked really flickery on high refresh rate screens + it produced artifacts on Saturn, so I don't think it would be missed. S-Video is good enough. I may readd it later, but we're close to a release and let's not ship unpolished settings. ^^
=> More informations about this toot | More toots from alice@mk.nyaa.place
And a new CRT shader now. I ended up porting crt-Cyclon, it is fairly comprehensive (but also not super demanding like CRT Royale, CRT Guest Advanced and the likes) - it actually has a shadow mask! also does color correction for NTSC and PAL, wihch we didn't have previously.
It can also do curvature, but that's still off for 2 reasons:
I'm still undecided about CGWG (green/purple) and RGB phosphor dots - the former is more accurate spacing-wise (that's what we have atm), the latter looks cooler when zoomed in ^^
Also changed Nestopia PAL palette again, the previous one fell apart with this shader - it already looked bad, now it's worse.
Anyway, still a big improvement over what we had before.
=> 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 now a comparison between the old CRT shader from gnome-games and the new faithful shader with NTSC.
Admittedly the old shader does curvature better than the new one (it's not enabled on screenshots but trust me on that one), but yeah, no curvature for now either way.
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice I feel like no curvature might be better, especially for handhelds. I can't imagine many games benefit from curvature, but I do know most benefit from the emulation of other aspects of CRT displays.
=> More informations about this toot | More toots from vtrlx@mastodon.social
@vtrlx@mastodon.social agreed, but it has a value in nostalgia ^^
=> More informations about this toot | More toots from alice@mk.nyaa.place This content has been proxied by September (ba2dc).Proxy Information
text/gemini