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
I keep getting sidetracked. So, I discovered that reducing resolution like it would in an RF signal actually changes colors, making them closer to what they should be. This tower should be grey, not green. It also fixes vertical striping, another thing that shouldn't be there
This is probably the game I spent the most effort on in this entire project at this point :neocat_googly_woozy:
(not complaining tho because when it comes time to support another platform that uses artifact colors, it should just work)
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice@mk.nyaa.place This reminds me to subpixel antialiasing... but applied to CRTs out of sheer ignorance.
What I mean is that I don't think the authors were doing it on purpose, but as they coded the game on a CRT monitor, they already designed the graphics as they would look like with all the CRT artifacts on top, because that's how it looked for them.
=> More informations about this toot | More toots from cinnamon@mk.absturztau.be
@cinnamon@mk.absturztau.be no, they were. This game looks like this in RGB.
The reason this specific game does it is that it was initially developed for Atari XE in parallel with for 7800. Then the XE version got cancelled so only Atari 7800 one exists - but since it was developed for both it uses artifact colors anyway, as 7800 is perfectly capable of ouputting those just like XE
=> More informations about this toot | More toots from alice@mk.nyaa.place
@cinnamon@mk.absturztau.be to clarify: 7800 only outputs artifact colors in 320 mode - most licensed games use 160 mode so it doesn't happen there, and this is the only licensed game that extensively uses it because of what I said above.
There are other games where you can see artifacts but they don't do it on purpose, e.g. the HUD in Pole Position II - you can see in the RGB image it's finer than the rest of the screen, and you there's bloom around it in composite
This one is obviously not intentional, but tower toppler absolutely is
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
@cinnamon@mk.absturztau.be and to clarify further: these are not CRT artifacts, these are composite NTSC artifacts. This is an important distinction - there's nothing about CRTs that produces artifacting, not all systems do this (e.g. Mega Drive, even tho it has the same horizontal resolution in 320 mode, doesn't, it does have artifacting but it's a subtle rainbow effect instead - see screenshots and there are tons of games that do this, tho usually for shading and not transparency) and it's significantly more difficult to do this with PAL (tho still possible).
I have more examples of intentional composite fuckery:
SNES frequently does dithering as well in high res and pseudo high res modes (no artifacting - there is diagonal striping but it alternates every field as SNES averages artifacts out like that, same as NES).
Shinobi on Sega Master System turns dithered warehouse backgrounds into a weird roller effect. This one I actually can't fully reproduce - there should also be red discoloration which I don't have, see https://www.youtube.com/watch?v=qLWZoEgjNnU
Saturn also does dithering Mega Drive-style, tho it looks exactly the same so not very interesting.
PlayStation does dithering as well - it can display more colors at once, it's just slower to calculate them so lots of games resort to dithering
All of this is just due to composite, it comes through just as well on an LCD with composite input - CRT only adds visible scanline separation from displaying 240p without alternating fields, curvature and phosphor dots. This specific shader also adjusts colors a bit (you can see it's a bit bluer) tho I should go through platforms and turn that off for the ones wher the color is already adjusted.
What I don't handle well rn is PAL - there's very little info online about this kind of stuff on PAL systems, and the only available shaders does NES-style output (but unlike NTSC doesn't alternate artifacts between fields, so I don't even know if that's accurate), so fails on megadrive etc. Since there's so little info I don't dare to try and adjust it unlike with NTSC one, so for now it will have to remain inaccurate :neocat_pensive:
=> 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@mk.nyaa.place That's true... I always wondered why the Super Nintendo had horrible "stairs" in the color region borders (an artifact that for me deprecated a lot the appealing of such a wonderful machine), while the MegaDrive didn't, even being a machine technically worse.
(Talking about PAL versions here, having experienced both on CRTs first hand in the 90's. I still even have my SNES hanging around here)
=> More informations about this toot | More toots from cinnamon@mk.absturztau.be
@cinnamon@mk.absturztau.be do the stairs alternate on each field?
Because that's one thing I'm wondering about - on NTSC they do* and the reason they exist is to average out artifacts over time and make the picture sharper than on mega drive. See the video - I turned off the CRT filter here so it's just composite, and it's red text on blue background - the glitchiest possible combination, so the flickering is more visible
Meanwhile the PAL shader I'm using doesn't do that and it indeed looks rather ugly - and since it's hard to find stuff online I don't know if it's actually like that IRL or the shader just doesn't do it
=> More informations about this toot | More toots from alice@mk.nyaa.place
@cinnamon@mk.absturztau.be also same as on that video - except I blend fields together at 60%/40% ratio now, so the flicker is less visible - and ofc it's at 60 fps and not at 30 - for that video I specifically reduced it so people can see it clearly, there's a 60 fps video in a post above that one
RE: https://mk.nyaa.place/notes/a0jyjo1jzh1a1nav
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice@mk.nyaa.place I remember the artifacts to be even more marked, but my memory isn't very good and I don't have any CRT TV around anymore. If I had it, I could plug the SNES and try to record a video.
One thing I know: the screenshots on the game cardboard boxes were crystal clear (like the RGB based arcade machines), and my child self always wondered how they managed to capture them without artifacts. Probably from a custom development board with RGB output and a good screen.
=> More informations about this toot | More toots from cinnamon@mk.absturztau.be
@cinnamon@mk.absturztau.be well, as I said you don't need a CRT for this - try recording on an LCD. As long as it's composite, you get all the composite artifacts
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice@mk.nyaa.place Will try when back at home
=> More informations about this toot | More toots from cinnamon@mk.absturztau.be
@alice@mk.nyaa.place The effect I remembered isn't very visible on this flat screen TV. I think the signal capture process smooths the stair effect. It's more visible in areas that change.
=> More informations about this toot | More toots from cinnamon@mk.absturztau.be
@cinnamon@mk.absturztau.be yeah, idk if it's visible like that
do you have a capture card? One reason it's hard to see on camera is moiré effect from the LCD pixels :/
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice@mk.nyaa.place I don't have an analog TV capture card, only first generation TDT. Still, the reason why the effect isn't visible to the eye is because of how this specific TV processes the analogue image.
=> More informations about this toot | More toots from cinnamon@mk.absturztau.be
@cinnamon@mk.absturztau.be yep, I just can't even tell how it processes it because of moire
=> More informations about this toot | More toots from alice@mk.nyaa.place
text/geminiThis content has been proxied by September (ba2dc).