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
@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 This content has been proxied by September (ba2dc).Proxy Information
text/gemini