ティアのホームページ☆ミ:Page 88 oC
<<< << < prev3$F? 88/554ページ(1661件) $FAnext3 > >> >>>
To Close..KB4058043がおかしい 2017年12月19日21時04分
先日のアップデートでKB4058043が普通に入りました。

入ったんです。

その状態で

終了後 → 起動

もしくは、

再起動

を行うと、起動が・・・本来なら20秒程度で起動するところ、
ディスクアクセスなどが全て終了した状態で数十秒待った後に、リセットが掛かり
それをもう一度繰り返すと、スタートアップの修復を自動的に試みます。

これでも起動が出来ないために、自動修復では無く修復の画面が表示される様になります。

この状態で、詳細設定の方にある、スタートアップの修復を実行すると、無事起動するのですが・・・?


ですが、次もう一度起動しようとすると、次の起動は失敗してしまうのです。


インストールされたKB4058043をアンインストールしてから、再起動などを行うと、普通に立ち上がるのです。
しかし、再度起動するとwindowsが起動した後にKB4058043が勝手に入ってしまうので、次の起動は失敗してしまうのです。

どうやら、KB4058043が入ることによって、windowwsの起動時に何かの設定変更を行っているのでしょうね?

で、それが失敗して落ちているんじゃ無いかと?

何はともあれ、MSですからね?としか言いようが無い感じです。


記述の通りですと、Windows Storeのデータの修復を行うようですよね?

こういったときに問題になるのがあれです。


アカウント名が日本語


アカウント名がunicode対応なのですから、CHKでもなんでも常に動く様にして貰わないと困ります。
Micorosoftの標準ツールでも、アカウント名が英語以外だと正常に動作しない物が多すぎです!!

つぎ、
マイドキュメントがCドライブに無い。

マイドキュメントなどは別のフォルダに移動してあるため、デフォルトのフォルダではありません。

こういった場合も、良くエラーが発生します。

ディレクトリその物は、普通に取得するので間違いは無いのですが、Tempフォルダからデータの移動などを平気で行うんですよ?

TMPフォルダもCドライブには無いので、ファイルの移動は基本的には出来ません。
そうです、コピーして、元を削除するなどの方法をとる必要があります。

もちろんAPIを利用してMoveを実行すれば、問題なく出来るのですが?
こういった場合に、ファイルが移動では無くコピーされてしまうと不具合が発生する場合があります。


そう言ったフォルダを移動できるようにしてあるんだから、そういった所をちゃんと作って欲しいものです!


まぁ、色々と書きましたが、原因は結局は分かっていません。

もしかしたら、上記の事柄が原因で、ちょっと時間が掛かっているために、タイムアウトして強制的に終了させられているのかも知れません。

いえね?
SSDですから、アクセスランプが止まる余地も無いほど超高速で立ち上がるPCが数十秒待機するって有り得ないでしょ?

何かの処理待ちをしているんだと思うのよ?

