CALENDAR

04 | 2017/05 | 06
- 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31 - - -

PROFILE

オマエダレナンダ

Author:よな
ぴくしヴ
つい(自動応答):lilium_yonah

真理は存在しない。許されぬ行為など無い。とはいえ挟まりたくはないです。
同人活動の傍らでニコニコ動画のボカロ・ニコマス畑の片隅で隠密行動中です。

動画方面では『ヨナP』を名乗らせていただいています。このP名は頂き物なので大事に使っていきたいと思います。ありがとうございます。大百科登録もありがとうございます。

連絡先:takanesukisukibyou[あ]yahoo.co.jp
([あ]には半角@を入れてください)

REPORT

COMMENT

TRACKBACK

CATEGORY

ARCHIVE

つうはん

とらのあな様に委託中!
COMITIA105新刊(オリジナル)
■遊撃のアーキテクチャ

既刊・アイマス眼鏡本
■はるひな

MYLIST

ボカロ系マイリス

ニコマス系マイリス

LINK

SEARCH

RSS

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
イベントの嵐で吐きそうマン。
でもコンソール上でイベントいろいろいじるよりは慣れるには良さそう。というか慣れないと進むことも出来ない気がする。
ちなみにイベントといっても夏のアレコレというワケじゃないのです。

いまいちがっつり踏み込みきれないのは,将来性とかそういうもののせいだろうか。ううん。

スポンサーサイト
穏やかじゃないですね。
イベントハンドラ苦手勢。それって致命的。

そんなわけでコンソールに見切りをつけたわけではないけど,1ドットからの描写がしやすいフォームアプリケーションへと製作現場を移動。移動したはいいんだけど,アレ。上記のアレほんと苦手。というかデリゲート全般なんなのあの人っていうくらい苦手意識があってどうにも上手く繋げられない事が多々。でもそんな泣き言垂れ流せないのがフォームの世界。ということでコンソールで作ってたアタリまでちゃっちゃか進めていきましょうというのが現状。やりながら慣れていこう。やっているうちに「ああ!」となる事も多々あるのです。

あのあとすぐ参照する形にしてみたら簡単にタイマー安定した。処理自体も簡単になった。なんだったんだ……。このfps表示って実際その回数表示しているわけじゃなくてその回数相当の時間を食いましたよって言ってる感じがする。

キー入力の問題。
長押しでの先行(過剰)入力の他に,入力時におかしい動きをする事が分かっていたり。
押している間動き続けるという処理。キャラクタの移動などに使うのだけど,一瞬止まることがある。というか必ず入力後一瞬止まってそのあとは押している間動き続ける。
入力キーを表示させていると,ON→OFF→ONONON……という感じになる。仕様と言い切ってしまえばそれまでな気もするけど,何とか直せないかと考える……が,なんでかさっぱり分からない。
しかし,なんかこの動き見覚えがあると感じた。あれだ。キーボードの入力。いや,キーボードで入力しているのだからそうなのだけど,Windowsのキーボードのプロパティ。文字の入力の「表示までの待ち時間」のアレ。というわけで,遅く変更してみたらそれの影響だったと判明。「表示の間隔」もその影響を完全に受けていて一番遅く設定するともはやゲームどころじゃない入力速度になる。キー入力の判断を処理しているんじゃなくて,入力された文字を判断しているのか。コンソールだからかもしれないけど,これは困った困った。
入力の判断方法を変えるか,キーが離されたと認識するまで押されたと判断され続けるようにするか,1回の入力の重要性を高めたゲーム性に変えるか。

悩ましい。

