- I remember an "interview with an ffmpeg enthusiast" which hit incredibly close to home with me. :-D
- The title had me hoping to meet the inventor of "love spreadsheets"... a tool that a certain coworker of mine would probably use for courtship maintenance.
Anyone ever try Dan Bricklin's Demo Program? That was his next venture post-VisiCalc, apparently a PC utility for designing text-mode screen mockups and workflows, and making them into product demos. Magazines were crammed with adverts for it for a while, but I don't know if it ever went anywhere.
- I suppose it can be crawled like any other website, since it's a collection of links - manx-docs doesn't host any of the manuals.
As such it can be bitten by the usual link rot problem, but at least it has multiple links for each entry, which should minimize that. Where no digitized copies are known to exist, the entry is listed without links - but that's still a good thing to have, for those with the means to do something about it.
- I'd say that a correct aspect ratio is part of the baseline for authenticity - nothing 'super' about it. But we clearly live in a world where most people don't see a dang thing wrong with 4:3 content smeared all the way across their widescreen TVs, so admittedly I'm the odd man out. :)
A better approach would be to derive the ratio from known signal timings, and from comparisons to actual monitor output (or photos of such) where applicable, rather than subjective judgment calls about how particular games look... but any attention being paid to this stuff at all is a good thing.
What more people need to be aware of is how to properly aspect-correct their retro gaming video footage for uploading and streaming...
- The output isn't the whole story, though. For instance, with Spy vs. Spy the graphics were made on one system and then ported to another system with no regard of the aspect ratio of the port. So it can definitely be that the video output of the system should be 4:3, but the game itself should actually be viewed in a different ratio specific to that title.
Also, this article doesn't go into it, but there is a problem taking screenshots and video recordings of games from emulators because they don't usually embed the aspect ratio into the media file. So when they files are viewed on the Web they look wrong. I did some tests with this recently -- YouTube supports AR metadata. More tests here: https://bsky.app/profile/pekkavaa.bsky.social/post/3lbyzru2e...
- You could make the argument that if the port was originally released that way, then it's 'authentic' enough to emulate it the same way on that particular target system. But yep, I can see why the squashed and stretched graphics would bother people, even if they match the experience on the actual hardware. The thing is, it's a bit of a slippery slope, because sooner or later you come across a case where some of the art was made on system A, and some on system B (with a different aspect ratio) to tweak or flesh out the port, or whatever. So some circles turn out perfectly round, while others are ellipsoid... and then whatcha gonna do? :) (IIRC the first Star Control suffers from this, although I could be thinking of something else here.)
100% agreed on the screenshot/video issue; that's kinda what I meant at the end of my last post. I've also discovered that Youtube respects PAR/DAR metadata, but I find it more useful to actually scale the video myself before uploading, by appropriate X/Y factors. That lets you sidestep the issues you commonly get when you leave the scaling to the YT backend/frontend, like blur and incorrect gamma... (and if your source is RGB, it's also a good idea do the YUV conversion yourself while you're at it.)
- Yore ain't a bad place to be. (Bon Scott impression optional)
- But that passage doesn't refer to the original Mac. It describes notions that started becoming commonplace around 2000, and the end of that paragraph specifically differentiates them from the Mac Classic era.
About the argument in general, the false premise would be that the set of things which "actually matter" applies universally. It's not a question of what exactly matters, but _to whom_. There are different types of users, and the pretense of always knowing what's good for all of them better than those users themselves is certainly not unique to one person's approach... even if Jobs' personality could make it appear as if he had it worse than most others in the industry.
- I get more Amiga-ish vibes from it, but maybe that's just the default look of the text and system icons, with their 1:2 pixel aspect.
It's not clear why the system charset and icons didn't receive higher resolution updates when 640x480 became available. It sure is weird seeing them sharing the same UI widgets with modern-looking, anti-aliased fonts... at first glance I thought the screenshots were edited(!)
- ooh, missed this submission... but I should point out that the author has made a bunch more very informative articles on the subject:
- IBM PC Technical Reference Character Set (00-FF) Quick Reference (Code Page 437): https://MW.Rat.bz/ibmpctr
- IBM PC MDA ROM Font Character Table (Code Page 437): https://MW.Rat.bz/mdarom
- The IBM PC Character Set Confusion Clarified (Code Page 437): https://MW.Rat.bz/confusion
- IBM PC Code Page 437 to Unicode Mapping Table: https://MW.Rat.bz/cp437map
- That sounds like a very relevant clue - interesting!
Maybe you're thinking of DisplayWrite? See the second screenshot at https://www.dosdays.co.uk/topics/Software/ibm_displaywrite.p...
- AKA the one where IBM mentions the unsupported "160 PELs by 100 rows" low-resolution mode, but gives only a vague hint about actually setting it up... and even that is wrong! ("requires special programming and is set up as the 40 by 25 alphanumeric mode.")
Smooth move, but the real details cropped up in magazines and BBS writeups a couple years later.
- Like we know it can do it, but we can't actually tell you, because some manager pissed in the feature set and it would annoy them greatly...
Probably not, but it seems like maybe?
- I guess the most mundane explanation is that proper 'BIOS support' for this mode would have been too complicated. It's character based, so you'd need to write all-new versions of those BIOS graphics routines for setting pixels and printing text - not to mention the BASIC stuff for lines, ellipses, and flood fills. That could well have exhausted the allotted ROM space, but you'd also have to "snow-proof" those routines, what with the CGA RAM bandwidth issue in 80 column mode... which would've made them even slower than the original versions, if you can imagine that!
In hindsight of course, the BIOS functions didn't matter when you wanted any sort of performance, regardless of the video mode. But IBM will be IBM.
- More
Patch added to support sanm codec31/c332 decoding as used on the Sega-CD release of Rebel Assault 1 from 1993.
FFmpeg aims to play every video file ever made. —-
https://x.com/ffmpeg/status/1931128047358578954?s=61&t=t...