frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

Open in hackernews

Superauthenticity: Computer Game Aspect Ratios

https://datadrivengamer.blogspot.com/2025/05/superauthenticity-computer-game-aspect.html
31•msephton•4d ago

Comments

msephton•4d ago
Personally I think Bruce Lee is a cool looking game. Like a playable diorama.

And with Macintosh web though the CRT was about 8.5" x 6.25" (1.36:1) the recommended active area (according to period repair guides) was 7.11" x 4.75", so yeah, pretty much exactly 1.5:1.

msephton•4d ago
* typo: even though

Oh, and the Macintosh active area was sized such that the dpi would be 72dpi and so WYSIWYG compared to PostScript point size and thus 1:1 print output (of course, eventually higher resolution printers arrived).

Firehawke•1d ago
Problem with this theory is that it's not taking into account what the artists were designing their art to be. Not every circle is meant to be a proper circle in the end-- sometimes there's a mix of PAR (Pixel Aspect Ratio) art and 4:3 in the same SCENE much less the same game: For instance, Chrono Trigger has mostly 4:3 artwork, but the moon seen behind Magus's Tower is actually 8:7 PAR.

I'd argue that in the end the whole game was meant to be seen by players on a 4:3 display, and thus 4:3 is "always" the correct answer for NES/SNES.. but your mileage may vary considerably.

I think the one thing I CAN have a hardline stance on is that stretching out 4:3 to 16:9 completely and absolutely distorts the intended look of the4 game and is ill-advised.

That said, there's one fly in the ointment. Systems like the TRS-80 Color Computer had a massive block of overscan that's visible by default on all displays. How MUCH of that overscan is visible depends on the display you're using (different TV plus different H/V size knob settings) and so actually working out what the correct display is and should be.. is a LOT harder and will vary a lot across different software on the same system. I'm not sure that just picking an aspect ratio per-game is correct; most users didn't exactly go and recalibrate their TV for each game they were playing, they'd pick a good baseline and live with it unless something was offscreen and thus required adjustment.

shmeeed•1d ago
Sadly, Firefox on Android in portrait squashes all the example pictures, rendering the page pretty useless. :(
mkesper•1d ago
To me it looks like square pixels amount to what the artists intended their work to look like. Come on, how do you imagine settler's wagons to look like? The moons? Also the grass with crt-royale looks absolutely rubbish to me.
arexxbifs•1d ago
One problem is that we've become so conditioned to seeing some of those iconic games with square pixels (because of emulators and screenshots) that the original aspect ratios look unfamiliar.

This is true also for most Amiga NTSC and DOS VGA games (both 320x200 on 4:3), such as Monkey Island. Here's an interview with Amiga artist Jim Sachs where he laments the lack of 4:3 aspect ratio when his works are displayed on modern machines: https://www.amigalove.com/viewtopic.php?t=1618

Some artists may of course have adjusted their screens in order to get square pixels, but I think the safe assumption is that they wanted to fill the typical default viewing area with graphics, since most users didn't (or, in the case of many cheap old TV sets, couldn't) adjust their screens.

egypturnash•1d ago
Gridrunner: Grid cells should be square. It's the law. Verdict: Square pixels.

Jeff Minter has done a few remakes of this game over the years. One of the more recent ones (1) includes direct ports of the Vic20 and C64 versions as an option. They are very emphatically not using square pixels.

1: Minotaur Arcade vol 1, https://store.steampowered.com/app/906110/Minotaur_Arcade_Vo... - sadly there’s no photos of the retro modes in the Steam page.

kookamamie•1d ago
(in ancient systems)
nottorp•1d ago
Funny, on mobile safari the site squeezes all screenshots horizontally so they still fit 3 per line. Any impression of the aspect ratio is gone unless you open them one at a time.
ack_complete•1d ago
Not to dismiss the thought that's been put into this, but the aspect ratio of the image (display aspect ratio) is almost always the wrong way to approach this. Retro computers typically have a limited number of dot clocks and video timings compared to the frame sizes that they can support. The Atari 8-bit, for example, supports only a single pair of horizontal and vertical refresh timings, but is very flexible regarding how wide and tall the display is. If you try to estimate aspect ratios based on the image area, you'll get lots of variance because many games deviate from the 320x192 area that the operating system uses.

