【68000】メガドライブ用ソフト開発 3本目【Z80】
クソゲー作って萎えましょう。
- ここ数年間に完成された新作ソフト -
ピエアー ソーラー (RPG)
ttp://www.piersolar.com/
Uwol- Quest For Money (アクション)
ttp://shiru.untergrund.net/software.shtml (Mega Drive の項目)
ベガー プリンス (RPG)
ttp://www.beggarprince.com/
Pringles Game (アクション)
http://68000.web.fc2.com/pringles.html せっかく人生の年月ついやして作るなら、他人に遊んでもらえるゲーム作ろうと俺なんかは思うけど
画面やら映像やら公開されても結局おれらは遊ぶことができない絵に描いた餅みたいなもんだし
しかもＰＳ４で筐体除けば本物が普通に遊べる今となってはって感じだけだな まぁでも趣味ってそういうものじゃない？
作らない立場から「俺だったら…」って話こそ意味を成さないわけで まぁ確かにクローンゲームの宿命というかそんなもんだよな
筐体（少し縮小）ごとWin版ダラをプログラムで組んで再現したブログもどっかで読んだ記憶あるんだが
製作途中で製作主の嫁から「それ作って何か意味あるの？」ってつっこまれたんだっけか、、
（記憶違いだったらスマン） 最初の目標がそもそもフリーで公開か、有料で売るのか、技術的に完成なのか
それぞれ置いてるゴールが違うんだから仕方がないよ（クローンだけにデータが流出でもしない限りは、盆栽の写真を見せられて称える気持ちと一緒）
まぁ、画面見せられて遊べないって気持ちは分からんでもないが、、 >>156
趣味なんだから好きに作ればいいよな
実際に手を動かして作成している人が偉いと思う スマン、ズレたな…
＞趣味なんだから好きに作ればいいよな
には同意なので 制作者仲間だったり同レベルで語れる人と交流ができてるみたいだし
意義はあるでしょ そこに意義があるなら制作者仲間だったり同レベルで語れる人だけでやればいい
動画なんかで一般公開すればプレイできないのが残念って思ってるやつの気持ちも汲んでやれよ 動画なら完成度の想像がつくから、遊べなくても動画だけでも見てみたいという需要はあると思う。
それに勝手に移植系なら著作権の問題があるからROMそのものを公開するのは難しい。 何そのクレクレ君に配慮して控えるべきって
一般公開してなかったら今のような仲間なんて集まってなかったろ
ここは製作技術板なんだし「俺も作る」とか建設的な話はできないもんかね
遊びたいから権利関係がクリアできるよう協力したいとかさ（無理だろうけど）
何もしてない側が妨害だけする流れ嫌いだわ >>154に貼られた動画（他の主がうｐしてる動画もだけど）、付いてるコメントを読むとね…
中には当時のプログラマーは何をしていたんだ〜だったかな…詮ないことも目にして少しモヤモヤしてたかも知れん、申し訳ない 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だとインストール出来ないので 企業コンテンツへのやり方としていいか悪いかは置いといて凄いのは凄い
愛があれば犯していいと、できちゃったから認知しては企業とタイミングがよかったな
寸止め１面だけ作ってみたや他の勝手移植連中はこれを目指すんですかね 勝手移植は出来上がっても動画を見て貰うだけしかできないのがなぁ。
>>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の色階調に合うように変色したのち
64ｘ96の枠に収まるように位置調整して切り取った後でBMPからMDのパックドピクセルに変換して・・・。
本当は減色をかけずにハイライトシャドーで対応しようかとも思ったけど、
キャラサイズが大きくてマスク分のパターンを定義するとパターン書き換えでは対応できなくなりそうだから止めた。
DMAで転送できるのはV_INT1回あたり約7KB。96ｘ64=6144ドット、2ドットで1バイトなので3072バイト。
スプライトアトリビュート640バイト、パレット128バイト、横ラスタスクロール1024バイトも毎回転送を行うのでこれで約5KB。
スクロール時に背景の書き換えも行うけど、こちらは途切れ途切れになるからDMAは使えず、余裕持たせる必要もあるし。
結構ギリギリっぽい。・・・しっかし・・・久しぶりにドット絵なんてやったから・・・目がチカチカするｗ せっかくオリジナルゲーム作るのに
フリー素材はもったいないな その辺りは難しいところ。例えば勝手移植の場合だと画像も音声も素材は揃ってて
プログラムをひたすら組んでいけば何とかなる。あとは根性のみ。
一人でゲームを作ろうとするとキャラを書いてドット絵に直して登録して、作曲してデータ化して、って
プログラムまで行きつけないんだよね。
フリー素材ではあるけど作者さんと連絡が取れて、
足りないパターンはフリー素材としてだけど追加すると言ってくれてるので使わせてもらう事にした。
まさかのメガドライブという事で驚いてたけど。 そもそも「絵心？作曲？何それ、美味しいの？」ってレベルの人間だからねぇ。プログラムに集中したい。
主人公は女の子なんだけど、これは単にPCMで喋らせた時に映えるんじゃね？と言う考えから。
PCMもBGMを鳴らしながら綺麗に喋らせられるであろう方法はある程度浮かんでいるので。
曲は・・・最悪クラシックでも持ってくるかとｗ フリー素材でも何かをリスペクトしたゲーム（結果Ｒタイプとパルスターくらい似てても）でも
堂々と公開できるもんのほうがええよｗ
そりゃ人気作品を完全トレースすれば注目もあびて気持ちええかも知れんが
ゲームに合うフリー素材を探すのも作者のセンスだぜ！ 今回のは多分キャラの大きさに合ったゲーム作りになりそう。
そもそもゲーム機なんかでゲームを完成させた事なんてないけど。
変換ツールとかは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でもどうにもならんねｗ
しっかしアクションゲームのジャンプだけでここまでてこずるとは思ってもみなかったな。 MDのゲーム作りしてる人はツイッターにもいるから
情報を得たいならそちらの方面も考えてみるといいかも。 
