ｉアプリでゲーム

**利用者側** · 01/11/06 19:30

単純ではまるってなゲームつくってほしいー。

**名前は開発中のものです。** · 02/06/01 14:23

>>407
通常の使用で100回もタイマを取得するようなことになってしまうような
コードは、俺は絶対に書かないが、世の中にはそんなプログラマが多いのか？
不思議になってくる。

**名前は開発中のものです。** · 02/06/01 14:24

っつうか、パケ代がたけーんだよ。なんとかしろ！＞NTTコドモ！！！

**407** · 02/06/01 14:47

>>408
いや、一つ間違えました。
DoJa2.0からはstart()にて復帰できる事が仕様として保証されたみたいですが、
DoJa1.0では「タイマーのインスタンスを破棄した上で再作成する必要があります。」だそうなので。
実行環境を認識し、DoJa2.0だったらShortTimerを作りなおさずに再利用する、様に作れば良いんですね。

＞通常の使用で100回もタイマを取得するようなことになってしまうような
コードは、俺は絶対に書かないが

との事ですが、DoJa1.0時代にはそれが常識だったらしいです。
まあ、「アプリケーションの実行が中断された場合」に限って取得すれば良いはずではありますが。
それでも理屈上は、何十回か（タイマー動作中に？）中断を繰り返せば、DoJa1.0時代の常識で書かれたコードはN504iでは落ちる、って事になるでしょう。

ところで>>404に
＞バグるっていうか、「例外が発生してる」んだよね
って書いたけど、実機でも例外がThrowされてる、とは明言されて無さそうですね。要確認でした。

**名前は開発中のものです。** · 02/06/01 16:44

10機種あればこの手の小バグの数が10倍になるというJavaの罠

**名前は開発中のものです。** · 02/06/01 17:28

Javaが原因ってより、
"Write Once, Run Anywhere" の幻想はハードに余裕が無いほど霞むって事だろうか。
ってゆうか、実力以上の仕事を強いられているんだろうね、製品開発を担当している人々は。バグが生じても当たり前のスケジュール、みたいな。

**372** · 02/06/01 21:05

えらい言われようの372です。
>>390
登山家に何故の山に登ると?と聞くと「そこに山があるから」と答えるのになぞらえて洒落のつもりで言ったんですが、
まじめな議論に水を差すような発言だったようで申し訳無いです。今後は冗談を控えるんでもう少し議論に付き合ってください。
>>398
あなたの主観で間違ってるといわれても困ります。具体的に説明してください。
少なくとも、俺のプログラムが何故あんなプログラムになったかは説明しています。
言いっぱなしは止めましょう。議論になりません。
俺はプログラムについていろいろ勉強したいのです。
>>400 0.2秒毎にイベントを発生させるのに、いちいち再作成する必要がありますとは書いてないよね。
将来的に0.2秒を可変にするつもりだったって説明してるでしょ?だから、必要なのです。
>>402
あなたがこの関数の設計者ですか?それともこの関数の作成意図がどこかに書かれていますか?
根拠を示してください。
>>404
>エミュ版制限の100って数字は、意図的なものの様にも思える。
その意図を公式に説明して無いから文句を言っているのです。
>「バグの為にオレの作りたいアプリケーションが作れない」
俺の主張は「俺の作った503アプリが504で動かない」です。
503用のアプリと互換性を謳っているのに504で動かないのは問題でしょ?
>>405
>確かにバグくさいが、こんなださいソース書いてる方が笑われるぞ。
バグなのと笑われるのは別々に論議しましょう。
>このアプリでしか発覚せん可能性、十分にあり。
DOCOMOが503用エミュのサンプルとして提供しているスペースインベーダーがShortTimer.dispose()で落ちます。
DOCOMOのサンプルを参考にして作ると今回の件に引っかかる可能性、十分にあり。

**372** · 02/06/01 21:09

>>408 & Thread使えばと指摘した皆さん
ShortTimerとThread.sleepで同じ動きをするサンプルを書いてみました。
http://mightguy.tripod.co.jp/cupmen/ShortTimerVSThread.lzh
カップ麺タイマーから余計なものを省いた仕様にしたつもりです。
・503, 504両対応
・レジュームの処理をする
・キー入力を受けつける
・ShortTimerおよびThread.sleepの間隔は2000から毎回-1する
・ShortTimerおよびThread.sleepと平行して画面出力を行う
DOCOMO503エミュでコンパイル後、jarファイルのサイズを比較
俺のプログラム能力では
ShortTimer:1234byte
Thread:1513byte
となり、2パケット強の差が出ました。
これは、Thread使うよりShortTimer使う利点になると思うのですが、どうでしょうか?
もし、Threadの方がShortTimerよりも小さくなるならば
今後はThread派に転向するので、プログラムの添削お願いします。
(ようやくスレッド名に沿った内容に近づいたかな?)

