なんだか雲行きの怪しい雑記帖

ぐだぐだ日記とメモと,あと不定期更新

スポンサーサイト

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

見出し記事

ここは管理人exrdの適当な日記帳です,基本的にぐだぐだに雑記を書いている場所です.
まともに見れるような所は殆どありません! のでご注意を.

それでも見るという方はどうぞ.

少し大きめの変更履歴:
 2017/04/30 要らない記事をすべて削除して色々整理しました

※この記事はブログの先頭にくるように日付を弄ってあります
※何か私に直接御用の方はメールで「fakeどっとexsrdあっと<じーめーる>」の方へお願いします
続きを読む
スポンサーサイト

【HSP】【hgimg4】Effekseerプラグインでhgimg4でも映えるエフェクトを!

この記事は

HSPのAdventCalendar、略さず言うと Hot Soup Processor Advent Calendar 20175日目の記事です。
去年も12/05に記事を書きましたが、今年も無事(?)12/05に記事を書くことができました。
特に意味はないけど ナントナク(*‘ω‘ *)ウレシイ

前置き

今回はエフェクト再生ランタイム「Effekseer」のスゴイ機能をhgimg4でも使えるようにプラグイン作ったので、hgimg4の超入門も兼ねて改めて使い方や使うとこういうことが出来ます! というのの紹介(有体にいうと宣伝)になります。

なお、話の中身自体は私の前の記事「【HSP】【DXLib】【Effekseer】HSPからエフェクト再生ランタイム「Effekseer」を使えるプラグインを作った話」と重複するところが少なからずあります、ご了承ください。

この記事の内容

今回の記事では下記の内容に触れていきます。

・hgimg4+Effekseerによるエフェクト描画(基本編)
・hgimg4+Effekseerによるエフェクト描画(応用編)
・エフェクトを使ったサンプル


基本編ではhgimg4+Effekseerでとりあえずエフェクトが出せるようになるまでを取り上げます。

応用編では、hgimg4+Effekseerで歪みエフェクトも出せるようにするまでを扱います。

最後に、どうせなのでエフェクト使った動くサンプルを作ってみたのでそれの紹介になります。
エフェクトありなしとで比較もあるので、エフェクトを入れると画面がどう変わるのか感じてもらえればと思います。
続きを読む

【HSP】【DXLib】検証デモ「がん☆ぷろ!」を作ってみて分かったことまとめ

気づいたら前回の記事から半年近く経ってる恐怖。

この記事は?

検証デモ「がん☆ぷろ!」(下記参照)を作ったときに得られた知見と工夫と苦悩とその他諸々を書き残す記事です。

「がん☆ぷろ!」について

プロ生ちゃん(本家様)と一緒に飛行艇に乗って敵を撃ったりバルーンを撃ったりする、HSP+DXライブラリ+Effekseerのデモ(アプリ)です。

このブログでは諸々事情があって公開してませんので、DLはHSPコンテストのページからどうぞ。
gunpro_intro1.pnggunpro_intro2.pnggunpro_intro3.png

なぜ「デモ(アプリ)」というややこしい表記をしているかについてですが、「がん☆ぷろ!」を作ったきっかけというか目標を述べておきますと…

  • HSP+DXライブラリを用いた3D描画の可能性(発展性)の検証・試作
  • (自作ライブラリ)Effekseerプラグイン for HSPの簡易検証・テスト
  • (自作ライブラリ)mistのβ版リリースのためのテスト

といった感じです、順不同で思いついた順で書きましたので順番は特に意味がありません。

3D描画の「試作」や「主張」といった意味合いで「デモ」、「検証」や「テスト」という目的があるため「(アプリ(アプリケーション:ソフトウェア))」みたいな表記が混在するに至った次第です、ごちゃごちゃしててすみませぬ。
完全に私自身のエゴに依るところが大きいのですが、特段面白さを突き詰めて作ったわけでもないので少なくとも「ゲーム」ではないし、「アプリ」と称するにもやるというより見てもらうものだし、と散々迷った挙句上述の表記に落ち着きました。

記事中で触れていく内容について

本記事(と前後編と分けるかもしれないので一連の記事)では上述のそれぞれの目的別に、

・「実際どれくらい使えるものだったのか」
・「こういう使い方が出来るようなのでやってみました」

といったことを中心に書いていこうと思います。

目的の後半2つは動作テストがメインなので記事中ではあまり掘り下げません。
つまりDXライブラリで3D描画周りの話がメインになるかと思います。

ただDXライブラリはHSP用にカスタムされたAPIを持っている訳ではありません。
トコロにより読む際にはWin32APIなどライブラリ呼び出しの基本的な知識だったり、
3Dも扱うため立体解析幾何(具体的にはベクトルとか行列とか)についての知識が必要になります(予定)、ご了承ください。

