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


HSPTV!掲示板


未解決 解決 停止 削除要請

2008
0811
paperline命令が1dot欠ける問題18解決


paper

リンク

2008/8/11(Mon) 16:09:14|NO.18052

はじめまして。
数年前HSP2.6を使っていたものなのですが、今年のHSPTV部門に出展しようと考えています。
確か、HSP2.6時代のline命令は終点の1dotが欠けてしまう仕様だったと思います。
そこで、以下のようなスクリプトを書いて試してみました。

boxf 320,0,640,480 repeat 480 await 1 line 320,cnt,0,cnt loop
上のスクリプトをHSP3.1/XP,SP2で試したところ欠けずに表示されました。
ただ、HSP2.6では環境によっては欠けない場合もあるというものだったと思うのですが、
HSP3.1ではlineの仕様はどのようになっているのでしょうか?
一通りネットやヘルプ、この掲示板のログも探してみたのですが、
探し方が悪かったのか発見できませんでした。
lineで画像を用意する場合、
環境によってドット絵で1dot欠けることは結構致命的だと思いますので……。



この記事に返信する


raisen

リンク

2008/8/11(Mon) 17:29:42|NO.18055

320と0を逆にしてみてください。欠けるのは終点です。
1dot欠けるのは、確かAPIの仕様だったと思います。



SYAM

リンク

2008/8/11(Mon) 19:16:36|NO.18056

HSPだけの話ではありませんが、一般的に連続直線や連続する面については、終点(または終点側の辺)を描画しないようになっていることが多いです。

これは、たとえば半透明の連続直線を引く場合、ある線の終点と次の線の始点をそれぞれ描画するとその点だけが2重に描画されてしまい、他の点と違う色になってしまうためです。
輝度50%の半透明な白で連続直線をひいた時、終点と始点を両方描画してしまうと、そこだけ真っ白になってしまうわけです。



paper

リンク

2008/8/11(Mon) 19:53:10|NO.18058

>>raisenさん
0と320を入れ替えたところ、ウィンドウ左端が白く欠けました。
ですが、終点が欠けるのであれば最初のスクリプトの場合、
p1,p2が終点座標ですので縦に一本白い線が引かれるのではないでしょうか?