同期待ち(同期を待つわけでは無い)のコードをfps表示と同じクラスにぶち込んだ方が利用しやすいだろうということで整理していたら,何やらfpsが安定しなくなった。60fpsで回しているのに58ちょっとになったり61を超えることもしばしば。これはよろしくない。
重いというわけでは無く,原因は待ち中のループ時に入れているSleep処理らしい。ちょっと寝過ぎているのか早起きなのか数周分のズレが発生している様子。処理をコメントアウトしたり猶予の数値変えたりすると60fpsで安定する。
とりあえず2ミリ秒くらい猶予設けて,ついでに寝たフラグで整流してみたら安定を取り戻したけど,なんかちょっとスッキリしないので辛い。
タイマー自体はStopwatchクラスで計測しているので,Frequencyでとってきた1秒あたりの数値を任意設定した希望fpsで割ったものを1フレームとして計算しているので,Sleepさんが欲しがるミリ秒としての数値としては相応しくないので,コードを分化する前はElapsedMillisecondsを突っ込んで済ませていたのだけど,現在はFrequencyと希望fpsから計算した1ミリ秒あたりのカウント数から現在のラップタイムを導き出している……とか書いていたらなんか普通にタイマー参照すれば無駄な計算無くなるんじゃないかって気がしてきた。
次回やってみよう。

あと問題があるとすれば,キー入力に先行入力の気配がある。長いこと押されていても,1フレームで入力を受け付けるのは1回までにしたいのだけど,fpsを極端に落とすと(たとえば1fpsとかにする)ちょっと長押しするだけではっきりわかるくらい別のキー入力まで長押ししたキーの処理が続く。30fpsでもたまに感じて,60fpsではあまり感じることはない……とはいえ,発生しているようなので,これは何とかしたい。STGの自機移動のように押しっぱなしで反応するタイプのゲーム用にチューンした結果これではいかんですよ。


あの後無茶苦茶ライブラリ化した。

ついでにFPS計測もそっちにまわしたりしつつ,同期用(※同期は考えられていない)の待機カラループもようやく回転数を減らして次ループ開始までの残り時間で可変なスリープでオヤスミしてもらうように変更。これも専用じゃないのでライブラリ側に回してしまってもいいかもしれない。ライブラリは体の良い収納場所かぁ?
そういえばFPSは60固定ではなく初期設定で任意の数値に変更出来るようにしてあるのだけど,フレームごとの変化を確認する用のただのデバッグ用の機能なので,初期設定値から変化することはない。ループ内で任意に変動させられるようにしたほうが便利かもしれない。

そんなこんなで,動作チェックがてらSTGみたいにリアルタイムで動かしてみるという動作を,複数行にまたがる図案のバッファ登録と平行して試してみたら,先日までの書き出し処理の受付では使いづらいと判明。スプライト的な扱いも出来るようにするとかなんとか先日言っていたけど,ちょっと暑さで膝に矢を受けてしまってな。表示座標と表示する値のパラメータがばらばらに登録申請する仕様を実装した。表示したい内容だけど登録すると,表示側が現在持っている座標に書き込まれるというもの。その座標は事前に登録しておける。登録しなければデフォルト座標(0,0)に書かれるだけ。
何これふざけてるの? というような感じだけど,実際使えてはいるけどこれ意味ないんじゃないかと感じる。というか今調べたら意味なかった。そんなことしなくても旧来の同時申請にするとコード行数にして1/3で済んだ。なんなのこれ。どうせやるならやはりでかい図案を事前登録して配置などを意識せず使えるようなスプライト型にすればよかった。やれたらやろう。

誰得記事だけど,自分はこうやって記録付けることで別の方法が多々見つけられるのです。(あくまで記録している時に見つかるのであって読み返しするほどではない)
画面出力まわりの整頓が完了してスリムかつモジュール感ある作りになった。

結果的に行ごとに出力していく感じになったが,使い方自体は行を意識する必要はなく,画面のドコに何を出力するかを指定するだけでOkayな形に出来たのでゲーム画面を作るにはやりやすい気がする。
あくまで,後から書き出す(正確には書き出しバッファ的なの所に登録する)方が上書きされて出力される形なので,単純。現状でもSTGやACTみたいな移動アニメーションが可能。ということで必要とあらばスプライト的な扱いの出来る透過付き矩形文字列も実装いけると践んではいるけど,あくまで移動できる見た目の最小値は1文字単位なのでシビアなアタリ判定などのゲーム制作は出来てもプレイ側としては難しいと思う。

