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
Neo Geo Pocket Color is a bit notable since it uses a digital thumbstick instead of a d-pad, so now I have an alternative d-pad appearance (read: press animation) that makes it behave as one
=> More informations about this toot | More toots from alice@mk.nyaa.place
I also redrew Master System d-pad and made NES overlay resemble the original controller rather than the dogbone one, with buttons in a horizontal line rather than slanted like on GB, and the d-pad looks a bit different
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
3 more platforms, out of which only 2 are playable on mobile: PlayStation, Sega Saturn, Mega Drive.
The latter is not playable since the emulator I'm using (BlastEm) doesn't support aarch64 and all the others are proprietary or incomplete (e.g. the one in MAME is just not very accurate)
It's still usable on x86_64 tablets tho, and I mean no reason not to have an overlay. I also made a 3-button version which is currently unused - I very much want to support it in future, but right now it's always 6 buttons even if the current game doesn't support it.
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
I now also have a WIP implementation on rumble on mobile, but it depends on a specific WIP change in feedbackd first. Once that lands, I'll land the Highscore change too.
(see https://mk.nyaa.place/notes/a1nxkpssf21a0cu4)
(watch with sound, you can hear rumble but not see it)
=> More informations about this toot | More toots from alice@mk.nyaa.place
Finally, I got sidetracked today playing Metroid: Zero Mission on OP6, and... it's surprisingly playable? Shoulder buttons are not great, I mean it's a touchscreen, but it is playable. So far I cleared Kraid, and at least up to that point it's perfectly fine, incl. Kraid battle itself.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Lots of progress today. By now it's mostly platforms that are weird and require special considerations, so I'll go in more detail here.
First, Atari Lynx. Lynx games can run in portrait and are fairly tall, so I needed a special overlay that's short and adds a padding to account for the notch.
Next, Nintendo DS. Same story because of 2 screens, and additionally the controls cannot overlap the screens in landscape as you have to be able to do the touch input. Also there's a mic button, and when not using vertical screen layout, a button to swap/rotate screens.
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
While I'm there, Famicom games have a mic button too now. This is all temporary, ideally I'd like to use the physical mic input, but for now it is what it is (GStreamer is scary)
(for those who don't know, unlike NES, Famicom has a mic in controller 2, instead of start and select buttons. Some games, like TLoZ, use it - you can shout into the mic to kill Pols Voices. For the US release, they made them weak to arrows instead but forgor to update the manual)
Next, Atari 2600.
This one is difficult because of all the console switches, and it comes in 3 versions because while the original controller only had one red button, games can actually use 2 with a Mega Drive controller. And then people came up with a way to use 3 on third party controllers.
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
And Atari 7800 as well! This one is less messy, tho it still has the console buttons/switches. I also based it off the european controller, not the horrible original one (same as SG-1000 is using Mark II controller (SJ-150) instead of SJ-100.
Also yes, Tower Toppler is using NTSC artifact colors, I actually do support those, tho I wasn't able to make the hues match exactly ^^
Finally, Virtual Boy. This was one of the platforms I had implemented in the old prototype branch, tho ofc this one was redone from scratch like everything else.
I swapped the right d-pad with the B and A buttons simply because those are more commonly used, so they are easier to reach.
So, that's it for today. At this point the only overlays left are:
For rotary controls I need to think how to present them in general, and WonderSwan is just weird.
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
And the last few overlays done. First, WonderSwan. This system is notorious for weird controls - I mean they aren't bad, but they are a nightmare to emulate since they don't map to either gamepads or keyboards. On a touchscreen, however, we can actually recreate them, even though they are still awkward. Especially on tablets - not shown but e.g. in landscape the Y buttons are still clustered below the screen so that they are easier to reach, which looks atrocious. But oh well.
=> 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 finally, rotary controls: Atari 2600 paddles and driving, as well as NES Arkanoid/Vaus controller. I still need to think how to even present these on a touchscreen in a good way, but for now an MVP - 2 buttons for turning in either direction. It's not great, but it works.
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
So, that's it for overlays. It's definitely not 100% done, there are sometimes criticals from missing widgets which I still need to investigate, and I need to verify that sideloading overlays works + write docs for that. But, now all of the games are playable on a touchscreen ^^
=> More informations about this toot | More toots from alice@mk.nyaa.place
A few more preferences, or rather they are a bit more flexible now. Load state on startup, video filter and frame blending are now both global and per-game, so you can override it for just one game if needed.
Meanwhile monochrome NGP and WonderSwan have matching snapshot thumbnails and screenshots now with accurate filter.
=> View attached media | View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
The feedbackd change for arbitrary rumble patterns has landed today, so I landed the highscore side as well - if you're playing a game that supports rumble on mobile. it can now use the phone's own rumble. This is tied to whatever player is using touchscreen; players using gamepads still get rumble on their respective gamepads while players using a keyboard don't get rumble, same as before.
Additionally, it's now possible to install firmware via drag-n-drop onto the firmware page in preferences. Not onto the library view yet - for that we'd need to be able to add games as well, and that gets complicated with multi-file games.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Implemented undo for remove from recent. Properly batched and everything.
Next will be move to trash - since the undo machinery is already there it shouldn't be too difficult
=> More informations about this toot | More toots from alice@mk.nyaa.place
the reason why the game is tinted magenta and then green is probably crt shader (which tints the game into magenta/green vertical stripes to simulate phosphor dots) + video compression, it does not look like that in person
=> More informations about this toot | More toots from alice@mk.nyaa.place
I managed to fix SMS artifacting: it's not perfect but it mostly matches how it should look like now.
The first screenshot is the new version, then how it was before, then RGB, and then the reference: https://www.youtube.com/watch?v=qLWZoEgjNnU, from http://nerdlypleasures.blogspot.com/2016/07/video-potpourri.html
SNES and PCE should also be a bit more accurate now.
Also implemented move to trash as well 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
This filter is such a rabbit hole ngl. Now I made 480i actually interlaced: no visible scanline separation, both fields are blended together with an offset. 240p is shown same as before.
Hopefully this won't be too horrible performance-wise
No recording as it got destroyed by video compression, so have screenshots instead.
While the "after" screenshot still has visible scanline separation, just more faint, it moves every frame so in practice looks more like slight jitter than anything else
Now I need to keep myself from diving into research of what consoles always output even/always odd field (e.g. NES) and which actually alternated it - scanlines should be more visible for some than others :neocat_googly_shocked:
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Meanwhile the FM audio issue in SMS turned out to be an upstream bug in Gearsystem and it's fixed now ^^
The maintainer is extremely responsive, I literally accidentally sent the bug report with only title filled in, and by the time I finished typing the actual body they already reproduced it ^^
So yeah, FM audio toggle is back, and it works reliably now.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Gearsystem upstream also added Light Phaser support, so we support it too now.
Unfortunately, they also broke savestate compatibility in process, and it crashes if you load an old one - same as earlier with FM sound. So that prompted me to version savestates. Now the old ones will be greyed out instead of crashing.
I'd prefer not to have that in the first place, but the app is not stable yet so I don't care that much.
Meanwhile, controls overlay is now accessible without the gamepad/keyboard menu. It's still there as well, of course.
=> More informations about this toot | More toots from alice@mk.nyaa.place
Ah, also I now parse the ROM header for SMS and GG as well. I just use the last 8 bytes as the ID - basically everything except the magic number. It's not fully unique, since e.g. early japanese Mark III games don't have the header altogether, but it's good enough for now. If it turns out to not be enough, we can add checksum to the mix later.
I'd like to parse headers for as many platforms as possible before the release - adding it later is a bit disruptive as you have to rescan the library, so having it immediately is nice as we can add a game database later if needed. Like here I needed it to only enable Light Phaser for games that support it.
=> More informations about this toot | More toots from alice@mk.nyaa.place
All cores specify their versions and commits now. It's not used for anything right now, so just displayed in the debug info in about dialog, as well as saved to snapshot metadata - what version was each snapshot saved with. Just in case we need to debug a bug with older savestates down the line.
Yes, I'm future proofing the app so I don't need to do invasive changes later.
=> More informations about this toot | More toots from alice@mk.nyaa.place
A few more input updates. First, I refactored the pointer input to route it through the same controller system as everything else, so it can now be shown in the input overlay.
Second, I now parse Mega Drive game headers (when they exist, anyway...) and with this only use the 6-button controller
when the game actually supports it.
Third, Famicom mic button is only available on Famicom games now, so tidying up input further.
Other than that, I fixed a bunch of input-related bugs, e.g. rotating screen while pressing touch controls doesn't result in input getting stuck anymore.
Also, snapshots store core version and commit now
=> View attached media | View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice Sorry, but any chance to have highscore in gnome-nightly?
=> More informations about this toot | More toots from vixalientoots@mas.to
@vixalientoots@mas.to it has to be in circle first. And for that it has to be released first
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice These filters always blow my mind, you're killing it.
=> More informations about this toot | More toots from SymTrkl@anarres.family
@SymTrkl@anarres.family to be clear: it is based on existing filters, I'm just trying to fix/improve them ^^
CRT one is actually fairly close to the original CRT-Cyclon, this is the only change I did; NTSC one had a lot more changes but still
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice Wonderswan!! I love mine its so fun, I really enjoy Angel Raising Project and Chaos Gear
=> More informations about this toot | More toots from thorn@avery.garden
@alice Never thought about in-game vibration being hooked up to a phone's vibration motor rather than just a controller, super cool. Wonder how this would work on Superstar Saga, since that gets rumble via the Game Boy Player. Maybe it would need a patch to allow it to be toggled anyway so it could work like the other games here.
=> More informations about this toot | More toots from DrewNaylor@mastodon.online
@DrewNaylor@mastodon.online probably no, but there's https://www.romhacking.net/hacks/6065/ - unless mGBA supports game boy player rumble - I don't know if it does
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice Since you mentioned it, I decided to check mGBA and it turns out it has an option to enable Game Boy Player features by default in the settings under Emulation (gba.forceGbp in the config file). Guess there's no need for rom hacks like the one here in this situation.
=> More informations about this toot | More toots from DrewNaylor@mastodon.online
@DrewNaylor@mastodon.online good to know! From highscore side i wonder if we can enable it automatically for those games
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice have you thought of using Ares for the mega drive emulation? I've used it for that it feels more stable for me than Blast 'em did on linux
=> More informations about this toot | More toots from Ackernym@mastodon.social
@Ackernym@mastodon.social I haven't, indeed seems nice on the first glance. They even have 32X code, huh (tho at least in stable I immediately found a bug)
That said, what version of BlastEm did you try? Because it's one of those projects that has had a stable release ages ago and it's buggier than the latest commit from main, same as e.g. melonDS
One thing I see that's not as good as in blastem is performance, tho ig that's to be expected. So yeah, I may try to port it to try it out (shouldn;'t be hard given I already have bsnes)
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice I wish I could remember, I tried it like...probably a year or two ago at this point! I had also just installed Linux on my computer as well and I think in all honesty that was probably the bigger issue than blastem itself lol
=> More informations about this toot | More toots from Ackernym@mastodon.social
@Ackernym@mastodon.social I mean nah, blastem's stable release is in a state where not so long the flathub build was crashing when you open a game
=> More informations about this toot | More toots from alice@mk.nyaa.place
@Ackernym@mastodon.social because yeah, I mean:
In other words, I'm not attached to BlastEm at all, and it is a pain to work with for quite a few reasons (e.g. the fact it's not using git so I have to mirror it myself), but it works fine here - but only recent commits, not stable
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice yeah I remember when I was on windows it worked alright, and then I switched to arch and then it crashed or didn't open for me, or something like that. Either way, I've been very pleased with Ares for Genesis/mega drive emulation, and in addition it's probably the easiest n64 emulator to set up too!
=> More informations about this toot | More toots from Ackernym@mastodon.social
@Ackernym@mastodon.social N64 whatever, I already have a well working Mupen64Plus port. The cleanest port I have by far too, as it's just a glue between mupen64plus-core, mupen64plus-rsp-hle and GLideN64, instead of a soft fork
=> More informations about this toot | More toots from alice@mk.nyaa.place
@Ackernym@mastodon.social tho I do have to ship a patch for gliden64 because https://github.com/gonetz/GLideN64/issues/2803 and the maintainer isn't responding
=> More informations about this toot | More toots from alice@mk.nyaa.place
@Ackernym@mastodon.social the only cores I'm not super pleased with rn are:
=> More informations about this toot | More toots from alice@mk.nyaa.place
@Ackernym@mastodon.social oh, melonds actually had a release recently, I need to rebase my port and try again.
desmume is another core that hasn't had release in years, so if melonds has one now that's good
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice ah yeahhh, I've found saturn emulation just entirely lacking, like mednafen is the only halfway decent one, but you'd think for as old as that system is there would be more options, but ehh.
=> More informations about this toot | More toots from Ackernym@mastodon.social
@Ackernym@mastodon.social kronos seems promising at a glance, but I haven't tried it so don't know how accurate it is nowadays
=> More informations about this toot | More toots from alice@mk.nyaa.place
@Ackernym@mastodon.social correction: I haven't tried it in detail - I did quickly test the libretro core so I know it is faster than mednafen (easily runs at full speed on my main pc), but there may very well be gotchas I'm not aware of
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice oh interesting! I've heard about Khronos but I didn't realize it had gotten better!
=> More informations about this toot | More toots from Ackernym@mastodon.social
@Ackernym@mastodon.social well, the thing is that I don't know how good it is - I'm not that invested into saturn library, so I don't know what to look for. sonic jam works, sega ages work, but beyond that - :shrugz:
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice and yeah honestly mupen64plus is a really good 64 emulator, I just prefer ares as an end user since it's non plugin-based, so it's comparatively easy for me to set up. That doesn't really apply though for Highscore since that's all already set up for the user though!
=> More informations about this toot | More toots from Ackernym@mastodon.social
@Ackernym@mastodon.social fwiw mupen libretro cores aren't plugin based either - well ok, they are but they just bake them all into the core and expose as an option. And well, ares is using existing rsp/rdp plugins (parallel), similarly just in tree. I don't know what (if anything) it's using for GL tho, parallel is vulkan-only, and that's why I'm stuck with gliden64 for now (I do want to switch later but no vulkan support atm)
=> More informations about this toot | More toots from alice@mk.nyaa.place This content has been proxied by September (ba2dc).Proxy Information
text/gemini