On top of that, it's a mistake to assume that the original images had squares. With a small number of pixels per tile and both an aesthetic and efficiency requirement for the tiles to be uniform, it's highly likely that what look like squares actually weren't -- they could only get so close with the available resolution. I see a lot of people try to guess aspect ratios based on what they think the art was intended to look like, and on multiple occasions have had to boot games on original hardware and contemporary displays to prove that, no, what looked like a circle was actually slightly elliptical.

The correct way to approach this is by starting from the pixel dot clock and video timings to determine pixel aspect ratio and work backward to display aspect ratio. This also reveals another typical sign that aspect ratios are being determined wrong -- when significantly different pixel aspect ratios are determined for multiple systems that all supported NTSC artifacting colors, like the Apple II and the Atari. Supporting NTSC artifacting means NTSC-compatible timings and a dot clock that is an integer multiple of the color subcarrier, which means similar pixel aspect ratios.

LocalH•21h ago
DAR is perfectly fine to use, as long as the entire image (including any borders) is included in the calculations. Thus, all images from the same system should end up with the same scaling factor.
ack_complete•19h ago
You can, but it's not a useful basis for comparison. The full pixel display area including borders for an Atari 8-bit system is 352x240. The 22:15 ratio that comes out of this is not generally useful, because most displays do not show this full area, nor can it be compared to broadcast specifications to determine how it will be nominally displayed. It certainly is not comparable to the 4:3 ratio that is frequently used to try to fit retro system displays.

The pixel aspect ratio is not affected by how large the active display region is. Displays can't even detect the border if the border is at blanking level black as older systems tend to do. It's determined by the horizontal/vertical timings and the pixel clock. Those can be compared to the specifications for NTSC/PAL square pixels to calculate the resulting display size and aspect ratio on a standard-tuned display for a given image pixel size.

Firehawke•18h ago
Right. You're not going to use V-size and H-size to remove the borders because that screws with literally every other use of the TV (other computers, TV shows, etc)..

About the only way to properly calibrate what the borders "should" be is to calibrate the TV to what would be a reasonable approximation for SD TV signals, and POSSIBLY make small adjustments after that point if the computer looks wrong.

Even then, every TV is going to be somewhat different and so there's a huge amount of variance on how it's going to look in the end. Same applies for computer monitors back then, though calibration of an RGB monitor is going to be even harder than composite since you can't easily run a VCR over it to try to get SD TV calibration.

LocalH•21h ago
One thing I see in this article is a very common blunder in dealing with images from these types of retro systems - non-integer vertical scaling. For accurate reproduction of these types of CRT raster images from an aspect ratio perspective, integer vertical scaling should always be done, followed by interpolated horizontal scaling to reach the correct aspect ratio.

Why? The original display method never blended across scanlines (except in the PAL world, where chroma only would blend across two otherwise discrete scanlines), but the analog nature of the scanning process provided a natural horizontal blending.

leguminous•19h ago
Some amount of vertical blending often occurred because scanlines tapered off in brightness, bleeding into the next scanline. For example, if the electron beam spot has a two dimensional gaussian profile, then the vertical profile of a scanline at a constant value will also be gaussian. If the height of the scanline (full width at half maximum of the gaussian) is around 1x the distance between scanline centers (a reasonable value at full brightness), then there will be significant overlap between neighboring scanlines. The point between the scanline centers will be a blend of them both.

How much blending there is depends on the brightness at that particular area (brighter parts of the image will have wider scanlines and more blending) and the characteristics and configuration of the particular TV.

If I wanted sharp pixels, I would use something like the pixel-art-scaling shaders in Retroarch. I like bandlimit-pixel and pixel-aa, but most of them look pretty similar. They basically try to antialias the pixel edges. I prefer to fill the screen as much as I can using the correct aspect ratio and not worry about integer scaling.

For more realistic blending, CRT shaders are pretty good now.

LocalH•18h ago
That depends on the size of the CRT. Signal-wise, there is never blending between scanlines (except for PAL chroma blending), only the natural blending of the image within each scanline as the voltage rises and lowers.

Show HN: AI Peer Reviewer – Multiagent System for Scientific Manuscript Analysis

https://github.com/robertjakob/rigorous
25•rjakob•1h ago•12 comments

Beware of Fast-Math

https://simonbyrne.github.io/notes/fastmath/
198•blobcode•8h ago•101 comments

The Two Ideals of Fields

https://susam.net/two-ideals-of-fields.html
9•susam•1h ago•3 comments

AtomVM, the Erlang virtual machine for IoT devices