書き出し予約が前後しても平気なようにするにはのZバッファ的な処理を入れれば良いんだろうけど,ベルトスクロールアクションやらスペースハリアーみたいな奥スクロールでもないとなかなか使う機会はなさそう。というかコンソールな現状だとMZ-700版スペースハリアーな画面が限界な気がする。
MZ-700版といえばコンソールでも■(四角ではなく1文字の背景にあたるエリア)をカラーで出す事は出来るので,タイニーなゲームは出来そう。
出来そうとは言ったものの,現在使っている画面出力は1行が1つの文字列なので,その中の1文字を色替えするといったことが出来ない。印字する直前に設定した色になる……はずなので,行ごとに違う色には出来るけど,それより細かくは出来ないのが現状。STGが出来るようなことは言ったけどタイニーゼビウスはこのプログラムでは出来ない。今は色の無い時代と割り切って開発を続けるのだった。


ちょっと見直してみると,毎フレーム出力しているあたりちょっと無駄な感じもあるので,せっかく行分割出力なのだから変更があった行だけ出力する形にした方がコストパフォーマンスはいい気がする。トリアーエズ更新フラグでも持たせてみる案。
ついでに,纏まってきているのだから,いっそライブラリ化してしまうのもいいかもしれない。けど,コンソールでこれを使う機会が今後もあるかというと無い気がする。でも,自作ライブラリは作って所持しておくといつかの時代きっと役に立つ時がくるとかなんとかなので,出来るならしちゃってもいいかもしれない。

二日あくだけで自分のソースが理解できないのは昔も今も同じ。

コンソールでMAPを表示というとローグを思い出したりする。
ので,マップチップは先人の知恵を借りてローグライク風マップ。
フウフウ
ライク風ってなんだ……。
通路にも壁がある。というのは想定しているシステムだとローグ系の通路にあたる部分がゲーム上よろしくないことになるのでMAPデザインするならもうちょっと道を選べる感じでないといけないことになりそう。

もうちょっと画面出力まわりの調整をしないと安心して次の作業にいけないので,暑さに負けないように頭を熱くしなくてはいけないのが辛い眠い。

先日の描画処理というかなんかを高速化仕様に変更。ついでに処理時間もざっくり計測してみた。

結果:書き出し一括化版は僅か1ミリ秒で書き換えを完了する。

目視の文字数としては前回とほぼ同じくらいの78*22≒1700文字。
書き出したい多数の文字列を書き出し用の文字列に突っ込んでそれだけを描画すると大体そのくらいまで速くなった。
実際は改行コードもぶち込んでいるので,その処理ように一行ずつ分かれているバックバッファ用文字列を合流させて一つの文字列にしていたので,2ミリ秒よりになる事頻繁に。
そこで,合流させずに行ごとので出力させてみたら,2ミリ秒。
どちらも1ミリ強~3ミリ弱くらいな様子と実用レベルの予感。

文字数が多さによる不利はないかと試しに一括化の方を改行ぶっ込まないで画面端によるの改行もどき版で試してみるとぶっ込み版より遅くなった。文字数というより「改行」する行為が重いのか。

次期主力出力機トライアルは続くが,ボックス型かライン型がほぼ同じ速度であるなら処理(出力用文字列登録)しやすい方を選びたい。というか現状ボックス型もライン型をつなげているに過ぎないので,ライン型でいいんじゃないかなと思う。
そんなわけで他と関係する処理部分に変化はほぼ無いわけなので,とりあえずライン型を採用してみつつ使いやすさなどを確認していく。
フォームアプリにすればこの無駄な苦労から解放されて画像だって使えるんじゃないかと思いつつも。


そういえば,ループ処理でフレーム安定用の待機場所で空白処理を回し続けるのもCPUによろしくない気がするので,スリープ入れてみようと画策したが,寝かせる時間の算出がどうも上手くいかず放置した。もうちょい考えてみよう。

 ホーム  次のページ»



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。