それが判らない。
どうしたら良いのか判らない(笑

あと、「wushowhide.diagcab」ってツールを使うと分かるんだけど
必須では無いいくつかのドライバ軍が、アップデートされずにずっと残っている。

意図的な非表示は行っていないんだけど、インストールされない。

っていうか

KB4058043 の方は、非表示にしても強制的に入れられてしまうので、今はWindowsUpdateを保留状態にしてある。

この場合、すべてのWindowsUpdateが保留になってしまうので、定期的に確認して、
更新があったら適応して「KB4058043」だけアンインストールするという方法をとる必要があるわね?

そういえばRS3が入ってから、タダの一度もWindowsStoreを立ち上げたことが無かったのに気がついたので、起動してみた(笑

良く分からない更新などをしてみたけれど、特にこれと言ってストアアプリは入れていないので標準で入っているいくつかがアップデートされた感じで終了。

とりあえず、Windowsが立ち上がる直前くらいの所で落ちていると思うので、何費とイベントが登録されていないのが困る。

判らない。


閉じる
テーマ:日記 URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1400
 
To Close..きららファンタジア 2017年12月15日15時24分
開始時の問題は色々とありましたが?

公称70万人の登録があるんですから、並大抵のクラスタリングていどでは持たないのは明らかなのに、今まで作ったことがあるらしいそれらのゲームのノウハウは生かされていなかったのでしょうか?


まぁ、それはそれとして・・・・

あたしもやっと始められました。

昨日はリセマラならぬ、ガちゃマラを繰り返していて・・・


本当なら、
☆5ゆの
☆5カレン
☆5青葉

あたりで固めたかったのですが?
まぁ、☆5×3とかは当然無理なわけで・・・・ってことで半ば諦めながらも、ゆのだけは☆5でっって所だったのですが・・・

結局5時間かけてゆのが出てきたのは4回

それなのに由紀とトオルは3回くらい連続で出ることもあるくらい、とにかく沢山出る。
しかも由紀にいたっては、1回(10連)で2枚出ると言うとんでもないことをしでかしてくれたりもしました。

まぁ、☆5×3はそれ以外にも出て、3回くらい在ったかな?

判りますか?

☆5ゆのの出現確率は、☆5×3と同等の確率と言うことです。


因みに、彼女たちも含めた☆5の出現は3〜5回に一度。

もちろん、3回連続で☆5が出ることもあれば、暫く出なかったこともあります。

おそらく出言えば、平均は4回に1回くらいじゃないかと思う(たぶん)
10連で4回に1回であれば・・・・40回に1枚 2.5%って所でしょうか?


って所で

とりあえず、フレ募集
IMG_000546.jpg ( 127 KB ) 2WYLWH24C9


さて?
ゲームについてですが・・・

Xperiaは相変わらずタッチが微妙で、こういった画面が細かい物のタップは苦手です。
おそらく触れる直前からセンサーが反応して、手を離した直後までセンサーが反応しているので、触れているときの座標は殆どズレが無いのでしょうけど、全体を通すとそれなりの距離移動しているんでしょうね?
だから、基本的には全てのタップがドラッグ扱いになっているんでしょうね?

まぁ、これらについては、Xperiaの問題なので、そっちの情報を元に有る程度調整したのですが?
4x MSAAを強制適用をONにして
HWオーバーレイを無効をONにして、
GPUレンダリングを使用をOFFにすると、大分改善する気がします。

ちなみにONにする側はゲームの速度が安定して
下のOFFはタッチ感度を下げる効果があると言われています。

まぁXperiaの話は置いておきましょう。


そういう訳で、UIが細かいのでちょっと操作が大変です。

Xperiaはは解像度はかなり高いのでSSの画面もかなり大きいのですが、変に伸びた感じは全くしないので、それぞれのデータもかなり大きい物が使われていることが分かります。

ゲームの進行について
チュートリアル不足を感じます。

とりあえず、ボスモンスターなどは未だ登場していないのですが、それらが出てくるまでは僧侶は不要(笑)
未だ1章ですけれど、重要なのは攻撃系で考慮するのは属性だけですね。

また、ナイトの高防御力まったく無意味。

序盤は戦士と魔法使いだけで十分だと思います。

見た感じ、属性が合うと攻撃力が2倍みたいな扱いを受けるようです。
キャラに拠りますがダメージは1.5〜3倍くらいと、”誤差”とは言えない程度の差異がありますがかなり増えます。

で、ナイトなのですが?
装備で、防御力しか増えません。
コレは、特に序盤では困ります。

高ランクの装備では、もしかしたら攻撃力も増える様になるのかも知れませんが?
完全に盾限定の使い方になるでしょう。

ナイトのスキルに、敵の注意を引きつけるという物がありますので、コレを使って、あとは微ダメージを与えると言うことでしょうか?

戦士は、どんどん攻撃力が増えていくので、武器もどんどん強化していけば、序盤はかなり楽になります。

それはそれとして、☆5のコストが高すぎて、序盤では使っていられない。

特にゆのは僧侶なので、後々使い道が出てくるでしょうけれど、序盤では

・敵が倒せない
・コストが高すぎる

の2点だけで使ってあげられません。

であれば、戦士か、魔法使いの☆5をお勧めします。

タダ、今後有料ガチャを行う気が無いのであれば、ここで☆5の僧侶を手に入れておかないと後悔することにはなると思います。


あと、☆3と☆4について。

☆4の有能さがとても目立ちます。

コストはちょっと高めですが、レベルがチョイチョイあがればサポートも含めて編成が問題なく出来るため、後進のレベリングも出来ますしとても良い感じです。

攻撃力も☆3に比べるとかなり高く、扱いやすいですね。
コレは、キャラクター性かもしれませんが、速度が高く、敵より先に攻撃が出来るのでノーダメージでクリアすることも出来ますし、逆属性で無ければ、早い内に一撃抹殺が出来ます。

タダ、この辺りも、章が進んでいくとどうなるかは判りません。
戦闘が激化してくると、もっと色々な面を考慮する必要があるのかもしれません。


オートについて。
あまり有能ではありません。
属性を無視して攻撃先を選ぶこともままあります。

まぁ、何はともあれ、比較的楽しいです。
戦闘はちょっと苦手・・・ダメージを受けない様に考えすぎているのが問題なのですが?
何も考えないでオートで放置していても、負けた事は有りません。

今は、まだレベリングの最中なので、同じマップをくるくる回り続けていますのでね?


ガチャは3回行ったので(課金1回と、無料石を使って)、☆4も若干増えましたけれど、
今のところ敵陣に風属性が多いのでレベルの上がっているキャラに偏りがあるのが難点です。
1戦闘目は 風
2戦闘目は 水
  ・
  ・
  ・

って分けろよ!  と文句が言いたい。

そうすれば、それぞれの属性が低レベルの内からそれぞれ育成出来る。


あと、出現属性が3つとか増えてくると、サポートとの切り替えが必要になってくると思うんだけど、やり方は未だ判らない

何はともあれ、もうちょっとプレイして、操作に慣れないとダメですね〜
閉じる
テーマ:日記 URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1399
 
To Close..今更のCOPYDATASTRUCTで文字列を送る。 2017年12月01日11時23分
知っている人は知っているし、その辺にあるサンプルプログラムを適当に実行してもそれはそれで動くんだけど・・・・
まぁあたしもそれで使っていたんだけど、実装に際し、色々と細かい問題点が有ることも判っている。


これはWindowsがどれだけ多言語に対応しているかという所にも拠る。


ようするに使うVSや、使う.net Frameworkのバージョンによっても動作は変わってくる。

これらを正しく問題なく使えるようにするにはやはり、正規のやり方が重要になってくる。

public string lpData;

とか定義してある物は、現在は使えても、その後使えなくなる可能性がある。

日本語、英語、だけならともかく、CHKやアラビア文字、ヨーロッパ文字やらロシア文字などが含まれてくればなおさら。

Windowsにおけるchar型は色々と不確定で、文字列としてはやはりstringを利用するのが推奨で有り、そう言った多言語をAPIで利用するのであれば、Unicodeの32やUTF-8へ変換するのがいい。

UTF-8は現在も拡張され続けているUnicodeの全ての文字を単一コードで表現出来る唯一の文字コードで有り、Unicode16等の古い文字列がコードページ次第で正常に表現出来ないのとは違う。

さて、その上でどうしようか?となる。

当然ながら文字列はUTF-8で有ることが良いけれど、C#はこの文字列をそのままで利用しているつもりでも内部の動作はUnicode16か32に置き換えられている。

また、プロセス間通信を可能にするWM_COPYDATAでは送信されるデータについては一切関知していない。

WM_COPYDATAはCOPYDATASTRUCTに定義されたデータを、該当プロセスのグローバルメモリにコピーしてから目的のアプリケーションに対して、通知している。
ようするに、直接送信されては居ない。

だから、適当にこの構造体にデータを代入しても、相手側には正しく届かない.

正しく送信するためにはどうすれば良いのかというと、
受信する側のアプリに合わせて文字列のデータを作成し、受信側は、送信側で送信したのと同じようにデータを受信する。

lpDataの正しい型式である、LPVOIDはc#では一般的には使われていない方で有り、コレは大概Intptrに置き換えられるけれど、作成したデータをポインタ型に変換出来ないC#ではどうすれば良いのかというと、Marshalのクラスを利用してポインタを作成しなければならない。

Marshalクラスは、いわゆる、アンマネージドメモリを操作するためにあるが、今回のWM_COPYDATAに添付するデータはアンマネージドメモリで有る必要は無い。

先ほどの通り、データはSendMessageで引き渡されたデータを相手方のメモリ空間に複製してからWM_COPYDATAで渡すから。

でもまぁ、C#ではこれ以外ポインタを利用出来ないので使うしか無い。

COPYDATASTRUCTはこんな感じ、

[System.Runtime.InteropServices.StructLayout(System.Runtime.InteropServices.LayoutKind.Sequential)]
public struct COPYDATASTRUCT
{
public IntPtr dwData;
public UInt32 cbData;
public IntPtr lpData;
}

LayoutKind.Sequentialを使わないと、最適化の際に順番が変わったりすることがあるので必須。


次に送信するデータの作成方法

これは文字列を送信するので、
Byte[] data = System.Text.Encoding.Unicode.GetBytes(sData);

でbyte配列型へ代入し、データを確定させます。
今回はUnicodeにしていますが、相手が利用する文字列に合わせる必要があります。

cd.lpData = System.Runtime.InteropServices.Marshal.AllocHGlobal(data.Length);

で書き込む領域を作成して、ポインタを取得します。

System.Runtime.InteropServices.Marshal.Copy(data, 0, cd.lpData, data.Length);

これでbyte配列からマーシャル領域へデータをコピーします。

cd.cbData = (uint)data.Length;

まぁ、これはいつ行っても良いのですが、送信するサイズを代入します。

これでデータは完成ですので、

SendMessage(hHwnd, WM_COPYDATA, (IntPtr)0, ref cd);

で送信して終わりです。


なお、

cd.dwDataは何を入れても構わないので、好きなデータを入れてください。

最後に
System.Runtime.InteropServices.Marshal.FreeHGlobal(cd.lpData);
でメモリ解放することをお忘れ無く。

ココで作成したメモリは明示的に開放しない限り開放されません。
特にHGlobalは使用出来る数に限界がありますので、HGlobalは多用しない方が良いです。


またAPIを直接利用する手もあります。

HeapAllocやLocalAllocを利用することで(c#でどれだけまともに動くかは判りません。)
より高速に動くメモリが確保出来ます。(Globalメモリの動作はとても遅い)

Marshalクラスがあるので使う意味はほぼ無いですが、GlobalAllocのAPIを利用することで殆ど同じ事が出来ます。というか、APIを直接使った方が優れています。


まとめ:

COPYDATASTRUCT cd;
cd = new COPYDATASTRUCT();

Byte[] data = System.Text.Encoding.Unicode.GetBytes(sData);
cd.lpData = System.Runtime.InteropServices.Marshal.AllocHGlobal(data.Length);
System.Runtime.InteropServices.Marshal.Copy(data, 0, cd.lpData, data.Length);

cd.cbData = (uint)data.Length;
cd.dwData = (IntPtr)0;

SendMessage(hHwnd, WM_COPYDATA, (IntPtr)0, ref cd);

System.Runtime.InteropServices.Marshal.FreeHGlobal(cd.lpData);



では受信する側

受信する側は、コレと反対のことをします。

COPYDATASTRUCT cd = (COPYDATASTRUCT)m.GetLParam(typeof(COPYDATASTRUCT));
でデータを取得します。

まず、アンマネージドメモリからコピーする為にbyte配列を作成します。
Byte[] data = new byte[cd.cbData];

System.Runtime.InteropServices.Marshal.Copy(cd.lpData, data, 0, (int)cd.cbData);
で、データをコピーして、

string sData = System.Text.Encoding.Unicode.GetString(data);
で、byte配列をUnicode文字列として取り出します。

これで終わりですね、
アンマネージドメモリはWindowsが確保してデータを送っていますので、C#側で開放してはいけません。


まとめ:

COPYDATASTRUCT cd = (COPYDATASTRUCT)m.GetLParam(typeof(COPYDATASTRUCT));
System.Runtime.InteropServices.Marshal.Copy(cd.lpData, data, 0, (int)cd.cbData);
string sData = System.Text.Encoding.Unicode.GetString(data);

受け取る側は簡単ですね〜


WM_COPYDATAはプロセス間通信の方法としては、とても簡単な機能ですが
お互いの送受信を制御しにくいと言う問題が有ります。

なので、WM_USER以降の番号を使ったメッセージの遣り取りなどを利用して、ハンドシェイク通信をすることをお勧めします。

まぁ、そう言うのであれば、WM_COPYDATAの遣り取りは、全くもって気軽に出来るものでは無いと言うことが判るかと思います。


また、上記の例を見ればc#で行うには、同じデータを何度も変換やコピーをする必要があり、あまり有効的な手段では無いことが判るかと思います。

文字列をunicodeに変換してからbyte配列へコピー
byte配列をアンマネージドメモリへコピー
WM_COPYDATAが送信先プロセスのメモリへコピー
アンマネージドメモリからbyte配列へコピー
byte配列をunicodeとして読み込みつつ文字列へコピー

とまぁ、5回もコピーしています。

アセンブラなどを利用すれば、もっと効率よく行えるんじゃ無いかと思わなくも無いのですが?

C#のプログラムじゃなくなっちゃうのでね?


まぁ、何はともあれIntPtrを素直に安全に使うのであれば、Marshalクラスを利用するしか有りません。
また、それとは別にガベージコレクションの対象外にしてメモリを固定する方法が有ったかと思うのですが?
ようするに、アンマネージコードとしてポインタを取得して利用する方法があったはずなのですが、忘れました(笑

Marshalクラス以外の方法でアンマネージ領域にアクセスするのは、C#の仕組みからして動作が遅くなるのでお勧めはしないのですが?それなりの量のアンマネージ状態で実行するコードが在るので在れば、それはそれで早くなるかも知れません。

まぁ、そんな感じで、WM_COPYDATAの話は終了。

それ以外のプロセス間通信としては、
COMやらDDEやらソケットが推奨。

パイプはソケットと比べて扱いが面倒なのであまりお勧めはしない。

閉じる
テーマ:たわごと URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1398
 
<<< << < prev3$F? 88/554ページ(1661件) $FAnext3 > >> >>>