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
After testing on steam deck instead of my ultrawide monitor that's curving in the opposite direction from CRTs, I reduced the curvature a bit since it looked weird, and also made the interlace shader blend frames even for 240p, so now annoying flickering in games shouldn't flicker nearly as much anymore. I'll prob tweak that further later on, since right now on 60hz it smooths it out too much, and on 100hz it's still a bit noticeable, but we'll see. Reduced flicker for NES as well, similarly by merging fields (well, enabled that option in the shader and adjusted it to merge 40%/60% instead of 50%/50%)
Maybe I can vary it based on the screen refresh rate? I can access that info via GdkMonitor, tho I don't know how consistent it will be across different screens...
And yeah, I switched to the trinitron colors for NES.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Finally tested everything on OP6/pmOS. A few of the shaders are buggy, will need to investigate that. Otherwise, DS and Saturn are slow, and ofc we don't have a core for Mega Drive - everything else runs fine.
Obv there are still no touch controls, but maybe now I'll have motivation to finish them.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Shaders are fixed now, and DS... Well, I tried melonDS, and its GL renderer easily runs at full speed. The catch is that it's still buggy ofc...
Software renderer is sluggish tho, much worse than DeSmuME's.
But with DeSmuME I'm not sure I can improve much, so now I have a hard choice:
fun
=> More informations about this toot | More toots from alice@mk.nyaa.place
And an obligatory recording
(and no, I don't suck at ninja gaiden and smw this badly :3 It's just hard to play it while looking at another phone's screen with camera on it)
=> More informations about this toot | More toots from alice@mk.nyaa.place
Spent some time designing touch controls. See, while I already had a prototype branch, that was, well, a prototype - notably, it didn't handle any of the "difficult" platforms, such as N64 or evn PlayStation. This time I'm trying to cover everything, tho I still need to finish Nintendo DS, Virtual Boy, WonderSwan and Atari Lynx.
All 4 are complicated - Lynx and WonderSwan have very weird and unique button layouts (esp the latter), while Nintendo DS obviously has 2 screens and is difficult because of that. Also because it has a screen gap, and some games need it so we cannot remove it.
I'm still unsure if I should expose things like Atari switches or SMS pause button - they are already in the header bar, so maybe not necessary? But also it is awkward in fullscreen and on keyboard/gamepad you have shortcuts unlike here.
Also probably need a button to open the gamepad menu.
And I still need landscape for everything, ofc.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Finished those - unfortunately I had to letterbox games but there isn't much I can do here , if not letterboxed they take basucally the entire phone screen height with no room for controls left.
One thing I can do to make things more authentic™ is to place WonderSwan a/b above the game when it's in portrait, but idk if it's a good idea so I didn't.
And now landscape ones: constrained space strikes again and makes DualShock layout a nightmare. It would be fine in fullscreen, but outside it? Yikes.
So I need to do one of the possible compromises:
Note that the landscape screenshots show PAL aspect ratios rather than NTSC. This is on purpose, as PAL games are wider and by designing for these I accommodate NTSC as well automatically - same as I accommodate PAL without any extra work by designing portrait layouts for NTSC
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
There were a few leftovers like switches for Atari 2600. Now it should be finished and I rearranged mockups to be more readable.
Now the only designs I need are:
I'm not making every platform for those, just enough that I can plan how it would work in general.
And then I need to figure out how to abstract all of this into something tractable.
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Ok, I tweaked the problematic layouts and made fullscreen versions too. I decided to do other compromises instead: reduce spacing and/or make it slightly overlap the game.
Also tried to take a stab at a larger screen design, but eh. There are multiple variants for what to do here and I don't have a tablet with a screen size like that. I do have my laptop ofc, but it has a significantly larger aspect ratio, so it doesn't work as a good reference for the general case.
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Fixed high resolution N64 games - e.g. Turok 2 was previously glitched since I set GLideN64 resolution to 320x240 as running every game in 640x480 would be meh. Now it only uses that resolution for compatible games, so it should be good. Dunno how I missed that.
Otherwise I'm thinking about the implementation for touch controls - there are multiple ways to proceed here. We could have automatic layout like: the top face button section contains 3 buttons in a row, or 4 buttons in a diamond etc.
Or, the overlay could be an svg...
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
I got sidetracked again, but on the plus side I made artifact colors on Atari 7800 work :3 (mostly - the hues are a bit wrong but it looks a lot closer to how it should look like now)
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Still idk what’s wrong with colors. It’s not just hues - specifically blue is wrong, it appears teal and it should be gray-ish. Everything else is how it should be, but not that color.
Also the artifact colors are a lot darker than they should be. That makes sense, it’s because the luma changes are supposed to be filtered out when it interprets the dithering as chroma but aren’t - but why would the color itself be wrong, no idea
=> More informations about this toot | More toots from alice@mk.nyaa.place
Well, gitlab is mostly down so I can't really work, so more Highscore progress instead.
First, I got sidetracked yet again and implemented color correction for Neo Geo Pocket Color. Previously the accurate filter was just showing the RGB source as is, which is not really what it should be. Like Game Boy Color, pre-backlight Game Boy Advance and DS Phat, it has muted colors and greenish blue - and games like this one use garish colors to compensate.
There's no existing shader for this, so I based it on non-backlit GBA correction, and tuned blue to be even greener, matching this recording: https://www.youtube.com/watch?v=LW6I9bOyzjQ
I think it turned out fairly well. One thing I'm not sure about is the big picture across platforms - for GBC and GBA I currently always do color correction - for GBC that's it, for GBA you can pick between original and backlit models which are both color-corrected and for DS you get DS Phat colors (color-corrected) vs DS Lite and newer colors (not color corrected). Here tho it instead color corrects when the accurate filter is on...
I'll also need color correctiojn for Game Gear, Lynx and WonderSwan Color. I have a hunch WonderSwan Color will have a similar screen too, while the other 2 will be more different since they are backlit. I may be wrong tho, need to do some research.
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
But I also made some progress on touch controls. I've been rewriting it using a combination of a metadata keyfile and an SVG for the actual controls, and finally got some results. They are not clickable yet, but each control is a separate widget, just like in the prototype.
=> More informations about this toot | More toots from alice@mk.nyaa.place
More progress, now I hooked up input and have working button and dpad controls with the new system, and redrew the placeholder layout to look less like a placeholder.
One open question is how to handle portrait/landscape with different layouts.
I also discovered Inkscape has a css editor, TIL
=> More informations about this toot | More toots from alice@mk.nyaa.place
Oh, I also have feedback on the controls, using the same kind of animation as in the gamepad layout view. So it's slowly coming together
=> More informations about this toot | More toots from alice@mk.nyaa.place
And now multiple layouts work - in particular, it works in portrait now (on phones; on larger screens not yet)
Landscape+non-fullscreen is scuffed, but at least it works. There will be platforms where this amount of controls will just not fit 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 a playtest. It's not as precise as I'd like, but I mean it's a touchscreen, not much you can do.
It also needs a few more things, like an A+B zone between the 2 buttons.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Tweaked layouts again after a bunch more playtesting - you can see the phone controls are a bit higher than before, and added tablet layouts (tho I fully expect them to see more changes). I also made hitboxes larger, and there's a shared area between A and B buttons now, for pressing both at once.
There are 3 more layouts: shorter phones (360x720 instead of 360x760), 16:10 tablets in portrait and a layout for really small window sizes with no controls
The entire thing is also more responsive now, e.g. the way game screen shifts makes more sense now
=> 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, now I'm happy with the overlays. Here are 2 phones with different screens and it runs fine on both... well, to a point. Phosh doesn't have a way to unfullscreen the app so you softlock it by fullscreening, and it also lags like hell in landscape for some reason. This is also using an older runtime as with the newer one GL doesn't work. However, on OP6 it runs well, and rn I only care about the layout.
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Added GBA and SNES controls as well.
I had to rework hitboxes on the face buttons to be round, and did a bit of polish in general.
The buttons on SNES are a bit smaller, otherwise they don't really fit (especially on the portrait tablet layout with select/start between dpad and buttons, not shown here)
The shoulder buttons on both SNES and GBA are as bad as you'd expect but this is probably not fixable.
Shoulder buttons on touchscreen are always scuffed no matter what, you're supposed to use fingers for them, not thumbs - while with touchscreen you use thumbs for everything. You can't hold a shoulder button with your index finger while pressing face buttons or dpad with thumbs, so e.g. GBA Metroid games are likely unplayable. But oh well, I mean it's bad even on keyboard - you really want a gamepad for games like that.
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Oh lmao, the camera "corrected" white balance because of the blueish tones in the second game
=> More informations about this toot | More toots from alice@mk.nyaa.place
2 more features for overlays:
The layout will need to be tweaked a lot (I mean I had a design for N64 which was completely different) but I wanted to try this one first just to check how it would work (answer - badly, the stick and A/B buttons are too low)
=> More informations about this toot | More toots from alice@mk.nyaa.place
Ok, it's in main now. It's still just GB, GBA, NES, SNES, N64 for now, but the infra is all there, I refactored it to allow things like stick<->dpad mapping and multiple touch controls for the same input, and there's a toggle now so that touch controls don't appear on desktop (can't autodetect it sadly)
I also tweaked N64 layout a bit since the last time. I kept the A/B button position, but stick and dpad are now swapped and Z button is now vertical so that the start button doesn't overlap the game - previously it was rather unfortunate as in Zelda games it was right over the map. There's now a tablet layout as well.
Anyway, other platforms are still missing but now it should be easier to iterate on it and add them one by one, instead of keeping everything in a single giant branch.
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Hm, so I implemented haptic feedback for touch controls, but it doesn't seem to be possible to implement the actual game rumble via libfeedback?.. I mean the entirety of feedbackd is structured around themes and named events, but here you need to simply play rumble with magnitude X and duration Y. Well, ideally strong/weak magnitude, but just magnitude is fine, just in general to differentiate stronger/weaker rumble. feedbackd does do that internally, but it's entirely private.
Even for input it more or less works by accident. The default theme only uses haptics for buttons, but there's no guarantee it won't turn into sounds instead (which would be unwanted here for rather obvious reasons). I currently set profile to quiet as well since the default theme actually does use sounds in the full profile, but ofc the daemon is allowed to ignore that too... So the app can only hope no one is doing weird things with themes :haggard:
I wonder if I should just copy parts of feedbackd in tree and use that instead - I mean that's basically what libmanette does for gamepads already. Tho also I see it uses udev for finding rumble devices, which won't really work in flatpak unless I hardcode those 3 specific devices that it supports
=> More informations about this toot | More toots from alice@mk.nyaa.place
And now SMS controls. I am planning to have matching dpads for every platform, yes ^^
Also wondering if I should arrange NES buttons in a line too - right now it's based on the dogbone controller if it wasn't obvious
Ah, and the reason this controller is special is that the pause button is not a part of the controller but is on the console. This is messy, but at least touch controls can now access this mess
I also experimented with an unfullscreen button, but I'm really not sure if there's any nice place for it... I may instead have some alternative way to bring up the header bar in fullscreen
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Today wasn't a particularly good day, but in those few hours where we actually had power I added overlay controls for a few more platforms: SG-1000, Game Gear, TurboGrafx-16, Neo Geo Pocket/Color
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Temporarily removed FM audio option for sega master system for now. As nice as it is, it doesn't work reliably at the moment, and I'd like not to ship broken features on day 1.
I'll report it upstream if I find a way to reproduce it there, and re-enable it once it's fixed. For now though - no.
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice is it tinting or replacing color?
=> More informations about this toot | More toots from efi@chitter.xyz
@efi@chitter.xyz it’s ntsc composite artifact colors. You can see what the input looks like in the first and third screenshot
=> More informations about this toot | More toots from alice@mk.nyaa.place
@efi@chitter.xyz so - neither, it’s interpreting luma as chroma and creating colors out of that
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice point me at the code and I'll double check the math
=> More informations about this toot | More toots from efi@chitter.xyz
@efi@chitter.xyz https://gitlab.gnome.org/World/highscore/-/tree/main/data/filters/ntsc?ref_type=heads
the problem is not the math ofc - either it doesn’t recreate some aspect of ntsc (like it doesn’t filter out chroma dots like a tv would, that’s why it’s too dark most likely), or just gets a specific aspect of atari 7800’s signal wrong - quite possible since it’s based on a generic shader that tried to emulate nes signal first and foremost
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice I thought you were emulating, not simulating brain asploded
=> More informations about this toot | More toots from efi@chitter.xyz
@efi@chitter.xyz i mean you can’t create a composite signal out of rgb picture - so unless you make the emulator itself output that (some do but it’s very rare and they usually can’t output rgb), that’s not possible
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice Damn neat
=> More informations about this toot | More toots from shalien@projetretro.io
@alice is there somewhere i can download a test flatpak or apkbuild for my OP6T with pmOS?
=> More informations about this toot | More toots from QuadRadical@wetdry.world
@QuadRadical@wetdry.world ci bundles, but
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice hmm have you built a .flatpak you can send over for a test? no pressure if not, ill wait for merge
=> More informations about this toot | More toots from QuadRadical@wetdry.world
@QuadRadical@wetdry.world ci builds them automatically, you can download it if you get past 503s
=> More informations about this toot | More toots from alice@mk.nyaa.place
@QuadRadical@wetdry.world also controls are only implemented for nes and game boy - i mean it is wip
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice On #phosh you should be able to swipe from top to bring up shell chrome and then either close the app or unfullscreen via OSK. (Seems the Phosh you're running is very old but it should already work in those versions).
=> More informations about this toot | More toots from agx@ruhr.social
@agx@ruhr.social unfullscreen via OSK?
Closing the app doesn't work if the app remembers the fullscreen state. I mean there's a reason we patched fullscreen out of ephy and evince back at the time
=> More informations about this toot | More toots from alice@mk.nyaa.place
@agx@ruhr.social in contrast, on gnome-shell edge swipe from the top unfullscreens the app instead - while it's bad as well as it means you can't show the header bar without unfullscreening, you can at least reliably exit it
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice as I said: you can bring up shell chrome and unfullscreen via OSK for the case where the app remembers the fullscreen state (still not ideal but making this an option on the apps thumbnail would be rather simple)
At least with the apps I use in fullscreen (e.g. epiphany) this works as expected (although epiphany now has a button nowadays)
=> More informations about this toot | More toots from agx@ruhr.social
@agx@ruhr.social sure, but the very fact I didn't know it was a thing shows fairly well that it's undiscoverable. Also I mean there's no reason to bring up OSK on this view. I also don't know how to bring up OSK in newer versions without finding an entry - in old versions there was an OSK button on the bottom bar, but not anymore
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice on newer versions hold the pill button and it wil bring osk
=> More informations about this toot | More toots from pan@seafoam.space
@pan@seafoam.space oh ok
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice phosh-tour explains how to bring up the OSK.
=> More informations about this toot | More toots from agx@ruhr.social
@agx@ruhr.social I didn't have that on pmos, but fair
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice which phone is that? It’s running gnome desktop?
=> More informations about this toot | More toots from umurgdk@mastodon.social
@umurgdk@mastodon.social oneplus 6
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice this one loooves haptic feedback :pleading_heart_eyes:
=> More informations about this toot | More toots from paulie@catcatnya.com
@paulie@catcatnya.com note that it works on like 3 devices and at least on op6 it’s not remotely as snappy as on, say, iphones/delta :neocat_pensive:
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice Feedbackd/libfeedback is around events making it simple to say "this happened" and not bother about what is delivered to the user (which varies across devices (diff. color LEDs, no haptic, etc)). It;s not meant to pass hw access to apps so it's not surprising it's not a perfect fit for games.
That said since we already pick up the haptic devices, adding something like browsers navigate.vibrate() would be rather simple (and was requested before). I thus added https://source.puri.sm/Librem5/feedbackd/-/issues/80
=> More informations about this toot | More toots from agx@ruhr.social
@alice Oh, and feedbackd supports way more than 3 devices for haptic. The comments in the udev rule just refer to the first devices these were added for.
=> More informations about this toot | More toots from agx@ruhr.social
@agx@ruhr.social that would help, thanks! It would be nice to have a way to know if it’s available ahead of time too, since I mean you can install feedbackd on desktop but obviously it can’t rumble then, so the app needs to know that to create a fallback (and it needs to know that ahead of time since there are multiple players and it needs an indicator for every rumble-less player, rearranging it later would be meh)
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice There's now a org.sigxcpu.org.Feedback.Haptic.Vibrate() API in #feedbackd similar to https://www.w3.org/TR/vibration/ .
busctl call --user org.sigxcpu.Feedback /org/sigxcpu/Feedback org.sigxcpu.Feedback.Haptic Vibrate 'sau' org.foo.app 7 250 1000 500 1000 750 1000 1000
[#]phosh #dbus #feedback
=> More informations about this toot | More toots from agx@ruhr.social
@alice these look amazing! omg
=> More informations about this toot | More toots from cas@treehouse.systems This content has been proxied by September (ba2dc).Proxy Information
text/gemini