【68000】メガドライブ用ソフト開発 3本目【Z80】
https://ameblo.jp/arcade-cabinet/entry-12259767161.html
このゲームのダウンロード出来ませんか?
それとメガドライブ実機用のSDカード使えるカセット欲しいのですが
ネット通販で調べると色々あるのですがどれが一番お勧めでしょうか? メガドライブ実機用のSDカード使えるカセット欲しいのですが
Amazon等ネット通販で調べると色々あるのですがどれが一番お勧めでしょうか? メガドライブ実機用のSDカード使えるカセット欲しいのですが
Amazon等ネット通販で調べると色々あるのですがどれが一番お勧めでしょうか? everdriveのHPで機能比較してみればいいんじゃない? >>172
公式みてもよくわかりませんでした
日本人で実際に使っている方の使用感想があれば参考になるのですが
調べても見当たらないんですよね 公式を見る限りでは何に対応しているかの差が書かれてるのだから
自分に必要な機能が有る物を選ぶぐらいじゃないのかな?
ttps://krikzz.com/store/home/33-mega-everdrive-x7.html メガドラミニのダライアス作った人の開発ツールってsggcなの? sega genesis SDK
で検索すると出てくるよ。 sgdkをネット上でプログラミング出来るサイトありますか?
ウチのpcだとインストール出来ないので >>175
こういう認識が流れている以上
早く経緯を公式発表したほうがいいんじぇね?と思う 納得の上引っ込めたんだろうと推測してるし、別にどうでもいいかな 発表動画ではあくまで会社が移植した体だしな
エンディングかなんかのクレジットにエントリーあるかぐらいでしか判明しないかもな
ゲームできること自体はもやもや晴れて感謝だわ ファンタジーゾーンの方も完成させて何時か出して欲しい
ttps://www.4gamer.net/games/465/G046598/20190823058/ やっぱりファンメイド版だったね。
しっかし基板用の筐体も作っていたとかどれだけダライアス(愛を超えた)馬鹿なんだろ。凄いな。 やっぱりと言うかそれ以外考えられなかったけど
まぁなんにせよ凄いよね sgdkをネット上でプログラミング出来るサイトありますか?
ウチのpcだとインストール出来ないので 企業コンテンツへのやり方としていいか悪いかは置いといて凄いのは凄い
愛があれば犯していいと、できちゃったから認知しては企業とタイミングがよかったな
寸止め1面だけ作ってみたや他の勝手移植連中はこれを目指すんですかね 勝手移植は出来上がっても動画を見て貰うだけしかできないのがなぁ。
>>184
流石にないんじゃなかろうかと。 個人アレンジならまだしも再現だと動画も怪しいなあ
つべなんかは音でもひっかかるし
メーカーが一声あげたらひっこめるしかないのが勝手移植
わかってやってるんでしょ 既に完成形が有ってそれに寄せる方が見た目でも分かりやすい。
オリジナルゲームではキャラも音も全て自作するしかなくてハードルが高くなっていくからな。 Easy68Kを使ってMDのプログラムを始めてみたけども
完全に0から始めてるからBGカラーを変えるだけで何日かかるやら。
”HALLO WORLD!”なんて先の先だな。 VDPがV_INTを発行してくれない。前やった手順と同じなんだけどなぁ・・・。 >>186
sgdk公式でネットプログラミングサイトつくってほしいですね
>>188
既存の移植度低かったタイトルを改良というのも
例えばフォゴットンワールドやヘビーユニット、雷電伝説 sgdkがインストールできないってどんなpcなんだ >>191
当時は移植度低いは残念に思えたが、
アーケードそのままかオンライン要素追加要素おまけ要素付きの
複数ゲームパッケージが当たり前の今となっては、
当時の移植度が味になっていてそれはそれで思い出を崩さんで欲しいという気持ちもある 大昔に作ったボンバーマンモドキのソースを流用して新しい何かを作ろうとしてたんだけど、
画面表示が全くうまくいかずに5日間悩んだ。>>190
DMA転送する為にVDPに与えるソースアドレスが
昔作った物と現在作っている物では違っていてそれが原因だった。
やっとBGカラーが画面に出てくれた。ここまでくれば・・・。 >>191
ファミコンのグラディウスACレベルまで行くと面白いんだけど、
ミニとかで遊んでいるとAC移植じゃないゲームの方が面白いんだよね。
今だとACゲームのエミュがメーカーから出てるから家庭用でその劣化版をACに近づけても
出オチと言うか一見で終わってしまう気がする。 やっぱりアセンブラは手強いわ。文法ミスでのエラーならアセンブラが教えてくれるけど、
アセンブラが通過してしまう文法以外のミスはしらみつぶしにチェックするしかない。
Mbit単位のROMの容量をこれで埋めていったんだから昔の技術者ってやっぱりとんでもないな。 納期もだし、容量とコスト、収支が黒か赤かの当然リアルな戦いの歴史やからなぁ…
ミニでの「やればできる子」みたいな後出しジャンケンの雰囲気を会社も一緒には…
あんまし俺は引いちゃう方だったから やっとV_INT毎にBGカラーを変える(点滅させる)事が出来た。
今度はH_INT毎にBGカラーを変えて224色同時発色に挑戦する。 とりあえずH_INT毎にBGカラーを変更する事は出来たけど重いな。これ。
デモには使えるだろうけどゲームで使うには実用的じゃないわ。
割り込み発生の都合で上2ラインが同じ色で223本までしか色が変えられえない。
https://i.imgur.com/jwbe4lH.png MDの320x224ドットモードの場合、1ラスターあたり523CPUクロックらしいけど、
割り込みの際、レジスタのPUSH,POPで148クロック持っていかれる・・・。 プログラムを見直してPUSH,POPする為のレジスタを削りまくって効率上げてみた。
ティアリングも消えて負荷もかなり落とせたので実用的に使える予感。
https://i.imgur.com/EsIMg8H.jpg 見た感じゲームってわかるぐらいの画面が公開できるのって
どれくらい先になりそう? SGDKは一切使わず完全に0からアセンブラでやってるからどうだろうね。
今、やっとフリーのキャラクタ見つけてBMPに落とし始めた所。その後BMPをMDのパターンに変換して・・・。
横スクロール型アクションゲームを作る予定だけど、
スクロールしない画面でキャラを左右に動かすところまででも2〜3週間は掛かりそう。
V_INTとH_INTでここまで躓くとは思わなかったし。プログラムを作る頭が鈍り過ぎ。 それでもテラドライブで作っていた頃よりも開発環境はかなり良くなったね。
エミュのデバッグ機能がかなり便利。それとアセンブラについてるシミュレータが有ったから、
結構複雑(だと思ってる)な事も想定道理で来たわけだし。 ハイライトシャドーを合わせてみた。
https://i.imgur.com/1FkOeQ3.png
ハイライトシャドーは常用するには癖がちょっと強い気がする。
コツを覚えれば面白い使い方が出来そう。
VDPの使い方はそれなりに把握できた気がする。 キャラクタエディタの必要性がかなり高いなぁ。
出来ればハイライトシャドー対応したものを。
こっちも自分で作るしかないかなぁ。 キャラごとにハイライトシャドーを駆使すればかなり色数かせげるのに…
って思ったことあったけど実際問題これは実用的なものとして可能なの?
どこもやってないから気になってた トイストーリーではかなり駆使されてるみたい。エンディング中ではMAX171色同時表示になるらしいから。
あとはシャイニングフォースで移動可能領域が点滅するのはハイライトシャドーを使ってるみたい。
ハイライトシャドーを指定する方法はVDPレジスタでハイライトシャドーモードを有効にする。
その後でカラーパレット3番14色目で描かれたスプライトを重ねるとその部分がハイライト状態になる
3番15色目で書かれたスプライトを重ねるとその部分がシャドー状態になる。
だからマスクでスプライトを使うから枚数が減るっていうのとマスクパターンが必要になるって事で
スプライト枚数とマスクパターンでメモリを使ってしまうってのが有るね。
このマスクパターンが横並び制限の対象になるかどうかはまだ実験してないから不明。
一番大変なのが色の管理。ノーマル状態でRGB各階調は3bitで0〜7になるんだけど、
シャドー状態は0.5刻みで0〜3.5の明るさ。ハイライト状態は同じく0.5刻みで3.5〜7の明るさとなって
ハイライト状態の0とシャドー状態の7が同じ明るさになったり、
ノーマル状態の1とシャドー状態の2が同じ明るさだったりと階調と実際の明るさが把握しにくい。
だからキャラクタパターンエディターを作って簡単に管理出来ればなぁと。
当時の開発機材の問題もあるかもね。
PC9801だと16色だからハイライトシャドー分の色が表示できないからイメージが出しにくいとか。 SGDK使わなくても作れるのですか
調べてもアセンブラーで解説しているサイト見当たらないから
ここでの発表が楽しみです
>>209
色数増加はエクスランザーでも強調されていたけど
何だか全体的に薄暗い感じしていまいちに見えました >>209
ハイライトとシャドーってそんな機能だったのか!
有効利用するにはパレット管理とゲームデザイン次第ですね。 エクスランザーの発色強化はハイライトシャドーに加えて
多分フレーム毎にパレットの色を変えて中間色のように見せかけてるんじゃないかと。
その見せかけてる色も含めての同時発色なんだと思う。フレーム毎のパレット書き換えがめちゃくちゃ激しい
トイストーリー他
https://www.youtube.com/watch?v=Z9rjwECf2wQ
エクスランザー
https://www.youtube.com/watch?v=7_9S7tgeeIo
海外製ゲーム?
https://www.youtube.com/watch?v=wJULPhhMe9Y 英語だけどハイライトシャドーの説明してる。画像だけでもたぶんイメージはつかめるかな。
https://www.youtube.com/watch?v=cVSM92CBGmc
途中でトイストーリーの虫食いのような画像が出るけど、黒い部分がマスクパターン。
変態技術としか言いようがない…。 >マスクでスプライトを使うから枚数が減るっていうのとマスクパターンが必要になるって事で
>スプライト枚数とマスクパターンでメモリを使ってしまうってのが有るね。
これはかなりのデメリットだね
気軽に色数を増やすためには使いたくないかも 本来はその名通り影とスポットライトに使う物だからね。
副産物として色数が増えてるってだけ。 フリー素材としてキャラクタを提供してくれてる人に連絡が付いたから主人公をMDで表示する作業を進め中。
ただ・・・元の素材がPCを基準にした大きさだからMDで使うにはかなり大きい。
その辺りの事はすっかり忘れてた。でもアクションが可愛いからそのまま使おうかと。
ちなみにサイズは・・・64x96・・・立ち絵だけで画面の高さ半分近く。
これを基にアクションゲームを作るとなるとかなり難しくなるな。
31色のBMPを15色に減色かけて更にMDの色階調に合うように変色したのち
64x96の枠に収まるように位置調整して切り取った後でBMPからMDのパックドピクセルに変換して・・・。
本当は減色をかけずにハイライトシャドーで対応しようかとも思ったけど、
キャラサイズが大きくてマスク分のパターンを定義するとパターン書き換えでは対応できなくなりそうだから止めた。
DMAで転送できるのはV_INT1回あたり約7KB。96x64=6144ドット、2ドットで1バイトなので3072バイト。
スプライトアトリビュート640バイト、パレット128バイト、横ラスタスクロール1024バイトも毎回転送を行うのでこれで約5KB。
スクロール時に背景の書き換えも行うけど、こちらは途切れ途切れになるからDMAは使えず、余裕持たせる必要もあるし。
結構ギリギリっぽい。・・・しっかし・・・久しぶりにドット絵なんてやったから・・・目がチカチカするw せっかくオリジナルゲーム作るのに
フリー素材はもったいないな その辺りは難しいところ。例えば勝手移植の場合だと画像も音声も素材は揃ってて
プログラムをひたすら組んでいけば何とかなる。あとは根性のみ。
一人でゲームを作ろうとするとキャラを書いてドット絵に直して登録して、作曲してデータ化して、って
プログラムまで行きつけないんだよね。
フリー素材ではあるけど作者さんと連絡が取れて、
足りないパターンはフリー素材としてだけど追加すると言ってくれてるので使わせてもらう事にした。
まさかのメガドライブという事で驚いてたけど。 そもそも「絵心?作曲?何それ、美味しいの?」ってレベルの人間だからねぇ。プログラムに集中したい。
主人公は女の子なんだけど、これは単にPCMで喋らせた時に映えるんじゃね?と言う考えから。
PCMもBGMを鳴らしながら綺麗に喋らせられるであろう方法はある程度浮かんでいるので。
曲は・・・最悪クラシックでも持ってくるかとw フリー素材でも何かをリスペクトしたゲーム(結果Rタイプとパルスターくらい似てても)でも
堂々と公開できるもんのほうがええよw
そりゃ人気作品を完全トレースすれば注目もあびて気持ちええかも知れんが
ゲームに合うフリー素材を探すのも作者のセンスだぜ! 今回のは多分キャラの大きさに合ったゲーム作りになりそう。
そもそもゲーム機なんかでゲームを完成させた事なんてないけど。
変換ツールとかはWindows上で動くフリーのCを見つけたからそれでちょこちょこやってく。 今キャラパターンをデータに落としているんだけど主人公だけで132KB(1Mbit以上)食ってる。
そりゃ当時こんなことできんわな。スプライトを大きな四角で取ってるから、
スプライトの使用枚数を増やしてでもパーツ毎に切り離せばサイズは小さくできるけど、
DMAが間に合う限り大きなままで行こう。
完全にキャラクタが出来上がってないと修正するのが面倒だし。 話はそれるが
改変を許容してるフリー素材画像の制作者は本当に寛大だと思う それは本当にそう思う。キャラクターのイメージが崩れるからねぇ。
加工OKでパレットの変更もOKだそうで。特にPCで書いた画像って256色が基準になってるから。
MD用にすると15色で一気に落ちるし。今回は原画が31色だったのでギリギリまでイメージを壊さずに15色に落とし込んだつもり。
とりあえず、MDで表示してみた。まだ全く動かず、どのぐらいの大きさになるのかイメージを取りたくて。
https://i.imgur.com/RLvgcEO.png
スプライト自体は32x32を6枚で64x96。画面に映すまでは大きすぎかな?とは思ったけど案外行けそうなサイズだった。
多分フラッシュゲームなんかではよくあるRUN系?と言うのかなあんな感じのゲームを作ってみようかなと。
元ネタです。
http://www.maroon.dti.ne.jp/pata2-magic/index.html 何時までも妙な背景色のままでもイメージが取りづらいから水色から白までの7色グラデーションにしたら
やっぱり階調不足なのか色の境目が目立つ。
そこで境界線をフレーム毎に上下にブラして中間色に見せかけられるか試したけど、
結構きれいなグラデーションになってくれた。ただ若干ながらフリッカが見える。
これをエミュ上で実行するとPCの負荷によって一瞬60fpsから落ちるとその瞬間だけ元の縞模様に・・・。
あとエミュによってはそれでは済まずにエミュの中の68Kがアドレスエラーを起こして止まる。
実機ではならないようだからエミュ特有の問題っぽいんだけど。
とりあえず、今あるドット絵のパターンは全て変換できたので土日の家にパッドに合わせて動かせるようにはできるかも。 キャラの大きさといえば
龍虎の拳や豪血寺一族、バーチャファイター2は
元のより小さくて残念でした
背景は元に近い感じだったから更に小人化したように見えたのも 頭の中で単純に320x224に対して64x96のパターンを表示すると横に対して20%、縦に対して42%を占める。
あれ?大きすぎじゃね?って感じ。実際には64x96と言っても余白が有るからそこまで大きくは見えないという。
キャラクタを提供してくれてる作者に敬意を示す為にまずはクレジット表記する為の文字キャラを作り中。
そっちが完成したらキャラがとりあえず動くだけのプログラムを出せると思う。
予定では今日なんだけどねぇ。
エディタで表示してるパターンと実機の画面での差異があるからそれが気になる所。
とりあえず頑張ってみる。 よくよく考えてみると全部自力でやるとなると画面に文字を出すだけで
それ用のルーチン組まなければいけないんだった。なんか色々と忘れすぎてるな。
クレジット表記するぞ!と思ったらまずはBG面の初期化(消去)、スクロールポートの初期化、
パレットの設定、座標をワークRAMに用意したBG用フレームバッファのアドレスに変換、
BG用フレームバッファに書き込み、V_INT待ち、VINT中にフレームバッファをVRAMにDMA転送。
やる事あり過ぎる。 サウンドドライバはどうするんだろうと思ったり
>>226
とは言え容量が少ない中でキャラの大きさを維持しようとすると
サムスピみたいな悲劇が起こるしなぁ… >>229
サウンドドライバの方は大まかな構想は出来てるから、
実際に実験してその構想が通用するかどうか試す予定だけど、
ウィンドウに文字書くだけで丸1日使ったレベルだから先が長いわ。
基本的な文字パターンの登録がようやく終わって画面に文字が出せるようになった。
アルファベット大文字小文字平仮名片仮名その他記号で254文字。
画面に文字が出るだけで雰囲気が一気によくなる。
Lv1上がった!メガドライブの重要な機能の一つウィンドウの使い方を覚えた! 本業?が忙しすぎて思考が回らずプログラム停滞中。期待してくれてる人が居たらごめんなさい。
動作モーションの処理とか紙に書いて仕様の設計は進めてるんだけど。
慣れないアセンブラでそっちにも苦戦してたり。 土日でせめて女の子が動かせるようになればと思っていたけど、デバッグルーチンを書いてるだけで終わった。
あまり見る機会は無いと思うけどゲーム中に振動なんかでバグって画面に「ADDRESS ERROR」とか出るあれ。
このルーチンのテストで使ったのがEmuHawkとFusionなんだけど、
Fusionでは意図的に起こしてるアドレスエラーを何故か無視して動く。
実際のゲームでそんなバグはある訳ないから実害は無いのだけど。
今日からやっとパッド入力とキャラの動作に移行。
DMAを使いまくるから早めに負荷を確認しておかないと今後詰まりそう。 土日でせめて女の子が動かせるようになればと思っていたけど、デバッグルーチンを書いてるだけで終わった。
あまり見る機会は無いと思うけどゲーム中に振動なんかでバグって画面に「ADDRESS ERROR」とか出るあれ。
このルーチンのテストで使ったのがEmuHawkとFusionなんだけど、
Fusionでは意図的に起こしてるアドレスエラーを何故か無視して動く。
実際のゲームでそんなバグはある訳ないから実害は無いのだけど。
今日からやっとパッド入力とキャラの動作に移行。
DMAを使いまくるから早めに負荷を確認しておかないと今後詰まりそう。 DMAを使ってキャラの書き換えをしようと奮闘してるんだけど、
テストの為に使ってるDMAでのスクリーン書き換えルーチンが有ると
キャラ書き換えのDMA転送容量を超えてしまって間に合わなくなる。
スコア表示やステータス表示にウィンドウを使いDMAで描画させるのは常套手段だと思うのだけど、
画面配置を決めてDMA転送量をゲーム中に使うだけの容量に下げないとこの先が出来ない。
もっと簡単に事が進むと思っていたけど、甘くないなぁ。 操作できず。放置しているとモーションが変わっていくだけ。
ソニックザヘッジホッグなんかでも行われてる奴。
パターン間でドットがパカパカと変化したりでこれだけでも手直しが必要だったり。
10秒毎にしぐさが変わる。全10パターン。
やってる事は・・・時間が来た時だけ女の子(ポチットさん)のパターン3KBをDMA転送。
背景はBGカラーを水平割り込み毎に変更。BGカラーなのでパレットは未使用。
フレーム毎に8色背景を上下に10ドットブラして中間色っぽく見せかけてるだけ。
PCの負荷によりエミュレーターが60fpsを保てなくなるとチラついてしまう。
実機ではキッチリ60fpsを保ったままだから起こらないんだけどね。
足元の文字はウィンドウ。40文字x4行文確保。フレーム毎にDMA転送。
現在、BG-A、BG-Bは未使用。
https://20.gigafile.nu/0409-b9352b0c1017f80949fc5c284fb1ec717
pass:poch
Fusion、EmuHark、実機で動作確認済み。
ゲームとして目指すところは・・・パックランドみたいな感じかな?あそこまで行きつけばいいけども。 ダウンロードしたファイルをそのままエミュにドロップすれば起動する・・・はず
今度は歩き、走り、に挑戦中。 ありがと。3連休でジャンプ系の動きが搭載できればいいな。 wavやmp3/4ファイルをvgmファイルに変換する
ツールありますか? MDのPCMって8bitモノラルだから変換すればいけるとは思うけど
ツールは分らないな。
先週は風邪ひいたせいでプログラムが全く進んでないや・・・。
今週こそは・・・。しゃがみとジャンプは完成させたい。空中コントロールをどうするかだな。 なんでsgdkで作らんの?
Cのほうが楽だろうし、超最適にコンパイルしてくれるのに
サウンドも最高ドライバだろうし
Mなの? >>241
プログラムする上では楽だろうけど直接実機をコントロールしてる実感がわかないから。
ゲームを作る事が目的と言うよりもメガドライブを自分の手で完全にコントロールしたいって気持ちの方が強い。
サウンドドライバもどういうドライバを書けば性能を引き出せるかって事を自分の手でやってみたいから。
それと、タイミング的にシビアなコントロールを行ってるって事もあるかな。
上に上げたデモプログラムでは背景を中間色込みで14色ぐらいに見せかけてるんだけど、
H_INTが発行されてから46クロック以内にデータを書き込まないと
色の変更してる箇所が画面上に表示さえてしまう。
この46クロックとか数命令並べただけでオーバーするから、吐き出されるソースをいちいち確認しないとダメだしね。
それとVRAMやRAMの使い方もSGDKの方でコントロールされてるから好き勝手に作れない。
SDGKのライブラリを使うにしても、結局カットアンドトライを繰り返してその関数の使い方を把握するしかないから
それなら自分で直接弄った方が楽って事になってくるし。ゲームを組む上での苦労は大差ない感じもする。
ある程度、組んでいくと条件分岐なんかも自分の中でテンプレートが出来上がってくるからそれほど苦でもなくなってくるし。 ゲーム作りは鈍足ながら進めているんだけど、
本来ならあり得ない上と下、右と左の同時押しの時のエミュの挙動がそれぞれ違うんだな。
EmuHawkだと新しく入力された方向が優先、Fusion364だと上と右が優先。
マニュアル側には同時押しも意識したプログラムを作るような記述が有ったんで
それに沿ったプログラムを組んでいたのに挙動の変化がなくて何故だろうと調べてみた。
アクションが増えるにしたがって論理バグがそこら中に出て四苦八苦。 日系ソフトウェア5月号の特集、
知りたかった音楽&効果音の作り方はスルーされていて残念
自作カセットの作り方も省略されていて残念 自作のゲームをデバッグするときにgdbを使っているのですが、ステップ実行すると、PCがVINTに割り込まれます。
回避方法の情報って有りませんか? >>248
SGDKを使った事が無いからなぁ。ラエル@rael16xさん当たりなら分かるかもしれないけど。
自分がはまったのはインタラプトルーチンのバグ。
自分の使い方がアホだったのかもしれないけど、
インタラプトルーチン(V_INT、H_INT)の中にアドレスエラー等の更にインタラプトが掛かるバグが有ると
デバッグルーチンでPCカウンタの値とか正常に取得できなくてどこにバグが有るのか分からなくなる。 >>249
レスありがとうございまうす。
確かにSGDKに詳しい方や海外のフォーラムに情報が多そうですね!
>自分がはまったのはインタラプトルーチンのバグ。
レジスタを直接アクセスするとデバッグが難しくなりますよね。
そこが楽しかったりしますが、、、(^^; >>250
インタラプトルーチンさえ組み終わっちゃえばかなり楽になるよ。
エラーが起きたアドレスがレジスタに入るから不具合個所はすぐに分かるし。
ただ、論理バグはアセンブラでもCでもどうにもならんねw
しっかしアクションゲームのジャンプだけでここまでてこずるとは思ってもみなかったな。 MDのゲーム作りしてる人はツイッターにもいるから
情報を得たいならそちらの方面も考えてみるといいかも。 さすがにあくどい商売しとるなって感想
黙認しとればコストかけずに勝手に移植されてくるんだかんな・・・
ン年ついやしても勝手移植作者がそれでいいならいいけどさぁ
結局は無許諾の足下みられたら反論はできんからな >>251
ついでにおそレス
アクションのジャンプはunityとかの普通にゲーム製作ツールでも難しいぞ
いっちゃん簡単なのは障害物無しのSTGか障害物当たったら即4ぬSTG
それこそダライアスみたいなのかな FZはミニ2への布石かと思ったけど
セガが何やら雲行き怪しくなってきたからどうなるか >>256
動作関係のフラグを1つにまとめた変数を作ってビットで状況を確認をしていたんだけど、
やりたい事を増やそうとしたら16bitに収まらなくなってきた。
メモリを節約するつもりだったんだけど、
そもそも64KBもワークRAMが有ればけちる必要が無いという事で
フラグはビット化せずにワードで行うように変更掛けてる。
これに伴って全部の動作ルーチンの書き換え中。
スーマリのプログラムの凄さを今更ながら実感してる所。
「歩く」にしても途中で速度変化が起きるし「Bダッシュ」も同様。
更に方向転換でのスリップなんかもあるし、慣性で滑るのもある。
やってる事は列挙できてもそれをプログラム化すると色々絡んでくるから物凄く複雑。 昔はシルフィードの背景がポリゴンかどうか結構議論されてた気もするけど
発売前の店頭販促ビデオですでにポリゴンと背景動画の組み合わせって言ってたんだね
https://youtu.be/0rw8vmoLVMk?t=115 動画のフレーム数の話もたまに上がるけど、そもそものCDの転送能力が1秒150KBだから
長時間のアニメーションをストリーミングで表示するってめちゃくちゃ苦労してるんだろうな。
メガドライブのVRAM書き換え能力は1フレーム辺り7KB有るけど、
CDのデータ転送を1フレームに直すと2.5KBしかないし。 正直、タイトーとセガのIP安売りの版権ガバムーブは何とかしてほしい
カプコン、任天堂と比べて権利意識が低く感じる
まあ経営的に目の前の一杯の水が欲しいのが伝わってくるが ついでにに言うと
作るのは勝手だが表には出せない
だからアングラ文化で貴重だと思っていたんだが IPの安売りっつーか、切り売りっつーか、コレクターズアイテムと化してるから全種類そろえようとおもたら逆に割高
スパファンって当時FZ完全移植できる技術あったのになんでグラ変えたんやろな
事情しだいによっちゃあクリアが難しい権利処理からんできそう >>261
おいおいガバガバはカプコンだぞ
なにせMAME用ロムイメージ詰め合わせとかFBAで動くアケステ形ゲーム機とかに平気で許諾出しちゃう
今度のレトロステーションもまあその類だよ >>262
本来はアングラ活動だったのが注目されただけかと。 注目されていいように商用利用されてるな、ダラ
まあ無許可で著作物利用したんだから権利者に文句は言えんけど >>267
てか、今回の公式販売についても作者が協力してるし。
ミニで出す時の条件として全権利をタイトーに引き渡す事だったらしいから
タイトーに引き渡す前に作者とSEGAの間で何かしらの交渉もあったんだろうな。
どっちにしても元々自分の為だけに作った物が
どういう形にせよ公開という事になったのだから作者も本望じゃなかろうかと。 一緒でしょ。少なくとも絵と音楽そのまんまなんだし。
手打ちだからとか耳コピだからとか関係ない、できあがったものがそのまんまだったら泥棒と一緒。 >>272
音楽と曲の著作はTAITOだけどプログラムその物の権利はプログラマでしょ。
だから本人が「消す」という選択肢がある。
MDミニI版を出すに当たってタイトーが全ての権利を引き渡す事を条件としていたらしいから。 つまり結局どちらにしろ、楽曲とグラフィックは無断拝借ってことだな
しかもこの横スクSTGなんて、それ差し引いたらなんも残らんSTGだし
まあ今製作してる人で普通にネットとか表に出したいなら
最低でも見た目と音楽は自力でデザインするか、フリー素材使おうず そんでもちょっとでも何かしら似てるとこあって
パクリって俺なんか言われたことあるし
ただそこは独自要素との度合いだから、
世の中にはトレース画像1枚で全部すっ飛んだゲームもあるし
難しい時代だなと思う今日このごろ >>272
>>273
連投スマン
なぜかID変ったんで
まあこれの件は色々と巡り合わせとか、よかったよかったで終わったと思う >>274
個人で作って公開する分にはメーカーも黙ってるだろ。それを販売しない限りは。 前に見たブログでは、吸い出したROMデータを加工してMDのプログラム書いてから
「こんなの作りました」ってタイトーに問い合わせたら「止めて下さい」って返事があった >>274
言いたいことはわかるけどこういう人たちって
あくまでどれだけ劣化を抑えて本物同様に再現できるかを目標にして作ってるからなぁ… >>273
>>278
「消す」
「止めて下さい」
きちんと提示したならタイトーさん見直しますね。
正直、一製作者として、自分のあずかり知らぬ場所で勝手にってのは、やっぱり気持ちは悪いんですよ。
それと、ぶっこ抜きは論外、自力でトレースも完コピはMUGENキャラと同じでアウトに限りなく近いグレーで、メーカーに訴えられれば100%必ず負けますね…
だから「消す」という選択肢があることは納得。 ちなみにいわゆるパクリレベルなら、自力で手を加えた部分が多ければ多い程度とのせめぎ合いみたいな論点になるから、
フリゲで公開ならまず安全圏でしょう
商用でも、ストUと餓狼レベルでも一時期論争はあったと思うけど、キャラクターも世界観も違うし、BGMも勿論まったく違う。
それぞれ確率して仲良くコラボもしてる >>277
ツベは権利者BANありそうだけどな、特に音楽関係は メガドライブの画面構成、知ってるつもりでもいざ使うと難しいな。
BG-Aとウィンドウは同じレイヤー?に存在しウィンドウが優先だからフルサイズで開かれるとBG-Aが全部消える。
VDPレジスタを初期化する時にフルサイズ指定していた事を忘れて
BG-Aに何も表示されねぇって悩んでた。 FM6に効果音モードがあると言ってる人がいたけど、無いよね?
レジスタマップを見てもFM3のしか見当たらない。 >>290
トイストーリーのPCM4チャンネル技術はすごい
音量も音程も変えられる
ツイッターで、XGMはサイズが大きい = メガドライブでPCMは以てのほか
なんて極論言ってる人がいたけど、過去に非VGM/XGMでここまで実現されてた事を知らないんだろうなぁ VGM/XGMという呼び名が無かっただけでやってる事は同じだと思う。
音量と音程を変えられるのはその音程の音とその音量の音を全てデータとして持ってるから。
容量が使えるようになってきたから使える技術なんだけど
PCMを多用した場合今度は4MB(32Mbit)に収められるかのせめぎ合いになるから極論でもない気はする。 >>292
音量と音程を変えられるのは変換テーブルを持ってるからで、
全ての音程、音量ごとに巨大なPCMデータを抱えてるVGM/XGMとは話が違うよ。
4チャンネル合成するところが同じだけ。
さらにVGM/XGMはループも展開したログだから極端に大きいし、
ドラムみたいな各曲共通のPCMデータもそれぞれの曲データに内包される。
それを同じ扱いにするのは乱暴すぎますよ。 >>293
それだと今度はゲームで使うには処理が重くなるからゲーム内容が限定されてしまうんじゃないかと。
確かに優秀なドライバでメガドライブに可能性を見せてくれてはいるんだけど。
多分その方は自分の知ってる方なんだけど、サイズの他に処理の事にも言及していたんじゃないかな。
ダライアスのBGMを担当していて、そのプログラマとの連携もしてるから、
処理に重さについても恐らくが話を聞いてると思う。
そのプログラマはファンタジーゾーンの処理落ちで色々苦戦していたし。 >>294
もちろん処理負荷とROM容量のバランスです。
同じ人だと思うけど、PCM2チャンネル程度でPCMダメと言うのはどうかという話であって、
PCM4チャンネルで常用できると主張したいわけではないです。
MDダライアス、ファンタジーゾーンのプログラマさんもまだ伸び代のある人で、
今の彼の腕がメガドライブの限界ではない事も留意しなければならないと思います。
実際、現役時代のメガドライブでPCM複数チャンネルのBGMを鳴らしてたゲームがあるのですから。 ゲームによってはそのPCM処理が重荷になる事があるってだけ。 メガドラのスタークルーザーはZ80だけでPCM3声を音階可変させてた
重いポリゴンゲームで出来てるんだから要はプログラマーの能力次第よ
PCM1、2声くらいで重荷とかねーわ >>297
Z80を使えば68Kの負荷は減らせるけど、PCMデータがROMにある時点でそれなりの負荷がかかるよ。
MDの仕様上、DMAを使いつつPCMを鳴らす事を考えるとPCMデータをZ80のRAMにコピーする必要がある。
このコピーの間は68Kを止めるしかないから。 >>298
Z80で音階を可変させてたって話な
例えばドラムとベース音1つをZ80RAMに全部入れられれば
Z80内でベースの音階を可変、ドラムと合成してPCM2声出せる
バッファリングはそうだけどそれを行ったからってゲームにならないとは思ってないでしょ? >>299
Z80のRAMが8KBしかないから多分入らないだろうな。
綺麗に鳴らすという事を諦めれば難しい事じゃないけど。 スタークルーザーは音質悪いけど、PCM3つ分がZ80メモリに収まってるのかな? エミュでZ80のワークRAMを覗いてみたけど、プログラムは0000h-055Fhまでの1375バイトまでしか使ってなかった。
XGM/VGMはPCMの再生音質を向上させてるから負荷の掛かり方は違うと思う。
MDPLAYERでの再生だけど、歌がこのレベルで再生できるから。
https://twitter.com/CadonSnd/status/1355911464683401220
https://twitter.com/5chan_nel (5ch newer account) >>302
そのワークRAMはスタークルーザーのこと? >>303
そそ。メガドライブはZ80から68Kのメモリ空間を
32KB単位のバンク切り替えで8000h-FFFFhに呼び出す機能が有り
PCMデータはそこから読み取る方法も有るんだけど、
これだとDMA動作中はZ80を停止させる必要があるからノイジーになってしまう。
ただ、このエミュだとワークRAMだけしか覗けないからZ80がどこを参照していたのかは不明。
XGM/VGMはDMA動作中でもPCM再生を止めないようにする為に
PCMデータをワークRAMにコピーしてる。 >>304
ありがとう
68000バスをアクセスしなかったらDMA中でもZ80を使えるとか、色々あってややこしいね >>305
PCMを使うって事が当たり前になってくるとその辺りの問題がかなり大きくなってくるね。
PCMを使わなければ素直なんだけど。 元ppz8の人のメガドラ用音源ドライバー、MDZはPCMの音質がいいな
それでいてPCMの音程、音量が変更できる
頑張ればPCM複数音で音程変更できそうとの事
自作ドライバーで多重PCMで音程、音量が変更できるは今のところAMPSだけかな? 音量だけ変更可ならmdsdrvがあるね
サンプリングレートが最大17kHzくらいで2PCM
最近のgui版で3PCMになったのかな?
海外勢はPCMのノウハウがあってうらやましい ゲーム用のドライバじゃなくサウンド再生に全振りすれば結構遊べる気がしないでもない。
PCMの波形を68Kに演算させてZ80に再生を任せるとか。
ゲーム用ドライバとしてだと音質確保するには結構トリッキーなことしないとダメだから手間がかかるね。 サウンド全振りならPCM16で音程・音量可変なんてのも出来るかもね。
Stephane氏のBad Apple!!みたいなソフトウェアADPCMも可能性のひとつ。
あれは全画面アニメーションもこなしながらだけど、それであれだけ鳴らせる。 XDMだとDMAでROMが読めない期間のデータを予めZ80にワークRAMに貯めこんでるみたいだった。 トイストーリーもそのやり方だね
どうするかを考えると、そこにたどり着くんだろうな DECOのサイドポケット、68Kのクロックアップしてると音量が狂ったりするから
PCMはZ80がやってるけどBGMのFM音源への書き込みは68Kがやってるみたいだな。 >>315
多分音色変更時のレジスタ書き込みに失敗してるんだと思う。
FM音源の書き込みウェイトをBUSYフラグを使わずにクロック計算してトラック処理をしたりしてるんだろうな。
MDのクロックアップは68Kに入るクロックだけを変更してるから
FM音源やZ80へのクロックは3.58MHzのままだから音程に影響は出ないし。
68KのクロックはVDPが作り出しているんだけど通常のクロックとは別に
V_BLANK中のみ10MHzでそれ以外の期間は13MHzを出す特殊なクロックが有ってそれを利用してる。 >>316
へー、面白いな
クロックもいろいろ拾えるんだね
>BUSYフラグを使わずにクロック計算してトラック処理
Hidecadeさんが作ったドライバがビジー終了まで待つだけだったから重すぎて、
海外の人から「そんなに時間がかかるはずがない」と指摘されてたのを思い出した >>317
可変のクロックはMDのゲームの場合V_BLANKにパッドを読むゲームが多いのでかなり有効だよ。
13MHzではパッドの読み取りが失敗するけど10MHzでは間に合うから。
CPUは交換しないと多分だめだけど。 小西さんがPCM2chに挑戦し始めたな
表現力が上がっていいよね 「虚数とか社会に出ていつ使うんだよ」にセガが回答 社内勉強会用の“ガチ数学”資料公開、ゲーム開発現場で使われていた
https://nlab.itmedia.co.jp/nl/spv/2106/16/news093_0.html >>319
難しくなるのは実際にゲームに組み込んだ時なんだよな。
DMA動作時のPCM再生をどうするか。 バッファリングをいかに上手くこなせるかだな
68000側もアセンブラで書くとCより楽
MAMEのIanさんがアドバイスくれてるし、やり遂げてほしい
TOY STORYを解析するのも勉強になる >>322
SGDKはソース公開してるんじゃなかったかな? >>323
SGDKのソースも勉強になるね
小西さんはタイマポーリングにこだわると苦労するかもしれない PCM使う上でもう一つのネックになるのがFM音源の書き込みの後のウェイトかな
再生レートを上げるとFM音源のデータを書く時間も制限されるし。
音色データを書くのもPCMの生成が来ない時間を意識する必要がでてくる。 FM音源のウェイトは地味に重いんだよねぇ。
XGMドライバーはウェイト代わりに別の処理をさせてるんだっけ。
そういう仕組みは必要だね。 自分が構想してるのはZ80にPCMデータを書かせた後は
そのウェイトの間にPCMデータをROMからZ80のワークRAMに貯め込むような方法。
数回やればDMA期間中再生する為のPCMデータは貯め込めるだろうな。と。
仮に55.5KHz(PCM再生ではマックスなレート)だとすると1フレーム当たり1000バイトあると足りるから。 SGDKってwindows2000だとビルド通らないの?
ダライアスの人のサンプルエラーなるわ
XPだと通ったけど
っつか今の時代だとHUCっていうC言語のPCエンジンライブラリまであるんだね SGDKは導入だけで力尽きてまたアセンブラに戻ったしなぁ。
BMP画像をを変換してメガドラで表示させて遊んでた。 PCやスマホで描かれた15色の画像をMD用に変換してるけど
1600万色を512色に落とすのがかなり大変だわ ツイッターのドット絵師さんがローゼンメイデンを描いていたからお借りして
メガドラで表示してみた
https://i.imgur.com/MHTfLXN.jpg >>216はまだ作り続けてるのかな
ポシャったにしてもどれくらい作れてたんだろうか >>335
色々やりながらだから待ってく進んでないけどね。作るのはやめてないよ。 テラドラの写真よくあげてる人?
もしそうなら5chに費やしてる時間をちょっとでもゲーム制作にまわしてほしいぞ 勝手移植版のボンジャックとゼビウスを見て来たけどちょっとモチベーションは上がったかな。
ただ、申し訳ないがそれだけに集中していられるわけじゃないので。
キャラの動きを未だ調節してるレベル。 よくよく考えなくても
68000で動くゼビウスってゴージャスだな >>339
つっても基板だとZ80を3つ使ってるからねぇ