…と思ったのですがよく考えたら0〜319ドットまではlineで塗り、
320〜640まではboxfで塗ってるから白くなるはずありませんね(^^;
うちの環境でも欠けるってことですね。すみませんでした。
-----
>>SYAMさん
連続直線についてはよく耳にしていたのですが、
半透明でのコピーという場合を想定していませんでした。
納得です。

-----
APIの仕様ということであれば基本的にHSPTVが動く環境なら欠けると考えてよいのでしょうか?
コンテストということもあり、HSPTVが動く全ての環境で同じように描画されてほしいのです。
ほかのHSPTV部門の作品でも欠けるものとして処理されてるんでしょうかねー。



As

リンク

2008/8/12(Tue) 16:17:05|NO.18074

常識といえるくらいの仕様です。

考えてみてください、


line 0,0,100,0 line 100,0,200,0

このようなスクリプトを書いたばあい。もし1dot欠けなければちょっとした問題がでてきます。
それは、“100,0”にあたるドットが2度も塗りつぶされてしまうからです。

なら、二行目のパラメータを 101 からはじめればいいじゃないかと思うかもしれませんが、
それは非常に困難なことなのです。連続してlineを使用した場合、必ずしも101から始まるわけ
ではないからです。

左斜めの方向にlineが描画される場合もあり、そういった描画開始位置の処理には複雑なコードが
必要になるため、lineは、連続した描画を考慮したうえで1ドット欠けているようにしているのです。



paper

リンク

2008/8/12(Tue) 21:32:24|NO.18085

>Asさん
欠けることは“常識”ですので私も存じております。
どうして欠けるの?という質問ではありません。なぜご理解いただけないのか甚だ疑問ではありますが。
私がお聞きしたいのはあくまで『環境によって欠けないことがあるのではないか』
という2.6時代の仕様がどうなったのかという点であり、
根本的に私の書いた日本語をご理解いただけていないようです。
今後はもっと理解力を要求しない書き方を精進致します、すみません。
APIやGDI、またはドライバにより必ずしも全ての環境で欠けるわけでないのではないか。
というのが論点であり、またその『欠ける可能性』はほとんどなく、
原則として全てのマシンで欠けると考えてよいのかどうかをお聞きしたいのです。
コンテストという性質上、不特定多数の方がダウンロードします。
その千差万別の環境でも同じように動くことが求められているのではないでしょうか。

「欠ける理由を得意げに話す」といった的を得えないレスしかないようなので解決とさせていただきます。
回答してくださった方、ありがとうございました。



GENKI

リンク

2008/8/12(Tue) 23:18:30|NO.18087

むう。雲行きあやしいな…まいいや。
文字情報って誤解を招きやすい媒体なんで読むときは寛容さが大事です。


さて少しそれましたが話をまとめると、
 ・HSPに対応するすべてのOSでのline命令の動作結果比較は誰も行っていない。
 ・プログラミング上での常識的な考え方では、どのosでも動作結果は同じと考えて差し障りない。
…ということでいいのかな。

line命令の実体である直線を描画するAPIはWindowsでは古くから使われていると思われ、
また単純ゆえにそうそう簡単に仕様変更はできないものです。
理由はpaperさんがおっしゃるとおり、

> 環境によってドット絵で1dot欠けることは結構致命的だと思いますので……。

ということです。この辺はHSPでも同じ。
また同じ理由でWIndowsであれば欠けない可能性は無いといっていいでしょう。
この辺はSYAMさんやAsさんも暗におっしゃっていますよ。このお二方の話を聞くとjavaやMacやLinuxでも問題なさそうな感じですね。



さていろいろ言いましたが結局この問題は可能性という話ばかりで白黒はっきりとしませんね。
このような動作結果をはっきりさせたい命令はline命令に限らず他にもあると思いますが、
常識や可能性だけじゃなくはっきりさせたい場合はこういう方法があります。
異なる環境、OSのテスターを募って実験してみる方法です。
やり方は簡単。
動作が違えば一目で分かるスクリプトを提示して、ここに限らずどこかの掲示板でテスターを募ればいいだけです。
このとき結果報告フォームを用意しておくと親切です。
あ、はじめに自分の環境での結果を提示することを忘れずに。

あきらめる前にまだ出来ることはたくさんありますよ。



SYAM

リンク

2008/8/13(Wed) 00:30:44|NO.18093

関係ないこと、書かなきゃよかったですね。
面目ない。



あり

リンク

2008/8/13(Wed) 00:53:51|NO.18094

今さらかもしれませんが・・・
HSP2.61と3.1の更新履歴を調べてみたところ、line命令の動作に変更があったとは
書かれていないようなので3.1でも2.61と同じ動作になる仕様だと思います。
・・・こういう事が知りたかったんでしょうか?
環境については絶対動くとも動かないとも言い切れない話ですし。

私が知る限りでは環境によってlineの動作が変わったという話を
聞いた覚えはありませんが、HSPTVが動く全ての環境で欠けない線が
描きたいという事ならlineを始点−>終点、終点−>始点の二度描画するとか
終点に1ドット置くとかの方法ではダメなのですか?
線が太る事も無いみたいですし、ようは欠けようと欠けまいと
描画結果が同じなら問題ないのでは?・・・と考えるのは早計ですかね?

・・・何か空気が読めてない気がしてきた・・・(汗)



ANTARES

リンク

2008/8/13(Wed) 23:58:34|NO.18165

 えーと、空気の読めないANTARESです(^_^;;

>輝度50%の半透明な白で連続直線をひいた時、終点と始点を
>両方描画してしまうと、そこだけ真っ白になってしまうわけです。
 そんな特殊な条件でしか問題にならないことのために
一般的な条件で問題になることを無視するのですか?

>“100,0”にあたるドットが2度も塗りつぶされてしまうからです。
 なぜ、それが問題になるのですか?
1ドット欠けることに比べれば、どうでもいいことだと思いますが?

>二行目のパラメータを 101 からはじめればいいじゃないかと思うかもしれません
 二度描かれるのが問題なら消せばいいだけのこと。
1ドット補うのも1ドット消すのもプログラマの手間としては同等であり、
どちらが問題が大きいかで考えるべきでしょう。

>Windowsでは古くから使われていると思われ、
>また単純ゆえにそうそう簡単に仕様変更はできないものです。
 多くのシステム変数名(HSP3ではマクロ名)が無意味に変更されていることを
考えれば、これも理由にはなりません。


>HSP2.6では環境によっては欠けない場合もあるというものだったと思うのです
 たぶん、勘違いではないかと思います。
私もありさん同様、欠けないという例は聞いたことがありません。

>APIやGDI、またはドライバにより必ずしも全ての環境で
>欠けるわけでないのではないか。
 例えばムービーの再生やDirectX等であれば、結構複雑な話になりそうですが、
lineのような基本的な処理については、バージョンアップによって仕様が
変わる可能性はあっても、環境による違いがあるとは考えにくいように思います。

 ただ、HSPTV上で動かすことを前提にすると、話が変わってくる可能性も
ありますが……。



レノス

リンク

2008/8/14(Thu) 02:32:50|NO.18173

全く空気の読めないレノスです (-_-;;

スレが荒々しくなるのは嫌なので、できれば寛容に受け止めてください^^

> 引用一部 略

> > 輝度50%の半透明な白で …(略)… 真っ白になってしまうわけです。
> そんな特殊な条件でしか問題にならないことのために
> 一般的な条件で問題になることを無視するのですか?
>
> >“100,0”にあたるドットが2度も塗りつぶされてしまうからです。
> 1ドット欠けることに比べれば、どうでもいいことだと思いますが?
>
> > 二行目のパラメータを 101 からはじめればいいじゃないかと思うかもしれません
> 二度描かれるのが問題なら消せばいいだけのこと。
> 1ドット補うのも1ドット消すのもプログラマの手間としては同等であり、
> どちらが問題が大きいかで考えるべきでしょう。

そこらへんの話は人の考え方によるので、どうしようもないと思います。
( 半透明の線の描画の特殊かどうか、です )

自分は、ANTARES さん自身がおっしゃるとおり、pget も pset も同じ手間ですが、
それならどっちでも良いじゃないかと思います。

> > Windowsでは古くから使われていると思われ、
> > また単純ゆえにそうそう簡単に仕様変更はできないものです。
> 多くのシステム変数名(HSP3ではマクロ名)が無意味に変更されていることを
> 考えれば、これも理由にはなりません。

Windows は世界シェア No.1 のOSであって、それからすればHSPなどちっぽけなソフトでしかありません。(残念ながら -_-;)
その分、「仕様を変更すること」の重みが全く違います。
また、HSP2 から HSP3 へは大きなバージョンアップなので、
このときの大きな仕様変更は理由になりません。

# あと、システム変数名の変更も無意味ではなかったと思います。
# 関数の数が多くなって、関数をサポートしたことを強調出来たのでは……?

> paper さん
回答者が質問文を間違って解釈してしまうなんて、よくあることです。
そのときは、「違います」と言うだけにすべきです。
いらいらしても文章に表さないのが大切では。

> 結論
結局いいたいのは、(理論上) Windows なら欠けないということです。

# HSPTV のバグや、PCの異常は除く



paper

リンク

2008/8/14(Thu) 08:18:37|NO.18196

私なりに表現をやわらかくして書いたつもりですが読み返せば皮肉たっぷりな感じの返信でしたね。
文字だけのコミュニケーションの難しさを改めて痛感しております。
ただ、『常識』や『暗に』といった言葉は複雑な社会背景を持つ人がいるネットでは禁句かな、とも思ったりします。
私みたいな人間には引っかかるものがありますので。

ご指摘のとおり、lineを始点終点を逆にして描画する、終点をpsetで塗りつぶす、
いっそ全てをpsetで描画する、といった選択肢を取れば確実ですね。
しかし、プログラムを組む上でやはり無駄、かもしれないことをすることがあまり好ましくないと思ったのです。
ループに組み込めば負荷はバカになりませんし、start.axのサイズも制限されていることから、できるだけスマートに書きたかったのです。

解決済みを押したにもかかわらず詳しく返信くださりありがとうございました。
これで心置きなくline命令が使えます。



ANTARES

リンク

2008/8/14(Thu) 20:38:00|NO.18234

>そこらへんの話は人の考え方によるので、どうしようもないと思います。
>( 半透明の線の描画の特殊かどうか、です )
 レノスさん自身が「特殊でない」と考えるのでない限り、無意味な主張です。
もし、レノスさん自身が「特殊でない」と考えるのなら、
その根拠を挙げてください。それが議論というものです。

>自分は、ANTARES さん自身がおっしゃるとおり、pget も pset も同じ手間ですが、
>それならどっちでも良いじゃないかと思います。
 その点に関してはもとより異論はありません。
その次の文を無視しないでほしい。

>その分、「仕様を変更すること」の重みが全く違います。
 WindowsやAPIの仕様変更の話をしたつもりはありませんし、
そんなことを議論する場所でもありません。

>また、HSP2 から HSP3 へは大きなバージョンアップなので、
>このときの大きな仕様変更は理由になりません。
 大きな仕様変更があったのに、lineについては仕様変更しなかったわけだから
lineが最も基本的な命令であることや互換性の問題は仕様変更しない理由に
ならないという主張に対して「大きな仕様変更は理由になりません」とは
どういう意味でしょう?



レノス

リンク

2008/8/14(Thu) 22:14:56|NO.18258

> 特殊でないという根拠
半透明コピーはよく使われています。
背景をすこし透かすときなど。

それと、自分は議論をするつもりはありません。

> その次の行を無視しないで欲しい
> > どちらが問題が大きいかで考えるべきでしょう。

同じ手間ならどちらの問題も同じ大きさなのでは?

>その分、「仕様を変更すること」の重みが全く違います。
↑の文は、↓の文に対する反論です。
> > Windowsでは古くから使われていると思われ、
> > また単純ゆえにそうそう簡単に仕様変更はできないものです。
>  多くのシステム変数名(HSP3ではマクロ名)が無意味に変更されていることを
> 考えれば、これも理由にはなりません。

[これも理由にはなりません] という言葉に対する反論のつもりでした。

> (略) … どういう意味でしょう?
しつこく、HSP2->3へのバージョンアップした時の、
システム変数名を無意味に変えていること に対する反論です。

「大きなバージョンアップの時、仕様変更があっても、それは例外だ」
という意味に捕らえてください。
※例外 … 「例に使えない」から例外といいました。

> paperさんの返信
見ようによっては非常に冷静な返答でしたね。
残念ながら皮肉と取られてしまいましたけれど。(あいての顔が見えないから)



ANTARES

リンク

2008/8/15(Fri) 21:00:48|NO.18316

>> 特殊でないという根拠
>半透明コピーはよく使われています。
 それは論点のすり替えです。
「line命令が終点を描く仕様になっていたら、線のつなぎ目で明るさが
変わってしまう場合がある」のが、特殊な条件か否かを論じているのですから、
半透明コピーは関係ありません。

>それと、自分は議論をするつもりはありません。
 議論する気がないのなら、(実質的に)レスしないことです。
レスするということは、議論を続ける意思表示になります。

>↑の文は、↓の文に対する反論です。
「多くのシステム変数名が無意味に変更されていることを考えれば、
<互換性の問題>も<lineの仕様を変更できない>理由にはなりません」
に対して
「HSP2 から HSP3 へは大きなバージョンアップなので、
このときの大きな仕様変更は<lineの仕様を変更できる>理由になりません」
と主張するのですか?
<>内は私が補ったものですが、これが正しいとすれば、
とてもおかしな主張だと思いますが、如何?

>「大きなバージョンアップの時、仕様変更があっても、それは例外だ」
>という意味に捕らえてください。
>※例外 … 「例に使えない」から例外といいました。
 「大きなバージョンアップ」を例として使ったわけではありません。
「システム変数名の仕様変更」を「大きなバージョンアップにおける仕様変更」の例として
使ったのです。
 「大きなバージョンアップ」は例などではなく、私の論旨の根幹です。
それを例外と言われても……。



レノス

リンク

2008/8/15(Fri) 23:07:27|NO.18322

> 「line命令が終点を描く仕様になっていたら、線のつなぎ目で
> 明るさが変わってしまう場合がある」のが、
> 特殊な条件か否かを論じているのですから

そうだったんですか!?
じゃあ、いままでの反論は自分の勘違いです。異論はありません。すいません。

てっきり「半透明の描画が特殊なケースか」の話だと思っていました。


> 議論
深い(長い、激しい)議論をするつもりはない、という意味でした。
この議論はすぐに終わると思っていたのですが……^^;。


> > Windowsでは古くから使われていると思われ、
> > また単純ゆえにそうそう簡単に仕様変更はできないものです。

の発言に対する、ANTARESさんの

> 多くのシステム変数名が無意味に変更されていることを考えれば、
> <互換性の問題>も<lineの仕様を変更できない>理由にはなりません

という反論は無意味です。(これが私の主張)

[根拠]
「多くのシステム変数名が無意味に変更されている」
という事実は、HSPの大きなバージョンアップに伴っています。
普通は、互換性の問題から無意味に仕様を変更したりできませんが、
この大きなバージョンアップのときは、互換性を無視しています。
(文法見直しのため、過去バージョンとの互換性を無視した。
システム変数廃止、関数になった一部の旧命令、演算順序、など)

よって、
> <互換性の問題>は<lineの仕様を変更できない>理由にならない
の例として
> 多くのシステム変数名が無意味に変更されていること
は不適切です。
(これが私の主張)


私の考えでは、
> 「HSP2 から HSP3 へは大きなバージョンアップなので、
> このときの大きな仕様変更は<lineの仕様を変更できる>理由になりません」
ではなく
> 「HSP2 から HSP3 へは大きなバージョンアップなので、
> このときの大きな仕様変更は<lineの仕様を変更でき"ない">理由になりません」
という意味でした。

ネット上の文章は出来る限り省略しないようにします。m(_ _;)m


>>> 直線を描画するAPIはWindowsでは古くから使われていると思われ、
>>> また単純ゆえにそうそう簡単に仕様変更はできないものです。
という文に対して、
なぜ「大きなバージョンアップにおける仕様変更」の例を出したのですか?



ANTARES

リンク

2008/8/17(Sun) 02:17:58|NO.18356

>> <互換性の問題>は<lineの仕様を変更できない>理由にならない
>の例として
>> 多くのシステム変数名が無意味に変更されていること
>は不適切です。

「多くのシステム変数名が無意味に変更されていること」は、
「大きな仕様変更」の例であって
「<互換性の問題>は<lineの仕様を変更できない>理由にならない」ことの
例ではありません。根拠です。

「多くのシステム変数名が無意味に変更され」たなど、大きな仕様変更がいくつも
あったから、「<互換性の問題>は<lineの仕様を変更できない>理由にならない」
のです。

また、「多くのシステム変数名が無意味に変更されていること」は
「そうそう簡単に仕様変更はできないものです」に対する反例でもあります。


>> 「HSP2 から HSP3 へは大きなバージョンアップなので、
>> このときの大きな仕様変更は<lineの仕様を変更でき"ない">理由になりません」
>という意味でした。
 ある仕様変更が他の仕様を変更できない理由にならないのはあたり前ですし、
結局どういうことなのかよくわかりませんが、
これは「<互換性の問題>も<lineの仕様を変更できない>理由にならない」
という主張に対する反論にはなっていなかったという認識でいいですか?


>ネット上の文章は出来る限り省略しないようにします。m(_ _;)m
 私もいっぱい省略してますし、そんなことを気にする必要はありませんが、
何を省略しているかは意識しておく必要があるでしょう。


>>>> 直線を描画するAPIはWindowsでは古くから使われていると思われ、
>>>> また単純ゆえにそうそう簡単に仕様変更はできないものです。
>という文に対して、
>なぜ「大きなバージョンアップにおける仕様変更」の例を出したのですか?

「そうそう簡単に仕様変更はできない」という主張があった。
      ↓
しかし、実際には同じくらい重大な仕様変更の例がある。
      ↓
明らかに矛盾しており、「仕様変更できない」という主張はおかしい。



ANTARES

リンク

2008/8/17(Sun) 02:46:03|NO.18357

 たぶん、レノスさんは最初に私の文章を読んだとき、
直感的に「HSP2→HSP3のような例外的な大改造を持ち出すなんて卑怯だ」
みたいなことを感じたのではないかと思います。
しかし、逆に「例外的な大改造の後だからこそ、普通なら十分根拠になる
互換性の問題が根拠にならなくなっている」というのが実態なのです。



レノス

リンク

2008/8/18(Mon) 02:18:10|NO.18394

>  たぶん、レノスさんは最初に私の文章を読んだとき、
> 直感的に「HSP2→HSP3のような例外的な大改造を持ち出すなんて卑怯だ」
> みたいなことを感じたのではないかと思います。
> しかし、逆に「例外的な大改造の後だからこそ、普通なら十分根拠になる
> 互換性の問題が根拠にならなくなっている」というのが実態なのです。

……そうですね。そういうことなんですね。
「直感的に〜」の文は図星です。

長々とありがとうございました。ようやくわかりました。



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