世界最大のデモパーティ「Revision」で優勝！制作したKLab社員にインタビュー (2020/06/11)
https://www.klab.com/jp/blog/pr/2020/revisionklab.html

Demo sceneって向こうの物ばかりだと思ってたけど、和製Demo(Intro)がここまで行ける日を目にすることができるとは…ものすごく嬉しい話だし、これからも楽しめそう。（もうちょい早くに知りたかった）

まあゲームもそうだし

落としてみたけど…8GBなArc A770のせいなんでしょうか、起動時のプログレスバーが70％程度のところでしばらく固まった後、落ちました。
ドキュメントにはDX11, 11GB以上のVRAM, 3080ti以上ってあるのでメモリ不足なのかも。AMDじゃ動かないかもとまで書いてあるし。
AIだけでのDemo sceneでもNVIDIA一択なのかしら。

めっちゃ怖いんですけどこのintro。https://demozoo.org/productions/322374/

手軽に見るなら8k/4k introで良いのかな

GPUが遊んでるのもアレなので久々にDemoでも見てみるかなーと漁ってるんだけど…イマドキのDemoって1GB物とかあるのか。もうMegaDemoじゃなくGigaDemoじゃないですかそれ

https://demozoo.org/productions/322662/

write_stdout()で使ってるIsknj1(), Isknj2()（これはsjgetchar.c内でのみ存在）、これとSJ_read()で使ってるiseuc3byte(), iseuc2byte(), issjis1()（これはkctype.h由来）、なんかこの辺はうまく整理できそうな気がするけどどうなんだろう。文字境界単位で処理させる、それの入口と出口の処理ってことなんだろうし。

あとは紙と鉛筆用意してちょっと考えまとめるか…チラシの裏みたいになんか書いてあるものじゃないとどうもアイデア湧かない…

エヴァンゲリオンももう30年近く前の話になるのか…（それを言い出すとWindows95とかもそうなる）

@hadsn CPUも熱かった（ので6x86Lにして低熱化した）とか、60/66MHzではなく75MHzのバスクロックへの対応を必要とするケースもあったとか（バスクロックの設定によりPCIバスが33MHzではなく37.5MHzで動いてしまうマザーボードもあった）、まあ色々じゃじゃ馬ではありましたね。それを使うユーザ達も随分熱い人がいたように記憶してます、NIFTY-ServeのFCYRIXフォーラムとか。

Cyrix直系のコアってAMD Geode（旧National Semiconductor Geode）LX 800辺りがまだ残ってるかどうか…だっけ？
Rise mP6のコアが確かDM&P Vortex86DXとしてまだ生きてたよね？86duinoで使ってるアレ（なのでお金に余裕があったら86duino Educakeをもう一台1個欲しいなって思ってる…あの時代の思い出を、冥途の土産として）

@hadsn あの頃貧乏な学生だった身には、PC自作で遊ばせてくれたという意味では良い石だったと思うけど世間的にはどうなんだろう…Quakeでの(FPU)パフォーマンスの低さが思いっきり低評価に繋がっちゃいましたよね。

羨ましいな、なんか組みたくなってくる。

あの辺のコードは完全にリファクタリングしないとどーにもならんってことだけは分かった。さて、どーやろっかな。

サーバも電源次第で良い仕事をしたりしなかったりするので、マイ電柱が（待て

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

どーすんのこれ。

3文字分トラップしといて、あとでまとめてputchar()×3で吐き出すのってさ…putchar()×3がatomicである保証ってどこにもない気がするんだけど。

…ってことは、トラップしてまとめて吐き出す意味って、無くね？

write(STDOUT_FILENO, xxx)でまとめて吐かないとatomicにならないような気が。

問題はUTF-8の文字境界単位のトラップ、最大4byteで考えるか6byteで考えるかなんだよな。今は4byteだけどかつては6byteな仕様だったし…また6byteに戻しますとか言い出す可能性もあるだろうし。

ん－、やっぱ文字境界単位でトラップしてるだけ、というコードに見えるな。EUCの場合だと、

・SS2(0x8e)もしくはEUCの範囲
　knj1stにSS2もしはEUCの1byte目をトラップ
　次の文字が来た時点でknj1st, [次の文字]の順に出力
・SS3(0x8f)
　knj2ndにSS3をトラップ
　knj1stに次の文字をトラップ
　さらに次の文字が来た時点でknj2nd, knj1st, [さらに次の文字]の順に出力

なので単に与えられた文字をwhile() putchar(*s++)でがーっとやってるのと結果は変わらない。並べ替えとかやってる訳じゃないし。

文字境界単位でのトラップって、文字の途中までバイト列を吐き出しちゃった時にBS食らうと画面表示がおかしくなる問題を回避する目的でやってるのかな。きちんと1文字分表示させた段階でBS食らうなら問題ないのだし。

言語設定がEUCになっているのでset_eucmode()は実行されるしeucmode = 1になるのも分かるけど、その先だよなあ。eucmode = 0にしても何か変わった動作をしているようには見えないのが謎。