https://www.atomvm.net/
54•ahamez•3d ago•16 comments

Precision Clock Mk IV

https://mitxela.com/projects/precision_clock_mk_iv
7•ahlCVA•8m ago•0 comments

Photos taken inside musical instruments

https://www.dpreview.com/photography/5400934096/probe-lenses-and-focus-stacking-the-secrets-to-incredible-photos-taken-inside-instruments
782•worik•18h ago•39 comments

Acclimation of Osmoregulatory Function in Salmon

https://www.unm.edu/~toolson/salmon_osmoregulation.html
5•mooreds•40m ago•0 comments

Show HN: I built an AI agent that turns ROS 2's turtlesim into a digital artist

https://github.com/Yutarop/turtlesim_agent
13•ponta17•4h ago•3 comments

Webb telescope helps refines Hubble constant, suggesting resolution rate debate

https://phys.org/news/2025-05-webb-telescope-refines-hubble-constant.html
48•pseudolus•3d ago•16 comments

Gradients Are the New Intervals

https://www.mattkeeter.com/blog/2025-05-14-gradients/
81•surprisetalk•8h ago•16 comments

The Book of Secret Knowledge

https://github.com/trimstray/the-book-of-secret-knowledge
51•AnotherDev415•6h ago•1 comments

Using lots of little tools to aggressively reject the bots

https://lambdacreate.com/posts/68
59•archargelod•7h ago•24 comments

Surprisingly fast AI-generated kernels we didn't mean to publish yet

https://crfm.stanford.edu/2025/05/28/fast-kernels.html
321•mfiguiere•19h ago•109 comments

Show HN: Fontofweb – Discover Fonts Used on a Website or Websites Using Font(s)

https://fontofweb.com
12•sim04ful•53m ago•3 comments

Simpler Backoff

https://commaok.xyz/post/simple-backoff/
95•todsacerdoti•10h ago•32 comments

The ‘white-collar bloodbath’ is all part of the AI hype machine

https://www.cnn.com/2025/05/30/business/anthropic-amodei-ai-jobs-nightcap
505•lwo32k•1d ago•875 comments

Beating Google's kernelCTF PoW using AVX512

https://anemato.de/blog/kctf-vdf
299•anematode•22h ago•89 comments

C++ to Rust Phrasebook

https://cel.cs.brown.edu/crp/
126•wcrichton•16h ago•26 comments

Pure vs. Impure Iterators in Go

https://jub0bs.com/posts/2025-05-29-pure-vs-impure-iterators-in-go/
4•ingve•2d ago•5 comments

AccessOwl (YC S22) is hiring an AI TypeScript Engineer to connect 100s of SaaS

https://www.ycombinator.com/companies/accessowl/jobs/hfWAhVp-ai-enabled-senior-software-engineer-typescript-focus
1•mathiasn•8h ago

Show HN: Icepi Zero – The FPGA Raspberry Pi Zero Equivalent

https://github.com/cheyao/icepi-zero
193•Cyao•3d ago•45 comments

Web dev is still fun if you want it to be

https://github.com/jchester/bobotw
40•jacques_chester•8h ago•21 comments

Ask HN: Anyone making a living from a paid API?

13•meander_water•51m ago•0 comments

The Trackers and SDKs in ChatGPT, Claude, Grok and Perplexity

https://jamesoclaire.com/2025/05/31/the-trackers-and-sdks-in-chatgpt-claude-grok-and-perplexity/
28•ddxv•6h ago•1 comments

Microsandbox: Virtual Machines that feel and perform like containers

https://github.com/microsandbox/microsandbox
330•makeboss•1d ago•156 comments

Revenge of the Chickenized Reverse-Centaurs

https://pluralistic.net/2022/04/17/revenge-of-the-chickenized-reverse-centaurs/
134•GreenWatermelon•2d ago•64 comments

The Illusion of Causality in Charts

https://filwd.substack.com/p/the-illusion-of-causality-in-charts
14•skadamat•2d ago•4 comments

Reverse engineering of Linear's sync engine

https://github.com/wzhudev/reverse-linear-sync-engine
126•flashblaze•2d ago•23 comments

Systems Correctness Practices at Amazon Web Services

https://cacm.acm.org/practice/systems-correctness-practices-at-amazon-web-services/
345•tanelpoder•1d ago•127 comments

Randomness Requirements for Security (2005)

https://datatracker.ietf.org/doc/html/rfc4086
21•mooreds•2d ago•3 comments