08/03/12 19:12:37
>>937
確かそれ不可能。
microSDにぶちこんでも認識しない。
バックアップ取るときに別形式に勝手に変換される。その形式しか認識しない。
945:デフォルトの名無しさん
08/03/12 22:56:50
SアプリでImageの拡大縮小しようと思って
GraphicsUtil.drawRegion() を使おうと思ったんだが、
透明色が反映されないのは仕様？
946:デフォルトの名無しさん
08/03/13 02:33:07
>>945
MEXAエミュのバグ
947:デフォルトの名無しさん
08/03/13 21:11:40
>>937
jadとマニュフェストのチェックはいつされるの？
948:デフォルトの名無しさん
08/03/13 23:41:25
オープンアプリの糞仕様変わらんかなー
949:デフォルトの名無しさん
08/03/14 10:58:39
>>948
まったくだ
950:デフォルトの名無しさん
08/03/14 11:05:13
BREWがあるからjavaはおまけ程度じゃね
951:デフォルトの名無しさん
08/03/14 11:25:15
KVMのバージョン1.１搭載端末ってもう出てるんすか？
952:デフォルトの名無しさん
08/03/14 21:40:41
>>937
>>944
どっちの情報が正しいんだろ？
本当にﾏｲｸﾛSDからインスコできるならW56Tに買い換えたい
AUショップの店員じゃその辺知らないだろな・・・
953:デフォルトの名無しさん
08/03/15 05:10:28
>>952
KCP+端末なら、OAPはSDからMIDletをインストール出来るよ。
いくつか制限事項があるけど、取り敢えずファイル名は短めに。
これ以上は言えん。
>>951
今の端末は、KVMってか、CLDCの1.1ですよ。
954:デフォルトの名無しさん
08/03/15 06:09:15
> >>951
> 今の端末は、KVMってか、CLDCの1.1ですよ。
そういう意味じゃないと思うぞ。確かに>>951の言い方も良くないが。
この春モデルから搭載され始めたOAPがver1.1で、ワイド画面が使えたりする。
端末はもう発売されてるよ。
955:デフォルトの名無しさん
08/03/15 07:29:20
W61Hの電子ペーパーってBREWからでも操作できないのかな。
模様が出るだけだったら無駄すぎるぜ。
カレンダーとか表示できれば便利だと思うんだけどなあ。
956:デフォルトの名無しさん
08/03/15 16:38:32
>>953
情報サンクス！
買い換えて試してみる
957:デフォルトの名無しさん
08/03/16 12:37:49
>>955
いや、模様が出るだけで制御できない。
W61Hのアレは最初から刻まれたパターン表示しかできない（昔のゲームウォッチの液晶みたいなもん）
つまり文字表示そのものが無理だ。
958:デフォルトの名無しさん
08/03/16 12:54:42
まぁ、自由に設定できたら著作権と面倒そうだからな。
959:デフォルトの名無しさん
08/03/16 14:50:53
W54SAで試してみた。できた。まあ953のいう通り。
960:デフォルトの名無しさん
08/03/16 21:55:14
>>958
今のところは著作権云々より単純にコストの問題だろう。
auは端末製造コストを相当削ってるみたいだから。
高性能化する携帯だが、背面液晶は昔から比べると随分寂しい情勢だな・・・。
961:デフォルトの名無しさん
08/03/18 21:36:23
どうしてもわからないので質問させてください
J2SE 1.4.2_17
Eclipse 3.3.2
MEXA 1.2 エミュレータ
Eclipseプラグイン for MEXA
J2ME Wireless Toolkit 2.2(patch済み)
EclipseME 1.7.8
（この２つは不要？？）
上記のものをインストールして、MEXAエミュレータで動作するところまで確認したのですが
難読・最適化のためにProGuard 4.2をインストール、proguardgui.jarを実行し、
・Input/Output jarを設定
・Java\j2re1.4.2_17\lib\rt.jarを削除、SOFTBANK_MEXA_EMULATOR12\lib\stubclasses.zipを追加
・LibraryのみKeep
・Use mixed-case class namesのチェックを外す
・Optimization passesを9に
この設定で生成したところ、たしかにサイズは減っているのですがMEXAのコンソールにVerifyErrorが出ていて実行できないのです
それとEclipseでProGuardを実行しようともしたのですが、MEの設定が必要な事がわかり、
J2MEのDevice ManagementでWTK22ディレクトリからImportし終わってOKボタンを押すと
「An error has occurred. See error log for more details.」と出て、
.metadata\.logを見ると、!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface".とあって
これは何なんだWTKかEclipseMEのバージョンがおかしいのでしょうか ･;(`ε()ﾞ
何か知っている方がいましたら情報ください
よろしくお願いします
962:デフォルトの名無しさん
08/03/19 01:38:09
最後の顔文字さえなければ教えたのに・・
963:デフォルトの名無しさん
08/03/19 09:15:29
>>962
困ってる様だし、知ってるなら教えてあげてはどうだろう
おれは知らないけど･;(`ε()ﾞ
964:デフォルトの名無しさん
08/03/19 10:18:03
俺はテキストエディタ派･;(`ε()ﾞ
965:デフォルトの名無しさん
08/03/19 10:51:46
>>961
Proguardを実行してできたjarを解凍して
WTKのpreverifyかけてあげなきゃダメだよ
EclipseからProguard使うのは、バッチファイルを
プロジェクトのビルダーに登録して、コンパイル後に
動くようにしてるけど、みんなはどうやってるんだろう？
･;(`ε()ﾞ
966:デフォルトの名無しさん
08/03/19 12:57:50
Ant
967:デフォルトの名無しさん
08/03/19 18:43:26
>>962
そんなこと言わずに教えてください・・
>>965
WTKのpreverifyというのがよくわかりませんがそれでMEを使わずに単独でProguardできるのですか
EclipseからProguard使うバッチファイルというのを調べてみます
968:デフォルトの名無しさん
08/03/19 22:29:10
Proguard使うって事は最終的な段階だし、WTKでビルドした方が安心感ない？
つー俺もテキストエディタ派･;(`ε()ﾞ
969:デフォルトの名無しさん
08/03/19 23:30:36
もう次スレのスレタイにこれ入れちゃいなよ→･;(`ε()ﾞ
970:デフォルトの名無しさん
08/03/19 23:54:50
MEXAエミュレータで10～20FPSで動くプログラムなら実機でもこれぐらいの速度は出るんでしょうか？
971:デフォルトの名無しさん
08/03/20 00:03:59
実機でためせばいいじゃん
972:デフォルトの名無しさん
08/03/20 00:10:43
PCのクロックと端末機種、それに処理内容によるとしか。
フレームレート気にするってことはグラフィックの負荷が高いアプリだろうから
実機のほうが圧倒的に速いような気はする。
973:デフォルトの名無しさん
08/03/20 01:05:17
>>972
ありがとうございます。
グラフィックに関しては、drawStringを複数回呼んで太文字を表現するプログラムを７、８回行うだけでも速度が低下することだけが気になります。drawImageとsetClipを使った部分描画でもかなりの回数描画できるのですが…。
プログラムはタスクシステムで、リストへの追加や削除で時間を要する場合があるので、だいたいこれぐらいで動いてくれればいいなと思ってます。この場合、問題はヒープの方ですかね？
974:デフォルトの名無しさん
08/03/20 01:21:29
当然だけどエミュより実機の方が思い通りに動いてくれる場合が多いよね･;(`ε()ﾞ
975:デフォルトの名無しさん
08/03/20 01:27:35
drawString()はdrawImage()とは比較にならないほど遅いメソッド。
実機でも非常に遅い。
976:デフォルトの名無しさん
08/03/20 01:34:58
それは重たいわな。もちろんBOLD指定は試したんだろうけど。
アルファ使えるんなら文字列部分は別イメージに描画しといて
それを使いまわしたほうがいいと思う。
リスト処理に時間が掛かる場合はUIとは別スレッドで。
977:デフォルトの名無しさん
08/03/20 01:47:29
>>975
やはりそうですか。
>>976
参考にさせてもらいます。
978:デフォルトの名無しさん
08/03/20 02:07:49
drawStringってそんなに処理速度遅いかな
内部的にはわからんが数回程度じゃ目に見えて遅いなーという印象はない
979:デフォルトの名無しさん
08/03/20 04:46:34
ゲームのスコア表示とかに多用するけど
同じくそれほど遅いと感じたことは無い気がする
iアプリじゃ太文字描画はdrawString重ねが定番みたいだし
iアプリと比べるのも変か
980:デフォルトの名無しさん
08/03/20 05:00:32
不変の文字をいくつも常時描画するなら、文字を書いた画像を一枚描画するほうが早いのかね
まあやり方次第か
981:デフォルトの名無しさん
08/03/20 06:30:25
いや、iアプリでもdrawStringは重い･;(`ε()ﾞ
982:デフォルトの名無しさん
08/03/20 07:14:17
たとえば長い説明文をスクロールさせたり、動く背景に重なってるスコアなど
毎フレーム再描画する必要がある文字列の場合、
素の状態の描画と、太字や縁取りの装飾をした描画で比べてみると遅さの違いがわかるよ。
キーを押したら”おはよう”を1行描くという処理と
キーを押したら”おはよう”を10行描くという処理では、ほとんど差はないと思うが。