- 1 名前：デフォルトの名無しさん [2008/03/20(木) 21:43:54 ]
- J2ME CLDC+MIDPベースの携帯電話用Java(主にEZアプリ、Vアプリ）に関するスレッドです。
質問でも議論でも何でもこい、と。質問は公式資料をよく読んでからにしましょう。
前スレ：
CLDC+MIDP+携帯電話用Javaスレッド part 7
pc11.2ch.net/test/read.cgi/tech/1180010672/
過去スレ
携帯JAVAのスレッド
pc2.2ch.net/test/read.cgi/tech/1011977260/(DAT落ち)
CLDC+MIDP+携帯電話用Javaスレッド part 2
pc5.2ch.net/test/read.cgi/tech/1070858996/
CLDC+MIDP+携帯電話用Javaスレッド part 3
pc5.2ch.net/test/read.cgi/tech/1091798483/
CLDC+MIDP+携帯電話用Javaスレッド part 4
pc8.2ch.net/test/read.cgi/tech/1108781476/
CLDC+MIDP+携帯電話用Javaスレッド part 5
pc8.2ch.net/test/read.cgi/tech/1132493827/
CLDC+MIDP+携帯電話用Javaスレッド part 6
pc11.2ch.net/test/read.cgi/tech/1155174514/
--
Java一般に関しては：
【初心者】Java質問･相談スレッド113【大歓迎】
pc11.2ch.net/test/read.cgi/tech/1204363011/
NTT DoCoMoのiモード携帯電話用Java(iアプリ)については：
iモード携帯電話用Java(iアプリ) Part16
pc11.2ch.net/test/read.cgi/tech/1198816379/
>>2-5あたりにリンク集･;(`ε()ﾞ
- 313 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 14:35:48 ]
- >309
1フレーム描画に何千回も計算するような箇所は固定小数点に置き換えたほうがいい。
ベクトルの正規化を多用する場合もsqrtの逆数は自作すべき。
float精度のニュートンラプソン法の初期値を一発で求めるトリッキーな方法がある。
- 314 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 14:45:01 ]
- >>312
いえ、使ってないと思います。。。
なにせjavaを始めたばかりで無知なもので。。。
いろいろとググってみて、分からなかったらまた質問させていただきます。
即レスサンクスでした。
- 315 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 16:24:46 ]
- >>311
keyRepeaedの意味はわかってるかな？
押しっぱなしにされたとき、一定間隔で呼ばれるものだ。
2chに書き込む時、キーボードのキーを押しっぱなしにすると
「あ、、あああああああああ」
って感じになるだろ？
同じもんだ。
keyPressedで押されたというフラグを立て、keyReleased（Repeatedにあらず）でフラグを解除。
という処理だけつくり、実際にキャラを動かすのはゲームスレッドで行なう。
ゲームスレッドでは、時間で定期的に処理を進める
- 316 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 16:49:28 ]
- GameCancas#getKeyStates を使うのが楽だと思う
ゲームキーしか取得できないが。
Softbank専用で数字キーとかの状態を調べたかったらDeviceControl使えばいい。
- 317 名前：デフォルトの名無しさん mailto:sage [2008/06/15(日) 21:46:03 ]
- DeviceControlってソフトキーも取得できるけど、端末によって左右が違ったりするの？
- 318 名前：309 mailto:sage [2008/06/16(月) 01:05:48 ]
- >>313
やっぱ置き換えた方がいいよね
実機である程度の体感速度が得られれば良いんだけど
もう面倒くさいから実数型のままで移植してみる
- 319 名前：デフォルトの名無しさん mailto:sage [2008/06/16(月) 21:37:14 ]
- オープンアプリ対応機って今のところ速度差無さそうだしな
ソフバンも3Gになってからは、解像度差による描画レート以外そんな変わんないよな？
海外だとMIDP2.0/CLDC1.1でも凄いスペックのがある
画面128x96とかヒープが512kとか、そんなんに実数演算させんなw
- 320 名前：デフォルトの名無しさん mailto:sage [2008/06/16(月) 21:40:32 ]
- >>319
つまり何が言いたいんだ？
- 321 名前：デフォルトの名無しさん mailto:sage [2008/06/16(月) 23:01:01 ]
- 機種ごとに差がないんだから、とりあえず実数で組んでみて速度確かめたらいんじゃね？
２行目以降は、「ところでよ」って話で確かに分からんな。すまん
- 322 名前：デフォルトの名無しさん mailto:sage [2008/06/17(火) 17:05:22 ]
- SoftBankでタッチパネル対応機種の一覧ってありますか？
独自APIじゃなくてpointerPressed()とかで座標を拾えるんでしょうか
- 323 名前：デフォルトの名無しさん mailto:sage [2008/06/17(火) 18:15:39 ]
- StorageConnectionを使用してネットワーク経由で
取得したjarファイルを端末に保存してアプリ内でリソースとして
展開するアプリを考えているのですが、jarファイル内のリソースの
暗号化などを施したほうが良いのでしょうか？
ちなみにjarは、んぱか氏のファイル結合ツールを使用してtxtや
jpgなどをjarでまとめようと思っております。
■ファイル結合ツール
ttp://www.saturn.dti.ne.jp/~npaka/kvm/midp2/InflateEx/index.html
- 324 名前：デフォルトの名無しさん mailto:sage [2008/06/17(火) 18:31:28 ]
- ヒープが足らないって落ちじゃないだろうな？
- 325 名前：デフォルトの名無しさん mailto:sage [2008/06/17(火) 19:12:53 ]
- すみませんが、エミュだと試せないので、
FEPControlについて教えて下さい。
初期表示される文字列を、
クリアキーで全て削除して、
さらにクリアキーを押した場合は、
getInputText()から何が戻ってくるのでしょうか？
String str = "テスト";
FEPControl fc = FEPControl.getDefaultFEPControl();
str = fc.getInputText(str,TextField.ANY,100,false);
- 326 名前：デフォルトの名無しさん mailto:sage [2008/06/17(火) 21:49:01 ]
- >>322
SoftBankでタッチパネル対応機種なんてなかったと思うけど・・・（Xシリーズ除く）。
Vodaの時代にも無かった気がする。
Jの時代にはパイオニアが出してた気がする。
うん。適当でごめん。
- 327 名前：311 mailto:sage [2008/06/17(火) 23:40:26 ]
- >>315
亀ですいません。。。
なるほど、そういう方法があるんですね！
キーが押されて離されてなかったら、押しっぱなしということですか
ありがとうございました！
- 328 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 00:34:48 ]
- エミュと実機ではキーの反応・動作が大分違う場合があるから気をつけるんだ
- 329 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 02:16:55 ]
- >>325
P5,P6で、null がかえってきた記憶がある。
はじめっから null が来ても "" が来てもおｋなように作っときゃ問題ないけどね。
- 330 名前：325 mailto:sage [2008/06/18(水) 13:01:34 ]
- >>329
レスありがとうございます。
""とnullの処理を入れて、3Gの実機を持っている人に試してもらったところ、
端末によって挙動が違うようでした。
・初期表示の文字が全部消えると、クリアキーは無効。文字入力処理は続行してます。
・クリアキーでFEPの入力画面が消え、getInputText()から戻って来ない。文字入力も出来ない。
２番目はハング状態のようです。getInputText()の引数で回避できるのでしょうか？orz
- 331 名前：325 mailto:sage [2008/06/18(水) 14:05:08 ]
- 自己レスです、解決しました。
getInputText()で、クリアキーを押下した際に、
RuntimeException が発生する事が分かりました。
これを、catchしてなかったのが原因のようです。
お騒がせしました。
- 332 名前：デフォルトの名無しさん mailto:sage [2008/06/18(水) 21:17:22 ]
- >325 解決してるようだけど、自分が知ってることを書いてみる。
P5のアプリを作ってた頃の調査結果。
FEP起動後、編集操作中にユーザーが[取消]を押すと
「編集内容を取り消すか？ YES/NO」のダイアログが出る。
そこでYES（編集取消）を押すとFEPは例外エラーを発生して終了する。
クリアキー押下でも何でも、とにかく編集を中断したら例外エラーが出る。
従ってFEP起動処理はtry-catchでくくるようにする。
ついでに、編集確定でFEP終了したのか、キャンセル操作で終了したのか、
フラグを立てておくとその後の処理で役に立つかも。
- 333 名前：325 mailto:sage [2008/06/19(木) 18:39:37 ]
- >>332
javadocの getInputText()には、
IllegalArgumentException の記述しかなくて、
RuntimeException が発生していたとは、なかなか気が付きませんでした。
検索しても情報が少なく orz
＞とにかく編集を中断したら例外エラーが出る。
＞フラグを立てておくとその後の処理で役に立つかも。
との事なので、FEP起動処理はtry-catchでくくり、
キャンセルされたら、元の文字列に戻すようにしました。
どうもありがとうございました。
- 334 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 19:48:57 ]
- >>323
スクラッチパッドに保存するだけなら取り出せるわけじゃないから暗号化はいらんが
スマートメディアのOtherDocumetあたりの外から見えるところに見られたくない物を置くなら
暗号化が必要だな。
ただ、Storageとio両方にアクセスできるように設計すると、素人アプリはコンテンツアグリゲータに
上げる時にハネられると思うぞ。
ttp://ac-admin.appget.com/open_kiyaku.htm#siyoukinnsi
- 335 名前：323 mailto:sage [2008/06/20(金) 02:55:19 ]
- >>334
やはりOtherDocumetだと暗号化は必須でしたか。
リソースの取得方法を再度検討してみます。
ご返答ありがとうございました。
- 336 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 09:29:38 ]
- Dojaの話で悪いが、某◯貝獸物語のリソースがSD-BindingでJARだったから、普通に解凍して取り出しが出来た。SD-Bindingはピュア バイナリぽいね。
必要があれば暗号化かければ良いけど、単純なジャミングならInputStreamとOutputStream辺りを継承して、上位と下位の4bitを入れ換えて取り扱うStreamクラスを作るのが楽なんじゃないかな。
- 337 名前：デフォルトの名無しさん mailto:sage [2008/06/22(日) 00:13:25 ]
- Dojaなら専用スレあるだろ....
- 338 名前：デフォルトの名無しさん mailto:sage [2008/06/22(日) 00:45:05 ]
- >>337
上の話は余談で下の話が実際言いたかったことじゃないの？
- 339 名前：デフォルトの名無しさん mailto:sage [2008/06/22(日) 01:23:47 ]
- >>336
EncryptionAttributeを立ててないだけ。
単に忘れたか、それとも速度が厳しかったかのどちらか。
>>335
んぱかに暗号化のサンプルが載ってるな。
ttp://www.saturn.dti.ne.jp/~npaka/kvm/midp2/CryptoEx/index.html
- 340 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 00:50:26 ]
- Sアプリのレコードストアが3Mにアップしたね
- 341 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 00:55:50 ]
- それに引き換え32kbの
- 342 名前：デフォルトの名無しさん mailto:sage [2008/06/24(火) 23:27:45 ]
- ソフトバンクの動向とか見てると
自由度の極端に低いauの糞仕様も
新OSの普及と共に緩和されそうだね
- 343 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 00:28:23 ]
- OS?
- 344 名前：デフォルトの名無しさん mailto:sage [2008/06/25(水) 01:50:46 ]
- >>342
詳しく
- 345 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 00:24:04 ]
- 国内でも流行り出したWindowsMobileとか
新OSのAndroidの事を指してるんでしょ多分
どっちもjava動くし実現度・自由度だって高いはず
- 346 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 01:10:15 ]
- Androidでjavaが動くって表現はなんか違う希ガス。
Androidは新らしく出現したjava環境でJavaMEのリソースは
殆ど流用できないんじゃまいか（外部apiに殆ど依存していな
い抽象ライブラリとかを除いて）
ttp://blogs.sun.com/hinkmond/entry/later_than_the_last_attendee
↑このブログ主JavaMEの伝道師らしいがAndroidには攻撃的だ。
- 347 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 17:58:40 ]
- AndroidはOSじゃないし
、WMはスマートフォンが主だから活躍の場が違うと思う
普通に住み分けがされるだけじゃないかな
- 348 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 18:11:28 ]
- Androidは開発環境がJava SE5.0+αだからME関係ないな。
スマートフォンにはCLDC+MIDPじゃなくてCDC+PP積んでほしい。できればAGUIも欲しいが。
- 349 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 22:56:38 ]
- Java SEのライブラリは使えないよ
開発環境やコンパイラを流用して最後に実行コードをDalvik用に変換するだけ
ずるいと言えばずるい
- 350 名前：デフォルトの名無しさん mailto:sage [2008/06/26(木) 23:10:51 ]
- 質問があるんですが…
WTKのfillTriangle()はJavaSEのawtと同じ仕様なんですが
MEXAエミュレータでは右下方向に1pixel拡大されるようです
手持ちの実機でも同様でした
これはSoftBank共通仕様と考えていいんでしょうか？
- 351 名前：350 mailto:sage [2008/06/27(金) 02:22:50 ]
- すみません。自己解決しました
WTKのエミュレータでは隣接する三角形のエッジを共有せず、MEXAは共有する仕様のようで
どちらもMIDPの実装としては有りのようです
両方に対応するため、起動時にテスト描画してエッジの色を調べることにしました
- 352 名前：デフォルトの名無しさん mailto:sage [2008/06/27(金) 05:15:26 ]
- アプリゲットが2G対応を2007年10月末に終了させていたことに、
今更ながら気づいたぜ。
これって、
もはや一般クリエータは2G端末(P4,P5,P6)向け配信を
(既存アプリ含め)一切できないってことだよね？
- 353 名前：デフォルトの名無しさん mailto:sage [2008/06/27(金) 12:33:13 ]
- >>352
他は？
developers.softbankmobile.co.jp/dp/tech_svc/java/appli.php
- 354 名前：352 mailto:sage [2008/06/28(土) 02:38:17 ]
- アプリLiveもとっくに終わってるものだと思ってたけど、
一応ゲームチャンネルとしてまだ残ってたのね、、thx
- 355 名前：デフォルトの名無しさん mailto:sage [2008/06/28(土) 18:59:46 ]
- 最近DocomoのAPIを分けるやり方が一番賢い気がしてきた
無駄に制限だらけのauとSoftbankなんて潰れてしまえ･;(`ε()ﾞ
- 356 名前：デフォルトの名無しさん mailto:sage [2008/06/28(土) 20:50:14 ]
- 海外MIDP端末とwillcomは自由だぞ
- 357 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 20:51:44 ]
- S!アプリを作っているのですが、703SHにてOutOfErrorが出てしまいます。
OutOfErrorなのでリソースを削るのが定石だと思うのですが、
実機でRuntime#freeMemory()とRuntime#totalMemory()を使ってメモリ状況をモニタリングしていると、
突然freeMemory()が増える(使用メモリが減る)タイミングがあります。
起動時に大きくリソースを読み込み、4MBのヒープの3.7MB前後をしばらく推移し、
その状態でリソースを読み替えの場面を行き来するとOutOfErrorが起きやすいのですが、
freeMemory()が増えたあとは2Mあたりを推移し、上記場面でのOutOfErrorは今現在発生していません。
freeMemory()が増えるタイミングまちまちで、大きくリソースを読み込んだ後1・2分程放置することで基本的になります。
この時に起きているであろう解放を明示的に起こす方法はありますでしょうか？
読み込み時は1ファイル毎にSystem.gc()を読んでおりますが、効果はありませんでした。
MEXA Emulator及び905SHでは、大きくリソースを読み込んだ後から既に2Mあたりを推移すると言う状況です。
何かご存知でありましたらご教授をお願い致します。
- 358 名前：357 mailto:sage [2008/06/30(月) 21:01:04 ]
- MicroEdition-Profile: MIDP-2.0
MicroEdition-Configuration: CLDC-1.1
MIDxlet-API: JSCL-1.2.2
を対象に開発を行っています。
他不足情報があるかもしれませんが、恐れ入りますがよろしくお願い致します。
- 359 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 21:45:58 ]
- GCの実装の問題だからどうしようもないと思うんだけど。
リソースのサイズ減らすしかないんじゃない？
- 360 名前：デフォルトの名無しさん mailto:sage [2008/06/30(月) 22:39:31 ]
- んだね
あとは自分の実装を見直してみること
gc呼んでも全く効果なしなら別に原因があるとも考えられる
- 361 名前：デフォルトの名無しさん mailto:sage [2008/07/01(火) 19:58:59 ]
- 1ファイル毎など生ぬるい。毎フレームだ。
- 362 名前：デフォルトの名無しさん mailto:sage [2008/07/01(火) 23:29:12 ]
- そんなことしてもだいたいキューに溜められるだけなんだが
- 363 名前：デフォルトの名無しさん mailto:sage [2008/07/02(水) 01:16:07 ]
- 何作ってるか知らんが一度に数メガ単位のリソース読むなんて非常識
- 364 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 18:08:24 ]
- 待ち受けとかノベル系のアプリ作っててふと思ったのですが、長時間キー操作がないとアプリの処理速度って遅くなりません？
で、関係ないキーとか押してみるとまた速度が元に戻る…の繰り返し。
これを解決するには一定時間ごとにアプリ側に制御を渡すような処理が必要なんでしょうか？
- 365 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 18:52:38 ]
- 電池馬鹿食いの待ち受けになりそうだなｗ
- 366 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 18:58:05 ]
- ノベルゲームってキー待ちじゃないの
入力がない間に処理が遅くなるってわかるの？
- 367 名前：デフォルトの名無しさん mailto:sage [2008/07/04(金) 20:06:12 ]
- >>366
キャラがアニメーションしてるとかじゃねーの？
- 368 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 03:09:14 ]
- 携帯電話の本質から考えると当然の仕様じゃないかと思う
参考までに現行の一般的な携帯の初期設定だと、
数十秒操作がないとバックライトも消えて低電力モードに移る
しかし勝手アプリでその辺りの制御をできるとは考えにくい
素人に電池馬鹿食いアプリ作られて困るのは各キャリアだからね
- 369 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 03:52:47 ]
- ？
バックライトの制御くらい普通にできるんじゃないの？
- 370 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 14:21:04 ]
- 実装はどうあれ、10ms以上ならsleep()入れてくれさえすりゃいいんだが
なんでループぶん回すかな、みんな…
- 371 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 15:12:59 ]
- >>369
バックライトやバイブの制御などは簡単に出来るのですが、それでアプリ側に処理を移したつもりでも、描画速度がガタ落ちしてるんですよね。
ループで延々と描画を続けるアプリはみんなこんな感じなのかな…
- 372 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 15:36:58 ]
- >>371
繰り返す処理の内容にもよるから一概には言えない
- 373 名前：デフォルトの名無しさん mailto:sage [2008/07/05(土) 22:43:00 ]
- 可変FPSにして余った分sleepしてる
- 374 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 01:24:40 ]
- >>369
少し言い方悪かったね
分かりやすく言うとCPUの省電力動作の移行に関する操作までは
できないということ
でも省電力移行する程の期間で出力が必要な実装なんて
個人的にはあまり聞いたことが無い
- 375 名前：371 mailto:sage [2008/07/06(日) 14:30:40 ]
- >>372
シューティングゲームを作っているんですが、whileでぶん回しながら
自機、敵機の描画し、Thread.sleep(50)でウェイトをかけています。
通常ゲーム中のキー操作がある場合は速度が遅くなる事はないのですが、
ステージ間のアニメーション(敵機が決められた軌道上をスクロールする)
が長い箇所の場合20秒程あるんです。
要するにユーザがキー操作をせず描画処理だけが続く時間が最大20秒ほど
あるという事です。で、この時に徐々に速度が遅くなっていき、最後らへんには
見るも無残な速度になってしまいます。
途中、関係のないキーを押下してみたりしてアプリ側に処理が移ると速度が
元に戻ります。
- 376 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 16:21:38 ]
- >>375
上の人も言ってるけど
ユーザビリティ的に考慮する必要は無いと思うよ
携帯のゲームやったことあるなら分かるでそ？
- 377 名前：371 mailto:sage [2008/07/06(日) 18:09:29 ]
- >>376
なるほど…。
という事は勝手アプリを作る上で、数十秒程度のアニメーションは難しいという事ですよね。
色々ありがとうございました！
- 378 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 18:35:42 ]
- 軽いモーションならまだしも、数十秒もあるアニメーションならムービーにして再生したほうが早いんじゃねえの
- 379 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 21:58:33 ]
- >>376
携帯使うときって基本バックライトが消えそうになったら
適当なキーを押すという使い方が一般的だからな
もちろんマニアックな設定をしてる人以外で
- 380 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 22:41:13 ]
- しかしそう考えると、ゲーム開始前で決定キーの
入力待ちの状態とかってあるじゃん。
アクションゲームとかそこでデモっぽいのが
流れてたりするけど、あれも放置してると速度が
遅くなるって事なのかな？
あんま携帯ゲームしないからよく分からないや。
- 381 名前：デフォルトの名無しさん mailto:sage [2008/07/06(日) 23:28:39 ]
- 携帯ゲーの場合デモ自体流さないな。
容量の関係とかで。
せいぜいタイトルで選択アイコンが点滅かアニメするだけ。
- 382 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 01:48:57 ]
- 色々試してみたらdoja端末だとバックライトが消えても処理は重くならず
OAP端末だと暫く待つと重くなる。適当なﾌﾘｰｱﾌﾟﾘをDLしてみても同じく。
特にRPGで常に手足がてくてくなってるｱﾌﾟﾘを見てたら明らかに手足の
速度が遅くなってﾜﾛﾀ(笑)
まぁ機種による可能性大だが…。
- 383 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 11:06:56 ]
- >>371
ガベージコレクションを自動的な発生に任せていると重くなる事があるけど、それかな？
適当な所でSystem.gc()してみ？
- 384 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 11:09:12 ]
- BREWは動作遅くなるのが仕様
Docomo、Softbankならおかしい
- 385 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 11:46:57 ]
- AOPはJBlend on BREWだからなぁ
- 386 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 13:18:42 ]
- 本当にBREWはビチ糞だな。
- 387 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 13:20:56 ]
- 個人的にはゲリじゃなくて便秘の方かな。
- 388 名前：デフォルトの名無しさん mailto:sage [2008/07/07(月) 19:16:54 ]
- System.gc();は毎フレームやれってばっちゃが言ってた。
東芝の場合はしらんって怒られました
- 389 名前：デフォルトの名無しさん mailto:sage [2008/07/08(火) 21:55:08 ]
- softbankで famiJSCL 使ってる人に質問
rom の内部読み込みはうまくいくけど
外部読み込みで「romの読み込みに失敗しました」
となります
対処法をご存知の方お願いします
- 390 名前：389 mailto:sage [2008/07/08(火) 23:14:52 ]
- ちなみにMEXA_EMULATORのコンソールには
起動エラー: java.lang.SecurityException: com.j_phone.io.Connector.StorageConnection.read was denied
と表示されます
- 391 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 00:17:44 ]
- famiJSCLって何？
Trustedでインストールしてないとか？
- 392 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 00:43:52 ]
- ググったけどスレ違いすぎる
- 393 名前：389 mailto:sage [2008/07/09(水) 01:18:36 ]
- やはりここもスレ違いでしたか
失礼いたしました
ちなみに Trusted でインストールしたら無事起動しましたが
実機ではやはりエラーが出ます
- 394 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 15:45:08 ]
- >famiJSCL
www.geocities.jp/v904shmania/#famiJSCL
--- 引用
ファミコン＆ディスクシステムえみゅ
- 395 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 18:45:20 ]
- スレ違いで悪いけど、famiJSCLやゲームギアのって音有りになってるが
音源はどうやってエミュレートしてるのか気になる
spf？mmf？MIDI？
- 396 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 19:25:10 ]
- デコンパイルしてソース読めば？
- 397 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 20:01:36 ]
- >>396
そのつもりだったけどfamiJSCLのダウンロード先が見つからないんだ・・
- 398 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 21:22:37 ]
- >>397
smaf-phrase
"famiJSCL"でググったら最初に見付かるサイトの最後の方にzipあるよ。
- 399 名前：357 mailto:sage [2008/07/09(水) 22:44:49 ]
- 今さらですが、取り合えずはなんとかは出来ましたのでご報告致します。
エミュや実機の動作の差分を見ていたところ、
703SHではゲーム用インナーのコンストラクタに入るところで急激に増えていました。
このクラスのメンバには一番多く変数が定義されており、
コピーコンストラクタで変数を大量に生成した後には703SHでは増えている感じでした
(エミュ・905SH・813SHでは約900KBに対し703SHでは約2MB)。
コンストラクタに入ったときにGCを呼んでも解放されなかったため、
new byte[Runtime.getRuntime().freeMemory()]
を2回呼ぶことで空きメモリが必要である事を主張し解放を促しました。
これにより前記の領域を解放させることが出来ました。
タイミングによってはOutOfMemoryErrorが出るので、安全策として、
ここの部分でのみErrorをcatchしています。
Errorの性質上、かなり気持ち悪い実装となりましたが、
現状ではこの方法で回避するとこが出来ました。
- 400 名前：357 mailto:sage [2008/07/09(水) 22:45:46 ]
- >>359
そのGCの実装の差異を何とか吸収出来る様なテクニックがあればと思いまして。。。
>>360
GCで解放されているものもあり、全く効果が無いわけではありませんでした。
ただ、もっと解放して欲しい領域には及んではくれませんでしたが。
>>361
1フレームに1ファイル読み込んでGCを呼んでおります。
>>363
リソース自体は300K程度で、
SH問題で動的なものもあり、
起動時に読み込むのは200K程です。
と言うわけで、怒鳴られてしまいそうな実装ですが、一応解決したました。
どうもありがとうございました。
- 401 名前：デフォルトの名無しさん mailto:sage [2008/07/09(水) 22:55:18 ]
- (´∀`) ｽﾊﾟｰﾝ!
⊂彡☆)´Д`)っ>>399
- 402 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 01:21:06 ]
- この流れでエミュエミュ言うから、うぜぇと思たら…
でもこれは駄目だろ
703shの実装以前に、何かが決定的に間違ってるはず
何がどれだけメモリを食ってるのかちゃんと調べたのか？
- 403 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 09:52:43 ]
- 循環参照でもして、メモリーリークしてるんじゃね？
- 404 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 10:39:35 ]
- いくらなんでも弱参照カウンタくらい実装してるだろVMが。
マーク&スイープだったりするぞ。
- 405 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 11:05:35 ]
- バグでガベコレがうまく働かない機種があったけど
それが703shだったかは忘れてしまった
- 406 名前：デフォルトの名無しさん mailto:sage [2008/07/10(木) 16:57:14 ]
- >>404
いまどきの、コンパクションすら行わない速度だけを求めた糞VMが、そんなことしてるかね？
アプリが終了するときはしっかりやってそうだが。
- 407 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 00:39:41 ]
- S!アプリのJSCL-1.1.x以降はメモリコンパクションをサポートしているらしいが？
- 408 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 01:01:31 ]
- >>357はキャンバススレッドにベターッと全てを実装してたりしてなｗｗｗ
- 409 名前：400 mailto:sage [2008/07/11(金) 01:12:44 ]
- >>402
自分のコードに絶対的な自信を持っているわけではありませんが、
ただ、元々Dojaからの移植でDoja版は問題なく動作をしており、
納品済みで公開されております。
Softbank版ではクライアントの方でチェックされている中で703SHのみ
OutOfMemoryErrorが出ると言う報告のものでありました。
なので、元のコード自体に決定的な間違いがあるとは思い難いと思っています。
最も、メモリ容量の推移についてを先方にチェックしてもらっているわけではないので、
報告が無いことが703SHと同様の動作をしてないことと等価では無いとも思いますが。
703SHは一旦の対応で返却してしまったため、次の機会に"何"が"どれだけ"
食っているかを調べたいと思います。
今回は大幅に増えるタイミングタイミングがメンバ変数の初期化子しか
無い状態だったので、また対応の時間もあまり無く、深く追うことができませんでした。
>>403
メンバ変数はint等の値型の多次元配列がほとんどで、
メンバに参照を保持するようなメンバは持っていません。
また、メンバ変数の配列はコンストラクタ等で生成した後は解放しないで、
新たに作ることなく使いまわしているので、リークしそうなものがほとんど無い状態です。
- 410 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 01:27:17 ]
- J2MEで巨大な多次元配列とな
- 411 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 11:51:06 ]
- いまどきのKVMならコンパクション実装してるぞ。
- 412 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 13:21:42 ]
- >>411
そうなの？
少なくともDoCoMoは昔は実装してたのに、901あたりから一切コンパクションしなくなった
速さ優先のもよう
- 413 名前：デフォルトの名無しさん mailto:sage [2008/07/11(金) 18:03:36 ]
- >>412
むしろP900、N900はコンパクション無いことが明記されているよ。
普通に組んでたら断片化を起こしているはずだし、
最近の物はほとんどコンパクションに対応してると思うよ
ttp://www.nttdocomo.co.jp/binary/pdf/service/imode/make/content/iappli/caution/n900is_iappli_notes_ver1.pdf
ttp://www.nttdocomo.co.jp/binary/pdf/service/imode/make/content/iappli/caution/p900iv_iappli_notes_ver1.pdf
|
 |