でもまぁ、説明を書く私の知識がそもそも豊富ではないため一般的に難しい内容に触れる気はそんなにありません、
ちゃっちゃと流すところは流していきます。
興味があるところだけかいつまんで読んで頂ければそれで私としても有難い限りですので、軽い気持ちでどうぞよろしく。
続きを読む

【HSP】「mist」の文法対応、構文拡張まとめ

この記事は?

拙作HSP用の動的実行プラグイン「mist」の話。

【HSP】不穏な動的実行プラグイン「mist」の記事ではHSPからmistの主に互換性部分について触れていますが、mistの実装自体互換性らへんは(プリプロセスを除いて)ある程度落ち着いてきていることもあり、マルチスレッド対応など動作拡張以外にも少しずつ構文拡張にも手をだしていたりします。

私はHP持っていないのでmistを実際にリリースする時は上の記事内容を修正していたりするのですが、そちらに互換性の話と拡張文法の話を一緒くたにすると流石に内容が膨れ上がってしまい、(読む人と、主に私の脳内が)収集がつかなくなってしまう気がしたので、内容を分割して構文拡張を主眼にした記事は別に作ることにしました。
つまりこの記事がそれです。

もっと具体的には何書くの?

この記事では構文拡張の拡張内容と、そもそもmistでは文法的にどこまで対応してないのかについてまとめていこうと思います。
先の記事とは内容が重複する箇所もあるかと思いますが、あちらは「HSPからmistを使うまでの導入」という流れを強く意識しているのに対し、本記事の方では文法面を主軸として「HSP本家と何が違うのか」について整理していこうかと思います。

主に書く内容については次あたりを予定。
 ・キーワード
 ・演算子の優先順位(結合順位)
 ・構文拡張
続きを読む

週アレ(16) GLSLでディザパターン(BayerMatrix)

週に一回アレしてアレしてたハズの記事:十六回目

ご無沙汰してました、もう週一回とか1ミリも関係ないのだけど、少し整理した技術系の話はこのカテゴリで通すことにしたのでこのタイトルになります。

今回はディザリングについてです。
具体的には、ディザのパターン生成(パターン配列としてはBayerMatrixを使用しました)と、パターンの複雑さと実際のディザの見た目について触れます。

今回のは若干マニアックな話題なんですが、昨今の3Dゲームだと半透明表現としてたまに(普通に?)使われているところではあるディザ半透明について、そもそもディザってどういう手法があるのかなと思って調べた記事になります。
続きを読む

【HSP】【DXLib】【Effekseer】HSPからエフェクト再生ランタイム「Effekseer」を使えるプラグインを作った話

もうなんかタイトルが邪悪.

前置き

表題の通りですが,なぜそれをやったのか(やってしまったのか)という話,モチベーションについて.

代替品がない

そういえばHSPってゲームでもエフェクトだそうとすると,パーティクル一つ一つの計算処理を全部手でコード書かないといけなくなるのですが,元々多くの変数を効率よく扱うための仕組みがないので凄い辛いんですよね.
ではその部分を分担してくれるライブラリがあるのかと言うと,現状フラッグシップなものが無い.(※個人の感想です)

近いものとして挙げられるのが「ParticleTestTool」,これは本当に近い,でも現状E3Dの状況を鑑みるととても惜しい.(今でもE3Dは従来通りのライセンスのまま使えますが,公式に同梱されなくなったことと,メンテされていなこと,更にはhgimg4がリリースされたという背景があるため,なんとも言えないところですね)

その他に挙げられるものが「SpriteStudio」だけど,これはHSPでもとりあえずアニメーション情報読み取って表示できる機能で,大量のスプライトを扱おうとするとHSPの処理コストからリアルタイムは結構きつそう.

「d3module」は素晴らしいけど,一つ一つのエフェクトを作るのに必要な職人芸的なパーティクルの挙動調整へ費やす時間が大変.
また,一個一個エフェクトを調整し終えることができたとして,そもそも大量のエフェクトを一括で管理するコードを”HSP上で”実装するのは現実的に難しいでしょう.

元々HSPはある程度粒度が大きいライブラリを揃えないと使いづらい

HSPは言語的(主に文法的)に,HSP側で多くの機能単位を内包しておくことが難しい,と思ってます.

結構具体的に説明するのが難しいんですが,誤解を恐れずにざっくばらんに言うなら「hgimg3よりE3Dの方が地形との当たり判定まで面倒見てくれるから3Dゲーム作るのは楽」とかそういう話です.

