CALENDAR

06 | 2014/07 | 08
- - 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ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
もう夏かもしれない。

夏までにロールアウトしたかったものことゲームがなんとか出来たものの,未知の言語に必要な知識がまだ足りない状況だったこともあり,とりあえず動けばイイ程度の作りになってしまっていた。

こんなの。
CPG
しょぼい。

コンソールでゲームとかちょっと。
なんなのこれ→じゃんけんゲーム。ただし基本的に勝てない。
こちらの入力を見てから判断する超反応型CPUなので正攻法では勝てないが,フェイントを入れることで相手の体勢を崩すことが出来ることもある。そこの瞬間にのみ勝てる。じゃんけんでもなんでもない。というかゲーム中にも説明書にも一言もじゃんけんとは書いていない。
そういうシステムのため,ランダム制は一切排除されている。擬似的な疑似乱数のようで疑似乱数でない数列で反応が決まっているので,それの消費具合が決め手となっている。構造知れば毎回同じ手数で勝てる。電源パターン的な再現性を試したかっただけマン。

あと,コンソールのくせに画面更新や入力判定などは無駄に60fpsで動作させている。入力もイベント扱い。
かなりロートルなコーディングをしてしまっている感じや無駄な処理もあるのは判明しているので,その辺の整理や習熟やらを課題として次へ。

そんな今後の試験用ゲームでした。

ゲームなのだろうか。

スポンサーサイト
視界の端に頻繁に虫が見える。
制作中のゲームにフレームレートの表示を実装してみた。そんな覚書。
コンソールアプリでそれは必要なのかというと,本当に60fps出ているのか知っておきたかったからトリアーエズの実装。


プログラムの練習問題とかにありがちな配列の内容を表示していくとかそういう類ので数値や文字列をずらっと表示すると,なんか表示完了までが遅いイメージがある。そんなわけで,タイマーでループ処理している場合,実際どのくらい出てるのか調べてみようという話。
結果としては,これといった処理を挟まない場合は安定して60fpsキープする様子。というか360fpsでも安定する。CPUのファンがちょっと唸る。なおCPUは並のC2Q。

そこでグラフィック……は基本的に出せないので文字列を表示させていく。処理のイメージとしては,ゲームでいうとマップチップで背景をずらっと埋めていく感じ。チップ1枚が1文字で,画面に敷き詰める感じ。

毎フレーム100文字ほどだと変化はないけど,200文字くらいから60fpsを維持できなくなり,800文字ほど表示させると12fpsくらいまで落ちる。
この文字数はこちらが要求したい数の半分くらいなので,これではちょっと厳しい。一文字ずつ出力していっていたからだろうが,コンソールでの出力はコストが高すぎる。
そこで一文字ずつ出力していくのではなく,出力する情報をためていってタイミングを合わせて一気に出す裏画面的な処理に変更してみた。
とりあえず一行ごとで試してみると,50文字くらいを16行ちょっと出力しても60fpsで安定。テアリング……というか単純な文字上書きのちらつきもなんか無くなった。これは助かる。
画面サイズは変化無しで決まっているのだから,いっそ画面全部分のバックバッファな文字列を予約しておいてそこに書き込んでいって描画処理時にそれを出力した方が速い気がする。

とはいえテストしていないので,行が1文字列と画面全部が1文字列のどちらが速いかわからない。文字が多すぎると遅くなったりして。ならないか。今度計測してみよう。
先日の描画処理というかなんかを高速化仕様に変更。ついでに処理時間もざっくり計測してみた。

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

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

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

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


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

 ホーム 



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