HyperCardの父、ビル・アトキンソン氏が死去
引用元：https://news.ycombinator.com/item?id=44210606
もしも別の世界線なら、HyperCardはもっと発展して、Webを取り込み、誰もがアプリを作れるツールになってたかもね。
ユーザーが粘土をこねるみたいに、自分だけの完璧なアプリを作れる。Jobsが言った”自転車”みたいにね。
アトキンソン氏が目指したのはきっとこっちの世界線だろうな。そういう世界に生きたかったよ。
本当に偉大な先見の明がある人を失ったね。安らかに眠れ！
皮肉なことに、HyperCardに続くようなグラフィカルなプログラミング環境って、たぶんFlashだったんだよね。
そしてFlashもやっぱり消えちゃった。
今、Web向けに汎用アプリを作るのに、こういう系のツールって何がベストなんだろう？（いわゆるvibecoding以外でね）
WebはHyperCardにかなり影響を受けてるんだ。
Tim Berners-Leeのオリジナルの試作品では、Webは双方向で、ブラウザと一緒にハイパーテキストエディタも付いてくる予定だった。
そういう意味では、HyperCardは今も生きてて、現代インターネットの基盤になってるんだよ。
今日、HyperCardみたいなツールを求める気持ちがあるのはわかるけど、HyperCardがどれだけ影響力があったかは測り知れないな。
ここにいる僕らの多くがHyperCardを体験してる。それが後の活動の種になったんだ。
小学校のPC授業でみんなでHyperCardを使ったのを覚えてるよ。
80年代、90年代にそういう授業をやった教室の数だけ、多くの頭脳が影響を受けたんだ。
後継が出なかったとしても、HyperCard自体が成功だったと評価できると思うよ。
それならDecker（https://internet-janitor.itch.io/decker）だと思うな。
僕のプロジェクトじゃないけど、HyperCardの後継を探してた時に見つけたんだ。
すごいのは、これブラウザで動くんだよ。
アトキンソン氏の功績は今も生きてて続いてるんだ。
現代向けにアップデートされて、クロスプラットフォームで、昔のHyperCardスタックとも互換性がある！
たしかHyperCard→Metacard→Runtime Revolution→Livecodeって流れだったかな。
https://livecode.com
僕が子供の頃にこの流れが始まって、兄のTuviah Snyder（今Appleにいる）がMetacardやRuntime Revolutionで多くのアップデートを担当してたんだ。
僕もHyperCard互換のスタックで最初のプログラムをいくつか書いたよ。
download.comに自分のアプリが載った時は楽しかったな、当時は意味があったよね :)
コードが冗長だからpleaseとかthank youが必要だっていつも冗談言ってたけど、超シンプルで分かりやすくて、ちゃんと動いたんだ！
今でも昔のHyperCardスタックをWebやモバイルで動かせたり、現代版vibecodingみたいな感覚で新しいものを作れたりするなんて、いいね。
DeckerはHyperCardの話が出るたびに結構話題になるけど…誰もこれで何かやってるの見たことないな。
Livecodeを使うより、あるいはHypernext Studioより、Deckerを使う理由はなんだろう？（Livecodeのライセンスは別としてね）
記憶が正しければ、クリックできるものにマウスカーソルが手形に変わるUIはHyperCardが最初だったと思うんだ。
あと、Brendan EichがJavaScriptを作った時、HyperTalkの影響をかなり受けてた気がするな。
Livecodeって、なんか全然違うものに見えるんだけど？
スタンドアロンアプリ開発のための普通のツールキットとかSDKみたいだね。
それはそれで、使ってる数人の開発者には素晴らしいのかもしれないけど、ユーザーがコンピューターとの関わり方を変えるようなものでは絶対ないよね。
なんかFileMakerとかMS Accessでも、そういう時代があったよね。プログラマーじゃなくても、あのアプリで結構すごいもの作れたんだ。なんで主流にならなかったかっていうと、データを共有する方法が良くなかったからだと思うんだ。データベースサーバーにアクセスする方法もあったけど、設定がめちゃくちゃ難しくて、結局ローカルのシングルユーザープログラムに限られちゃってたんだよね。
HTML、CSS、PHP、MySQLは覚えるのが大変だったけど、これでmulti-user programが簡単に作れたんだ。だからWebが勝ったんだと思うよ。
いや、ベースは全く同じだよ。ホームページをスクロールしてみてよ、Livecode（アップデートされたHyperTalk）の例が見れるから。昔のHyperCardスタックとかMetaCardスタック、Runtime＼Livecodeスタックを、LivecodeのIDEで開いて、コード書いて、編集とかできるんだ。HyperCardの頃と似てるけど、modernな機能やアップデートが加わってるよ。
HyperTalkとの互換性があるし、今の言語はHyperTalk（つまりアップデートされたMetaTalk）のアップデート版なんだ。昔の全部を取り入れつつ、今日の新しい機能も加えてる。Livecodeアプリは、クロスプラットフォームのdesktopアプリケーション（Mac, Win, *nix）、mobileアプリケーション、それに確かHTML5 deploymentでのwebアプリケーションとしてもdeployして実行できるんだ（彼らはそう言ってる）。
僕はこの会社とは全然関係ないけど、自分の理解と記憶を共有してるだけだよ。
Deckerで作られたprogramとかgame、zineはここにあるよ: https://itch.io/games/tag-decker
LiveCodeと違って（僕が知る限りHyperNextもだけど）、Deckerはfreeでopen-sourceなんだ: https://github.com/JohnEarnest/Decker
HyperNextはあんまり活発に開発されてないみたい。去年のアップデートが最後みたいだし、modernなcomputerでは使えないんだ。Deckerの最新リリースは昨日の朝だったよ。
もっと詳しく知りたいなら、喜んで話すよ。
「別の世界線では、HyperCardは枯れて死ぬことがなく、成熟し続け、webを受け入れた…」
また別の世界線では、誰かがHyperCardにURLとかGET、PUTみたいなのを追加しようと思って、Tim Berners-LeeのWeb browserの発明は決して起こらなかったかもね。だってHypercardが全部やっちゃってたんだから。
HyperCardは間違いなくVisual Basicの元になったよね。Visual Basicも、今のweb frameworkがそうであるように、かなり長い間、カスタムUI業界を支配してたんだ。
HyperCardのpointerって、いつもhandだったっけ？
HyperCardは僕のprogramming careerの基盤だったよ。「HyperCard Bible」は本物のBibleみたいに大切にしてたんだ。
正直、今のmodern webは正当なhypertext systemじゃないと思うんだ。20年前のFlashとかserverside CGIの頃も十分ひどかったけど、今は主要なwebsiteのほとんどが、ただJavaScript programを配信して、それから専用のAPIでデータを取得してるだけなんだ。それにpaywallや、LLMに許可なくcontentを学習させないようにするための絶え間ないCAPTCHA checkもあるしね。
Hyperlandを見てみてよ。Douglas AdamsとDoctor Whoの人が作った、初期90年代の、当時の未来のhypermedia revolutionについてのdocumentaryなんだ。昔はWebがそれと似てたのを覚えてるけど、今のmodern webは、少しでもhypertextに似てるものからは、すごくかけ離れてるよ。
contextとか、stack programmerがどう設定したかによるんだよ。「The Complete Hypercard Handbook, 2nd edition」の図51-1によると、可能性としてはwatch、busy、hand、arrow、iBeam、cross、plusがあったらしいよ。
「For Dummies」とか「Bibles」とか、昔の分厚いマニュアルがあった時代が懐かしいな。
ああいうのを何回かちゃんと読めば、だいたい自分のものになったんだよね。ちゃんと終わりがあったっていうかさ。
今のバージョンアップが constantly 続くのって、全然終わりがないんだよ。
Bible みたいな本なんて絶対に出せないよね。あーあ、 nostalgia。
この本でちょっと議論されてるよ。
https://www.goodreads.com/book/show/192405005-hypermedia-sys…
たぶん、Web の初期のアイデアに Hypercard の後継として戻ろうって主張してるんじゃないかな。
粘土を sculpting する analogy は最高の比喩じゃないと思うな。
sculpting ってすごく大変だし、特にちゃんと焼きたいなら粘土を回すのも大変だよね。
もしかしたら正確な analogy なのかもしれないけど、人によって難しさの感じ方が違うかもね。
一つには、これってめちゃくちゃ amazing だろうね。
でも一方で、 early Javascript が TPM Secure Enclave みたいに見えるくらいの security nightmare だっただろうな。
HyperCard は great だったけど、Visual Basic の inspiration じゃなかったよ。
僕は Ruby（プログラミング言語とは関係ないよ）を作った team にいて、それが Visual Basic の ”Visual” の部分になったんだ。
Alan Cooper が Tripod っていう prototype で最初の design をしたんだけど、彼は当時 unusual な design philosophy を持ってて、同じ goal の既存製品を見ないで ”design in a vacuum” することを選んだんだ。
彼に聞いてみるつもりだけど、HyperCard を見たことはまず間違いなくないと思うよ。
Flash は HyperCard の一番大事な点、つまり end user が edit mode にして、source code を見て、そこから学んで、extend したり、一部を copy して、自分たちの user interface を作れたっていう点を completely missed したんだ。
これは単なる ”View Source” じゃなくて、誰でも使える built-in で easy to use で scriptable で graphical で interactive な WYSIWYG editor を使った ”Edit Source” なんだよ。
HyperCard は Web ができるずっと前にそういうことを全部やってたし、JavaScript ができる何年も前から fully scriptable だったし、COM/OLE/ActiveX や OpenDoc/CyberDog や Java/HotJava/Applets のずっと前から plug-in XCMDs で extensible だったんだ。
何百万もの end user に広く使われて、game や storytelling, art, business, personal productivity, app development, education, publishing, porn とか、とにかく色んなことに使われてたんだよ。static な web page WYSIWYG editors （ましてや live interactive scriptable extensible web application editors なんて）が登場する far before にね。
LiveCard（WebStar/MacHTTP 経由で HyperCard を live HTTP web app server back-end として使う）は、 interactive WYSIWYG editor で graphical な live web page や forms を作れて、kids でさえ live HyperCard apps や databases, clickable graphics を Web に publish できた最初の tool だったたぶんね。
HyperCard は NeWS 用の HyperLook に deeply inspired されて、それは PostScript で script されて draw されて model されたものだよ。僕はそれで SimCity を Unix に port したんだ。
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
https://donhopkins.medium.com/alan-kay-on-should-web-browser…
＞”Apple’s Hypercard was a terrific and highly successful end-user authoring system whose media was scripted, WYSIWYG, and “symmetric” (in the sense that the “reader” could turn around and “author” in the same high-level terms and forms). It should be the start of — and the guide for — the “User Experience” of encountering and dealing with web content.
”
＞”The underlying system for a browser should not be that of an “app” but of an Operating System whose job would be to protectively and safely run encapsulated systems (i.e. “real objects”) gotten from the web. It should be the way that web content could be open-ended, and not tied to functional subsets in the browser.” -Alan Kay
＞[…] This work is so good — for any time — and especially for its time — that I don’t want to sully it with any criticisms in the same reply that contains this praise.
＞I will confess to not knowing about most of this work until your comments here — and this lack of knowledge was a minus in a number of ways wrt some of the work that we did at Viewpoints since ca 2000.
＞(Separate reply) My only real regret about this terrific work is that your group missed the significance for personal computing of the design of Hypertalk in Hypercard.
＞It’s not even that Hypertalk is the very best possible way to solve the problems and goals it took on — hard to say one way or another — but I think it is the best example ever actually done and given to millions of end users. And by quite a distance.
＞Dan Winkler and Bill Atkinson violated a lot of important principles of “good programming language design”, but they achieved the first overall system in which end-users “could see their own faces”, and could do many projects, and learn as they went.
＞For many reasons, a second pass at the end-user programming problem — that takes advantage of what was learned from Hypercard and Hypertalk — has never been done (AFAIK). The Etoys system in Squeak Smalltalk in the early 2000s was very successful, but the design was purposely limited to 8–11 year olds (in part because of constraints from working at Disney).
＞It’s interesting to contemplate that the follow on system might not have a close resemblance to Hypertalk — perhaps only a vague one ….SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))
https://donhopkins.medium.com/hyperlook-nee-hypernews-nee-go…
＞HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!
＞The Axis of Eval: Code, Graphics, and Data
＞Hi Alan! Outside of Sun, at the Turing Institute in Glasgow, Arthur van Hoff developed a NeWS based reimagination of HyperCard in PostScript, first called GoodNeWS, then HyperNeWS, and finally HyperLook. It used PostScript for code, graphics, and data (the axis of eval). [… ]
＞What’s the Big Deal About HyperCard?
＞”I thought HyperCard was quite brilliant in the end-user problems it solved. (It would have been wonderfully better with a deep dynamic language underneath, but I think part of the success of the design is that they didn’t have all the degrees of freedom to worry about, and were just able to concentrate on their end-user’s direct needs.
”
＞”HyperCard is an especially good example of a system that was “finished and smoothed and documented” beautifully. It deserved to be successful. And Apple blew it by not making the design framework the basis of a web browser (as old PARC hands advised in the early 90s …)” -Alan KayHyperLook SimCity Demo Transcript
https://donhopkins.medium.com/hyperlook-simcity-demo-transcr…
＞[…] All this is written in PostScript, all the graphics. The SimCity engine is in C, but all the user interface and the graphics are in PostScript.
＞The neat thing about doing something like this in HyperLook is that HyperLook is kind of like HyperCard, in that all of the user interface is editable. So these windows we’re looking at here are like stacks, that we can edit.
＞Now I’ll flip this into edit mode, while the program’s running. That’s a unique thing.
＞Now I’m in edit mode, and this reset button here is just a user interface component that I can move around, and I can hit the “Props” key, and get a property sheet on it.
＞I’ll show you what it really is. See, every one of these HyperLook objects has a property sheet, and you can define its graphics. I’ll zoom in here. We have this nice PostScript graphics editor, and we could turn it upside down, or sideways, or, you know, like that. Or scale it. I’ll just undo, that’s pretty useful.https://news.ycombinator.com/item?id=34134403DonHopkins on Dec 26, 2022 | parent | context | favorite | on: The Psychedelic Inspiration for Hypercard (2018)Speaking about HyperCard, creating web pages, and publishing live interactive HyperCard stacks on the web, I wrote this about LiveCard:
https://news.ycombinator.com/item?id=22283045DonHopkins on Feb 9, 2020 | parent | context | favorite | on: HyperCard: What Could Have Been (2002)Check out this mind-blowing thing called ”LiveCard” that somebody made by combining HyperCard with MacHTTP/WebStar (a Mac web server by Chuck Shotton that supported integration with other apps via Apple Events)! It was like implementing interactive graphical CGI scripts with HyperCard, without even programming (but also allowing you to script them in HyperTalk, and publish live HyperCard databases and graphics)! Normal HyperCard stacks would even work without modification. It was far ahead of its time, and inspired me to integrate WebStar with ScriptX to generate static and dynamic HTML web sites and services!
https://news.ycombinator.com/item?id=16226209MacHTTP / WebStar from StarNine by Chuck Shotton, and LiveCard HyperCard stack publisher:
CGI and AppleScript:
http://www.drdobbs.com/web-development/cgi-and-applescript/1…
＞Cal discusses the Macintosh as an Internet platform, then describes how you can use the AppleScript language for writing CGI applications that run on Macintosh servers.
https://news.ycombinator.com/item?id=7865263MacHTTP / WebStar from StarNine by Chuck Shotton! He was also VP of Engineering at Quarterdeck, another pioneering company.
https://web.archive.org/web/20110705053055/http://www.astron…
http://infomotions.com/musings/tricks/manuscript/0800-machtt…
http://tidbits.com/article/6292
＞It had an AppleScript / OSA API that let you write handlers for responding to web hits in other languages that supported AppleScript.
I used it to integrate ScriptX with the web:
http://www.art.net/~hopkins/Don/lang/scriptx/scriptx-www.htm…
https://medium.com/@donhopkins/1995-apple-world-wide-develop…
The coolest thing somebody did with WebStar was to integrate it with HyperCard so you could actually publish live INTERACTIVE HyperCard stacks on the web, that you could see as images you could click on to follow links, and followed by html form elements corresponding to the text fields, radio buttons, checkboxes, drop down menus, scrolling lists, etc in the HyperCard stack that you could use in the browser to interactive with live HyperCard pages!
That was the earliest easiest way that non-programmers and even kids could both not just create graphical web pages, but publish live interactive apps on the web!
Using HyperCard as a CGI application
https://web.archive.org/web/20060205023024/http://aaa-protei…
https://web.archive.org/web/20021013161709/http://pfhyper.co…
http://www.drdobbs.com/web-development/cgi-and-applescript/1…
https://web.archive.org/web/19990208235151/http://www.royals…
What was it actually ever used for? Saving kid’s lives, for one thing:
＞Livecard has exceeded all expectations and allows me to serve a stack 8 years in the making and previously confined to individual hospitals running Apples. A whole Childrens Hospital and University Department of Child Health should now swing in behind me and this product will become core curriculum for our medical course. Your product will save lives starting early 1997. Well done.- Director, Emergency Medicine, Mater Childrens Hospital
— Minecraft
— Roblox
— LittleBigPlanet
— Mario Maker
こういうのが kids が creative になるためにやってることだよね。
もうちょっと serious （だからあんまり succesful じゃないけど）：
— Logo/Turtle Graphics
— Scratch
— HyperStudio
HyperCard は graphic design と hypertext （links）の両方だった。この二つの modality が separated されたんだけど、それには practical な理由があると思うよ。
だって html/css design って実は sucks だし、amateur art form にはならなかったからね。
writing と publishing 用には Wiki、Obsidian とか、Blogs （RIP）、forums、social media がある。interactive や programmable にはなってないけど、これらが people の publishing の needs を満たしてるんだ。
Livecode は昔 opensource だったから使いたかったんだけど、その window は閉まっちゃったな。
なんか Flash の replacement が欲しいんだよね…。
AccessとかExcelで作ったものってさ、なんか最近AIで生成するやつとすごい似てるんだよね！
Macromedia製品だけで作った昔のツールを生き返らせなきゃいけなくて、最近https://ruffle.rs/ってのを知ったんだよ。
スティーブ・ジョブズの本からの引用だよ。ビル・アトキンソンがどうやってウィンドウを重ねて表示するのを可能にしたかって話。Xerox PARCでもできてなかったんだって！「できないって知らなかったから、やれたんだ」って彼の言葉がすごい。
事故った話とか、Jobsが見舞いに来て「regionsはまだ覚えてる？」って聞いたエピソードも載ってる。
AppleとXeroxのアプローチの違いは、PARCの人たちがやり方を知らなかっただけじゃなくて、もっと複雑かもね。Altoってフレームバッファがなくて、ウィンドウごとにバッファがあったんだ。そのせいで、スキャンラインごとにウィンドウをたどって描画してたみたいだよ。
もっとコメントを表示（1）
誰か、この技術的な部分をもっと詳しく説明してくれない？今のOSと違いすぎて、すごさがイマイチ理解できないんだ。
「regionsはまだ覚えてる」って記事(https://www.folklore.org/I_Still_Remember_Regions.html)も読んだけど、よく分からなくて。
この分野の歴史を語り継いでいくのは大事だよね。誰か詳しい人、解説プリーズ！
疑ってるわけじゃないんだけどさ、そこには具体的な違いがあるの？Macにスクリーンバッファがあったことで、Altoじゃできなかったクリッピングが可能になったってこと？
PARCの話を聞いて思い出したんだけどさ、Starcraftでも似たような話があったんだよ。ライバルのデモにビビってゲームを大幅に作り直したんだけど、後でそのデモが実はプリレンダで、俳優がプレイしてるフリだったって分かったんだって！
コメント17957の事故の話、すごいけどちょっと暗いよね。Jobsみたいな雇い主は、働きすぎて死にそうになるほどの超優秀なやつを気に入るだろうけどさ。
でも、それが本人の幸せにつながるわけじゃないし、みんながみんな革命的なことできるわけじゃない。
素晴らしい働き手も必要だけど、幸せでバランスの取れた人も必要だよね。
コメント17959への返信だよ。昔は今みたいにメモリがなかったから、ウィンドウ全体をバッファに持てなかったんだ。
アプリケーションは直接フレームバッファに描画してたんだけど、他のウィンドウに隠れる部分は描かないようにする必要があった。
そこでQuickDrawの「region」が登場！これは「ピクセルの集合」みたいなマスクで、これを使って描画をクリッピングしたんだ。
Regionはビットマスクじゃなくて、水平スパンのリストとかで実装されてたらしいよ。だから交差とかの計算が速かった。
ざっくりだけど、今のコンピューターと違うのはこういうとこかな！
コメント17961のStarcraftの話、知ってる！ライバルの「Dominion」のデモに圧倒されて、自社のゲームを「宇宙版Warcraft」って批判されたと感じて、大幅に作り直したんだよね。
後でIon Stormの元社員がバラしたんだけど、E3 1996のあのデモは全部プリレンダで、実際のゲームプレイじゃなかったんだって！
領域の実装は、”unpacked array of sorted inversion points”なんだって。
もし68kアセンブリ読めるなら、PtInRgnの実装はここにあるよ→https://github.com/historicalsource/supermario/blob/9dd3c4be…
これのおかげでMacはメモリを大幅に節約してウィンドウ表示できたし、特別なハードウェアもいらないんだ。
領域ごとに画面が更新されるから、自動で隠れたり、更新やクリッピングが管理されてたんだよ。
そう、それが僕が言ってた水平スパンだよ。
それはX座標のソートされたリストなんだ（左から右）。ペアでグループ化すると、領域内のピクセルの開始・終了間隔（可視部分）になるけど、僕が説明したみたいに、フラットな配列として操作する方が実際は便利なんだ。
コードをちょっと調べたけど、各スキャンラインはY座標がプレフィックスされてて、範囲外のターミネーター（32767）を使ってるね。
重なり合うウィンドウでは、手前のないウィンドウの可視領域は”L”型や”T”型になることもあるよね。
ビルの領域構造は、ウィンドウの可視行のRLE（run-length encoded）表現みたいなものだったんだ。
一番手前のウィンドウの領域は、0から幅いっぱいの行を示す。
部分的に隠れたウィンドウは行の開始・終了が異なるし、細いウィンドウが上にあると穴も開く。
すごいのは、この構造の領域や長方形を高速に足し算、引き算、交差、結合するルーチンを書いたことだと思うよ。
ほとんどの人は、快適な人生でも、もし創造的な欲求を追求できなければ少し惨めになるものだよね。
それを起業家として追求するか従業員として追求するかは状況次第。
どちらにしても、私たちの仕事を使う人や楽しむ人は恩恵を受けるんだ。
ビル・アトキンソン氏、Mac Paintの仕事で観客から拍手を受けて満面の笑み:
https://www.youtube.com/watch?v=nhISGtLhPx4
それ以上のことがあるんだ。
X座標のリストは累積的で、一度反転（inversion）としてマークされると、次のY座標が出てくるまでだけでなく、それ以下の全てのY座標で反転として扱われ続けるんだ。
これは、NOTRECTループ内でD3がリセットされないというコードに現れてる。
こうすることで、二つの互いに素な領域のユニオンを取るような操作が簡単になるんだ。
点の集合を単にソートして結合するだけだからね。
1980年には、フレームバッファメモリはまだ信じられないほど高価だったんだ。
僕らの研究室の512x512x8bitのカラーバッファは、1980年に3万ドルもした。
Macの512x384x8bitバッファは、1984年の2500ドルのMacの価格に収まる必要があった。
Xerox Altoはこれらより早かったけど、もしフルフレームバッファがあったらもっと高かっただろうね。
いい説明だね、でもその時代を生きた人には当たり前の詳細をいくつか付け加えるよ。
『Obviously it could have not been a mask of pixels』についてもっと具体的に言うと、メモリが多すぎるという説明に関しては、多くの初期GUIは1bit/pixelだったから、ビットマスクはウィンドウの内容と同じ量のメモリを使ったんだ。
領域だけを描画する複雑さには別の利点があった。
OSは領域が表示されたときにアプリに知らせることができたから、表示されて更新が必要な場合や、ちょうど表示された場合にだけ領域を再描画すればよかったんだ。
複雑なことをしていて結果をバッファリングする正当な理由がない限り、再レンダリングしていたと思うよ（これは数十年前、コンパクトMacでマンデルブロフラクタルプログラムを作っていた頃の記憶だけど）。
問題解決ってさ、技術的に正しくても、使えるくらい効率的じゃないとダメなんだよね。高いハードウェア使うのも手だけど、同じ条件なら低い方がいいじゃん。
Michael Abrashのグラフィックス本の黒本さ。バッファって聞いて、唯一賢そうな書き込みFIFO作ったんだって。そしたら競合は一番バカげた読み込みバッファだったらしいよ。これメンティーにも教えてる。何か「可能」って知ってるだけでかなりデカい情報。あと自慢すんな、情報漏れるから。可能だって知ってるだけで達成するのめっちゃ楽になるんだ。
https://valvedev.info/archives/abrash/abrash.pdf
QuickDrawのソースコードだとRegion構造体の中身は”unpacked array of sorted inversion points”って呼ばれてるね。詳細はちょっと少ないけど、PtInRgn(Point, RegionHandle)の実装見るとどんな感じか掴めるかも。
https://github.com/historicalsource/supermario/blob/9dd3c4be…
俺が知る限りだと、bounding box（一般的なL/T/R/B形式）の後ろに、領域内の「コーナー」のX/Y座標が並んでる感じ。重なった矩形ウィンドウからできる領域にはかなりコンパクトだし、ヒットテストはめっちゃ速い。
その話、俺はちょっと違う読み方したな。JobsがAtkinsonにregion覚えてる？って聞いたんじゃなくて、Atkinsonがそれを持ち出したんじゃないかな。
付け加えるとさ、俺たちの中には直接お金にならないクリエイティブな欲求がある人もいるんだよ。全く使う人や楽しむ人がいないことだってある（いれば尚良いけどね！）。
もちろん、それで生計立てようとは思ってないけど。
確かにシンプルになるね。パーピクセルじゃなくて、スクリーンごとにウィンドウソートできるし :)。
レース・ザ・ビーム中のパーピクセルソートは難しいんだ。ゲーム機はたいてい、ラインごとのオブジェクト（スプライト）数を制限したり、ライン到達前にそれらをフェッチ・キャッシュしたりしてたよ。
うーん、それもうちょっと分かりやすく説明してくれない？よくわかんないんだ。D3はリセットされないんだよね、各スキャンラインの最初に0になる保証があるから。コードは全ての「スキャンラインブロック」を、引数で指定されたYを含むのを見つけるまで進む必要がある。各スキャンラインはまだ自己完結していて、「外側」の状態でX=0から論理的に始まるように見えるんだけど？
「pix-els」の発音の仕方いいな。今の発音にどうたどり着いたのか学ぶのは、こういうコンピューター史の話でたまらないね。
Andy Hertzfeldのインタビュー見てたらさ、Macintoshプロジェクトの一番の課題はLisaのシステムをMacで動かすことだったって言ってたんだ。
ハードウェアはWozからヒントもらったらしい。Wozは効率化のためにハックを多用する人だったから、Macチームもソフトウェアで同じアプローチが必要だったんだって。
メモリのことだけじゃなくさ、非圧縮のビットマップマスクって処理にすごく時間かかったんだって。
特に領域を組み合わせる時で、8ピクセルの倍数でずれてない場合とか大変だったらしい。
反転の水平座標だけなら、同じ形状の複雑さなら8ピクセル幅でも800ピクセル幅でも処理時間は同じなんだって。
昔AppleのColorSyncチームにいた時、ビル・アトキンソン氏の家に呼ばれたことがあるんだ。
その時は色関連の話ばっかりしなきゃって思ってたけど、今思えばもっと色々話せばよかったって後悔してる。
彼は当時デジタル写真にすごくハマってて、高価な機材でフィルムをスキャンしたりして、写真集も作ってた。
暗部のディテールがしっかり写せるって興奮してたよ。
’もっと色々話せばよかった’って？
じゃあ、僕も色々話したいな！
今Macintoshのカラー、特にColor Pickerについて調べててさ。
もし興味あったら、BlueSkyのアカウント作って連絡するよ。:) URL: https://merveilles.town/deck/@rezmason/114586460712518867
John CalhounはMac IIのカラー対応の頃はいなかったと思うよ。
Color QuickdrawのエンジニアだったEric Ringewaldとか、ハードウェアのMichael Dhuey、あとJean-Louis Gasséeに話を聞くのがいいかもね！
僕はGeneral Magic, Be, Eazel, AppleでたくさんのApple伝説と仕事したんだ。
JKCalhounとは直接はなかったけど、オフィスはよく通ったよ。
そうそう、僕がAppleに入ったのは’95年で、Color Quickdrawはもうあった頃だよ。
笑っちゃうんだけど、Color PickerのPowerPCへの移植を任されてさ。
68030アセンブリ見て’ヤベェ、これCで書き直さなきゃかも’って思ったのが、Appleでやってけるか不安になった最初の一つだよ。
君のユーザーネーム見てると、前にも話したことあるかもね。
’金持ちの引退エンジニアが高価な写真機材買って突然写真家を名乗る’って？Duchampなら何か言うかもね。
実は僕もそんな感じなんだけど、何年も自分をアーティストって呼ぶのが怖かったんだ。
高価な機材でシグナル得てるだけで、ボタン押すだけ、カメラが全部やってるって思ってた。
でも、そんな考え方は有害だし不要だって気づいたんだ。
アートにもうゲートキーピングは要らない。
僕はビジュアルアーティストだよ。スキルより機材が良いかもしれないけど、アーティストだ。
もっとコメントを表示（2）
デジタルのダイナミックレンジは、昔のアナログみたいに十分じゃない気がするんだよね。今は当時よりは良くなったけど、モノクロで作業してると、彼が直面したのと同じ限界を感じることがたまにあるよ。
良いモノクロデジカメって、なんであんな大金がかかるんだろうね。カラーCCDからBayerグリッドを外すのも怖くて試せないし。あれがない方が暗い場所で1〜2段分くらい感度上がりそうなのに。
天体用CCD（モノクロが多い）でカメラ作れないかなって思ったけど、あれもピクセル数が多いと安くないんだ。
僕も同じ道をたどって、SigmaのFoveonカメラにしたんだ。
比較や利点についてはここを見てみて：https://www.photigy.com/school/sigma-foveon-sensor-review-dp…
白黒写真ならLeica M Monochromが良い高価なカメラだと思ったけど（https://en.wikipedia.org/wiki/Leica_M_Monochrom）、Foveonの方が断然上だと僕は思うんだ。
：https://youtu.be/OODMWXX_N7A
：https://www.stevehuffphoto.com/2013/01/14/quick-comparison-l…
これで本当に決めた写真がこれだよ：https://www.fredmiranda.com/forum/topic/1806915/0&year=2023#…
これは改造したDP1mからだけど、SD Quattro HはIRフィルターが簡単に外せてセンサーも大きいんだ。
microlensも外すことになるね。あれ、感度上げるのに役立ってるんだけど。
D5300のファインダーのフォーカシングスクリーンは何度か交換したことあるけど、センサーを debayering するのは試さないな！
でも、そういうのは中古カメラ屋とかeBayで手に入る安いボロカメラでやるもんだよ。
ピクセル数が全てじゃないし、本格的に投資する前に、どれだけ興味があるか試すにはそれが一番でしょ？
僕の写真への興味だって、2016年のスマホカメラじゃできないことにイラッとしたのが始まりなんだ。
ハハ、でもこれも「仕事の話」だよね。
きっとビルも Quickdraw の頃の話より、こっちの方が好きだったんじゃないかな。
オプティカルプリントすると失うものもあるけど、得るものもあるんだ。1対1じゃないんだよね。
僕はハイブリッドワークフローが大好きで、フィルムを選んで色合いとか粒状性とか写真の見た目を決めて、デジタルでアナログフィルムの限界を補うんだ。
悲しいけど、今はフィルムは面倒すぎるね。僕にとって写真は、カメラやプロセスじゃなくて構図が全てなんだ。フィルムは安定した結果が出るから好きだったけど、今はデジタルも使うし、実際そうしてるよ。
「芸術評論家が集まると形とか構造とか意味について話すけど、芸術家が集まると安くターペンタインが買える場所について話すんだ。」
WWDC（2011年？）でBillに会ったんだって。
ランチの時に隣だったのに、その時は彼だと知らなかったんだ。
名前教えてくれて、写真も見せてくれたよ。
優しくて穏やかな人だったみたいだ。
このニュースは本当に悲しいね。
（前のコメント引用部分について）金持ちの引退したエンジニアが高級機材で写真家気取り、って話、それって彼じゃなくてあなた自身のことじゃないの？
そう思うな。
個人攻撃はやめようよ。
そんなことしても、良いことより悪いことの方が多いって。
ガイドラインはここ見てね。
https://news.ycombinator.com/newsguidelines.html
うわ、あなたがだいたい正しいのが悔しいな。
反論しようと思ったけど、「良いことより悪いことの方が多い」ってとこ見て納得したよ。
それは本当にその通り。
とにかく、私が悪かった。
もっとちゃんと、優しく説明すべきだったね。
でもそれって本当だよね。
こういう現象があるから、PRSみたいな会社も成り立ってるんだ。
プロシューマー向けの製品って、いろんな業界にあるよね。
電動工具とかまさにそれ！
それは否定しないよ。
いろんなことについて言える観察だと思うな。
本当にその通りだよ。
なんで低評価されてるのか分からないな。
この人が亡くなったばかりなのに、写真家とか、写真撮影はこうあるべき、みたいなエリート気取りの意見を言って、Billが間違ってたみたいに言う人がいるなんて。
まあ、そんな風に伝わるつもりは全然なかったんだ。
Billについて言ってたわけじゃないよ。
Billの写真に悪いとこなんて何もなかったし、プロの写真については詳しくないから意見も言えない。
ただ、その時感じたことを正直に言ってただけ。
今日話すか迷ったけど、いつも正直すぎちゃうんだよね。
引退してから、プロとしてやってたことを余暇に続けるなんて、変だって想像するのはおかしいかな。
