|
|
(08/21) MAME改造0.223-アフターバーナーII （＋前回のセット）
(04/10) MAME改造ver0.196-ビートマニア1stと2nd
(09/21) MAME改造ver0.189-ベラボーマン・フェイスオフ
(05/21) メガブラスト：開幕で装備変更方法(2015年5月22日追記)
(11/27) MAME改造ver0.156-ベラボーマン・フェイスオフ
(10/17) 続々々：MAME改造-ベラボーマン・フェイスオフ
(07/29) 続続：MAME改造-ベラボーマン・フェイスオフ
|
タイトル横の画像は管理人から返信ありマークです
|
|
http://kani.blog.shinobi.jp/Entry/240/
(ソースはこちらの11月30日の記事で更新しました)
どうでもいい改造。
ソース内の英語のつづり間違いをちょっとだけ修正。
comunication → communication
controler → controller
pallette → palette
pallete → palette
(ソースはこちらの11月30日の記事で更新しました)
どうでもいい改造。
ソース内の英語のつづり間違いをちょっとだけ修正。
comunication → communication
controler → controller
pallette → palette
pallete → palette
PR
http://kani.blog.shinobi.jp/Entry/238/
(ソースはこちらの11月16日の記事で更新しました)
ナムコゲーの反転表示を全面的に直すよ、という作業の続きです。
前にtoypopの画像処理とソースの書き方が似ているものを改造すると書きましたが、
xeviousは似てなかったけど気になったので手を出してしまいました。
むしろ逆にtoypopの書き方に似せて書き直しました。
で、
ギドスパリオの破壊画像がおかしかったのでコレも直したかったのですが、今回はあきらめました。
かなり手ごわいので、長期戦になりそうです。
一応こんなかんじのことまで調査。
スプライトROM容量いっぱいのスプライト番号が
最大 0x013f
なのに対して、ギドスパリオの破壊画像のスプライト番号が
0x0104, 0x0184, 0x0105, 0x0185, 0x0106, 0x0186, 0x0107, 0x0187(終了)
になる。
(ソースはこちらの11月16日の記事で更新しました)
ナムコゲーの反転表示を全面的に直すよ、という作業の続きです。
前にtoypopの画像処理とソースの書き方が似ているものを改造すると書きましたが、
xeviousは似てなかったけど気になったので手を出してしまいました。
むしろ逆にtoypopの書き方に似せて書き直しました。
で、
ギドスパリオの破壊画像がおかしかったのでコレも直したかったのですが、今回はあきらめました。
かなり手ごわいので、長期戦になりそうです。
一応こんなかんじのことまで調査。
スプライトROM容量いっぱいのスプライト番号が
最大 0x013f
なのに対して、ギドスパリオの破壊画像のスプライト番号が
0x0104, 0x0184, 0x0105, 0x0185, 0x0106, 0x0186, 0x0107, 0x0187(終了)
になる。
https://blog.cnobi.jp/v1/blog/user/17efd160d8c7775430967cb4b2b26db4/1320056494
改造ソースのダウンロードは↑ココから。
10月31日からの改造も一緒に入っています。
11月1日以降で改造した表示関連のソースについて、
src\mame\video\baraduke.c
src\mame\video\digdug.c
src\mame\video\galaga.c
src\mame\video\gaplus.c
src\mame\video\mappy.c
src\mame\video\pacland.c
src\mame\video\retofinv.c
src\mame\video\skykid.c
src\mame\video\toypop.c
きちんと命令ひとつひとつの目的を考えながら描画アルゴリズム内を読んでみました。
画面上でのドット単位の調整の後に8ビットマスクをとってたり、
10ビットの座標に8ビットのマスクをとってみたり、
x座標にしなきゃいけない計算をy座標にしていたり、
など、上記のファイルが担当しているゲームは全部やばそうです。
ダメそうに見えたのは全部、3つ目に挙げた間違いが主な原因です。
大丈夫そうに見えるのも、影響のある座標をたまたま使っていなかったから助かっていただけみたい。
MAME全体で使えるタイルマップルーチンが開発されたらそれに対応するパッチをあてて、
みたいな改造を少しずつ加えていくうちに徐々に変になったのではないかと思います。
せっかく気づいたので、上記ファイル内のゲームを全て改善しようと思います。
改善のつもりが改悪してる可能性もじゅうぶんあるので、ゆっくり少しずつ慎重にやっていきます。
できたら、どなたか検査の協力をお願いします。
今回までに改善したつもりのゲーム
●digdug ●galaga ●libble rabble ●toypop
改造ソースのダウンロードは↑ココから。
10月31日からの改造も一緒に入っています。
11月1日以降で改造した表示関連のソースについて、
src\mame\video\baraduke.c
src\mame\video\digdug.c
src\mame\video\galaga.c
src\mame\video\gaplus.c
src\mame\video\mappy.c
src\mame\video\pacland.c
src\mame\video\retofinv.c
src\mame\video\skykid.c
src\mame\video\toypop.c
きちんと命令ひとつひとつの目的を考えながら描画アルゴリズム内を読んでみました。
画面上でのドット単位の調整の後に8ビットマスクをとってたり、
10ビットの座標に8ビットのマスクをとってみたり、
x座標にしなきゃいけない計算をy座標にしていたり、
など、上記のファイルが担当しているゲームは全部やばそうです。
ダメそうに見えたのは全部、3つ目に挙げた間違いが主な原因です。
大丈夫そうに見えるのも、影響のある座標をたまたま使っていなかったから助かっていただけみたい。
MAME全体で使えるタイルマップルーチンが開発されたらそれに対応するパッチをあてて、
みたいな改造を少しずつ加えていくうちに徐々に変になったのではないかと思います。
せっかく気づいたので、上記ファイル内のゲームを全て改善しようと思います。
改善のつもりが改悪してる可能性もじゅうぶんあるので、ゆっくり少しずつ慎重にやっていきます。
できたら、どなたか検査の協力をお願いします。
今回までに改善したつもりのゲーム
●digdug ●galaga ●libble rabble ●toypop
http://kani.blog.shinobi.jp/Entry/235/
(ソースはこちらの11月11日の記事で更新しました)
前回の日記で書いた反転表示がおかしいもののうち、
トイポップとリブルラブルだけ修正できました。
src\mame\video\toypop.c line 258
(改造前)
sy += 40;
(改造後)
//sy += 40;
まだ自力で直せていないものの共通点は
縦画面
みたいです。
bosconianは横画面なのに全然大丈夫ではありませんが、
縦画面のgalagaを基本にしたプログラムを90度横に倒しています。
(ソースはこちらの11月11日の記事で更新しました)
前回の日記で書いた反転表示がおかしいもののうち、
トイポップとリブルラブルだけ修正できました。
src\mame\video\toypop.c line 258
(改造前)
sy += 40;
(改造後)
//sy += 40;
まだ自力で直せていないものの共通点は
縦画面
みたいです。
bosconianは横画面なのに全然大丈夫ではありませんが、
縦画面のgalagaを基本にしたプログラムを90度横に倒しています。
一個だけタイトーが混ざってるけどな。
http://kani.blog.shinobi.jp/Entry/234/
(ソースはこちらの11月2日の記事で更新しました)
改造したファイル
src\mame\video\baraduke.c
src\mame\video\digdug.c
src\mame\video\galaga.c
src\mame\video\gaplus.c
src\mame\video\mappy.c
src\mame\video\pacland.c
src\mame\video\retofinv.c
src\mame\video\skykid.c
src\mame\video\toypop.c
0.143u7 の toypop.c で改造したのとそっくりな構造をしたスプライト描画ルーチンを同じように改造した。
0.143u7の説明で書いたこと
--------ここから
描画ルーチン内のforループのカウンタのメモリ確保を効率化。
「C++」コンパイラになってからできるようになった
for (int i=0; i<max; i++)
という書き方を利用する。
ブーリアン型(0か1にしかならない)としてしか使っていない変数 sizex,sizey,flipx,flipy を使って
(sizex * flipx)
(sizey * flipy)
という掛け算をしている箇所を、ビット積算に変更した。
計算結果は同一。
一般的に機械語レベルでの掛け算割り算はビット演算に比べて遅い。
--------ここまで
(ビット積算・ビット演算の部分は、間違えて論理積算・論理演算て書いてた)
mappy.c の中の phozon もそっくりだけど、
それは sizex,sizey が 0,1,2,3 の値になるので
真似して同じ改造をしてはいけません。
●●●●●●●●●●●●●●●●●●●●
動作確認したところ、ほとんどのゲームの反転表示がおかしくなっていました。
でも
baraduke, pacland, skykid
は大丈夫そうに見えましたが、少ししか触ってないので完全に大丈夫かはわかりません。
自分の改造が失敗したのかと思ってあせったけど、どうやら以前からあったバグみたい。
toypop は 0.125までは正常 0.126からおかしい
mappy は 0.113は正常 途中はまだ調べてない 0.124はおかしい
そのうちなんとかしたいね。
http://kani.blog.shinobi.jp/Entry/234/
(こちらの11月2日の記事でトイポップとリブルラブルだけ修正しました)
http://kani.blog.shinobi.jp/Entry/234/
(ソースはこちらの11月2日の記事で更新しました)
改造したファイル
src\mame\video\baraduke.c
src\mame\video\digdug.c
src\mame\video\galaga.c
src\mame\video\gaplus.c
src\mame\video\mappy.c
src\mame\video\pacland.c
src\mame\video\retofinv.c
src\mame\video\skykid.c
src\mame\video\toypop.c
0.143u7 の toypop.c で改造したのとそっくりな構造をしたスプライト描画ルーチンを同じように改造した。
0.143u7の説明で書いたこと
--------ここから
描画ルーチン内のforループのカウンタのメモリ確保を効率化。
「C++」コンパイラになってからできるようになった
for (int i=0; i<max; i++)
という書き方を利用する。
ブーリアン型(0か1にしかならない)としてしか使っていない変数 sizex,sizey,flipx,flipy を使って
(sizex * flipx)
(sizey * flipy)
という掛け算をしている箇所を、ビット積算に変更した。
計算結果は同一。
一般的に機械語レベルでの掛け算割り算はビット演算に比べて遅い。
--------ここまで
(ビット積算・ビット演算の部分は、間違えて論理積算・論理演算て書いてた)
mappy.c の中の phozon もそっくりだけど、
それは sizex,sizey が 0,1,2,3 の値になるので
真似して同じ改造をしてはいけません。
●●●●●●●●●●●●●●●●●●●●
動作確認したところ、ほとんどのゲームの反転表示がおかしくなっていました。
でも
baraduke, pacland, skykid
は大丈夫そうに見えましたが、少ししか触ってないので完全に大丈夫かはわかりません。
自分の改造が失敗したのかと思ってあせったけど、どうやら以前からあったバグみたい。
toypop は 0.125までは正常 0.126からおかしい
mappy は 0.113は正常 途中はまだ調べてない 0.124はおかしい
そのうちなんとかしたいね。
http://kani.blog.shinobi.jp/Entry/234/
(こちらの11月2日の記事でトイポップとリブルラブルだけ修正しました)
http://kani.blog.shinobi.jp/Entry/250/
(ソースはこちらの12月26日の記事で更新しました)
http://kani.blog.shinobi.jp/Entry/228/
こちらの日記で公開したものに対して、マクロを削ったほうがいいよ
みたいな助言をもらえたので、やってみました。
あと、バトルガレッガの海外版は、普通はプレイできないセッティングがあるのですが、
特殊テストモードならプレイ可能になることに気づいたので、全部有効にしました。
リージョンの名前の後ろに「Never End ROM RAM Check」て書いてあるのが該当します。
それから、イースターエッグ追加。
(1)
バトルガレッガで、魔法キャラコマンドとHARDやSPECIALを併用する方法。
A B C を押す時に放さないで押しっぱなしにして、
STARTを押すところで不要なボタンを放す。
(2)
バトライダーとバトルバクレイドも、バトルガレッガと同様の
特殊テストモードからゲームを始めると「SPECIAL VERSION」になる。
特殊テストモード中にレバー左右でリージョンの変更ができる。
(ソースはこちらの12月26日の記事で更新しました)
http://kani.blog.shinobi.jp/Entry/228/
こちらの日記で公開したものに対して、マクロを削ったほうがいいよ
みたいな助言をもらえたので、やってみました。
あと、バトルガレッガの海外版は、普通はプレイできないセッティングがあるのですが、
特殊テストモードならプレイ可能になることに気づいたので、全部有効にしました。
リージョンの名前の後ろに「Never End ROM RAM Check」て書いてあるのが該当します。
それから、イースターエッグ追加。
(1)
バトルガレッガで、魔法キャラコマンドとHARDやSPECIALを併用する方法。
A B C を押す時に放さないで押しっぱなしにして、
STARTを押すところで不要なボタンを放す。
(2)
バトライダーとバトルバクレイドも、バトルガレッガと同様の
特殊テストモードからゲームを始めると「SPECIAL VERSION」になる。
特殊テストモード中にレバー左右でリージョンの変更ができる。
前の日記のコメントを読んだ人ならわかるとおり、
アナログジョイスティックの件は、
標準の入力装置の割り当てに問題があるのでそれを直せばいい、
ということになって巻き戻ったそうです。
改造した自分としても処理が複雑化するのは嫌いなので、
今回とられた、問題のほうを取り除くやりかたは嬉しかったりします。
あと、まだ気づかなかったバグを結構生んでたみたいでごめんなさい。
アナログデバイスを別のもので代用する処理を単純にカットすれば
（件の一行を「if(1)」に書き換える）理想的な動きになることに気づいてから、
これをどうやって、代用品をカットしないでも同じ動作にできるかを
色々と考えたわけですが、公式のほうで代用品の割り当てを変える
という対応で全て解決できてしまって、結果的に無駄な努力になりましたｗｗ
そんなわけで、これまでこの件で色々協力してくれた人たちに、
ありがとうございました。
アナログジョイスティックの件は、
標準の入力装置の割り当てに問題があるのでそれを直せばいい、
ということになって巻き戻ったそうです。
改造した自分としても処理が複雑化するのは嫌いなので、
今回とられた、問題のほうを取り除くやりかたは嬉しかったりします。
あと、まだ気づかなかったバグを結構生んでたみたいでごめんなさい。
アナログデバイスを別のもので代用する処理を単純にカットすれば
（件の一行を「if(1)」に書き換える）理想的な動きになることに気づいてから、
これをどうやって、代用品をカットしないでも同じ動作にできるかを
色々と考えたわけですが、公式のほうで代用品の割り当てを変える
という対応で全て解決できてしまって、結果的に無駄な努力になりましたｗｗ
そんなわけで、これまでこの件で色々協力してくれた人たちに、
ありがとうございました。
u8の改造を公開しようとしたら、公式がu9になってたでござる。
作業やり直すので、前の話題でお茶を濁す。
ソースを公開した時にブログでは一行で説明していましたが、
ソースの添付ファイルにこんな説明をつけていました。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
● ループレバーなどの入力ルーチンを修正
まずは誤動作の確認方法。
SNKの「怒」を、P1STARTを押さえながら起動するとテストモードになる。
青い四角がたくさん並んでいる画面になったらP1STARTを２回押すと入力テスト画面になる。
そのなかの「P1 DAIAL」と「P2 DAIAL」がループレバーの項目。（つづりはキニスンナ）
「X」キーをチョンチョンと短く何度も押して数字の動作をよく見ると、
正しくは「9,10,11,12,1,2,3,4」になるはずのところ、
ときどき「9,10,11,12,(空白),1,2,3,4」になることがある。
原因は２つある。
１つ目。
数字の繰り返し構造を再現する処理において最小値の算出を間違っている。
２つ目。
個別のゲームのドライバーを作る都合で、MAMEが発生した数値の増減の向きを
逆転させると作りやすい場合があるが、その逆転させる処理に使うための基準となる数値の
算出を間違っている。
普通は一瞬のことなので気づかれにくいが、トラックボール、パドルなどの
無限回転の構造をもったデバイスすべてが同じ状態である。
これを修正した。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
● アナログジョイスティックなどの入力ルーチンを改善
アナログジョイスティックを使用するゲームで
（スペースハリアー、ナイトストライカーなど）、
PCにアナログジョイスティックをつないでプレイする時、
ユーザーの設定で
「Analog Controls」
「AD Stick X Digital Speed」= 0
「AD Stick X Autocenter Speed」= 0
「AD Stick Y Digital Speed」= 0
「AD Stick Y Autocenter Speed」= 0
「Input (This Game)」
「AD Stick X Analog Dec」= None
「AD Stick X Analog Inc」= None
「AD Stick Y Analog Dec」= None
「AD Stick Y Analog Inc」= None
にするなど、かなり工夫しないと、スティックを途中まで傾けて静止しようとすると
傾きが小さいと中央に戻されそうなる
傾きが大きいと画面端まで引っ張られそうになる
という現象がおきる。
原因は、アナログジョイスティックを静止させることは、ユーザーがそれを使った入力を
していないこととみなす設計をしてある（と想像できる構造をしている）ため、次の段に
用意された、デジタルジョイスティックをアナログジョイスティックの代わりに使う
ための処理が誤動作してしまう。
PCでは、ジョイスティックのデジタルとアナログの使い方に違いはなく、デジタルは、
アナログが使える数字の最小値・中央値・最大値の３種類で返せばいいんじゃないか
という作りになっている。
MAMEはその３種類以外の半端な数値は近いほうの数値に読み替えて処理する。
これを、ユーザーが上記の設定をしなくてもすぐにプレイできるようにした。
改造内容は、
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
ユーザーが手を放すと定位置に戻る機能がついてるアナログ入力デバイスは
（ジョイスティック、ハンドル、ペダルなど）、
その戻る定位置（ハンドルなら中央）とその近辺のアソビの範囲から外れている場合は、
静止していても、ユーザーがその状態を入力しているものとして受け付けるようにした。
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
それで、公式のu9での更新では
前回の日記
http://kani.blog.shinobi.jp/Entry/229/
に書いた間違いを無くすために、
このアナログジョイスティックのほうの処理をu7の時の状態に戻されています。
ループレバーのほうの処理は入ったまま続行のようです。
間違いに気づいて修正の記事を書いたのにそっちが採用されていないのは
おそらく、もっと念入りに検査せえや、てことだと思います。
作業やり直すので、前の話題でお茶を濁す。
ソースを公開した時にブログでは一行で説明していましたが、
ソースの添付ファイルにこんな説明をつけていました。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
● ループレバーなどの入力ルーチンを修正
まずは誤動作の確認方法。
SNKの「怒」を、P1STARTを押さえながら起動するとテストモードになる。
青い四角がたくさん並んでいる画面になったらP1STARTを２回押すと入力テスト画面になる。
そのなかの「P1 DAIAL」と「P2 DAIAL」がループレバーの項目。（つづりはキニスンナ）
「X」キーをチョンチョンと短く何度も押して数字の動作をよく見ると、
正しくは「9,10,11,12,1,2,3,4」になるはずのところ、
ときどき「9,10,11,12,(空白),1,2,3,4」になることがある。
原因は２つある。
１つ目。
数字の繰り返し構造を再現する処理において最小値の算出を間違っている。
２つ目。
個別のゲームのドライバーを作る都合で、MAMEが発生した数値の増減の向きを
逆転させると作りやすい場合があるが、その逆転させる処理に使うための基準となる数値の
算出を間違っている。
普通は一瞬のことなので気づかれにくいが、トラックボール、パドルなどの
無限回転の構造をもったデバイスすべてが同じ状態である。
これを修正した。
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
● アナログジョイスティックなどの入力ルーチンを改善
アナログジョイスティックを使用するゲームで
（スペースハリアー、ナイトストライカーなど）、
PCにアナログジョイスティックをつないでプレイする時、
ユーザーの設定で
「Analog Controls」
「AD Stick X Digital Speed」= 0
「AD Stick X Autocenter Speed」= 0
「AD Stick Y Digital Speed」= 0
「AD Stick Y Autocenter Speed」= 0
「Input (This Game)」
「AD Stick X Analog Dec」= None
「AD Stick X Analog Inc」= None
「AD Stick Y Analog Dec」= None
「AD Stick Y Analog Inc」= None
にするなど、かなり工夫しないと、スティックを途中まで傾けて静止しようとすると
傾きが小さいと中央に戻されそうなる
傾きが大きいと画面端まで引っ張られそうになる
という現象がおきる。
原因は、アナログジョイスティックを静止させることは、ユーザーがそれを使った入力を
していないこととみなす設計をしてある（と想像できる構造をしている）ため、次の段に
用意された、デジタルジョイスティックをアナログジョイスティックの代わりに使う
ための処理が誤動作してしまう。
PCでは、ジョイスティックのデジタルとアナログの使い方に違いはなく、デジタルは、
アナログが使える数字の最小値・中央値・最大値の３種類で返せばいいんじゃないか
という作りになっている。
MAMEはその３種類以外の半端な数値は近いほうの数値に読み替えて処理する。
これを、ユーザーが上記の設定をしなくてもすぐにプレイできるようにした。
改造内容は、
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
ユーザーが手を放すと定位置に戻る機能がついてるアナログ入力デバイスは
（ジョイスティック、ハンドル、ペダルなど）、
その戻る定位置（ハンドルなら中央）とその近辺のアソビの範囲から外れている場合は、
静止していても、ユーザーがその状態を入力しているものとして受け付けるようにした。
□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□□
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
それで、公式のu9での更新では
前回の日記
http://kani.blog.shinobi.jp/Entry/229/
に書いた間違いを無くすために、
このアナログジョイスティックのほうの処理をu7の時の状態に戻されています。
ループレバーのほうの処理は入ったまま続行のようです。
間違いに気づいて修正の記事を書いたのにそっちが採用されていないのは
おそらく、もっと念入りに検査せえや、てことだと思います。
https://blog.cnobi.jp/v1/blog/user/17efd160d8c7775430967cb4b2b26db4/1319644113
改造ソース
(diff形式のzipでなく、ソースのままのzipです)
(前回入れた、東亜プランやビートマニアの改造も入っています)
MAMEのドライバーで「ペダル」として定義してある入力が
キーボードで操作できないバグを作ってしまっていた。
申し訳ないです。
修正しました。
src\emu\ioport.c
2715行目修正
(誤)
if ((analog->previousanalog != rawvalue) || (analog->absolute && analog->autocenter && analog->centerdelta != 0 && rawvalue != 0))
(正)
if ((analog->previousanalog != rawvalue) || (analog->absolute && analog->autocenter && analog->centerdelta != 0 && rawvalue != analog->center))
前回の記事に付いたコメントへの返信でこれからやりますと書いたものはまだ入っていません。
grindstmの"different"が云々というのだけ対処してあります。
改造ソース
(diff形式のzipでなく、ソースのままのzipです)
(前回入れた、東亜プランやビートマニアの改造も入っています)
MAMEのドライバーで「ペダル」として定義してある入力が
キーボードで操作できないバグを作ってしまっていた。
申し訳ないです。
修正しました。
src\emu\ioport.c
2715行目修正
(誤)
if ((analog->previousanalog != rawvalue) || (analog->absolute && analog->autocenter && analog->centerdelta != 0 && rawvalue != 0))
(正)
if ((analog->previousanalog != rawvalue) || (analog->absolute && analog->autocenter && analog->centerdelta != 0 && rawvalue != analog->center))
前回の記事に付いたコメントへの返信でこれからやりますと書いたものはまだ入っていません。
grindstmの"different"が云々というのだけ対処してあります。
https://blog.cnobi.jp/v1/blog/user/17efd160d8c7775430967cb4b2b26db4/1319644113
改造ソースはこちらからダウンロードしてください。
公式版が、ver0.143u8 になりました。
これまでここで発表していたものの大部分が取り入れられています。
すみません。
取り入れられた部分にさっそく自分のミスを発見しました。
それを修正します。
src/emu/ioport.h の 248行目
(誤)
#define __ipt_gambling_start IPT_GAMBLE_HIGH
(正)
#define __ipt_gambling_start IPT_GAMBLE_KEYIN
今のところ、これだけです。
これより下記の改造に興味が無いなら、
改造ソースをダウンロードするほうが手間なので、
自分で修正をタイプしちゃってください。
修正しないと、コマンドラインで
mame -lx
と打ったときのゲームリストの中の
ギャンブルゲームの使用するスイッチに漏れが生じます。
取り入れられなかった部分は
toaplan1.c
toaplan2.c
twincobr.c
wardner.c
djmain.c
で、今回の改造ソースはこの部分が入っているだけです。
内容は特に進展なし。
公式のソースに取り入れられたことに関して、
自分が発表してから取り入れられるまでの時間がわりと短いと思うので、
ここの部分は公式の理念に反するからやっぱり撤回！
なんてこともじゅうぶん考えられるので、
自分が勝手に追加した系の改造を応用した次の改造は
もうちょっと様子（次のバージョン）を見てから取り掛かります。
(例：コイン設定の「1coin / 10credits」などの定型文字列の利用など)
改造ソースはこちらからダウンロードしてください。
公式版が、ver0.143u8 になりました。
これまでここで発表していたものの大部分が取り入れられています。
すみません。
取り入れられた部分にさっそく自分のミスを発見しました。
それを修正します。
src/emu/ioport.h の 248行目
(誤)
#define __ipt_gambling_start IPT_GAMBLE_HIGH
(正)
#define __ipt_gambling_start IPT_GAMBLE_KEYIN
今のところ、これだけです。
これより下記の改造に興味が無いなら、
改造ソースをダウンロードするほうが手間なので、
自分で修正をタイプしちゃってください。
修正しないと、コマンドラインで
mame -lx
と打ったときのゲームリストの中の
ギャンブルゲームの使用するスイッチに漏れが生じます。
取り入れられなかった部分は
toaplan1.c
toaplan2.c
twincobr.c
wardner.c
djmain.c
で、今回の改造ソースはこの部分が入っているだけです。
内容は特に進展なし。
公式のソースに取り入れられたことに関して、
自分が発表してから取り入れられるまでの時間がわりと短いと思うので、
ここの部分は公式の理念に反するからやっぱり撤回！
なんてこともじゅうぶん考えられるので、
自分が勝手に追加した系の改造を応用した次の改造は
もうちょっと様子（次のバージョン）を見てから取り掛かります。
(例：コイン設定の「1coin / 10credits」などの定型文字列の利用など)