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
A few more shader improvements.
First, I experimented with having Nestopia output raw colors and decoding them frontend side. Multiple problems here:
Second, I split out a separate NTSC filter variant for NES - specifically, to adjust gamma. Games like Super Mario Bros looked blown up - the sky was way too bright. Now it's comparable to other filters.
Third, renamed Faithful filter to Accurate. Never liked the old name. So now we have Anti-Aliased, Sharp, Blurry, Smooth, Accurate by default.
Fourth, there were a few leftover bugs with crt-Cyclon's slotmask sizing when interlacing. I didn't notice since we use aperture grille mode instead, but fixed regardless - just to avoid potential landmines later.
Finally, I created a git repo for additional filters, similar to https://github.com/hizzlekizzle/quark-shaders and https://github.com/libretro/slang-shaders - I want to keep the base app minimal for obvious reasons, but I totally understand that people will want to use other shaders. So, I pushed the few shaders I had locally, and ported a few more from the libretro repo.
Note that licensing on some of these will be vague - some people do things like "License: GPL" without specifying version, so it's anyone's guess what it actually is. I'm not shipping it with the main app, so it shouldn't be a problem - but just be warned.
So now, if someone wants a niche shader, I can just add it there, or ask them to port it themselves if they are experienced with it - contributions are welcome, that repo is a dumping ground so if you have a silly shader - you're welcome to contribute it.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Can't believe I forgor to link the actual repo: https://gitlab.gnome.org/alicem/highscore-extra-filters
A few more improvements today, I researched in detail what specifically artifacts each system has, and well, with a generic shader some things will invariably be wrong - so we're back to multiple presets. More than before, in fact: 9 total.
For example, Atari systems had way more color bleeding than they should.
NES has its stair-steppy artifacts that change every frame back. This record is very hard to record as you need at least 60 fps + will be more or less visible depending on your monitor refresh rate and response time, but hopefully the gif combined from 2 screenshots shows it well enough. ^^
SNES and PC Engine also has the artifacts, but static.
Mega Drive and Saturn have the dithering rainbow effect now, while 8-bit Sega consoles have less color bleeding.
It's not perfect - e.g. Atari 7800 and SMS artifact colors don't look right. Tower Toppler should have solid colors (but different from the one in the actual pixel data), not a rainbow.
Edit: I had a gif of the NES effect, but mastodon instances can't display it and by extension don't display any images at all
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Got it to work by converting it into a video that loops 300 times instead
=> More informations about this toot | More toots from alice@mk.nyaa.place
And curvature is back as well now. Since this shader emulates an aperture grille, it's trinitron-style curvature, only in one direction.
Pointer input is also warped the same way, so there's no mismatch between input and the game like there was in gnome-games.
I was previously worried about games with large overscan area, so I adjusted the CRT shader to account for that - it compares the game's aspect ratio to 4:3 and does curvature around that entire area (assuming the game takes 100% of the width if it's shorter than 4:3 or full height if it's narrower than that) - so curvature stays consistent between platforms - on the screenshots you can see games with 192, 230, 224 lines respectively and the curvature is consistent.
What I'm unsure about is if I should switch back to Trinitron-style NES palette as well (CXA2025AS, also Nestopia libretro default), or stay with YUV/Consumer (upstream Nestopia default). Trinitron style palette has more blue sky in SMB, while the default one is more purple, and ofc it's NES palette so there isn't a single "correct" palette...
I should really look into allowing to load multiple filters internally, this is getting out of hand - I had to update 11 separate filters to add curvature:
They all reference the same CRT shader, with mostly identical params (the only difference is that they set its color space to NTSC-U for the first 9, PAL and sRGB respectively)
=> 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 Between the two Super Mario Bros screenshots, I prefer the blue over purple.
I wonder what Nintendo does in their official ports? (Like to the Switch, for both the NES SMB and also SNES SMAS.)
Their official page has it in the middle. I wonder if you could average it out and split the difference?
https://www.nintendo.com/en-gb/Games/NES/Super-Mario-Bros-803853.html
Their video is more purple (but also very dark, so not a great reference).
SMB2J has blue: https://www.nintendo.com/en-gb/Games/NES/Super-Mario-Bros-The-Lost-Levels-696744.html
(BTW: I absolutely love your posts like this.)
=> More informations about this toot | More toots from garrett@mastodon.xyz
@garrett@mastodon.xyz Nintendo does a lot of things, some of which don't even try to be accurate:
SMAS doesn't really count since SNES does RGB natively and thus has a defined palette, and while the arcade versions (PlayChoice-10/Vs. System) do RGB, it's super garish and doesn't resemble console output on any TV basically.
So - I wouldn't use official ports as a reference here ^^
=> More informations about this toot | More toots from alice@mk.nyaa.place
@garrett@mastodon.xyz another option is to ofc just provide palette options here too, but for that I'd like to do NTSC decoding frontend side, not core side - that way we avoid mismatching snapshot thumbnails, for example.
In that case I could see an option for choosing CRT type, which would toggle both NES palette between trinitron/generic, as well as curvature and aperture grille/slotmask - the CRT shader I have can do those too
Basically choosing between these 2
But well, when I tried doing exactly that, the generic YUV decoding worked fine while trinitron colors were strangely off.
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place This content has been proxied by September (ba2dc).Proxy Information
text/gemini