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


HSPTV!掲示板


未解決 解決 停止 削除要請

2014
0920
HIJIKIお絵かきチャットを作ろうとした時のプラグイン選びと送受信内容7解決


HIJIKI

リンク

2014/9/20(Sat) 17:18:11|NO.65085

HSPで、一般的なクライアント・サーバモデルのお絵かきチャットを作成しようとしています。
http://holyweb.pgw.jp/hijkcapture/hijiki/9cy0r2gp.png

そこで、2 点の質問があります。
1.
 使用するネットワークプラグインは pcbnet2 を予定していますが
 それよりもっと適切なプラグインはありますか?
 また、その理由も加えてお答え頂けると嬉しいです。

2.
 一般的に、お絵かきチャットのプログラムでは、
 何のデータをやりとりさせるのでしょうか?
 クライアントが線を描いた時の、マウスドラッグ座標を送信して
 サーバ側がそれを各クライアントに返してあげるのか、
 それとも、クライアントが線を描いた結果の画像を送信して、
 サーバ側がそれを各クライアントに返してあげるのか、など。
 何のデータをどのようにやりとりして実装するべきなのかを
 教えて頂きたいです。

その他、細かなアドバイスや技術サポートは
あればあるほど嬉しいです。
お暇な方はよろしくお願いいたします。



この記事に返信する


Flat

リンク

2014/9/20(Sat) 17:26:13|NO.65086

1. どれも大差ないと思います

2. TCPを用い、かつ描画結果が一意に決まる場合はどちらでも問題無いと思います
そうでない場合は画像を使用したほうが良いかと
(UDPとかは通信データが失われる可能性を孕んでいるので)

もし画像を送信するなら、圧縮したほうが回線に優しいです。
あとは、変更があった領域のみを送信すると通信データ量が少なくなっていいかも。



HIJIKI

リンク

2014/9/20(Sat) 17:32:10|NO.65087

>>flatさま
さっそくご返答ありがとうございます。

>2. TCPを用い、かつ描画結果が一意に決まる場合はどちらでも問題無いと思います
>そうでない場合は画像を使用したほうが良いかと
>(UDPとかは通信データが失われる可能性を孕んでいるので)

TCP 通信を用いるべき という点はよくわかりました。
ありがとうございます。

ただ
「描画結果が一意に決まる場合はどちらでも問題無いと思います
 そうでない場合は画像を使用したほうが良いかと」
の部分が何を意味しているのか、わかりませんでした。

特に、描画結果が一意に決まる場合 とは一体どういう意味でしょうか?
よろしければ、お手数ですが引き続きお願い致します。



cats

リンク

2014/9/20(Sat) 17:39:40|NO.65088

pcbnet2はいろいろと機能が付いているのでおすすめです。
絵の通信はバイナリで行います。
絵を描いたクライアントは完成した絵のバイナリデータをサーバーに送信し、
それを受け取ったサーバーは全クライアントに絵(バイナリデータ)を送信します。
しかし、絵のサイズは可変ですので、まずはじめに絵のサイズを知る必要があります。
絵を描いたクライアントは絵を送る前に絵のバイナリデータのサイズをサーバーに送信し、
それを受け取ったサーバーは全クライアントにバイナリデータのサイズを送信します。
するとクライアントは次に来るであろうバイナリデータを受信する体制に入ります。
受信するデータに対して十分な変数のサイズを確保しておかないとオーバーフローにより
任意のコードをサーバー上で実行される可能性があるので注意してください。



KOMARI

リンク

2014/9/20(Sat) 17:55:19|NO.65089

 一度出来損ないとかいうレベルの代物じゃないお絵かきチャットを作ったことがあります。
まともに動くことすらなかったですが、(TCP)通信の勉強にはなりました。

1.
 自分が使いやすいものならなんでもいいんじゃないですか。
 TCPかUDPかによって使えるものも変わるんでしょうけど。
2.
 >>一般的に、お絵かきチャットのプログラムでは、
 >>何のデータをやりとりさせるのでしょうか?
 残念ながら、私は一般的な方法に関しては知りません・・・。
 前自作したときも適当に自分で考えてやってました。
 >>それとも、クライアントが線を描いた結果の画像を送信して、
 これをすると、データ量が膨大になるのでお勧めはしません。
 ので、
 >>クライアントが線を描いた時の、マウスドラッグ座標を送信して
 >>サーバ側がそれを各クライアントに返してあげるのか、
 今私が作るとしたら、通信方法としては上記のように、
  自分がしたことと同じ動作を他のクライアント上でさせる
 ことを前提に組みますね。
 それをなしえるだけの構造を考えて実際に関数群を組むのは、結構骨が折れそうですが。

 個人的には、
 1."ただのペイントソフト"が作れる
 2.通信関連の知識が多少ある
 なら、"お絵かきチャット"という形にしてもそう難しくはないのではないか、と思っています。
 結局、
 >>何のデータをどのようにやりとり
 するかは、HIJIKIさんがどう"ペイントソフト"を組むか次第だと思います。
 通信する上で、"ペイントソフト"の関数群をどうすれば扱いやすくなるのかに関しては、
 ・そもそもどんな機能を用意するのか
 ・例えば線を描けるなら、情報として何が必要なのか。その情報からどうやって線を描画するのか。
 など、あらかじめHIJIKIさんが思い描く"ペイントソフト"の方針が分かっていないと、答えようがないのではないでしょうか。

 結論としては、"ペイントソフト"の関数群をスマートにする方法を考えればいいのではないでしょうか。
例えば、"ペイントソフト"上で線を引く関数に与える情報量を少なすれば処理負荷が減ります。
それは結果的に見れば、"お絵かきチャット"で流用した時に通信負荷も下がりますよね。
気が向いたら私も組んでみようかなあ。



Flat

リンク

2014/9/20(Sat) 18:05:35|NO.65091

>描画結果が一意に決まる場合

たとえば、ペイントソフトの中にはスプレーなどの機能を持ったものが存在します。
そのスプレーは乱数を用いていますので、環境によって結果が変わることもあります。
そのことを描画結果が一意に決まらない場合と表現しました。
(まあ乱数シードを統一すればよい話ですが。)

他にも浮動小数(HSPの実数など)を用いた計算では少なからず誤差が発生します。
その誤差も環境依存ですので、計算を重ねるうちにずれてしまうことがあります。
それも描画結果が一意に決まらない場合と考えております。



HIJIKI

リンク

2014/9/20(Sat) 18:37:58|NO.65094

>>catsさま
ご返答ありがとうございます。

線の座標情報ではなく、絵をバイナリデータとして送信しても、
実装次第では回線的に問題ないということがわかりました。
他の回答と併せて参考にさせて頂きます。ありがとうございます。

>>KOMARIさま
ご返答ありがとうございます。

とても参考になりました。
もちろん、ペイント部分の機能は作成したことがあります。

仰るとおり、ペイント部分の処理を極力シンプルにおさえ、
座標のみを送信すればスムーズにいきそうです。
ありがとうございました。

>>Flatさま
再度ご返答ありがとうございます。
とてもよくわかりました。

お互いの環境で処理した時に、描画結果が異なる可能性があるもの
という意味ですね。

参考になりました。ありがとうございました。



HIJIKI

リンク

2014/9/20(Sat) 18:43:45|NO.65096

ここまで出ている回答で
私が知りたかったことは十分出ていると判断しましたので、
解決とさせていただきます。

みなさまありがとうございました。



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