S.F.@SFPGMR
これすごいな。。
デイリーガジェットさんのツイート: "日本でファミコンやPC-88が圧倒的なパワーを持っていた時代に、欧州や北米市場で人気を博したホビーパソコンのコモドール64復刻版「The C64」が今年12月に登場 小型化でなくフル機能フルキーボード搭載で、素晴らしいことに当時のままプログラミングもできます #コモドール64 https://t.co/jW7SiH8HWR"
“日本でファミコンやPC-88が圧倒的なパワーを持っていた時代に、欧州や北米市場で人気を博したホビーパソコンのコモドール64復刻版「The C64」が今年12月に登場
小型化でなくフル機能フルキーボード搭載で、素晴らしいことに当時のままプログラミングもできます
#コモドール64
https://t.co/jW7SiH8HWR”
しろ@siro700
木曽駒ヶ岳から見下ろす夜の街、夜、こっそり山小屋から出て徘徊するの面白いですよ https://t.co/43JMONZF31
S.F.@SFPGMR
おお、ボクセル・モデラをまた発見。
S.F.@SFPGMR
うーむ。クォータニオン使えばジンバルロックを回避できるのか。。
S.F.@SFPGMR
wasm用のプリプロセッサ（mwasm）をnode.jsで作っている｜sfpgmr @SFPGMR｜note（ノート）
wasm用のプリプロセッサ（mwasm）をnode.jsで作っている｜sfpgmr｜note
動機 WASMが出てきて、WASMを吐くコンパイラが作れそうだったので「オレオレ言語」を去年の2月くらいから作っていた。今はちょっとお休みの状態になっている。プリプロセスをどうしようかというところで手が止まってしまったのだ。複雑なプリプロセッサ+メタ・プログラミング機能を追加しようとして実装をどうしようか迷っているうちにモチベーションが萎えてしまった。身の丈に合わない仕様を思いついたんだけど私の実装能力が低いから先が見えなくなったのだ。binaryenの助けを借りながら、WASMバイナリを吐くとことまではできたんだけどね。 オレオレ言語を作っている 趣味というのは「締め切り
プリプロセッサで吐いてるwatをwabt.jsでparseしてwasmにしてるんだけど、なんかおかしいんだよなあ。。
GitHub - AssemblyScript/wabt.js: A buildbot for wabt.js, a port of WABT to the Web, with TypeScript support.
A buildbot for wabt.js, a port of WABT to the Web, with TypeScript support. - AssemblyScript/wabt.js
wat2wasmでバイナリ化する結果と異なるという。。
凡ミスだった。。
let wasmModule = wabt_.parseWat(args.input, preprocessedSourceText);
wasmModule.resolveNames();//これが足らなかった。。
wasmModule.validate();
wasmModule.validate();でエラーでまくりでうわぁ。。となってた。wat2wasmだとエラーが出なかったのでなんでかなあと。resolveNames()呼ばないといかんのね。。
PSGエミュレータは元のCソースを手作業でwatにする作業は終わった。これからデバッグに入る。
いっぱい不具合はあるだろうねえ。不具合を潰す作業は、プチプチを潰すのと感覚的に似てる感じがして、なんか好きなんだよね。。
chromeでwasmをステップトレースできるようになってるから、デバッグもなんとかなりそうだね。
ソースコードはcソースに比べて1.5倍位になっただろうか。
こんな感じでデバッグできるからね。。 https://t.co/vnPKrXN3LO
死んだ。。 https://t.co/XpueErSwQu
とりあえず呼び出しで死ぬようなことはなくなったが、そもそもPSGでどうやって音を鳴らすのかすっかり忘れている（笑）ここで言っているのはPSGのレジスタ操作でどうやって音を鳴らすのかということ。音程はどうやってコントロールするのか、発音・消音はどのような手順の行うのかということ。。
今のところは適度な大きさのバッファにPSGの音声データをレンダリングして、それをWebAudio APIに渡すことで音を鳴らそうと思ってるとこ。AudioWorklet使ってみたいんだなー。これが。
このサンプル・コードが参考になりそう。。
web-audio-samples/wasm-worklet-processor.js at master · GoogleChromeLabs/web-audio-samples · GitHub
Web Audio API samples by Chrome WebAudio Team. Contribute to GoogleChromeLabs/web-audio-samples development by creating an account on GitHub.
このバックで流れているBGMはWebAudioで波形メモリ音源をエミュレートしてみたものだ。この時はPeriodicWaveNodeを使って各チャンネルの音声を4ビット波形データから作ったんだよな。
4bit波形データ→フーリエ変換で周波数データに変換→PeriodicWaveNodeで再生みたいな感じ。
PeriodicWaveNodeを使うと複雑な波形を合成することができるんだよな。。倍音加算式音源みたいなもんだよな。知らんけど。。
AudioBufferSourceNodeだとちょっとコントロールが難しいんだよな。。持続音というか波形を流しっぱなしにするのが難しいというか。loopパラメータはあるけど、ループで戻るときに波形をうまくつなげないとノイズが出るしね。。
私としてはほんとはWebAudioのような高機能なものではなくてもっと低レベルなものが欲しいんだけどね。ASIOのWeb版のようなやつ。
これ見たらちょっと思い出したな。。PSGの使い方。。
AudiotWorklet内でWASMを使うことはできるけど、バイナリをfetchすることはできんのですわ。なのでメインスレッド側でWASMバイナリをfetchした後ArrayBufferでAudioWorkletに渡せばよいのですな。。渡し方はいろいろあるけど私はコンストラクタで渡すことにした。
WebAudioAPIの仕様を読むと、AudioWorkletProcessor のコンストラクタの引数にAudioWorkletNodeOptionsオブジェクトが渡されるのですな。
AudioWorkletNodeOptionsにはprocessorOptions メンバがある。これはAudioWorkletNodeをコンストラクトした時の3番目のオブジェクトのメンバである。
let node = AudioWorkletNode(audioctx,"PSG",{
processorOptions:{
wasmBinary:psgBin,
sampleRate:audioctx.sampleRate,
clock:3580000
}});
こんな感じでメインスレッドからAudioWorkletにパラメータを引き渡すことができるんですな。。
パラメータは勝手にシリアル化されるので利用者はオブジェクトも渡すことができるのですわ。。
そしてこんな感じでコンストラクタでwasmバイナリを有効化して初期化するようにしてる。が今はメソッドが動くようになっただけでまだまだバグが大量発生中。AudioWorkletのコードはChromeではまだステップ実行できないようだ。知らんけど。。 https://t.co/mjChlilAU8
なのでpostMessageでメインスレッド側にデバッグ情報を渡してconsole.logで表示してチェックするようなことを今はしている。。
今はPSGレジスタに書いた情報がちゃんと読み込まれるかテストしてるところだが、それすらちゃんと動いとらん（笑）。もうちょっとメインスレッド側でテストを進めてからやらんといかんわな。。
postMessageとか使ってるとなんかWindows APIを思い出すなあ。。PeekMessageとかGetMassegeとか..
過去にPeriodicWaveで作った波形メモリ音源はナムコの4bit波形メモリ音源を参考にしてる。つくりはまるで違うけど、波形テーブルは同じものが使える。よってこのようにゼビウスのBGMほぼ「まんま」の音を鳴らすことができる。。
このPSGエミュレータがまともに動いたら、ローレゾな画面のシューティングゲームを作りたいなあと思ってるんだよなあ。WASMでね。。このPSGエミュレータを使うかどうかはわからんけど。
I/Oやゲームシステムなどの低レベルな部分はJSでやって、アプリはWASMで作るというかたち。本来であれば低レベルなレイヤーはWASMで作って、JSがそれを利用するのがふつうだが（笑）。
リニア・メモリをVRAMに見立ててWASMにアクセスさせて、それをJS側でシェーダーに渡して描画させるようなことをすれば、昔のPCのビット・マップグラフィックをエミュレートすることは容易にできるだろう。
JSだけだけど、ArrayBufferでRGBプレーンを作ってそれをシェーダで描かせるようなことも過去やってみたんだよね。
ArrayBufferやDataViewのおかげで線形メモリに対する細かなアクセスがJSでできるようになったのを利用してる。
https://t.co/haDwdKGOdA
アニメーションはパレット・チェンジの手法を使ってる。そのあたりの処理はシェーダーにパラメータを渡してシェーダー側で処理するんですな。
だけどWebGL 1.0のシェーダーは整数値の扱いにちょっと制約があって。ビット演算とかできないんだよな。そこがちょっと面倒なんだけどね。WebGL 2.0だとその制約はほぼなくなったんだけどね。
これをさらに応用するとMZ-700のキャラクタVRAMをArrayBufferでエミュレートすることも可能なんですな。。このサンプルはArrayBufferにMZ-700のキャラクタとアトリビュートをまんま再現している。
https://t.co/O8gyJOYZDm
WASMでZ-80とか周辺チップのエミュレーションコードを書くのは、おそらくJSで書くより簡単にできるのでは..と思ってる。
PSGエミュレータのデバッグでハマってる私。ただちょっと光明が。。
使い方も思い出すことができた。ネット上の情報も思いのほか豊富でびっくりした。。
ちょっと鳴るようになった。
この実装にあたっては色々驚かされことが多い。昔のチップなんでほとんど乗算使わなくていいし。とはいえ自分で一から実装してるわけじゃないんどけと。
cソースがお手本としてあって、それをwatで書き直してるんだけどね。スタックマシンだけにメモリのロードストアが頻発するのがちと面倒くさいというか。。
ようやくEGが動くようになった。。凡ミスもいいとこだけど。。
今はpostMessageでAudioWorkletにパラメータを送ってるけど、そろそろparameterDescriptorsでレジスタのラッチと値設定できるようにしよう。a-rateでいいわなあ。あとは128サンプルずつ処理するようにwasm側にコードを追加するか。
これができたらVRAMやスプライトRAMの実装でもしようかな。160x100か320x200くらいの解像度でね。これは特定のハードウェアのエミュレートをするのではなくオレオレだが。wasm側のメモリでVRAMをエミュレートして、それをWebGLに渡して描かせるのである。
そしてオリジナル波形メモリ音源のwasm化もやってみよう。。
画面まわりはWebGL2.0になってシェーダーで整数の取り扱いが改善されたので相当楽に実装できそうな気がする。とはいえ私が実装すると相当時間はかかるけどね。。
PSGのパラメータからEGや波形を作るところはなんかとても面白いコードなんだよなあ。思ってたのと全然違うんだな。これは矩形波でデューティ比固定、さらにはEGも特殊だからこそできる実装というか。。
ちなみに今の時点でのPSGエミュレータのWASMバイナリのサイズは2689bytesである。わずか2K..。
#WebAssembly
AudioWorkletをもうちょっと勉強せんといかんね。。
PSGエミュレータは音はそこそこ鳴るようになったのでUI作ってテストしてみることにした。不具合はまだありですな。。 https://t.co/PLMuTS7yPi
こういうUIがHTMLでサクッと書けるなんてすごい時代になったよな。。
まあまあ動くようになった。
Chromeのみで動作する。。
ちょっとVRAMについて思案中。リニアメモリのある一角をVRAMとして、WASMからそこに書き込んだらそれをGPUにデータテクスチャで渡して描こうかなと思っている。橋渡しのコードはJSで書く。
レトロ風のVRAMの構成を考えると、テキストVRAMとビットマップVRAM、そしてスプライト用RAMの3種類が考えられる。
テキストRAMもWASM側でASCIIキャラクタを書くとキャラクタのビットパターンをGPUで展開することでエミュレーションする。思案してるのはビットマップ用のVRAMとスプライト用RAMなんだよな。160x100もしくは320x200ピクセルくらいのローレゾなグラフィックでパーティクルをやりたいんだな。
160x100pxだとこんな感じのグラフィックスになる。
https://t.co/sI8iuTdPzj160x100pxでゲームを作る
160x100pxでゲームを作る
CRT風のポスト・エフェクトをかけてるけどね。動いてるキャラはポイント・スプライトで書いてる。WASM側では軽いパラメータを渡すだけにして、GPU側でいろいろややこしい計算を受け持たせようという算段である。
VRAM周りの仕様が固まってWASM+JSで実装できたら、
・JSで作った波形メモリ音源をWASM+JSで書き直す
・JSで作ったゲームシステムをWASM+JSで書き直す
・ゲームシステム上で動く横スクロール・シューティングをWASM+JSで作る
で年内は過ごそうかなと。
まあ趣味なんでどうなるかはわからんけどね。。
まずはテキストVRAMからか。フォント・ビットマップは美咲フォントを使わせていただくことにしよう。漢字はどうしようか。。漢字対応するとなるとVRAMは1キャラ当たり最低2バイト必要ですな。
UTF-8文字コードをJIS X 0208に変換して表示するか、もしくはUTF-16に変換して表示するか。。うむぅ。難しいなあ。。
美咲フォントとはこれですな。ありがたく使わせていただくことにしよう。
160x100はこれくらいだった。ちょっと間違ってた。。 https://t.co/n467t8oA2M
ただまあこの解像度でもフルカラーだとかなりの表現力がありそうだな。。
いま美咲フォントを表示するための仮想テキスト VRAMの設計をしている。ここ数日は美咲フォントをどのようにデータ化するか考えてたんだけどようやく考えがまとまった感じ。
エンコードはutf-16のリトルエンディアンにする。フォントを調べてたらbdfというフォントのフォーマットのデータがあって、それはUnicodeで定義されてた。そして美咲フォントもコードポイントが0xffffまでにおさまってるしね。複合文字とかサロゲートペアは仮想VRAMのレイヤーでは無いことにする😅
それでbdfファイルの内容を読み込んで、横256キャラ、縦256キャラのキャラクタ用テクスチャに展開するわけですな。そしてそれを使って文字をレンダリングするのですな。1文字8x8pxなので2048ｘ2048のテクスチャとなる。
テキスト仮想VRAMは40x25で、1文字あたり4バイト確保する。2バイトはコードポイント指定用で、2バイトはアトリビュート用。ブリンクとか色指定とかそういうやつね。なかなか豪勢な仕様ですな。。
仮想VRAMにコードポイントとアトリビュートを書き込むと、それをシェーダでテキストビットマップに展開する。GPUで昔のCRTコントローラのエミュレーションみたいなことをするわけ。
フォントデータを256x256(2048x2048px)のビットマップにレンダリングしてみた。ほとんど空白だけどまあこんなもんですわな。。一応ちゃんと変換できとるな。。 https://t.co/tZiWmTgyGK
なんかこのドット感がいいねえ。。 https://t.co/cyXJVHGxnw
実際のデータは1px=1bitとして横8pxを1byteにパックしてる。そしてそれが256x256x8個あるから512Kbyteの容量になる。gzip圧縮すると65kbyteくらいの大きさ。
16GBくらい普通の時代でも、メインメモリが16kとかそういう時代のPCから触ってると512kbyteは巨大データな感がある。
空白の部分はある程度のブロック単位で詰めて、コードポイントをビットマップ位置に変換するところで吸収しようかなと思ったりもするけどね。。
そうすると非圧縮でも256Kbyte前後にはなりそうだよね。
WebGL側にはフォーマットR8のテクスチャでこのデータを収める。そしてピクセルシェーダーで描画位置のテキストVRAMテクスチャからコードポイントを読み出す。
読み出したコードポイントを使ってビットマップテクスチャの位置を計算して1byteを読み出す。
さらにその１byteから描画対象のビットを求めてそのビットが立っていたら描画する。
このあたりの処理はWebGL2.0になって整数のビット演算ができるようになったんでとても楽にできるようになったんだよね。
160x100pxの仮想画面で仮想テキストVRAMを作り、美咲フォントを表示してみた。テキストVRAMは背景８色、文字色８色というもの。ドットがでかいな。こりゃ。 https://t.co/dIIm2JKB5p
一応パレットやブリンクもサポートしてるという。。あとはアルファもサポートしとけばいいかなと。。
なんかでもusampler2Dの動きが思った通りでなくてちょっと悩んでるところはある。とりあえずsampler2Dでしのいでるけどね。usampler2D使うと符号なし整数値でテクスチャルックアップできるからいいな！と思ってたんだけど、実際得られる値がなんか違うんだよなあ。
これが動くサンプル。
透過指定属性を追加した。 https://t.co/o649B8HWlD
テキストVRAMはDWORD値でそれぞれの属性配置は以下の通り
bit0 ... 15 UNICODEコードポイント（utf-16）
bit16 ... 23bit アルファ値(0 ... 255)
bit24 ... 26bit 背景色(0 ... 7)
bit28 ... 30bit 文字色(0 ... 7)
bit31 ブリンク
これが一応動くサンプル。。
いやーしかしusampler2dの挙動が今ひとつ分からないなあ。やっぱりね。。
と思って色々調べたらやはり凡ミスだった。。ああ、すっきりした。。
とりあえずCRT風ポストエフェクトを外し透過状況がよくわかるようにしたのがこちら。テクスチャのルックアップもusampler2DつかってtexelFetchで処理してみてる。
https://t.co/OsMRNasRSW仮想テキストＶＲＡＭの実装
仮想テキストＶＲＡＭの実装
仮想テキストVRAMの読み取りからピクセルを返す手前までがすべて整数で処理できるようになったのはやっぱりすっきりしていいわ。。
こんなGPUシェーダの使い方してるの私ぐらいかもしれないね。。
#webgl2
ただ私が持ってるAndroid 8.0タブで実行するとちょっとチラツキが目立つ。おそらくCRT風ポストエフェクトのせいだろうな。オプションにしてフラグでON・OFFするようにしないといけないね。。
あとはこの仮想テキストVRAMをwasmのメモリにマップすればよいだけだが。さてどうしようか。
いまのところの考えとしては、メモリはJSで作ってそれを #webassembly にインポートしようと考えている。仮想的なハードウェアのメモリマップをリニアメモリで表現するわけですな。
仮想テキストVRAMはまあそのメモリの１区画を使用する。たとえばメモリオフセットの0xE000からマッピングするとなると20桁x12行・１キャラクタあたり4バイトだから960バイト確保することになる。
でその区画をtexImage2D()でテクスチャに割り当てる。
void gl.texImage2D(target, level, internalformat, width, height, border, format, type, ArrayBufferView srcData, srcOffset);
srcOffsetを0xE000にすればいけると思ってるんだよね。
もしくは
new TypedArray(buffer [, byteOffset [, length]]);
を使って、メモリに対するビューを新たに作ってそれをsrcDataに割り当ててもよいかなと。
let tvram = new Uint32Array(memoryBuffer,0xe000,240);
こんな感じかなあ。。
キーボードやゲームコントローラのI/OなんかもJSで情報を取得してメモリに書き込む。それをwasmモジュール側で読み込んで処理を行う。JSでハードウェアに近い低レベルな処理を行って、wasmに引き渡すわけですな。
高級言語で低レベル処理をして、wasmアセンブリでアプリを作るという。逆転現象。。
オーディオもWebAudio+JSで仮想波形メモリ音源を作ってそれをメモリ経由でwasmからアクセスできるようにする。これも8音ポリくらいで4bit波形メモリ＋EG+LPFくらいの仕様にしようかなと。
あとはゲーム・キャラクタを動かすエンジンをどうするかですな。いまはポイント・スプライトを使ったスプライト・エンジンを仮組みしてるけど、ローレゾで３Dキャラを動かしたいという欲求も湧き上がってきてるんだよね。。
メモリ・マップド I/O方式ですな。まさに。
ただいつもそうなんだけど、ゲーム・キャラクタのグラフィックを描くところでやる気がなえてしまうんだな。。ドット絵って難しいんだよね。絵心がない私にとってはね。。
今回はその高いハードルを越えるためにあえて160x100というローレゾでチャレンジしようと思うんだな。。量子化の粒度を粗くすれば私にも何とかなるのではないかと（笑）。
Blenderではなくもっと簡単にモデリングできるツールはないかなと思って、今MagicaVoxelを試そうとしてるという。。3Dペイントでもいいのかなと思うが。FBXのインポータを作ればいんだよな。。
ローポリでやりたいと思ってるんだよね。
ふーん。。
これは使えそうな予感。。 https://t.co/mtMCrIBrCF
まあでもいいかあ。Blenderで。ちょっと頑張るか。。そうなると160x100だとローポリであってもちときつい感がしないでもないね。。
と思ったがこれはいけそうな予感。。 https://t.co/oXFjuKfxbC
このフォーマットでそれなりなレンダラを作ればいける気がしてきたな。。
voxel-model/MagicaVoxel-file-format-vox.txt at master · ephtracy/voxel-model · GitHub
Contribute to ephtracy/voxel-model development by creating an account on GitHub.
1ピクセル=1ボックスみたいな感じでできんやろか。。
これはやる気がちょっと出てきたよ。。
9x9くらいがよさそうですなあ。。 https://t.co/YxpbBOrvQO
.voxファイルのフォーマットって、RIFFですがな。。
wavファイル読むときに書いたよな。RIFF読むやつ。。
あれだなあ。ジオメトリシェーダとかテッセレータとかあれば一点から指定された正方形のボクセルを生成できるような気もするが、その手はwebgl2では使えんしなあ。。
今考えてるのは各ボックスの座標をポイントスプライトの頂点として渡してあとはゴニョゴニョしてできんかなという感じ。
あとはトランスフォームフィードバックとか頂点シェーダでのテクスチャサンプルあたりを使ってなんとかできんかな。。
ポイントリストでどんな感じになるか試そうとしてる。もうすぐコードはできる。
一応表示できたけど、微妙に違う気が。。 https://t.co/VBZ2mZFalh
2倍に引き伸ばして回してみた。ギリギリX軸回転しとるのがわかる。。ライティングが適当すぎるのでちゃんとやらんといかんな。。
でもいけそうですな160x100pxでボクセルデータ表示は。これでキャラ作成はなんとかいけそうだ。。
ライティングちゃんとやろうと思ったら、法線ベクトルは必要ですわな。法線のことすっかり忘れてた。。
うまいこと法線を計算で求める方法はないだろうかの。。
並行光源＋「ライティングしてる風見えるいい加減ベクトル」によるライティングを実装してみた。これくらいで十分かもな。ピクセルサイズはZ座標に適当にバイアスをかけて算出するようにしてる。
こんないい加減でもそれなりに３Dに見えるのが不思議ですわな。。
11X11ボクセルのキャラを表示してみる。うむ。まあまあそれらしく表示されるね。
ちなみにキャラはボクセルのメッシュを作ってそれを組み合わせて面を作るのではなく、各ボクセル=1ピクセル（Z=0）として表示してる。ピクセルはZ座標に応じて拡縮させてる。
フレームバッファのサイズは160x100pxという小さなもの。そこに描画するからピクセルが際立つ画像になるわけですな。当然アンチエイリアスはなし。
あとはボクセルで構成された複数キャラクタを同時表示できるようにすればとりあえずは完成かな。。ピクセルを粗くすることによっていい加減でもそれなりに見えるという目標は自分の中では達成したかなと。。
と思ったが、立方体を回してみるとやっぱり法線に変わりのベクトルの処理がいい加減だから、立方体に見えん。これはちょっとな。。
ボクセルデータのなんちゃってライティングのいまいまの状況。40x40のボクセルで試してみた動画。なんか点光源のライティングみたいな感じになってる。自分としては平行光源＋環境光でライティングしてるつもりなんだけどね。。
なんか粗いポリゴンっぽい感じだけど、これはボクセル＝ピクセルとしてレンダリングしてるからね。
なのでピクセル単位で動かすなんちゅうのもできるわけですな。。
さてボクセルで作られたオブジェクトを１キャラとして、複数キャラを同時表示する部分を作ろうか。たぶんこれくらいの解像度（160×100px）であればよっぽどひどいコードを書かない限りパフォーマンスで足を引っ張ることはないだろう。。
ライティングはまだまだ改良の余地はあるけど、先に進めようと思う。
と思ったらライティング用の逆行列の計算間違っとる。。
こりゃ思ったとおりにならないはずだ。またしても凡ミスですな。。
やっぱり「なんちゃって法線」はもう少し工夫しないと「らしく」見えませんな。こりゃちょっとおかしいわ。。
これが今のところの成果物。。
voxファイルの表示
voxファイルの表示
S.F.@SFPGMR
あかん。今日はフワフワしためまいのような感じがすごくて気持ちが悪いなあ。。
ここ2-3日の気温の乱高下は体にこたえるな。ものすごく疲れている。。
S.F.@SFPGMR
TR909が持てはやされた1980年後半〜1990年あたりの曲。909のシャカシャカハイハットが全面にでてるという。。
LFOの「LFO」。シャカシャカ言ってるこの曲も繰り返し聴いたね。何がいいんだか。。
S.F.@SFPGMR
ベレッタ＠雛厄@beretta8989
奈良県民の私が、天理周辺の古墳散策の仕方を教えるね。
・池があったら古墳ある
・柿畑や墓地にしか見えなくても古墳
・小高い森や林はほぼ古墳
・それが神社だったとしても境内に古墳ある
・SHARPの工場だったとしても中に古墳ある
・怪しいと思ったら案内板が無くても大抵古墳
S.F.@SFPGMR
おお、このアセンブラニーモニックは68000ですな。。
Yuji Naka / 中 裕司さんのツイート: "Happy Birthday Sonic 28th. This is a 1990 photo of Sonic 1 under development. And Sonic 1 is a program to examine the ground. 誕生日おめでとうソニック！28回目だね。これはソニック1開発中の1990年の私の写真とソニック1の地面を調べるプログラムです。 #Sonic28th… https://t.co/ZcDke4Zl1x"
“Happy Birthday Sonic 28th. This is a 1990 photo of Sonic 1 under development. And Sonic 1 is a program to examine the ground.
誕生日おめでとうソニック！28回目だね。これはソニック1開発中の1990年の私の写真とソニック1の地面を調べるプログラムです。
#Sonic28th”
ソニック・ザ・ヘッジホッグの初版はメガドラだからそりゃそうか。。