昔のゲームはすぐバグって面白いですね

私のところは、コントロールボックスRGB出力→分配器→一つは操作用モニター、もう一つは 録画用コンバーター(XRGBフレームマイスター1080p出力)→キャプチャーボード (SC-512N1-L/DVI無圧縮avi1080p取込み)→AviUtlで編集mp4という感じです だいぶ前に作った環境なので、今ならもっといいやり方があるんじゃないかと思います コンバーターによって色合いにクセがあるようで微妙に気に入らない部分もあるんですが 修正する技術力が無い・・・

@@up2assembled 早速の返信、ありがとうございます。 その「XRGBフレームマイスター」てのが、ゲーム基板からのRGB信号をイイ感じにデジタル画像化してくれてる感じでしょうかね。自分の頃は、基板からプレイ動画を撮影する際には、コントロールボックスの映像出力をそのまま直に「VHSビデオ機器」に繋げて録画してましたので(笑)。フレームとかもズレてましたし、とにかく映像の滲みが酷かった記憶しかありません。 KZbin上でも時々、色んなゲーム基板から録画したプレイ動画が投稿されていますが、どれも画質が良くない感じだったので、自分の頃と比べても余り録画技術は進歩していないのかと思っていましたが…。その「映像信号コンバータ」の種類や性能によって出来上がりがピンきりになるのかもしれませんね。 P.S. 編集ソフトの機能にもよりますが。物理機器の方で色々と調整を完璧に行うのは非常に手間がかかりますので、よほど変になっていない限り、とりあえず初期設定というか安定録画可能な設定でアナログ映像として素材録画してしまい。その後にAVIやMPEG形式のデジタル動画に変換してから、それを色々と色調整とか行う方が編集作業的にも楽だと思いますよ。 人間の目基準だとどうしてもファジー感覚になるので、タイトル画面とかのスクショ画像をMAME版と比較しながら色合わせ等を行い、その色補正数値を一括で動画の方にもデジタル処理する感じでいいんじゃないかと思います。

@@WARASUBOFACTORYアドバイスありがとうございます 私もちょっと聞きたいことがあるんですが このゲームのラスボスは最初に停止していて、こちらの攻撃が先にできるんですが その攻撃が同じ間合い(ドット単位)、同じタイミング(フレーム単位)で 攻撃してもヒットするときとガードになるときがあって、そういう反応は 他の対戦格闘のCPUでも割とあったりしますか？やっぱりランダムなのかなぁと思ったので

@@up2assembled ＞ヒットorガード 結論から言えば「ゲームによる」としか。結局は全てはゲーム内のプログラム次第というか、どういった処理ルーチンを組んでいるのかに依存しますので。 例えば『餓狼伝説 (1991/SNK)』では通常のR中であれば、プレイヤキャラとCOMのお互いの打撃技を同時にカチ合わせる事により、いわゆる「相打ち」が発生しますが。これを互いの体力をギリギリまで減らして後1発でKOになる様な状態にしてから実行すると、何故かその最後の瞬間だけは絶対に「相打ち」が発生せずにプレイヤキャラかCOMキャラのどちらかが必ず生き残り、スト2みたいな "DKO" は絶対に発生しないのですが。これは内部プログラムのKO判定処理が1P側と2P側(COM側)で同じ1フレーム内に同時処理が完結されず、時間差で先に1P側から判定が行われた後に次のフレームに以降した後で2P側のKO判定が処理されるために起こる怪奇現象です(従ってプレイヤキャラ、COMキャラを問わずに2P側に居る方が必ず生き残る)。 同じCAPCOM社のゲームであれば『ストリートファイターII (1991/CAPCOM)』でも。通常、格闘ゲームの常識と言うか、相手の攻撃はレバーを後ろ方向へ入れて置く事で自動的に「ガード」になるシステムになっていますが。一部の技がガード不能になるバグというか仕様があって、それは「攻撃発生が1フレームの技は密着状態だとガード不能になる」というモノです。厳密に言うと「1/2でガード不能になる」という事が分かっています。ブランカの「ローリング」とか、サガットの「アッパーカット」がこれに該当します。 これらは恐らく1990年代前半のPCB性能だと演算速度に不安があったので、幾つかの処理が重なって重くなりそうな場合には、画面描画が遅れる様な「処理落ち」をさせる事無くスムーズにゲーム進行を処理するために、意図的に判定処理を分散させて同一フレーム内で処理させずに、次フレームへ持ち越して処理させる事によってプレイヤに体感での遅延を感じさせない様な内部処理をおこなっているせいではないかと推測します。逆に考えなしに全ての処理を漫然とゲーム内で発生した順に次々と立て続けに処理させる様なプログラムならば、複数の処理が1フレーム内に集中してしまった時には『グラディウス (1985/konami)』みたいな "処理落ち" が発生してしまいます。 今でこそ「処理落ち」は一種の演出として認められていますが。少なくとも1980年～1990年代前半くらいまでは「プログラマーの恥」として認識されていましたし、あってはならない事だという認識が一般的でしたので。当時のプログラマー達はあの手この手の裏技的ハックを駆使して、何としても「処理落ちだけは回避する」というのがまともなプログラマーの矜持だった様に思います。 スト2の「ガード不能」の事例も、その技が発生した瞬間の処理で「1/2で～」みたいになっている訳では無く、恐らく「奇数フレーム時は攻撃側の処理を優先し、偶数フレーム時は防御側の処理を優先」みたいな感じで内部処理を行っているため、結果的に「1/2でガード不能=ランダム」みたいになっているのだと思います。この『闘いの挽歌』でも恐らく似た様な内部処理が行われた結果、プレイヤキャラ側の攻撃開始の距離px数等は同一であるにも関わらず、恐らくはゲーム基板の起動fps数(電源ON時間)によって結果にランダム性が生じているのではないかなと推測します。 こういった「フレーム単位での厳密な計測」は実機PCBを用いてだと非常に困難であり、こういったフレーム関連の検証作業は事実上、MAME等のエミュ環境でしか検証不可能だと思われます。

@@WARASUBOFACTORY 想像以上の詳細な解説ありがとうございました 大変勉強になりました

いい曲ですよね

炎の剣の威力です。 炎の剣は確かに最強の威力！ですが1振りで体力1減少が欠点です(´・ω・`)

実物は見た事ないですが、MAMEのソースコードだと同じシステム1基板ですね

4画面にある宝玉を全部叩き壊すと1面クリア。 敵は「あっ！」ボタンで気をそらさないと基本倒せない。 ドアは上レバーで入れて他のドアにワープでき、光るドアに入れば主人公が一定時間無敵

同感です

ホントだ

もう市場に出回ったから修正不可能です(笑)。

おお、ついに来ましたか 続きやりませんか？ 一万点更新は見当がつきませんが・・・

@@up2assembled ほんの僅かには考えてますがｗハイスコア更新を前提だと他のタイトル2～3つを検討した方が遥かにましなレベルで極まっていますのでちょっと・・・ｗ 今までずっと連無しで検証してきたので連付きだとどこまで可能なのかはまるで検討ついて無いです。

宝にたどり着いたとき、サイが一緒に喜ぶのがかわいいですね スタート時のBGMが印象に残ってます

３周はすごい インストに書いてありましたが、エビの名前はイートガブルス 3:41 あれは面食らいますよね

Sorry,I only understand a little English. Will it be a high score when approaching and attacking? If so, it is easier to hold down the attack button when approaching.

Thank you!