前の記事で書いたVGS-Keyboardで、とりあえず音を鳴らす仕組みを実装。
これで、単純なMIDIキーボード対応のVGSシンセサイザーみたいな感じになりました。
この音を鳴らす仕組みですが、1鍵1voiceという面白い仕様にしました。
通常のVGS音源(6voices)とは別音源としてVGSキーボード音源という24voices(!?)の新たな音源システムを定義する形で実現。(このキーボード音源の各voiceの実体はこの辺りで実装している構造体要素ですね)
これは、本物のチップチューン音源だったら割と実現が難しいです。
ピアノ等のリアル楽器は1鍵1voice方式だから、よりリアル楽器に近い自然な実装といえますが、それだとコストが掛かり過ぎるので。
しかし、こうした方が音ゲーとして扱い易そうかなと。
今考えてる音ゲーの大枠での仕組みは、VGSのNOTEオペレーションに通常の譜面データと同じ形でノーツ発生命令みたいなものを作りそれに従って操作していく感じのもので、このノーツに合わせて鍵盤を叩くことがゲームの操作としてそれとは別のスキームで発音ロジックを実装していくというものです。つまり、それなら音源システムはオリジナルVGS音源とは別枠にしておいた方が何かと都合が良いということになります...多分(この辺はカンだけを頼りに作っているので必ずしも正解ではないかもしれません)。
まずは、東方VGSの曲データをベースにして、とりあえず1曲遊べる状態のものを作ってみないと分からないですね。(理屈を捏ねる時間があったらコードを書けと)
2017年1月29日日曜日
音ゲーをオープンソースで作っていこうと思っています
既に作り始めてます。
https://github.com/suzukiplan/vgs-keyboard
https://github.com/suzukiplan/vgs-keyboard
もっとも、この記事を書いている時点ではMIDIキーボードの入力に合わせて鍵盤を描画するだけみたいな感じですが。
音ゲーというのは、比較的歴史が浅いこともあって、特許回避などが非常に面倒くさいジャンルとして知られています。歴史が浅いといっても、代表的な特許が出願からそろそろ20年経過して効力が切れようとしている頃合いなので、来年あたりから自由度が増してくるかもしれませんが。
ちなみに、README.mdの方で書いていますが、ゲーム本体はオープンソース&完全無料です。ついでに、コンテンツのデータ・フォーマットについてもデコーダ部分はオープンという、ほぼおっ広げ状態で開発していこうと思っています。
ゆくゆくは、楽曲データを同人ショップで売るなどしてマネタイズしようという作戦ですが、当面は(これがゲームとして面白いと確信できるまでは)無料で出すつもりです。
2017年1月28日土曜日
OSXでMIDIキーボードの入力信号を取得する方法(完結編)
前回と前々回の記事の続きです。
簡単におさらいしておくと、
・前々回:MIKMIDIを使えば実現できそうだと理解。
・前回:MIKMIDIを使ってnanoKEY2のデバイス情報が取れることを確認。
という感じで、今回はMIKMIDIを使って、nanoKEY2の入力信号をハンドリングする方法の解説です。
先に回答を書くと、以下のような感じで実装すれば、「★ココで捕捉」の箇所で入力信号を捕捉できます。
以降は、上記の実装をザックリと解説するだけなので、コードだけ見れば分かる人は読まなくても、もう自分のプログラムでMIDIキーボードを入力機器として使うことができますね。
まず、MIKMIDIDeviceManagerのavailableDevicesで接続されているデバイスの一覧を取得します。
デバイスの実体(MIKMIDIDeviceのMIKMIDIEntity)には、
・source endpoint
・destination endpoint
という2種類の情報があり、入力信号を捕捉するにはsource endpointの方を使います。
入力信号の捕捉は、MIKMIDIDeviceManagerのconnectInputで対象のsource endpointを指定してあげれば、入力信号が発生した時にeventHandlerがコールバックされるという感じです。
簡単ですね。
で、このプログラムを動作させた状態で、nanoKEY2の「ド」のキーを押してみると、押したタイミングで、XCodeのconsoleに
という感じのMIDIイベント(MIKMIDICommand)が発生します。
そして、キーを離してみると、
というMIKMIDICommandが発生しました。
つまり、キーボードのキーを押すとcommand 159が発生して、離すとcommand 143が発生するという感じでしょうか。そして、noteで対象の音階が分かるという感じです。
いやー、簡単ですね。このMIKMIDIというライブラリはCore MIDIというframeworkを使っているのですが、直にCore MIDIを叩くよりは大分楽な感じではないでしょうか。
しかも、OSXだけでなくiOSにも対応しているので、入力機器としてブルートゥースMIDIキーボードを使うiPhoneアプリなんかも作れてしまうのではないでしょうか。(今回はスマホ関連のことは未調査ですが)
簡単におさらいしておくと、
・前々回:MIKMIDIを使えば実現できそうだと理解。
・前回:MIKMIDIを使ってnanoKEY2のデバイス情報が取れることを確認。
という感じで、今回はMIKMIDIを使って、nanoKEY2の入力信号をハンドリングする方法の解説です。
先に回答を書くと、以下のような感じで実装すれば、「★ココで捕捉」の箇所で入力信号を捕捉できます。
MIKMIDIDeviceManager* dm = [MIKMIDIDeviceManager sharedDeviceManager];
NSArray<MIKMIDIDevice*>* devices = [dm availableDevices];
for (MIKMIDIDevice* device in devices) {
NSArray<MIKMIDIEntity*>* entities = device.entities;
for (MIKMIDIEntity* entity in entities) {
NSArray<MIKMIDISourceEndpoint*>* sources = entity.sources;
for (MIKMIDISourceEndpoint* source in sources) {
NSLog(@"source: %@", source);
[dm connectInput:source error:nil eventHandler:^(MIKMIDISourceEndpoint * _Nonnull source, NSArray<MIKMIDICommand *> * _Nonnull commands) {
// ★ココで捕捉
NSLog(@"detected commands: %@", commands);
}];
}
}
}
}
以降は、上記の実装をザックリと解説するだけなので、コードだけ見れば分かる人は読まなくても、もう自分のプログラムでMIDIキーボードを入力機器として使うことができますね。
まず、MIKMIDIDeviceManagerのavailableDevicesで接続されているデバイスの一覧を取得します。
デバイスの実体(MIKMIDIDeviceのMIKMIDIEntity)には、
・source endpoint
・destination endpoint
という2種類の情報があり、入力信号を捕捉するにはsource endpointの方を使います。
入力信号の捕捉は、MIKMIDIDeviceManagerのconnectInputで対象のsource endpointを指定してあげれば、入力信号が発生した時にeventHandlerがコールバックされるという感じです。
簡単ですね。
で、このプログラムを動作させた状態で、nanoKEY2の「ド」のキーを押してみると、押したタイミングで、XCodeのconsoleに
2017-01-28 18:41:57.014351 VGSKeyboard[36587:9378038] detected commands: (
"<MIKMIDINoteOnCommand: 0x600000024aa0> time: 18:41:57.013 command: 159 channel 0 note: 48 velocity: 118 \n\tdata: <903076>")
という感じのMIDIイベント(MIKMIDICommand)が発生します。
そして、キーを離してみると、
VGSKeyboard[36587:9378038] detected commands: (
"<MIKMIDINoteOffCommand: 0x608000029860> time: 18:41:57.549 command: 143 channel 0 note: 48 velocity: 64 \n\tdata: <803040>")
というMIKMIDICommandが発生しました。
いやー、簡単ですね。このMIKMIDIというライブラリはCore MIDIというframeworkを使っているのですが、直にCore MIDIを叩くよりは大分楽な感じではないでしょうか。
しかも、OSXだけでなくiOSにも対応しているので、入力機器としてブルートゥースMIDIキーボードを使うiPhoneアプリなんかも作れてしまうのではないでしょうか。(今回はスマホ関連のことは未調査ですが)
OSXでMIDIキーボードからの入力信号を取得する(導入編)
前の記事で書いた MIKMIDI を使ってみる件の導入編です。
まず、XCodeで適当なプロジェクト(VGSKeyboard)を作り、CocoaPodsでMIKMIDIを取り込みます。
Podfileを以下のように作成して、
pod update と pod install を実行すれば取り込めます。
そして、podにより生成されたワークスペース(VGSKeyboard.xcworkspace)を開き、ViewController.mでとりあえず、デバイス一覧を拾ってログに出すコードを書いてみました。
そして、実行してXCodeのログを確認してみたところ、
おぉ、ちゃんとnanoKEY2のデバイス情報が取れている。
まず、XCodeで適当なプロジェクト(VGSKeyboard)を作り、CocoaPodsでMIKMIDIを取り込みます。
Podfileを以下のように作成して、
source 'https://github.com/mixedinkey-opensource/MIKMIDI.git'
target 'VGSKeyboard' do
pod 'MIKMIDI', :git => 'https://github.com/mixedinkey-opensource/MIKMIDI.git'
end
pod update と pod install を実行すれば取り込めます。
そして、podにより生成されたワークスペース(VGSKeyboard.xcworkspace)を開き、ViewController.mでとりあえず、デバイス一覧を拾ってログに出すコードを書いてみました。
$ git diff VGSKeyboard/ViewController.m
diff --git a/VGSKeyboard/ViewController.m b/VGSKeyboard/ViewController.m
index 6ba3050..e9a5aea 100644
--- a/VGSKeyboard/ViewController.m
+++ b/VGSKeyboard/ViewController.m
@@ -7,13 +7,15 @@
//
#import "ViewController.h"
+#import "MIKMIDI.h"
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
- // Do any additional setup after loading the view.
+ NSArray* availableMIDIDevices = [[MIKMIDIDeviceManager sharedDeviceManager] availableDevices];
+ NSLog(@"availableMIDIDevices: %@", availableMIDIDevices);
}
そして、実行してXCodeのログを確認してみたところ、
2017-01-28 15:54:45.962064 VGSKeyboard[34236:9311302] availableMIDIDevices: (
"<MIKMIDIDevice: 0x608000262100> Bluetooth:
Entities: {
}",
"<MIKMIDIDevice: 0x600000075a40> \U30cd\U30c3\U30c8\U30ef\U30fc\U30af:
Entities: {
}",
"<MIKMIDIDevice: 0x6080002628c0> nanoKEY2:
Entities: {
<MIKMIDIEntity: 0x600000075a80> nanoKEY2:
Sources: {
<MIKMIDISourceEndpoint: 0x600000051a60> nanoKEY2 KEYBOARD,
}
Destinations: {
<MIKMIDIDestinationEndpoint: 0x608000047890> nanoKEY2 CTRL,
},
}"
)
おぉ、ちゃんとnanoKEY2のデバイス情報が取れている。
OSXでMIDIキーボードからの入力信号を取得する方法(模索中)
VGSの技術を応用した音ゲーとか作ったら面白いかもしれない。
という訳で、MacにMIDIキーボードを繋いで、そこから入力信号を拾うにはどうしたものか。
以前、ゲームパッドの入力信号を拾うため、色々と調べてみた結果、IOKitを使えば良いということが分かり、gamepad-osxというライブラリを作りました。
これは、IOKitのHID(Human Interface Device)の接続・切断・入力信号を拾う機能を使って実現しています。
MIDIキーボードも、HIDの一種と言えるので、同じ方式でいけるのでは?
と、思って色々と試してみたのですが、どうもMIDIキーボードはHIDとして認識されないらしい。ちなみに、使っているMIDIキーボードはKORGのnanoKEY2です。このMIDIキーボードは、Logicでは普通に使えているので、OSとしては認識できているようです。
MIDIキーボードはHIDとは別の手段で入力を検出するのかな?
そう思ってGitHubで何か良いものは無いものかと探してみたところ、良さそうなヤツがありました。
https://github.com/mixedinkey-opensource/MIKMIDI
上記を使えば、MIDIキーボードに限らず、MIDIデバイス全般を操作(MIDI信号の送受信)ができるらしいです。コレを使って、MIDIキーボードをMIDIデバイスとしてコンテキストが取れれば、そこから入力信号が取れる筈。
とりあえず、今回は足回りはコレで何とかなりそうだということで、試しに使ってみよう。
使ってみた結果の記事は別途書くつもりです。
という訳で、MacにMIDIキーボードを繋いで、そこから入力信号を拾うにはどうしたものか。
以前、ゲームパッドの入力信号を拾うため、色々と調べてみた結果、IOKitを使えば良いということが分かり、gamepad-osxというライブラリを作りました。
これは、IOKitのHID(Human Interface Device)の接続・切断・入力信号を拾う機能を使って実現しています。
MIDIキーボードも、HIDの一種と言えるので、同じ方式でいけるのでは?
と、思って色々と試してみたのですが、どうもMIDIキーボードはHIDとして認識されないらしい。ちなみに、使っているMIDIキーボードはKORGのnanoKEY2です。このMIDIキーボードは、Logicでは普通に使えているので、OSとしては認識できているようです。
MIDIキーボードはHIDとは別の手段で入力を検出するのかな?
そう思ってGitHubで何か良いものは無いものかと探してみたところ、良さそうなヤツがありました。
https://github.com/mixedinkey-opensource/MIKMIDI
上記を使えば、MIDIキーボードに限らず、MIDIデバイス全般を操作(MIDI信号の送受信)ができるらしいです。コレを使って、MIDIキーボードをMIDIデバイスとしてコンテキストが取れれば、そこから入力信号が取れる筈。
とりあえず、今回は足回りはコレで何とかなりそうだということで、試しに使ってみよう。
使ってみた結果の記事は別途書くつもりです。
Apple開発者アカウントをどうするか
Apple開発者アカウントの更新時期がそろそろ迫ってきました。
が、今回は更新しようか若干悩ましい。
今のところ、更新しない方向で考えています。
最低限、更新できる程度の売上がAppStoreから出ていれば良いのですが、ここ1年間、新作を出していないこともあって、更新費用(12000円)すら稼げていない感じです。(ちなみに、過去365日での売上は37ドルと67セントで、収益は26ドルと9セント)
新作を作ろうとする意欲はまだ有るのですが、今作っているものはPC(Windows+Mac)向けで、MacであればAppStoreよりはWindowsとセットで出せるSteamとかの方が良いと思っていて、それならApple開発者アカウント(正確にはAppStoreでの配信権)を維持する必要がありません。
仮に更新しなかった場合、SUZUKI PLAN製のアプリをAppStoreから新たにインストールすることができなくなります。念のため、最近のダウンロード数をかなり久々にチェックしてみましたが、東方VGSとかはまだ1日平均100ダウンロードぐらいされているらしい。東方強い。
が、今回は更新しようか若干悩ましい。
今のところ、更新しない方向で考えています。
最低限、更新できる程度の売上がAppStoreから出ていれば良いのですが、ここ1年間、新作を出していないこともあって、更新費用(12000円)すら稼げていない感じです。(ちなみに、過去365日での売上は37ドルと67セントで、収益は26ドルと9セント)
新作を作ろうとする意欲はまだ有るのですが、今作っているものはPC(Windows+Mac)向けで、MacであればAppStoreよりはWindowsとセットで出せるSteamとかの方が良いと思っていて、それならApple開発者アカウント(正確にはAppStoreでの配信権)を維持する必要がありません。
仮に更新しなかった場合、SUZUKI PLAN製のアプリをAppStoreから新たにインストールすることができなくなります。念のため、最近のダウンロード数をかなり久々にチェックしてみましたが、東方VGSとかはまだ1日平均100ダウンロードぐらいされているらしい。東方強い。
2017年1月23日月曜日
若者の酒離れ
私は酒をほぼ飲みません。
だたし、下戸ではないです。
ビールは苦いからあまり好きではないですが、日本酒であれば、美味しいものは美味しいと思っていたりします。ですが、飲むのはほぼ飲み会限定で、飲み会が無ければほぼ飲みません。稀にコンビニで買って飲むことがありますが、それも、数ヶ月に1回あるか無いかという頻度です。
「若者の酒離れ」みたいなキーワードの記事をチラホラ見るので、これは恐らく私に限ったことではなく、世間一般で起きている現象らしい。
http://www.zakzak.co.jp/society/domestic/news/20161231/dms1612311000006-n1.htm
お酒といえば、そういえば主にビール類等の酒税がもうすぐ変わるとか。
今まで境界があやふやだったビール類(ビール、金麦、第三のビールなど)の酒税が統一され、その結果、ビールの税額は若干安くなるが、金麦や第三のビールは高くなる(ビールと同じ税額になる)らしいです。
発泡酒(ビールなど)、醸造酒(日本酒、ワインなど)、蒸留酒(ウィスキー、ウォッカ、焼酎など)などの製法毎に税率が別れる感じになるとか。これ自体はシンプルで良いねと他人事のように思っています。
この改定は、「メーカーと協議した上で決定」しているということは、国にとっては税収、メーカーにとっては売上がこれで上がると踏んでいるんでしょうけど、それで(税収・売上が)上がるのか割と疑問です。
少し話しが逸れますが、酒に関する法律の話しで、よく「免許を持っていない人が酒を造るのは違法」といったことを聞きますが、これは、酒税法7条で酒を製造するには免許が必要だからと規定しているためです(同法で罰則も規定されています)。
酒に税を掛けたり、製造を免許制にするのは、世界的には割と普通なことですが、日本で酒の製造を免許制にしたのは明治32年から(参考)と、割と歴史的に見て浅かったりします。江戸時代やそれ以前にも普通に酒屋はあった筈なので、もっと前からあったのではないかと思っていたのですが、明治以降の近代化という名の「西洋かぶれ化」のムーブメントの過程でようやく誕生したものなんですね。
酒の製造免許を取ることは、設備を準備するのが難しい関係で個人ではほぼ無理ですが、酒を作ることそのものは割と簡単なようです。まぁ、実際に作ったことが無いから分からないですが、コチラのサイトでどぶろくの作り方を確認した限り、素人でも作れそうです。(当然、クオリティの高いものを作れるかは別でしょうけど)
で、仮に酒の個人製造が合法化された場合、酒を飲む人は皆個人で酒を作って飲むから税収は落ちるか?高度成長期より前の物質が豊かでなかった頃と違い、現代であれば個人製造する手間を支払うより、安定した品質で且つ量産化できる設備が整ったメーカー製のモノにカネを支払う方が安いはずなので、(販売さえ抑えておけば)税収への影響は皆無だろうと思います。
この推測が正しければ、免許制度を製造から販売に変えても税収と売上は変わらないということになります。
しかし、酒造りにも「モノをつくることの楽しさ」みたいなものはある筈で、実際、それを巡って起きた裁判(通称、どぶろく裁判)なんかもあったりしたようです(参考)。この裁判は結局国が勝っています。ですが、モノをつくることに対する欲求は、食欲や性欲などと同じぐらい人間の根源的欲求みたいなもので、それを法で縛るのはどうなんだろうと。勿論、規制する必要性があるのであればともかく、果たしてその必要性は有るのかがイマイチよく分かりません。そして、割とこういう所で本来発生している筈の需要の原体験みたいなものを潰してしまっていることがあるので、それによる上積み分が「税収も売上も伸びるのではないだろうか」と思っている根拠です。
つまり、昨今言われている「若者の酒離れ」の根本的な原因は、その需要の原体験みたいなものを潰したことによるものだろうという風に考えている訳です。
まぁ、額にしてどんくらいとか全然分かりませんが。ついでに、参考で出したどぶろく裁判の主旨によると「個人に製造を許すと税収が減ると予想される」とのことなので、判例ベースで考えれば、先述した「現代であれば個人製造する手間を支払うより、安定した品質で且つ量産化できる設備が整ったメーカー製のモノにカネを支払う方が安いはずなので、(販売さえ抑えておけば)税収への影響は皆無だろう」という私の考え方は、最高裁判所のお墨付きで間違っている(と予想される)ということになります。
だたし、下戸ではないです。
ビールは苦いからあまり好きではないですが、日本酒であれば、美味しいものは美味しいと思っていたりします。ですが、飲むのはほぼ飲み会限定で、飲み会が無ければほぼ飲みません。稀にコンビニで買って飲むことがありますが、それも、数ヶ月に1回あるか無いかという頻度です。
「若者の酒離れ」みたいなキーワードの記事をチラホラ見るので、これは恐らく私に限ったことではなく、世間一般で起きている現象らしい。
【参考記事】
進む若者の酒離れ 20代男性の4割が「月に1回も飲まない」理由http://www.zakzak.co.jp/society/domestic/news/20161231/dms1612311000006-n1.htm
若者の「酒離れ」は必然! そもそも日本人の約半数は酒が弱いので「無理やり飲ませてた今までが問題」
若者の「酒離れ」は本当だった! 飲食店はノンアルコール飲料で若者を呼ぶ時代になる?
お酒といえば、そういえば主にビール類等の酒税がもうすぐ変わるとか。
ビール類酒税55円に統一へ 10月めど メーカーと本格協議 来年度税制改正
今まで境界があやふやだったビール類(ビール、金麦、第三のビールなど)の酒税が統一され、その結果、ビールの税額は若干安くなるが、金麦や第三のビールは高くなる(ビールと同じ税額になる)らしいです。
発泡酒(ビールなど)、醸造酒(日本酒、ワインなど)、蒸留酒(ウィスキー、ウォッカ、焼酎など)などの製法毎に税率が別れる感じになるとか。これ自体はシンプルで良いねと他人事のように思っています。
この改定は、「メーカーと協議した上で決定」しているということは、国にとっては税収、メーカーにとっては売上がこれで上がると踏んでいるんでしょうけど、それで(税収・売上が)上がるのか割と疑問です。
少し話しが逸れますが、酒に関する法律の話しで、よく「免許を持っていない人が酒を造るのは違法」といったことを聞きますが、これは、酒税法7条で酒を製造するには免許が必要だからと規定しているためです(同法で罰則も規定されています)。
そういえば、昔自宅で梅酒みたいなものを作っていた気がするが、あれは違法なのかな?と思ったのですが、梅酒とかについては合法らしい(国税庁のHPのQ&Aを参照)。以下、全く根拠の無い妄言を書きますが、私は、この法律で免許が必要とするものを「製造」ではなく「販売目的での製造」などにした方が、税収も売上も伸びるのではないだろうかと考えています。
酒に税を掛けたり、製造を免許制にするのは、世界的には割と普通なことですが、日本で酒の製造を免許制にしたのは明治32年から(参考)と、割と歴史的に見て浅かったりします。江戸時代やそれ以前にも普通に酒屋はあった筈なので、もっと前からあったのではないかと思っていたのですが、明治以降の近代化という名の「西洋かぶれ化」のムーブメントの過程でようやく誕生したものなんですね。
酒の製造免許を取ることは、設備を準備するのが難しい関係で個人ではほぼ無理ですが、酒を作ることそのものは割と簡単なようです。まぁ、実際に作ったことが無いから分からないですが、コチラのサイトでどぶろくの作り方を確認した限り、素人でも作れそうです。(当然、クオリティの高いものを作れるかは別でしょうけど)
で、仮に酒の個人製造が合法化された場合、酒を飲む人は皆個人で酒を作って飲むから税収は落ちるか?高度成長期より前の物質が豊かでなかった頃と違い、現代であれば個人製造する手間を支払うより、安定した品質で且つ量産化できる設備が整ったメーカー製のモノにカネを支払う方が安いはずなので、(販売さえ抑えておけば)税収への影響は皆無だろうと思います。
この推測が正しければ、免許制度を製造から販売に変えても税収と売上は変わらないということになります。
しかし、酒造りにも「モノをつくることの楽しさ」みたいなものはある筈で、実際、それを巡って起きた裁判(通称、どぶろく裁判)なんかもあったりしたようです(参考)。この裁判は結局国が勝っています。ですが、モノをつくることに対する欲求は、食欲や性欲などと同じぐらい人間の根源的欲求みたいなもので、それを法で縛るのはどうなんだろうと。勿論、規制する必要性があるのであればともかく、果たしてその必要性は有るのかがイマイチよく分かりません。そして、割とこういう所で本来発生している筈の需要の原体験みたいなものを潰してしまっていることがあるので、それによる上積み分が「税収も売上も伸びるのではないだろうか」と思っている根拠です。
つまり、昨今言われている「若者の酒離れ」の根本的な原因は、その需要の原体験みたいなものを潰したことによるものだろうという風に考えている訳です。
まぁ、額にしてどんくらいとか全然分かりませんが。ついでに、参考で出したどぶろく裁判の主旨によると「個人に製造を許すと税収が減ると予想される」とのことなので、判例ベースで考えれば、先述した「現代であれば個人製造する手間を支払うより、安定した品質で且つ量産化できる設備が整ったメーカー製のモノにカネを支払う方が安いはずなので、(販売さえ抑えておけば)税収への影響は皆無だろう」という私の考え方は、最高裁判所のお墨付きで間違っている(と予想される)ということになります。
登録:
投稿 (Atom)
合理的ではないものを作りたい
ここ最近、実機版の東方VGSの開発が忙しくて、東方VGSの曲追加が滞っています。 東方VGS(実機版)のデザインを作りながら検討中。基本レトロUIベースですがシークバーはモダンに倣おうかな…とか pic.twitter.com/YOYprlDsYD — SUZUKI PLAN (...
-
家電量販店のPCゲームパッドコーナーに行くと、軒並みWindows用のゲームパッドしか売っていません。稀に「Mac OS X対応」を謳っているゲームパッドも置いてありますが、実際に動かしてみると妙に誤動作をして更にガッカリしたりとか(経験済み)。 色々と試してみたのですが、最...
-
MSX版「覇邪の封印」の攻略情報を書きます。 MSX版には、パッケージに布製の地図とフィギュアが同梱されていますが、これらは単なるオマケではなく、ゲームをプレイするために必要なツールでして、説明書でもフィギュアの左足部分を現在位置に置いてプレイする旨が指示されています。実際に地図...
-
ゲームボーイのCPUについて、誤った技術情報が検索トップの方に表示されるので、私が把握する限りでZ80との仕様差を書いておきます。 ゲームボーイのCPUとは? ☓ 8080 ☓ Z80 ○ 8080カスタム or Z80カスタム(正確にはSHARPのLR35902) ...