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
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
nothing truly illustrates the Never The Same Color nature of NTSC better than artifact colors - it's nearly impossible to precisely reproduce these as they drastically change from even the tiniest adjustments
=> More informations about this toot | More toots from alice@mk.nyaa.place
And I got sidetracked again. This time on my quest to make games look as ugly as possible I added an option to disable CRT filter, so you get NTSC/PAL only - i.e. how the games would look like on an LCD screen.
And - a lot of tweaks again :neocat_woozy: I reenabled dot crawl for PSX since we're emulating composite, again improved the cursed warehouse rolling effect in SMS Shinobi, and made the result scale with linear horizontally and with AANN vertically instead of nearest - otherwise it gets pixelated when scaling
You may also notice the vertical red stripes between green panels now also match how they look like in https://www.youtube.com/watch?v=qLWZoEgjNnU so it is definitely getting better
Also updated cores, Gearsystem broke savestates again - specifically to add paddle support. I don't have that yet, but it should be straightforward to expose it, just not today.
Also rebased the Sega CD code, but BlastEm's Sega CD support is very unstable atm, so it's gonna remain in a limbo 😔
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
A few small fixes:
One day this will be perfect :3
=> View attached media | View attached media
=> More informations about this toot | More toots from alice@mk.nyaa.place
Been a while since the last update, but I was sick (kinda still am but eh). So, the app finally prompts to view controls when starting a game. I ended up going with a small notification popup in the corner rather than just opening the overlay. It also tells you which controller is used and it shows up again if it changes later
Thanks @xerz@fedi.xerz.one and @tromino@lovingcounty.cafe for the idea :3
I'll also need to have an option to remove these - if you know controls and don't want these to ever show up it would be nice to have. The problem is I have no idea how to call it. Controller/controls/input notifications/popups/hints/prompts? idk
=> More informations about this toot | More toots from alice@mk.nyaa.place
I also had to draw a whole bunch of icons for this (incl. 3 different lightguns :neocat_googly_woozy:), but it's fine ^^
=> More informations about this toot | More toots from alice@mk.nyaa.place
I reverse engineered the luma/chroma filters from the NTSC filter (the original shaders precomputes them for performance reasons (calling sin() 64 times for every pixel can get slow) but deosn't document where it got them). So, now I know what those functions are and can also tweak them.
Speaking of, did a few tweaks - the new functions are not an exact match of the old ones, and instead have a few improvements:
I also switched N64 to composite-like output, and fixed a fairly nasty bug caused by missing {} in an if statement...
=> 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 it makes me mad that this exists and I never got to experience it
=> More informations about this toot | More toots from efi@chitter.xyz
@efi@chitter.xyz tbh the game itself isn't that interesting - there are much better ports than the atari 7800 one
=> More informations about this toot | More toots from alice@mk.nyaa.place
@alice@mk.nyaa.place Have you ever looked at how the Apple II and other old computers "generated" colors using composite video? Actually outputting patterns that, when blended by the CRT, formed colors.
https://nicole.express/2024/phasing-in-and-out-of-existence.html (see section "The boundaries")
=> More informations about this toot | More toots from cinnamon@mk.absturztau.be
@cinnamon@mk.absturztau.be this is exactly what this is, yes
=> 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
@cinnamon@mk.absturztau.be same as @haeckerfelix@mastodon.social showed me a few photos of PAL PlayStation output on an LCD screen and it's hard to see
One thing I can see there is massive dot crawl, which I'm actually not seeing on your video
=> More informations about this toot | More toots from alice@mk.nyaa.place
@cinnamon@mk.absturztau.be here's how it looks like with the filter (but without CRT)
Second and third screenshots are NTSC, with artifacts alternating, PAL one is static
=> 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 I realized I actually have a tv capturer in disguise: an old DVD+VHS recorder with hdmi output (the last one on the shop back then), but when I tried to set it up I saw interferences tuning the SNES RF channel. They're probably caused by the legacy analog RF spectrum now being used for mobile phones in Spain. As a result, the image flickers horribly. In the end I only took another picture from the TV (a different one). When I tried to tune the console directly on the TV it didn't even detected the channel (0 analog channels found). The DVD at least did some effort to find it.
I'm attaching the picture. You can see colour staircases (a checkerboard), mostly noticeable in the black to red transition. I remember that they "moved" (alternated the checkerboard pattern) at every frame on a CRT. If they don't move now, it's because of the signal capturing technology.
=> More informations about this toot | More toots from cinnamon@mk.absturztau.be
@cinnamon@mk.absturztau.be ooh! Can you also record megadrive? This one does look quite similar to what the filter produces but that makes sense given it emulated ntsc signal. Still need to alternate artifacts between fields but it is rather close. Megadrive tho doesn’t do this and should look completely different
=> 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 This content has been proxied by September (ba2dc).Proxy Information
text/gemini
