[HN Gopher] Subpixel Snake [video]
___________________________________________________________________
Subpixel Snake [video]
Author : codetrotter
Score : 167 points
Date : 2025-01-24 17:21 UTC (5 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| mempko wrote:
| The color space portion was interesting. Learned something new!
| lukevp wrote:
| Very interesting! Learned a lot about color space and how it
| applies to subpixels, glad I watched this!
|
| Gameplay wise, I think it should be a bigger game board and there
| should be accounting for the speed of the snake through each
| subpixel (when traveling left to right, going from R to G is less
| horizontal movement than going from B to R, and traveling
| vertically, each step is massive compared to the horizontal
| movement.) This should be pretty easy to do by ratio'ing and
| changing the speed of each animation step based on where in the
| spectrum it is. That would make it feel a lot more polished I
| think.
| mrandish wrote:
| As an obsessive arcade retro-gamer who custom built a high-end
| emulation cabinet with a 27-inch quad-sync analog RGB CRT - I
| approve of this video! As soon as he described running into the
| green pixels problem, I knew he was going to learn something
| interesting. Sub-pixel structure, phosphor chromaticity, etc are
| such a fun rabbit hole to dive down. And it's still highly
| relevant in today's OLED, QLED, etc displays.
|
| Also, a tip for when you play classic arcade or console retro
| games from the 80s and 90s: they will look _much_ better (and be
| more authentic) if you play on a CRT - or, if playing via
| emulation, just turn on a CRT emulation pixel shader (CRT Royale
| is good). These pixels are art which the original devs and
| artists intentionally hand-crafted to use the way CRTs blend
| colors and scanlines anti-alias naturally. You deserve to see
| them as they were intended to be seen. Just look at what you 've
| been missing: https://i.redd.it/9fmozdvt6vya1.jpg
| gwbas1c wrote:
| I'm pretty sure those are similar, but different, images.
|
| Having grown up with CRTs, very few games look "better" on
| them; mostly games that used interlacing to create flashing
| effects. (Edit: Forgot that light guns need CRTs due to
| timing.)
|
| Otherwise, CRTs are like vinyl: Some people will invent all
| kinds of reasons why they are better, but in practice, they
| aren't.
| pdpi wrote:
| The argument isn't "CRTs are better". You're right -- they're
| not. The argument is that pixel art from that era was
| designed around the specific limitations of CRTs, and takes
| advantage of the specific way that CRTs would mess with the
| pixels.
|
| This is similar to what happened with electric guitars -- you
| can make cheap amps with barely any distortion these days,
| but that sucks horribly for playing music composed around the
| presence of distortion. E.g. amp distortion tends to add a
| bunch of harmonic content that makes major/minor triads sound
| pretty bad, which is why power chords are popular. On the
| other hand, power chords sound pretty terrible without
| distortion, because they need that extra harmonic content to
| sound good!
| mrandish wrote:
| I agree with you about vinyl but I think you're
| misunderstanding my point about CRTs. I'm not claiming CRTs
| are inherently "better" either technically or aesthetically.
| In general, they're not. I'm _not_ like some audiophiles who
| argue vinyl, tube amplification and "magic copper" cables
| are better - denying both signal theory (Nyquist et al) and
| objective data (double blind A/B/X tests). Modern digital
| formats and devices are almost always better overall. The
| cases where they aren't are rare, very specific and, even
| then, 'better-ness' is only in certain ways and not others.
|
| My background is in video engineering and the point I'm
| making here is very specific. It only applies to hand-crafted
| retro game pixel art created in the CRT era. And my point
| isn't even about CRTs! It's about how the RS-170A composite
| video standard that CRTs used encodes color. The "A" in
| RS-170A added color to the existing black and white
| television standard while remaining compatible with old B&W
| TVs. It was sort of a clever analog-era compression hack.
| I'll skip the technical details and history here (but both
| are fascinating) and simplify the takeaway. Broadly speaking,
| in digital representations of composite video color encoding,
| the correct color of a pixel can only be known relative to
| the current phase of the pixel clock and the pixels adjacent
| to it. Sometimes it's a fairly subtle difference but other
| times it can change a pixel from blue to red.
|
| To be clear, this wasn't "better" in any way (other than
| allowing optional color). The "hack" of encoding chroma
| information at half the frequency of luma and only in
| relation to a sub-carrier frequency came with trade-offs like
| chroma fringing on high frequency edges, ringing and other
| spurious artifacts. However, it was the only video we had and
| video game creators of the 80s & 90s used the tech they had
| to create the best images they could. For example, we would
| put a pixel of a certain color next to a pixel of another
| color to intentionally change the color of the second pixel
| (and NOT just due to blurring the two together, it literally
| decoded to a different third color). I did this myself in the
| 1980s, intentionally positioning a white pixel next to a
| black pixel on an even numbered column so they would show as
| a single red pixel on the screen. Using this encoding
| technique, I could display 9 different colors from a computer
| that only had two bits per pixel. That's why just displaying
| a naive RGB output of the game isn't properly decoding a
| signal that was hand-encoded to have more and different data
| than what's in the naive RGB.
|
| So I recommend using a CRT shader not because it emulates a
| glass tube with phosphors but because it includes the
| decoding logic to correctly display the original encoded
| content. Personally, I never use the shaders that add noise,
| blurring, cross-talk or other degradation. That would be as
| dumb as adding the pops and click of a dirty vinyl LP to a
| pristine signal. That would make it _less_ accurate. My goal
| as an engineer is to be more accurate. It 's fine if adding
| spurious crap tickles somebody's nostalgia bone from when
| they were a kid - but I'd never do that. I want to to see the
| original pixels and colors the artists saw and intended their
| audiences to see. That requires properly decoding the signal.
| And the example I posted demonstrates just how different an
| image can appear when properly decoded.
| crazygringo wrote:
| > _You deserve to see them as they were intended to be seen._
|
| I've never bought that argument, and I grew up playing games on
| CRT's.
|
| The reality is that different CRT's had wildly different
| characteristics in terms of sharpness, color, and other
| artifacts -- and it also varied tremendously depending on the
| type of video output/input. Were you hooked up to a TV? A cheap
| monitor? An expensive monitor?
|
| About the only thing you can say for sure is that CRT's were
| blurrier. And the comparison image you provide is completely
| misleading because the brightnesses are totally different,
| which suggests that the LCD/LED version isn't using correct
| gamma. If you used a random CRT her skin tone also had a good
| chance of turning greenish or whatever because that's just what
| CRT's did -- the color artifacts could be atrocious.
|
| I definitely appreciate wanting to blur the image in an
| emulator to remove the jaggies, and the retro CRT effects are a
| cool novelty. But I just don't buy the argument that it's "how
| the games were intended to be seen", because there was just way
| too much variation and the screen quality was so low. It's like
| only listening to music from the 90's on cheap speakers over
| the roar of the road because it's how the music was "intended
| to be heard". No it wasn't. It's just the best you had at the
| time.
| amiga386 wrote:
| > I just don't buy the argument that it's "how the games were
| intended to be seen"
|
| I do, though.
|
| At its most extreme, compare how this CGA imagery looks like
| on an NTSC television, with the crisp, clean signals that
| generated it. The demo makers here _absolutely_ intend you to
| see this via NTSC, it will look like complete trash if you
| don 't.
|
| https://int10h.org/blog/img/1k16_flowergirl_cga_1024_colors..
| ..
|
| (from https://int10h.org/blog/2015/04/cga-in-1024-colors-new-
| mode-...)
|
| This article gives you more examples:
| https://www.datagubbe.se/crt/
|
| And it links to this video with yet more examples: https://ww
| w.tiktok.com/@mylifeisanrpg/video/7164193246401383...
|
| There's no mistaking it. The artists on those 80s/90s games
| worked with the expectation of how it looked on display
| hardware of the time. The actual pixels, in complete
| precision on a vastly higher resolution display, look like
| shit. Or they look "retro".
| crazygringo wrote:
| Your first link is using weird color hacks that maybe could
| have worked on some specific hardware, but nothing like
| that was used on any average popular video game of the time
| as far as I know.
|
| So that's not an example of how regular video game artists
| were working, it's an example of how some (current-day?)
| demoscene people are trying to push specific vintage
| hardware to its limits.
|
| And like I said -- you can apply a blur filter (or basic
| interpolation) to get rid of jaggies, that's totally
| understandable. The pixels weren't meant to be sharp square
| blocks, just blobs of color. But a lot of these pages are
| showing how CRT's supposedly looked so much better are
| doing a lot of cherry-picking -- the reality was that they
| looked like blurry color-distorted wavy jittery messes just
| as often. There just wasn't any kind of consistency between
| dramatically different displays. Artists couldn't plan for
| some highly specific amount of horizontal smear to look
| "just right" because there was gigantic variance.
| amiga386 wrote:
| > a lot of these pages are showing how CRT's supposedly
| looked so much better
|
| That's shifting the goalposts. The question is whether
| old games were _intended to be seen_ on CRTs, or
| _intended to be seen_ on LCD screens created years later.
| There 's no question, they were _intended to be seen_ on
| CRTs.
|
| The pixels were placed by artists who looked at how they
| rendered on a CRT, and they'd change pixels here and
| there, do hand dithering, and play with the colour
| palette until they got what they wanted _on the CRT_.
| That was the canvas they painted with. The artists _didn
| 't have_ high-resolution LCD screens.
|
| And the thesis of all the things I linked were "the
| artists _intended_ you to see this on a CRT ". And yet,
| people playing games in emulators on modern high-res LCD
| screens have picked up this _unintended_ visual style and
| dubbed it "retro", and modern artists have created new
| art that was _intended_ be seen on LCD and look "retro"
| while doing so. They didn't even get a CRT to check how
| it looks on it.
|
| Two different sets of artists, with two different
| intents, separated by time and fashion.
| weinzierl wrote:
| _" The question is whether old games were intended to be
| seen on CRTs, or intended to be seen on LCD screens
| created years later."_
|
| I think the counter-argument is that they were intended
| to be seen on CRTs but the differences between CRTs were
| bigger than the difference between CRT and LCD.
|
| I don't know if this holds water but I think this is the
| point some try to make.
| wang_li wrote:
| I don't buy it either. Showing something that came out 30
| years after the time in question is not supportive of the
| argument. People wrote games and developed games and made
| game art on CRTs. They just developed on what they had. No
| one was sitting down and factoring in blur, scanlines,
| phosphor persistence, or etc.
| mrandish wrote:
| GP here. I don't want to repeat the lengthy technical
| explanation I already posted in another response downthread,
| so please refer to that:
| https://news.ycombinator.com/item?id=42817006
|
| > The reality is that different CRT's had wildly different
| characteristics in terms of sharpness, color, and other
| artifacts -- and it also varied tremendously depending on the
| type of video output/input.
|
| As a video engineer old enough to have started my career in
| the analog era, I fully agree composite video displayed on
| consumer TVs could vary wildly. I already explained the
| technical point about decoding the signal information
| properly in my other post but you're making a different point
| about variability, so I'll add that just because TVs could be
| mis-adjusted (or even broken) doesn't mean there's not a
| technically correct way to display the encoded image data.
| This is why we used color bars to calibrate TVs.
|
| > I definitely appreciate wanting to blur the image in an
| emulator to remove the jaggies
|
| But that's not my point, blur was an undesirable artifact of
| the composite video standard. 80s and 90s 2D pixel art was
| hand-crafted knowing that the blur would blend some colors
| together, minimize interlace artifacts and soften hard edges.
| However, I only use shaders that model a small amount of blur
| and I run my CRT in analog RGB instead of composite, which
| can be quite sharp. My goal is not nostalgia for the analog
| past or to degrade a game's output as much as my parent's
| shitty 1970s living room TV did. I had to engineer analog
| video in that past - and I hated it's shortcomings every day.
| When I play 80s and 90s video games, whether via shaders or
| on my analog RGB CRT, it probably looks quite a bit sharper
| and clearer than the original artists ever saw it - but
| that's not due to some subjective up-res or up-scaling - it's
| due to accurately decoding and displaying the original
| content to the technical standard it was created to comply
| with (even if many consumer TVs didn't live up to that
| standard). In the 90s I worked at a TV station and after
| hours we'd bring in consoles just to play them on the $3,000
| Sony BVM broadcast reference monitor. And they looked great!
| That's what I'm after. _Accurately_ reflecting the original
| artist 's intent in the maximum possible quality - without
| slipping over the line into editorializing colors or pixels
| that were never in the original data in the first place. I
| want to play the game as it would have looked back in the day
| on the best video output available, through the best cable
| available and on the best screen money could buy. And via
| emulation and shaders, now everyone can have that experience!
| playa1 wrote:
| I'm a fan of authentic retro hardware. That sounds like an
| awesome cabinet, I would love to spend hours and pockets full
| of quarters playing on it.
|
| This post caused me to go down a rabbit hole about CRT
| simulation.
|
| Looks like it is a thing.
|
| https://github.com/blurbusters/crt-beam-simulator
| mrandish wrote:
| > That sounds like an awesome cabinet
|
| Why, yes! Yes it is. :-)
|
| If it sounds good, you should consider one of your own. My
| goal was not the retro nostalgia of my recreating my parent's
| shitty 1970s living room TV but instead creating a cabinet
| that would allow me to explore these games each in their
| authentically correct resolution and frame rate and at the
| maximum quality and fidelity possible. That's why I chose an
| analog RGB monitor and the last, fastest GPU ever made with a
| native analog RGB signal path (R9 380X). I run a special
| version of the MAME emulator called GroovyMAME made just
| enable technically correct native display via analog signals
| on a CRT.
| http://forum.arcadecontrols.com/index.php/board,52.0.html
|
| I created this cabinet over ten years ago, before emulation
| pixel shaders were a thing. If you don't want to go to the
| effort, expense and time of acquiring and calibrating a high-
| end CRT, good pixel shaders can now get you >98% of the way
| there much easier and cheaper.
| Sohcahtoa82 wrote:
| The linked Subpixel Zoo article taught me that Pentile is still
| actually incredibly popular.
|
| My first Pentile screen was on my Motorola Droid 4 phone, and it
| was _awful_. Small text was often impossible to read depending on
| the color of the text and its background. The massive gaps
| between colors made solid red, green, or blue areas of the screen
| look like a checkerboard. It basically had a screen-door effect
| before VR became mainstream and made "screen-door effect" a
| household term.
|
| So it hit me as a surprise to know that Pentile is still popular
| and used today. I guess it's just gotten better? Smaller gaps
| between the subpixels? Maybe higher resolutions and pixel
| densities hide the weaknesses shown in my Droid 4?
| wffurr wrote:
| >> Maybe higher resolutions and pixel densities hide the
| weaknesses shown in my Droid 4?
|
| That's exactly it. Droid 4 resolution was low enough that the
| subpixel arrangement was clearly visible. Newer displays are
| dense enough that subpixels aren't visible at all.
| mdasen wrote:
| Early PenTile displays often had a different arrangement:
| https://en.wikipedia.org/wiki/PenTile_matrix_family#/media/F...
|
| You can see that it's Blue, Green, Red, Green on the
| horizontal/vertical axis so each red sub pixel is separated by
| two green and one blue sub pixels.
|
| Modern PenTile displays usually use a triangular layout:
| https://static1.xdaimages.com/wordpress/wp-content/uploads/w...
|
| I'm not an expert at text rendering, but it seems like you'd be
| able to get an RGB sub pixel combination a lot closer together
| with this triangular layout than the linear one.
|
| But also, the Droid 4 was simply lower resolution. Apple moved
| to 330 pixels per inch in 2010 and the Droid 4 was 275 PPI in
| 2012. So the Droid 4 was poor resolution even for its time and
| the PenTile layout would make it even worse by removing a third
| of the sub pixels.
|
| Today, the Galaxy S25 has 416 PPI and the iPhone 16 460 PPI so
| it is dramatically more pixels.
|
| Pixel density would have the largest impact, but I think that
| the triangular layout that modern displays use probably also
| helps. You talk about the screen door effect and I feel like
| the triangular layout wouldn't have as much of that issue (but
| I'm not an expert on sub pixel rendering).
| bawolff wrote:
| For the zooming out to make the css pixel = real pixel, i wonder
| if you could just use units like 0.25px instead. Or maybe divide
| by window.devicePixelRatio in js to make it dynamic.
| FriedPickles wrote:
| If you're as dumb as me and try to actually play this, note that
| the "Snake speed" value is inverted.
| hatthew wrote:
| the speed is ms per frame
| grayhatter wrote:
| ms/frame isn't a speed... it's a delay? maybe a rate?
| hatthew wrote:
| Yeah frames per second probably would have made more sense.
| That being said, I think it's fine to colloquially refer to
| time/distance as speed, e.g. my walking speed is 15 minutes
| per mile, but it should probably be specified that that's
| the unit in use. But also this isn't a carefully designed
| game, it's a small tech demo, so -\\_(tsu)_/-
| kiru_io wrote:
| Thank you for this video. Love the style, introduction to color
| space and the practial use.
| tantalor wrote:
| The snake moves weird because the subpixels aren't square.
|
| I would increase the snake's horizontal speed (per subpixel)
| relative to vertical, so speed in either direction is the same
| from the user's perspective in the actual viewport.
| yuvalr1 wrote:
| This great video goes into a bit more detail about pixels. It
| also shows that there is an interesting difference with the color
| green not only in monitors, but also in camera sensors that
| detect the color:
|
| https://youtu.be/PMIPC78Ybts?list=PLplnkTzzqsZTfYh4UbhLGpI5k...
|
| I can recommend it, and all the other videos of Cem Yuksel. He is
| really great at presenting!
| htk wrote:
| Who's old enough to remember the joys of tweaking ClearType on
| Windows XP?
|
| It was a great workaround for rendering smoother text on low dpi
| LCD displays.
| blibble wrote:
| qbasic nibbles did the same using the ansi box drawing characters
|
| there was a text character with half the vertical "cell" in use
|
| this, along with clever use of foreground/background colours
| allowed double the vertical resolution (in text mode!)
___________________________________________________________________
(page generated 2025-01-24 23:00 UTC)