根本的にHSPは抽象化ができないので,汎用化されたデータであってもアルゴリズムが適用できないあたりが原因だと思ってますが,よく分からない話に突っ込みそうなので置いておきます.
ひとまずここでの主張は,「エフェクトを一個再生したい」という実装者の要求に対して,「自分でパーティクル一つ一つの挙動をコードとして実装する」のではなく「予め別のツールで作っておいて,データとして保存したものを”再生する”と命令するだけで画面に表示されれば楽ですよね」と,そんな感じです.
 (あるいは,もしOBAQに描画する機能が存在せず,自分でOBAQ内のオブジェクト全部をイテレートして自前で描画するしかできなかったら辛いよね,とか.)

エフェクトって映える

聞いた時ちょっと至言だなって思った.

ちなみに今回のEffekseer組み込みを行うと,次のようなエフェクトは「エフェクトファイル読み込み」→「再生」命令でサックリだせる.
effekt_Intro2.pngeffekt_Intro1.png
(Effekseer本体付属のサンプルを本プラグインを使って表示したところ)

その他どういうエフェクトがあるかはEffekseer公式の紹介ページを参照とのこと.

上記画像見てテンションが上がらない場合,あまりこのライブラリを使うメリットがないような気がする,そういう方には申し訳ない…. 続きを読む

【HSP】【DXLib】標準のCEL系命令をDXLibの命令で置き換えるモジュール


前置き

表題の通りですが,なぜそれをやるのかについて簡単に.

DXLibはプリミティブな命令の集まり

そもそもDXLibはかなりプリミティブというか,命令体系(という言葉が正確な表現かどうかはさておき)としてはHSP標準のソレと似ていてます.

具体的には,一つの画面を構成するために行う処理が,いずれも「画面のこの場所にこの画像を描画する」といった命令の積み重ねでできていること,です.

ちょうどHSPの標準命令と体系が似ているのであれば,単純に置き換えが簡単そうです.

なんだかんだDirectXって高速

更に,DXLibは内部でDirectXを使って描画を行っているため,HSPの標準命令が行うGDIよりは高いパフォーマンスが見込める点があります.

ついでに言うと,GDI(GDI+ではない)では扱えない透過情報を持った画像が扱えるようになる,というのもメリットが大きい.
(そういえばGDI+を使ったArtlet2Dというライブラリもあるのですが,あんまり早いという話は聞かない)


今回目指したこと

最初に言っておくと,あんまり大きいことは目指さなかったデス.

そもそもこれをやった理由が
・案外HSPerの方でDXLibに興味ある人が多そう(主観)
・「でも今からDXLib使ってみるのもな…置き換えコストが大きくて嫌だなぁ」とか思っている人って実は沢山居そう(願望)
の二点であり,根本的に勘違いの可能性も捨てきれないからです...

HSPの標準命令を網羅的に置き換えるのは無理ですが,命令数も少ないCEL系の命令だったらDXLibにも置き換えられそうだし費用効果が高そうなので,今回はそこを着地点としました.

モジュール本体は続き。 続きを読む

【HSP】HSP用のプラグインHPIを作るまでの一通りの流れと寄り道


ずっと誰かがこういう記事書くだろうと思って早2,3年.
誰も意外とこういう記事書かないので書いてみようと思って書いてみます.


この記事は


HSP用のプラグイン(HPI)の作り方をSDKに沿って説明します.
基本的な作り方の説明が記事としての主眼ではありますが,ちょっとした小ネタみたいなのも混ぜていこうかなと思います.

というのも,私自身HSPのプラグインとしてちょっと規模が大きめ(だと自分では勝手に思っている)の,動的実行のためのプラグイン「mist」を作っている時にSDKで迷ったり悩んだりした点が「結構」あったので,探してもあまり資料なかったしどうせならそれらをまとめて資料として公開した方がいいかな,と思ったのが理由の一つです.
もう一つ個人的にはそこそこ大きな理由がありますが…そちらは後述.

HSP自体はバイトコードを埋め込んで実行させることができたり,COMを扱えるためプラグインなしでもかなり広範囲に手が届く(というよりは,やろうと思えばできる)ようになっていますが,それでもプラグインならではのメリットもあります.

ぱっと思いつくところでは
  • バイトコードを埋め込んだりせず,コマンド・関数を定義して機能追加できるため,無理せず拡張できる(機能自体の改変が比較的容易:ただし,モジュールよりは改変のし安さは難しいですが)
  • HSPのインタープリター上ではなくOS上で実行されるので高速
  • HSP内部の情報や変数情報も取得可能なため,通常のDLLに比べより状況に則した(HSP的に書きやすい)機能の追加が可能
  • ほぼ同一のコードでランタイム内にコードを組み込み,拡張ランタイムとして本体に埋め込み可能※

ら辺が分かりやすいメリットでしょう.
※ただしかなり難易度高いです,多分後述

対象読者

  • プラグイン作ってみたい人
  • HSPが書ける人
  • C/C++が若干書ける人
  • VisualStudioが触れる人

続きを読む

FC2Ad

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