paint(), repaint()についての記述をみつけました。
http://www.nttdocomo.co.jp/p_s/imode/java/pdf/jguide504_020517.pdf
68ページ。paint(), repaint()は用途が違うようです。
意図した画面を確実に出したい場合はrepaint()ではなくpaint()を使えと書いてあるように読めます。iアプリは一般的なJAVAと違うようですね。

**エアリエル** · 02/06/01 22:06

そういえばN503だけショートタイマーが正確ではないそうですよ。
情報ソースはこちらでふ。
http://vs.g-appli.net/tips03.html

PだけRESET_VM_EVENTが通知されなかったりとか、、
まぁ色々機種があれば色々あるわな～～、、、統一せい！（怒

**372** · 02/06/02 00:02

>>415
いろいろ制限あるんですね。商売でiアプリかいてる人は大変だなぁ。

誰も答えてくれないからShortTimerを頻繁にdisposeするのは下品だって解説してるサイト
探してるんだけど、見つからないです。
実はここのみんなに担がれてるんじゃないかって気になってきたよ。

**名前は開発中のものです。** · 02/06/02 00:30

ここでアドバイスしてくれたひとは信用ならんって訳か？
じゃ最初から他で聞けよ

**エアリエル** · 02/06/02 00:33

>誰も答えてくれないからShortTimerを頻繁にdisposeするのは下品だって解説してるサイト
>
ご要望とあらば作りますが…(笑）

**372** · 02/06/02 00:49

>>417
あなたは、ろくに理由も説明されずに人を殺せってアドバイスされたら殺しちゃうタイプですか?
ShortTimerに関しては「普通はそんなプログラム書かない」と言うだけで
何故それが普通なのか誰も解説してないでしょ？
ShortTimerバグの回避方法とか、Threadの使い道とかいろいろ参考になってるので感謝してますよ。
文句だけ言うなら他で言えよ

**名前は開発中のものです。** · 02/06/02 01:08

例えば「自動改札機の正しい通り方」なんかを解説してるサイトなんてのを探しても
おそらく見つからないわけで。

**名前は開発中のものです。** · 02/06/02 01:44

>>420
http://www.himeji-iec.or.jp/life/c_03/
これじゃ駄目？

**エアリエル** · 02/06/02 01:49

>「自動改札機の正しい通り方」なんかを解説してるサイトなんてのを探しても
>
ご要望とあらば作りますが…(笑）

、、と、冗談は置いといて、
3分クッキングでこんなに盛り上がってて楽しかったけど飽きた。
それに、夜更かしはお肌の大敵だからみんな寝ようね。
これ以上盛り上がってもつまらないので、とりあえず眠って、
頭冷やすなり、凍らせるなり、滝に打たれるなり幽体離脱してきてちょうだい。

**名前は開発中のものです。** · 02/06/02 10:03

>>413
＞将来的に0.2秒を可変にするつもりだったって説明してるでしょ?だから、必要なのです。

だからよぁ、必要無いって指摘があるでしょーが。>>393に。意味が解らない？
それとも無数のバリエーションに可変する必要があると主張するか？
最悪、最高のレゾリューション（最小の間隔、例えば100ms）のタイマー1個で済ます、って手もあるよ？

**名前は開発中のものです。** · 02/06/02 10:39

>>414
＞68ページ。paint(), repaint()は用途が違うようです。

全く同じだと思っている人は少ないでしょう。その違いは認識した上でrepaint()を用いているのが普通だと思いますよ。repaint()は、システムが負荷に応じてpaint()呼出しのタイミングを調節できるようにする為に用意されている、と認識してます。

＞意図した画面を確実に出したい場合はrepaint()ではなくpaint()を使えと書いてあるように読めます。

確実に......まあ、より確実にpaint()が実行されるのは事実でしょうね。
画面の書き換え頻度が0.2秒毎程度でpaint()以外に重たい処理を行わないiAppliならrepaint()で十分なんじゃないかとも思えるんですが、なんぜ機種毎に何が起こるか解らない端末ですから、確実性を求めたくなるのも、もっともかもしれませんね。
開発ガイドを熱心に読まれているようですね。73ページ下の注意事項も重要だと思いますよ。processEvent()呼出しからpaint()を呼び出すのは、推奨されていないんじゃないでしょうか？paint()が十分に軽いと確信されているのなら、これ以上は言いませんが。

**424** · 02/06/02 10:47

....まあ、どうせ限られたイベントしか発生しないのだろうし、タイマーでアスキーアートを書きかえる程度のアプリケーションであれば、processEvent()からpaint()を呼び出しても実害は発生しないでしょうね。余計なアドバイスでした。

**372** · 02/06/02 12:41

>>423
＞無数のバリエーションに可変する必要があると主張するか
414で主張していますが。
最小の間隔のShortTimerを使いまわすとプログラムが増えて
jarファイルのサイズが大きくなるので却下です。
パケット代も考慮しましょうよ。

>>424
素人なんで参考に出来るのがDOCOMOのサンプルとWEBの情報だけなんですが、
503エミュのサンプル
\J2MEWSDK4DOJA\apps\uidemo\src\uidemo\CanvasDemo.java
でprocessEvent内からrepaint()しているのが確認できます。

**エアリエル** · 02/06/02 13:07

あの～ところで、、503用アプリは504で中央に寄せられた形で表示されると
聞いた事があるんですが、本当ですか～？それとも意図的に中央にするメソッドか
何かがあるんでしょうか？そんなのがあるんなら教えて欲しいです～～～。

**名前は開発中のものです。** · 02/06/02 14:02

>>426
＞でprocessEvent内からrepaint()しているのが確認できます。

あなたはその例を参考にしてrepaint()を用いるようにしている、という事ですか？

>>427
>>271-275では解決しなかったという事ですか？

**名前は開発中のものです。** · 02/06/02 14:11

>>897これとかねｗ
http://freehost.kakiko.com/freen/kesaku.html

**372** · 02/06/02 14:35

>>議論に参加している皆さんへ
話がややこしくなってきているのでここで一度整理したいと思います。
1:N504iと504エミュのShortTimer.dispose()問題
dispose()を呼ぶこと自体が問題なので、
ShortTimerを使うならここで紹介された回避策を使う
Threadでタイミングを取る
という意見に俺自身納得しました。今後この件に関してはの俺のスタンスは、
プログラムのここを変更すると効率が良くなる
ほかの方法でもタイミングが取れる、といった前向きな議論以外には参加しないということにしたいと思います。

2:ShortTimer.dispose()が正常に動く端末でのdispose()の是非
>>414にて、特定条件下でのThreadに対するdispose()の利点(jarサイズ)を挙げてみました。
これに対して、プログラムの書き方次第では立場が逆転する
disposeしないでShortTimerをうまく使いまわすと効率が良い、といった議論は大歓迎です。
「俺はこんなださいプログラムを書かない」「普通はこんなことしない」といった
実例をあげない反論は無視させていただきます。
あと、「dispose()は極力避けましょう」と多くの人が言っている根拠(雑誌の記事、ネットのTips集など)を知りたいので情報をお持ちの方はお教えください。

3:その他
俺がサンプルとして書いたプログラムに関する根拠のある突っ込み(最近だと>>424)はいろいろ勉強になるので大歓迎です。

**372** · 02/06/02 14:54

>>424,428
極力短時間というのはどう解釈すれば良いんですかね?
解釈の一例として426で挙げたプログラムは参考にしています。
いろいろ指摘を受けた結果、カップ麺タイマーに関しては極力短時間の
範疇を超えてるなと現在では思っています。

**名前は開発中のものです。** · 02/06/02 15:11

>>430
>>414のサンプルを見てみましたが、repaint()について理解していない様に思えます。
それと、あなたはたしか、ある時間が経過した事を知らせるアプリケーションを作ろうとしてたんだと思います。
最低限、その機能を持たせたサンプルにしていただけますか。
現状だと、両コードが同等の挙動を示すとは思えませんし。（interval値の変化など。）
（同等の動作をしている事を画面等で確認できる様にした方が良いのでは。）
その上で、出来れば実機でのタイマーとしての精度なども合わせて評価してみて欲しいですね。
そう精密な精度を要求するアプリケーションでは無いでしょうけれど、レゾリューションが荒いと評判のiアプリ環境で、Timer（恐らくsleep()も？）を細めに無数に繋ぎ合せての経過時間算出というのは、あまり普通の方法では無い様に思えます。

**432** · 02/06/02 15:16

>>432
＞レゾリューションが荒い

タイマーの事です。

**名前は開発中のものです。** · 02/06/02 15:21

>>431
＞いろいろ指摘を受けた結果、カップ麺タイマーに関しては極力短時間の範疇を超えてるなと現在では思っています。

これまであなたは、自分は間違っていないと主張する事に一生懸命だったように思えます。気のせいでしょうか？

**エアリエル** · 02/06/02 15:45

そんな事はどうでも良い。我が問いに答えよ（笑）
揚げ足とりは”大好き”だけど、今回の揚げ物は面白味が無い。
ということで、とりあえず終わりにしませうや。
さもないと実況しちゃうよ？

**名前は開発中のものです。** · 02/06/02 15:48

>>435
>>428に答えよ。
揚げ足とりで無く、反省を促しているつもりなんだけど。今後の為に。
実況？すれば？

**エアリエル** · 02/06/02 16:08

>>436
あ～～～っと！さっそくレスが来た！！！！！（笑

まぁ～ええからええから、、人の考え方は違って当然、
その人にはその人のやりかたってものがあるんだから
ちょっと自分の気に食わん意見があってもしゃ～ないねん。
まっ気にせんとこうや～～。というわけで、我が問いに答えよ（爆
反省しろいうても、言ってる方の言う事が本当に正しいの？
言われてる方の言う事が正しいの？私はどっちでもいいし
どうでもいい。というわけで、我が問いに答えよ（しつこい(笑

**名前は開発中のものです。** · 02/06/02 16:24

>>437
はぁ。>>428に答えよ。

**名前は開発中のものです。** · 02/06/02 16:36

サンプルコードとか、落ちてないの？

**名前は開発中のものです。** · 02/06/02 16:56

エミュレーション環境ではその方法でセンタリングされたけど、実機ではダメなの？

**エアリエル** · 02/06/02 18:15

DrawAreaもいいんですが、これはJAMに情報を書きこまないといけないし、
一般的なアプリは120*130ですから、SO504iの128*128だと仕様でダウン出来ない
そうですし…(前提条件のサイズは必ずその機種の描画サイズ以下でなければいけない)
なんかこう～都合良く503.504全機種で使えるようなものはないですかね～。

**エアリエル** · 02/06/02 18:19

>>271-275では解決しなかったという事ですか？

↑この記述見落としてました。
それと該当の271～275、、忘れてました。

**名前は開発中のものです。** · 02/06/02 18:58

>>441
＞なんかこう～都合良く

ではまず、あんたの都合を教えてください

**名前は開発中のものです。** · 02/06/02 19:30

>>442
＞忘れてました。
>>427
＞あの～ところで、、503用アプリは504で中央に寄せられた形で表示されると聞いた事があるんですが、本当ですか～？

「中央に寄せられた形で表示されると聞いた事がある」ってのは結局、DrawAreaの事だったの？別の方法を聞いた事があるの？

**372** · 02/06/02 20:19

>>432 最低限、その機能を持たせたサンプルにしていただけますか。
http://members.tripod.co.jp/mightguy/cupmen/ShortTimerVSThread2.lzh
・503, 504両対応
・レジュームの処理をする
・キー入力を受けつける
・ShortTimerおよびThread.sleepの間隔は5000から毎回-1000し、1000になった段階で終了表示を行う。
・ShortTimerおよびThread.sleepと平行して画面出力を行う
「5回ならタイマー5個用意すればすむ」という人は5000という値を増やしてください。
DOCOMO503エミュでコンパイル後、jarファイルのサイズを比較
ShortTimer:1304byte
Thread:1682byte
となりました。

>>434 気のせいでしょうか？
気のせいです。複数の主張を一まとめにして語られても困ります。
実際、N504iと504エミュに問題があるって主張は変えてないし、
皆さんの協力のおかげで原因とその対処方法が確立されたわけですよ。
ただ、カップ麺タイマーの件を指摘した>>393にはどこまで削れば極力短時間に収まるのか、解説願いたいですね。

**名前は開発中のものです。** · 02/06/02 20:50

なんだかなあ・・・

**エアリエル** · 02/06/02 21:18

>>443
え～っとねぇ～、まず頭で考えたのが自動的にコードになってくれてねぇ～…

>>444
504で503アプリは勝手に中央揃えになってくれると聞いた事があります。
つまり、、別の方法という事になります。
しかし、まぁたぶんDrawAreaの事でしょうね。
人づてに歪んだ形で伝わってきたんでしょう。

**名前は開発中のものです。** · 02/06/02 21:31

>>445
そんなに間隔を広くしちゃ、当初の目的？のAAアニメが出来ないじゃん。アニメ止めちゃうの？
細かいインターバルの単発タイマを大量につなげた際の誤差を計測するのが嫌だから止めたの？
タイマーを大量に（百個～数百個？）取得する際にトラブるのが問題だったんだよね？その線で続けないの？
上手い省略が難しいなら、元々小さなアプリだし、フル実装しちゃえば確実じゃない？
動作確認してみた？通話の割り込みなどで中断した際の復帰は正常に動作してる？
repaint()の動作、まだ解ってないみたいだね。paint()はrepaint()が呼ばれた回数だけ呼ばれるとは限らない事は解ってるんだよね？

なんか、想像以上だよ、あんた。

**372** · 02/06/02 21:45

>>448
あなたが423という家庭で話すね。
>>430の2読め
ShortTimer使わないでThread使ったらという人がいるからShortTimerを使う利点の話してるの。
話を勝手な方向に持っていかない。

＞なんか、想像以上だよ、あんた。
あんた、俺以上だよ

**エアリエル** · 02/06/02 21:47

現在のソースでは着信復帰時にintervalのカウントをやり直す
(という表現が正しいかはわからないが)みたいなので、強烈にズレません？
着信時はアプリが止まってる訳だから、この時間分の誤差はどうしようも
出来ないけど、せめて着信があったその直前の値から数えないとマズイと思う。

**名前は開発中のものです。** · 02/06/02 22:01

>>450
ずれるって事は、復帰はするの？うちのエミュでは例外が出て復帰出来ないんだけど。

**名前は開発中のものです。** · 02/06/02 22:09

>>449
コードのサイズを比較したいんだよね？ShortTimerを使った場合とThreadで実装した場合で。
ならさ、それに関連する部分の必要なコードは一通り正しく実装しないとね。例えば中断からの復帰とか。現状、正しく動作しないみたいなんだけど。
インターバルが小さいままでも大きくしてもコードサイズに影響ないと思うんだけど、どうして初めの仕様から大幅に変えたんだろう？0.2秒間隔近辺の可変でも良いんじゃないの？
で、経過時間を表示する様にしとけば良いじゃん。

**名前は開発中のものです。** · 02/06/02 22:18

>>449
あまりに元のアプリの仕様とかけ離れてると、「こうやればコードサイズを小さくできるよ」って指摘のしようが無いんだけど。
現状のコードに対して指摘しても、「その方法は私のアプリでは使えません」って事になる可能性が高いでしょ？

**エアリエル** · 02/06/02 22:32

>>451
実際には動作させてませんので、あしからず。
見ての通り、残りあと少しといった所で着信があったら、また最初から数え直しでしょ？

**372** · 02/06/02 22:46

>>448, 451
レジューム処理の確認をしないままUPして申し訳無い。

http://members.tripod.co.jp/mightguy/cupmen/ShortTimerVSThread3.lzh
・503, 504両対応
・レジュームの処理をする
・キー入力を受けつける
・経過時間の表示
・ShortTimerおよびThread.sleepの間隔は1000から毎回-100し、100になった段階で終了表示を行う。
・ShortTimerおよびThread.sleepと平行して画面出力を行う
DOCOMO503エミュでコンパイル後、jarファイルのサイズを比較
ShortTimer:1427byte
Thread:1695byte
となりました。

>>453
元の仕様に近づくように変更しましたが、まだかけ離れていると思う点があれば指摘してください。

**名前は開発中のものです。** · 02/06/02 23:52

>>455
Threadの方、修正したら1253byteになったよ。
ShortTimerの方は、さわる気にならかったよ。

**haruka** · 02/06/03 04:12

>>455
リソースの限られている機械向けのソフトウェアで、
オブジェクトの生成→破棄を必要以上に頻繁に行うっていうのが、
私にはとても奇妙に感じるのです。

Thread版見たけど、一回タイミング測る毎に
Threadを生成→破棄を繰り返してるってのは、
ちょっと普通じゃないと思うな。

**名前は開発中のものです。** · 02/06/03 08:08

>>456-457
ソースコードがみたいにゃー

**458** · 02/06/03 09:03

>>456
気になって仕事に行けねぇ(藁
せめてrun()だけでもここにはってくだちい
予想ではこんな感じか?
public void run() {
while (true){
repaint();
try {
if (interval > 100) interval -=100;
Thread.sleep(interval);
} catch (InterruptedException e){}
}
}
で、class Wを取っちゃうの。

**名前は開発中のものです。** · 02/06/03 14:28

ソースの注釈を見たところ、製作者としては時間計測の精度に気を使っているようです。
時間を正確に計りたいならもっと良い方法はあるでしょうけれど、
現在の方法でどの程度の精度が得られるのか、実機（何機種か）で評価してみていただきたいです。
カップラーメンタイマーとの事ですから、３分か５分の計測が良いでしょう。
（通話などの割り込みがあるケースは無視して良いでしょう。）
ストップウォッチを用いて、各機種ごとに10回程度計測し、....んな事、だれもやらないですね。

**名前は開発中のものです。** · 02/06/03 22:19

ル・マン24時間レースのアプリとかどうですか？

ちゃんとセーブ機能をつけないと大変なことになりますが・・・。

**名前は開発中のものです。** · 02/06/03 22:30

>>461
サーバー側で勝手に周回してるようなゲームだと良いかも。
時々アクセスして状況を見る。気が向いたらドライバー交代して運転も可能？

**372** · 02/06/03 23:27

>>457
＞私にはとても奇妙に感じるのです。
普通のプログラマが奇妙に感じるプログラムで、jarファイルのサイズ(==パケット代)が減るかも
という仮説に基づいてのプログラムしたものです。
＞ちょっと普通じゃないと思うな。
俺にはrepaint()とThread.sleep()を並列化させる方法があれしか思い浮かびませんでした。
今回の件でいろいろ勉強になりましたが、まだまだ未熟だと実感しています。
ですので、もっと良い方法があったらご教授ください。

>>459さんのプログラムに２、３行追加して、repaint()とThread.sleep()を並列化させるという方向で
>>456さん言うの方法を小一時間考えてみたのですが、俺の乏しい知識では思いつきませんでした。
降参です、>>456さんにはぜひともプログラムを公開していただきたい。お願いします。

>>460
意図を汲み取って頂けてなんとなくうれしいです。
それに、精度のこともあるけど、比較するなら同じ条件じゃないと不公平じゃないですか。
repaint()とThread.sleep()のを並列にしないなら、ShrotTimer側のresume処理を端折っても良いとか言えちゃうわけでして。

**通りすがり** · 02/06/04 00:25

>>455 さんの物を元にいじってみた。
Thread 1237byte
ShortTimer 1271byte
容量重視でいったので必要な分しか書いてません。
場違いだったら大変申し訳ない。
http://www.xoasis.com/~fnmvei/apps.zip

**名前は開発中のものです。** · 02/06/04 00:31

Thread版のclass c に対して、
変数
　volatile int n = 0;
を追加し、run() の
　repaint();
を
　n = 2;
　repaint();
　n *= 2;
に修正、paint()の先頭に
　n +=3;
を追加、func()のどこかに
　g.drawString("n:" + n, 50, 15);
を追加してみてください。
nはいくらになるでしょうか？

或いは
repaint()を呼び出しているThreadとpaint()が呼ばれているThreadは同一でしょうか？
例えばThread.currentThread().toString()などとすればThreadを識別する為の文字列が得られると思います。

実行環境によって結果が異なる可能性は、ありますね。私はiアプリ端末を持っていませんから実機での確認は出来ませんが・・・・

**465** · 02/06/04 02:25

そういう問題でも無さそうですね・・・・
じゃあ、Threadを生成するのとrepaint()、どっちが重たいか・・・・
いや、そんな事考えるより、単純に計測スタート時のSystem.currentTimeMillis()を基準にタイミング調整するように作っとけば累積誤差とか気にせずに済むんだよね。
（機種によっては、補正が必要らしいけど・・・・。）

**haruka** · 02/06/04 05:50

>>463
片方のスレッド(a)で、
Thread.sleep(...); count++; b.notify(); をぐるぐるまわして、
もう片方のスレッド(b)で、
repaint(); wait(); をぐるぐるまわせばいいんじゃないの?

wait()の方がnotifyより後に実行されちゃうとハマるから、
本当にやるならフラグ管理してwait()を飛ばす等の処理が必要になるけど。

**名前は開発中のものです。** · 02/06/04 21:54

あまりどういう事か把握できなくて何だけど
repaint() paint() で描画やら無くてもいいと思うけどこれは的外れかな・・。
paint() は repaint()によって呼ばれるとは限らなかったはずだから。

**名前は開発中のものです。** · 02/06/04 22:46

>>468
プログラムから意図的にrepaint()しなくても、例えば通話の割り込みからのアプリへの復帰などの際にシステムからpaint()が呼ばれたりする訳ですよね。
だからこそ、paint()が呼ばれた際に描画を行う事が望ましいと思うのですが。
そして、システムの都合に合わせ、無駄な再描画による電力消費を抑制する為にもrepaint()呼出しによる控えめな描画要求を行うのだと思います。
リアルタイムなアクションゲームなど、再描画がムチャクチャ激しいアプリケーションの場合は、そういう気遣いの優先順位は低いでしょうけどね。
ゆるいアプリなら、わざわざrepaint()やpaint()を無視する必要は無いと思うんですが。
もちろん、paint()では表示バッファの更新を行うのであって、オフスクリーン描画他の処理はpaint()で行う必要はないと思います。

**名前は開発中のものです。** · 02/06/05 22:58

>>372は消えましたか？

**372** · 02/06/06 02:34

>>464
この時間はサイトが重いのか、ファイルを拾うことが出来ませんでした。申し訳無い。
昼間の軽い時間に再チャレンジしてみます。

>>470
仕事で残業(泊まり)あったりするんで、皆勤賞は狙えないかもです。

>>一連のThread議論
前にも一度引用したんですが、
http://www.atmarkit.co.jp/fmobile/rensai/doja06/doja06.html#2
の●Canvas#repaint()のタイミングってところ。
この記事を信じると、repaint()で描画スレッドが作成され他の処理と並列に描画する端末と
repaint()内部でpaint()を呼ぶ端末があるように読めます。
俺の解釈では後者はThreadを使わないで描画処理していると思うんですが、
N503i,P503iを借りてきて実験してみるという環境にいません。
そこで、>>465さんの提案を誰か実際の端末(P503i, N503i)でやってみてもらえませんか?

**haruka** · 02/06/06 09:00

>>469
それはあってると思うよ。
でも同じ理由で、、
paintで描画以外の処理をやるのは、
あんまりオススメできないと思う。

意図しないときに呼ばれたり、呼ばれなかったりするわけだから。

**名前は開発中のものです。** · 02/06/06 11:32

>>472
＞でも同じ理由で、、paintで描画以外の処理をやるのは、あんまりオススメできないと思う。

オススメしてるように読める？？？
私としては、このスレでもその種のコーディング（かならず呼ばれる事を前提にした）は止めたほうがいいと何度か注意してるんですけど。名無しだから識別出来ないけど。

**名前は開発中のものです。** · 02/06/06 11:47

372って社会人なのか。てっきり学生だと思ってた。実社会には適応出来てるんだろうか。会社でもああいう調子だとしたら、同僚はストレス溜まってるだろうと思う。

**エアリエル** · 02/06/06 13:33

まるでちょっと前までの私みたい…(爆

**haruka** · 02/06/06 23:00

>>473
そういうわけじゃなくて、372がそういうコーディングしててヤバいよってのを
指摘したかっただけ。誤解するよーな書き方してごめん。

**エアリエル** · 02/06/08 12:58

ちょっと！ヤバイだとかウソツキとかいう表現
どうしてそういうことが言えるんですか？
とか言ってた人がいたな～～。。。

**名前は開発中のものです。** · 02/06/08 19:02

誰か、彼が何を言おうとしてるか解る人いますか

**名前は開発中のものです。** · 02/06/08 21:32

>>478
Exciteで英訳→和訳してみますた。

─
ちょうどしばらく――!それは、それがYABAI--USOTSUKI--である場合、言います――[表現]はどのように行なわれ、そのようなもの、言うことができる――それはそうです――?また言った人--それはそうです(棚)。。

**372** · 02/06/09 01:06

まじめに議論に参加していただいた皆さまには申し訳無いが、
俺の言動で煽りが寄ってくるようなので、名無しに戻ります。
類は友を呼ぶって事ですかね...
・processEvent()内部は出来るだけ短く
・paint()内部には描画に関係しないプログラムを書かない
を基本にThread使ったプログラムをいろいろ書いてみて、一から勉強しなおします。

**エアリエル** · 02/06/09 02:50

>>478
もしかしなくても私の言ってる事？古いネタだが、ムネオ答弁だよ。
いや～ムネオハウスの聴きすぎでヤバイというキーワードを見かけると
頭の中でそのセリフが渦巻く。誰か止めて

**名前は開発中のものです。** · 02/06/09 08:59

>>480
真面目にねえ・・・・・あなたの様な態度の人間に「まじめに議論」してると思わせ、何度もレスを返し続けるのって、かなり苦痛なんですよ。
放置しておくのも苦痛だったから相手してたけど、もう勘弁してほしい。次はもう「参加」しませんから、私は。
あなたには「煽り」と感じられる様なレスなら付けるかもしれないけど。
相手に真面目に接して欲しいななら、自分の態度を省みた方が良いよ。

ところで、メーカーから何か返答はあった？
あの「仕様」が望ましくない＆明文化されていないのは事実だろうし。
回避手段はあるにしても。

**名前は開発中のものです。** · 02/06/10 23:05

//何かボタンを押してスクロールが始まるとN504iだと「おれもＮ５０４ｉのバグを見つけた」までしか表示されません
//ほかの機種ではどうですか?
import com.nttdocomo.ui.*;
import com.nttdocomo.io.*;
public class appli extends IApplication{
private canvas c;
public void start(){
c = new canvas();
Display.setCurrent(c);
}
}
class canvas extends Canvas{
public ShortTimer timer;
public void processEvent(int type, int param){
if (type == Display.KEY_PRESSED_EVENT){
if (timer == null){
timer = ShortTimer.getShortTimer(this, 0, 100, true);
timer.start();
}
}
if (type == Display.TIMER_EXPIRED_EVENT) repaint();
}
private int x = 0;
public synchronized void paint(Graphics g){
g.lock();
g.clearRect(0, 0, Display.getWidth(), Display.getHeight());
g.drawString("おれもＮ５０４ｉのバグを見つけたよ。", x--, 15);
g.unlock(true);
}
}

**名前は開発中のものです。** · 02/06/10 23:31

ちなみにフォントサイズ変えるとどうなるの？

（しっかし、ゲーム以前の話しばっかだね）

**エアリエル** · 02/06/11 10:07

>>484
504が出たばっかりだから仕方ないよ。
フォントサイズは12がデフォだけどそれ以外は機種依存のはず。

**名前は開発中のものです。** · 02/06/11 12:03

あんたに仕方ないって言われてもなぁ

**エアリエル** · 02/06/11 13:20

そんなナイスツッコミしなくても…

**エアリエル** · 02/06/12 10:52

http://appget.com/pc/view_2347.htm
これか…。

**エアリエル** · 02/06/14 01:26

やっぱり下げると人が来なくなるねぇ～～

**名前は開発中のものです。** · 02/06/14 12:02

あんたとかかわりたくないんだよ

**エアリエル** · 02/06/14 18:30

>>490
はいはい…、馬鹿の一つ覚えか何かよくわからんがその手のレスはもう飽きた。

**名前は開発中のものです。** · 02/06/14 18:47

なるほど、このへんで限界なのね
ネタ無いならageんな

**エアリエル** · 02/06/14 19:42

>>492
たまに上げとかないと消えちゃうけど…いいの？（過去最短３日で消えた事がある）
まっ消えたら消えたで新しくスレ作ればいいという話もあるけど…。
下げるとスレの存在に気がつく人が減る。たまにはイイでしょ？

**名前は開発中のものです。** · 02/06/14 20:52

491でageた事の言いわけにはなってないよね
落ちてもいいんじゃない？なんせネタが無いんだから
「iモード端末バグ・不具合報告・対策スレ」でも別途立てた方がいいんでないの？板違いかもしれんけど

**エアリエル** · 02/06/14 22:01

>>494
？？別に、なんで上げ下げに許可やら言い訳やらせにゃいかんのだ？

**名前は開発中のものです。** · 02/06/14 22:40

開き直ったね
勉強になるよ

**エアリエル** · 02/06/14 23:08

>>496
>開き直ったね
なんでやねん～

さて、、つまらん話題。
504i全社出揃ったけど結局どれが一番普及するかな？
どこか統計を取ってるようなサイトありませんか～？

**名前は開発中のものです。** · 02/06/14 23:12

放置すれ。

**エアリエル** · 02/06/15 00:05

なんか消したがってる人が一人いるな～。
何かヤバイ事でも書いてしまったん？

**496** · 02/06/15 00:13

あんた以外、１人しか書き込んで無いと思ってるでしょ
ていうか、俺以外はあんたの自演、って可能性もあるか
ところで、落ちても消えはしないでしょ

**エアリエル** · 02/06/15 08:28

>>496
>あんた以外、１人しか書き込んで無いと思ってるでしょ
それは貴方でしょ？
私、372、その他おーぜー、が成立してたわけだから
私と他１名と考えるアホはいないね。
もっとも、それら全てが自作自演なら別だが…。
そうそう、人のやる事にイチイチいちゃもんつけてるヒマがあるなら
ウチのアプリ買ってヒマつぶしに遊んでてくれ(爆

504i
F：前よりは１０倍速いらしいが特に突出すべき点は無い…？
D:３Ｄエンジンがついたが、１社のみなので専用アプリはそんなに出ない…？
SO:我が道を突き進むのはいいが、画面が狭すぎる…気がする？
N:我が道を突き進むのはいいが、画面が広すぎて嫌がらせのようにも思える…？
P:情報少なし…何か強烈な特長あるの…？
と、私はこんなようなイメージですが、実際の所はどうなんでしょ？

**haruka** · 02/06/15 12:24

>>501
宣伝は他のところでやってくださいな。

P504i買いましたよ。
ベンチマークどおり2Dグラフィクスがすごく速いとか、
背面液晶に表示できるってのは特長にならないの?

**名前は開発中のものです。** · 02/06/15 12:41

>>501
あー、そんなに遡るのね。上手い上手い。
で、あんたのアプリ弄ってるよりは
あんたの世渡り術を観察してる方が暇つぶしになるよ。

**エアリエル** · 02/06/15 14:05

>>502
もしかしてFより速いとか？

**エアリエル** · 02/06/15 14:26

>>503
いや～ん♪えあ恥ずかしぃ～ん♪
と、これ以上荒らしてもしょうがない。元の路線に戻すとするか…。
（そこの荒らした本人が何をいってるかと思った人ダウソ♪(死語))

iアプリの稼動する携帯に占める504の割合は現在どのくらいなもんなんでしょ？
まだ503アプリ作ってた方がお客様にとってはいいのかな？

**名前は開発中のものです。** · 02/06/15 15:19

確か504はPが最速でNがワーストだった記憶が・・・・・
違ったらｽﾏｿ。

503から504へ完全移行には多少期間が要るだろうから504じゃないと実現不可な
アプリで無い限りは503ベースで良いかと思うと言ってみるﾃｽﾄ。

**名前は開発中のものです。** · 02/06/15 16:14

504iシリーズのJavaベンチマーク、公開されているサイトをご存じでしたら是非教えてください。
各機種がどこのプロセッサを採用しているかなんて情報は、聞こえてきてますか？
（そんな事解っても、って意見もあるでしょうけど。基本的に興味本位ですが、業界の動向・メーカーの力関係の変化を知る材料になるとも思います。）