HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2015
0601
てとginfoのバグ?11解決


てと

リンク

2015/6/1(Mon) 23:03:03|NO.69602

間違っていたらスイマセン。
http://www.rinku.zaq.ne.jp/ultimate/tips/text/pos1.htm

のHSP3用のモジュールを利用しています。

3.5β2でこのモジュールを使っている部分が3.5β1を使っているときに比べて少し位置がずれて中央寄せなどが上手くいきません。
普通にposなどで位置を指定している物についてはこれまで通りの位置に来ているのでginfo命令の不具合かな?と勝手に思っているのですが、皆様は正常に動きますでしょうか?



この記事に返信する


名無し

リンク

2015/6/2(Tue) 02:00:02|NO.69608

>少し位置がズレて
bmpsaveとかでスクショ取って比較できるようにしてくれると助かったのになー……
ただま、ginfo_cxとginfo_cyはカレントポジションの位置を表すから、
おかしいと思ったらginfo_某の全変数の値をログに取るとかして比較すれば一発かと



てと

リンク

2015/6/2(Tue) 22:14:08|NO.69620

名無しさん

ありがとうございます。
ちょっとよくわからないので、とりあえずginfo_○○の値を全部表示させてみました。
PC上で実行しているときとAndroid端末で実行しているときで異なる値が出ていたものが二つありました。
(PCではバージョンアップ前と同じ位置に表示されています、Androidで実行したときのみズレます。)

#module
#deffunc align str string, int type, local cx, local cy
cx = ginfo_cx : cy = ginfo_cy
pos 0, ginfo_dispy : mes string // 見えない位置に書き込む
switch type
case 1: pos cx - ginfo_mesx / 2, cy : swbreak // 中央揃え
case 2: pos cx - ginfo_mesx, cy : swbreak // 右揃え
default: pos cx, cy : swbreak // 左揃え
swend
mes string
pos cx, cy + ginfo_mesy
return

の中で言うとginfo_mesxとginfo_mesyです。
それ以外はPCでもAndroid両方で同じ値を返してました。

で、ずれている位置をよくよくみると、中央寄せ(上のモジュールですとcase1)にしているのにもかかわらず
左揃え(defaultとか引数0のとき?)になっているようです。
ということはAndroidで実行したときに上手く動作していないのはswitch typeというところの分岐が上手くいっていないってことでしょうか?



port

リンク

2015/6/2(Tue) 23:08:18|NO.69624

>PCでもAndroid両方で同じ値を返してました
なんでAndroid(hspdish)での話だと明記しておかないんだ??
と言うかその「ginfo_mesxとginfo_mesyの差異」についても
数字で詳しく書いてくれないと伝わらないんだけど分かってる?
……まあ、中央揃え(case 1)が左揃え(default)になってるってことは、
たぶんginfo_mesxがAndroidじゃ0だってことなんだろうけど



てと

リンク

2015/6/2(Tue) 23:31:12|NO.69626

portさん

説明不足で申し訳ないです。
ginfo_mesxは(ちなみにginfo_mesyも)0ではありませんでした。
PCのときは40、Androidのときは46でした。
(yはPCのとき40、Androidのときに50でした。)

モジュールの事全然わからないです利用してるので上手く説明もできずに申し訳ありませんです。



port

リンク

2015/6/2(Tue) 23:53:44|NO.69627

うーん……ちょっと待てよ、値が違うってことは
PCとAndroidじゃ標準のフォント違うの?
だとしてもginfo_mesxが0じゃないのに中央揃え=左揃えってのは本当に謎
こちらこと力になれなくてすまない



てと

リンク

2015/6/3(Wed) 21:39:11|NO.69648

portさん

ありがとうございます。
詳しくはわかりませんが、Androidの場合フォントは端末依存らしいです?
標準フォントが機種ごとに違うらしいです。

ginfo_mesxの件ですが、バージョンアップ前のhsp3dishでもPCとAndroidで値は違っていて、バージョンアップ後のHsp3dishとそれぞれ同じ値でした。
ginfo_mesxが0ではないので、分岐が上手くいってないのが原因かな?と思ってswitchではなくてif文でやってみたのですが改善されませんでした。

ということで、ginfo_mesxの部分に数値を入れて動作確認したところ、ちゃんと位置が変わるので、switchは問題なく動作しており、やっぱりginfo_mesxの部分が原因になっているようです。

時間が有るときに色々弄ってみて原因探してみようと思います。



てと

リンク

2015/6/3(Wed) 21:46:47|NO.69649

連投すいません。

原因?らしき物がわかりました。
上のモジュールの

pos 0, ginfo_dispy : mes string // 見えない位置に書き込む

という部分で、長さを取得したい文字列を見える部分に表示させると上手くginfo_mesxが取得できるようです。
ちゃんと中央寄せができました。

バージョンアップ後、画面外に表示させた文字列の長さを上手く取得できていない・・・ということでしょうか。

しかし、この方法だと見える位置にいらない文字が表示されてしまうので、この方法は使えませんね。
う〜ん・・・



暇人

リンク

2015/6/3(Wed) 23:02:32|NO.69652

こんな流れに出来れば画面外にする必要は無いかな

repeat 〜表に見せたくない処理〜 redraw 0 〜描画に関係する処理〜 redraw 1 loop
実際に描画するのと画面外に描画させてた時の処理速度がどうなるかは分からないけど・・・



port

リンク

2015/6/3(Wed) 23:28:43|NO.69653

>No.69649
いっそ別バッファに表示させてみては?
>No.69652
それ表に見せたくない処理部分も見えるんですけど……
毎回boxfとかで塗りつぶすんならともかく



暇人

リンク

2015/6/4(Thu) 00:26:26|NO.69656

>NO.69653
>それ表に見せたくない処理部分も見えるんですけど……
ん?
通常のHSPなら見えるけどdishなら見えないでしょ?

#include "hsp3dish.as" sx=480: sy=800 screen 0,sx,sy repeat color pos 0,0 mes "ABC" title ""+ginfo_mesx await 32 py=sin(0.1*cnt)*32 redraw 0 ; グラデーションで矩形を塗りつぶし gradf 0,180+py,320,100, 1, $ff00ff, $ffffff ; 文字を表示 color 0,0,128 font msgothic, 20, 1 pos 32,220+py mes "HSP3Dish gradf sample" redraw 1 await 1000/30 loop
dishはredraw 0で全画面クリアしてredraw 1で、それまでの描画を見えるようにする
通常のredraw 1とは違い以降の描画は見えない



てと

リンク

2015/6/4(Thu) 08:03:57|NO.69658

暇人さん

ありがとうございます。
ただ、このモジュールが文字列の長さの取得と文字列の表示をまとめたものになっているので、どうしてもredrawの中に入ってしまいます。
文字列の長さ取得部分と表示を分けてモジュールを作ることで対応できそうですが、各所で大量にこのモジュールを利用しているため修正が大変そうですね。

うーん。

posでマイナスの値を指定したときの動作がバージョンアップ前後で違うようです。
例えばYにマイナス値を入れてメッセージを表示させると以前のバージョンでは画面外に消えていましたが、バージョンアップ後は座標0の位置にあらわれます。
値を大きくして画面外に飛ばすと両方表示されませんでした。
が、以前は画面外に表示処理はしているが、バージョンアップ後は画面外での表示処理を省略している可能性もあるかな?
それでginfoでうまく長さ取得できていないのかもしれません。



ONION software Copyright 1997-2018(c) All rights reserved.