ｉアプリでゲーム

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

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

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

>>572
>あのさぁ。何のネタも無いのに寒い書き込みでageるのって空しくない？

我慢しきれなかったんだね・・・よりはマシだと思うが？(笑

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

MoPeeいいね。
オープニング用アプリ制作には使える。
ゲームは作るのはダメだけど。

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

>>573
あんた、ageない方法を知らない人？

**573** · 02/08/10 02:03

>>575
はいはい…、あんたが一番ですよ。

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

典型的なガキのリアクションだね･･･

**573** · 02/08/10 10:16

>>574
スパイシー犬の方が良い、、、と、思ったけど、、高いね～
こりゃ確かにMoPeeもいいかも。

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

おいおまいら！MoPeeとスパイシー犬って何ですか？
当方バター犬なら知っています。

**573** · 02/08/13 21:22

検索すると出てくるぞな。
まっ「スパイシー犬」で出てくるかは不明だが。

**名前は開発中のものです。** · 02/08/16 12:29

P503iでは、左から２番目の黒鍵のドラム音(GM音源スタンダード1で、タン！という音が
ちょっとサイバー？になったような音)が範囲外の音として鳴らせないのですが、
504でもやっぱり改善されて無いですか？

こういうちょっとした事ってリファレンスにもどこにも載って無いから、
非所有者としては困るんですよね～～。

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

そういう情報を共有出来る定番サイトって、ないもんでしょうかね。
メーカーサイドのサポートの充実も望まれるところですが。
機種間の非互換、仕様のグレーな部分、を明らかにし、
コンテンツ開発上の困難を排除する将来の方向性を明確化する為の、
複数メーカーの共同出資する団体、みたいなものがあっても良さそうな。

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

携帯をそろそろ買い換えようかと思っているのですが、
MemoryImageSourceみたいな関数が用意されている機種って知ってますか？
auでもDocomoでもjphoneでもいいので、ピクセルいじる関数で
ファイアーエフェクトとか作って遊びたいのですが…

APIを観ると、docomoですと、SonyとNECの405シリーズに
PutPixselのAPIがあるのですが、これをさすがに画素数分行うというのは
処理的に見て重そうです…。

この機種でピクセルばりばり打てるぜ～等、情報お待ちしております。

**haruka** · 02/08/17 17:39

>>583
ファイヤーのエフェクトとかやるときに現状一番実用的なのはP504i／SO504iの
Graphics2#setRenderMode だと思う。
ただしP504iはこれが有効になるメソッドが限られていてキツいんだよね。

**583** · 02/08/18 12:39

405じゃなくて504すね、その他名称の統一が出来てなくてスマソ。
Graphics2#setRenderModeだと、srcとdstを加算、減算、乗算合成は
出来ると思うのですが、左右のピクセルを足し合わせたり、等は
出来るんでしょうか？（スポットライトとか、似非バンプなら作れそう）

マニュアル見ると、OP_REPL、OP_ADD、OP_SUBしか、operatorがないように
見うけられるのですが…

j-phoneの方がjavaが充実してると良く聞きますが、いじってる方、
そちらの方の状況も教えてくださると助かります。
ピクセルモーフとかして遊びたいんです（笑）
思いきり機種依存していいから俺にピクセル触らせろ～

**haruka** · 02/08/18 18:37

>>585
memoryImageSourceは504にはありません。
P504iのputPixelは結構速いです。
そしてP504iでputPixel使って1桁以上処理能力が足りないようなら、
memoryImageSourceがあっても、やっぱりダメでしょう。

現時点でやるなら、
1. putPixel使って作る。
2. 非圧縮GIFをスクラッチパッドに書き出して、
それをgetImageする。RGB332の256色でよければ(笑)
どっちが速いかはやってみないとわからないですが。

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

>>586
情報どうもありがとうごうざいます。DoCoMoに関してはそんな感じですか…
自分なりにJ-PHONEのjava機能を調べてみたのですが、
setPatternでいけそうです、その他にもMIDPに対応してるので、その中の
BitMapクラスを使うなど、こちらの方が色々方法がありそうです。

javaにだけ関して言えば、DoCoMoよりもJ-PHONEのjavaの方がAPI群が充実
しているような感じがします。機種はJ-51シリーズのどれかかな、かなり絞れてきました。

あとはベンチマークなんかがとってあるサイトかどこかあればいいのですが…
503iでなくて、J-PHONEのベンチマークをまとめてるサイトとかってありますか？

**haruka** · 02/08/19 19:39

>>587
…まあ、がんばってください。
私はJ-PhoneのAPIをいまいちっぽく感じてるのと、
ダウンロードの手順が煩雑なのでDoCoMoの方が好きなんだよね。

setPatternは8x8の配列にしておかないといけないし、
256色だし、いろいろ嫌なところあるんじゃないかなあ。

setPixelの速度を手元のP504iで計測したんですが、
・128x128のループ内で配列の中身をsetPixel
　　→ 600msくらい
・128x128のループ内で配列の中身をローカル変数に代入するだけ
　　→ 200msくらい
です。参考までに。

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

タイトー、ezplus向けギャルゲーサイト「ギャルズセレクション」
http://k-tai.impress.co.jp/cda/article/news_toppage/0,,10612,00.html

ギャルゲーだ
わーいわーい

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

P系についてるテトリスって、どこかでダウンロードできないの?
俺はNなんだけど…

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

なんで「製作技術板」なのにダウソ君が来てるの？

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

そらアンタ…制作者の宣伝に決まってまんがな。

**名前は開発中のものです。** · 02/08/23 11:13

J-スカイ向けJavaアプリ「鬼武者」に四話「危疑の石壁」
http://k-tai.impress.co.jp/cda/article/news_toppage/0,,10661,00.html

セガ、ソニックカフェにブロック崩しゲーム
http://k-tai.impress.co.jp/cda/article/news_toppage/0,,10658,00.html

宣伝わーい

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

宣伝は携帯・PHS板のスレでやれ。ユーザ多いし。

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

>>594
ここのユーザーが少ないと誰が決めたんだ？

**名前は開発中のものです。** · 02/08/24 10:33

遊び手はあっちのが遥かに多いに決まってるだろうが。ゲーハー板並みの厨板でもあるし。

●504専用アプリを語るスレ2●
http://cocoa.2ch.net/test/read.cgi/phs/1026275407/
ααα良きiアプリααα その２
http://cocoa.2ch.net/test/read.cgi/phs/1026400839/

このスレあたりの活況を見て来い。

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

へー、本当にiAppliで遊んでる人っているんだなぁ・・・・

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

>>595
地球の人口が10億であると誰が決めたのでしょう？
この板に人が少ないことは決定の必要さえない単なる事実だと思いますよ。

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

地球の人口が10億だって…ぷっ(w

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

ごめん。適当に書いた。

**名前は開発中のものです。** · 02/08/26 20:49

J-SKYでゲームを作っているのですが、
理由あってPNGファイルを２つのファイルに分割しなければならなくなりました。

ゲーム内で使う時に、再結合してPNGに戻して読みたいのですが、どうすればよいのでしょうか。
createImage(byte[])はPNGをサポートしてないように見えるのですが・・・

**名前は開発中のものです。** · 02/08/26 20:56

携帯だけで開発できたらいいのにな

**エアリエル** · 02/08/26 21:38

>>601
まずファイルをバイナリ分割。
そして、保存領域にデータの並びがきちんと連続するように書き込む。
後は普通に読込めば良い…はず。

**名前は開発中のものです。** · 02/08/26 22:00

やはり一旦レコードストアに書き出さないとダメですかね。
PNGファイル。ものによっては結合すると2K弱くらいあるのでメモリー内で処理したいのですが…。

createImage(byte[])が使えれば文句ないんですけどね…

**エアリエル** · 02/08/27 00:20

、、、保存領域に書き込んで、メモリ内に読込んでしまったら
保存領域を破棄！ではダメなの？

場合によっては2枚のまま、、という方法もなきにしもあらず。

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

iアプリ3Dの作成をしています。

先日学び始めたのですが疑問が２つあります。

・視点をいくら引いても、モデルが小さく表示されない

・クラスやメソッドを見る限り、複数のモデルをいっきに描画する方法がない？
　このままだと壁向こうのモデルが見えてしまいそうな…
　モデルごとに自分でソートする…！？

Direct3Dは昔結構やっていたのですが、視点を引いても小さくならないのが謎です。
表示される大きさがsetScreenScaleだけに依存しているような…

どなたか分かるかた、教えていただけないでしょうか

**名前は開発中のものです。** · 02/08/29 17:23

「iアプリ3D」？って、これの事ですか？
http://www.mitsubishielectric.co.jp/service/d-style/d_spec/504i_java/z3d/z3dguide_f.html
とかいう

**haruka** · 02/08/29 17:50

>>606
多分マスコットエンジンの方の3Dを使ってると思うんだけど、
マスコットエンジンは透視変換をやらないので、
当然カメラを引いてもオブジェクトは小さくならないです。

…そんなの3Dじゃねえよ。。笑

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

（;´Д｀）
やっぱり透視変換してなかったのね…。
どこにおいても、視線と平行な状態での描画しかされないからあやしんでましたけど…

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

怪しいも何も、ドキュメントに明記されてるじゃん…

**名前は開発中のものです。** · 02/09/01 20:45

＞＞５９６
ゲーハー板を馬鹿にするな！あの板のおかげで抜け毛が減ったぞ！

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

誰か雀GO tonightの牌の画像をきれいなものに変えた504バージョンを作ってください。

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

質問
NTTドコモから落としてきたツールでコンパイルまでは成功する。エラーなし。
で、実際起動させてみると↓の様な警告が出てできない。

java.lang.NullPointerException
Stack trace data not available

動作確認のとれたプログラムで試してるのでjavaの設定のせいだと思う。
何が足りないんですか？教えて下さい(´・ω・`)ｼｮﾎﾞｰﾝ
必要なら、現在インスト中のjava関係書きます

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

画像ファイルあたりがなくて、データをつくれてないのではあるまいか。
NullPointerException って、ポインタにアドレスが割り当てられてないわけで

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

３Ｄを多様したアプリってＤ専用でもないと厳しいですかね＞５０４

しかし、自分の機種＋１，２機種は対応させたいな・・

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

あげちゃえ！！！

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

「iαppli Development Kit」実行すると、黒いの出てすぐ終了しちゃうんですけど、原因わかるかた解決方法を教えてください。

**エアリエル** · 02/09/17 23:31

クラスパスが通ってないか間違ってる…かも。
もしくはJAVAのSDK(JSEとか言ったっけ？)のバージョンが古いか新しすぎる。
↓によると1.3.1推奨だそうな
http://www.nttdocomo.co.jp/p_s/imode/java/tool_504i.html

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

氏ね

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

↑なぜ？

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

エアリエルだからだろうと。

**名前は開発中のものです。** · 02/09/23 16:07

うちは1.4.0で動いてるにょ。

**名前は開発中のものです。** · 02/09/23 17:07

にょってゆーな。

**名前は開発中のものです。** · 02/09/23 21:53

にゅ？

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

エアリアルって豚みたいなオタクなんでしょ？略してリアルブタク

02/09/24 11:44

自分ではアドバイスも（しない｜できない）くせに
コテハンをたたくやつがおおいな

**エアリエル** · 02/09/24 21:55

>>625
ソウダ！ワタシノショウタイハチキュウシンリャクニキタノッペラセイジンダ(ワラヒ

>>626
せっかく名前を書く欄があるのに固定で書けないというのは悲しいもんですな。

**エアリエル** · 02/09/24 22:00

ところで、504is情報はまだかな…？
やっぱりアプリの部分は504iと変わらないんですかね？
いや～、、ちょっと期待してるんですけど。。。

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

オマエじゃどうせまともなもの作れないから安心しろよ

アドバイス通り、名前欄埋めてみたよ。

**617** · 02/09/25 15:29

>>618
できました。ありがとうございました。
遅レスですみません。

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

isとか全然知らなかったので検索した。
http://k-tai.impress.co.jp/cda/article/event/0,,10746,00.html
＞「504iSは年内、505iは来年春」というスケジュールであるとのこと。

それぞれでまた各社各様の仕様でしょうから、アプリ製作者は今まで以上に
多彩なハードウェアに向けたアプリのチューニングが楽しめますね…。

というか、iAppli実行環境の性能（速度、容量など）が十分に高くなってくれば、
そして、それらの機種が主力になれば（初期の機種を無視できるようになれば）、
リソース制限関連のチューニングに関しては、省ける様になるんでしょうけど。
機種間の個性差も小さくなってくるんでしょうね。

**エアリエル** · 02/09/25 18:23

>>629
そのたうり！まともなモノ作ってても面白くないので、
これからもゆっくりとのんびり大急ぎで早く
ちったぁ～マシなモン作っていきます。

>>631
年内…。そうですか…。情報ありがとうございます。
個人的には、iSとしての拡張機能は各社バラバラでいいから
少なくとも504iのオプションAPIは基本APIに格上げしてもらいたい。

**haruka** · 02/09/25 22:57

背面液晶のサイズがばらばら→背面のビットマップは機種ごとにデザイン
の予感。。笑

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

携帯JavaでGameBoyが動く!?
http://www.zdnet.co.jp/mobile/0209/26/n_game.html

＞　現在のところまだ動作速度が遅く、“アクションゲームが快適に楽しめる”
＞ほどではないが、携帯のJavaでGameBoyソフトが動作することを示した意義は
＞大きい。審査員からも驚愕の声が聞かれた。

02/09/28 19:13

>>634
サイズが20kとかって書いてあるよね
すごいよね

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

あげてみる

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

>>634
今ビジネスとして動いても版権とかの関係上辛いだろうけど
あと1,2年で化け物に成長する悪寒。
このスレの1/9ぐらいのサイズだから、おれらは9倍無駄なことをしてきたと（違）

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

日立，MPEG-4アクセラレータ搭載のケータイ向けアプリケーション・プロセサを発売へ（発表資料要約）
http://ne.nikkeibp.co.jp/DSP/2002/09/1000014782.html

＞　今回の製品にはMPEG-4処理の専用回路（ハードウエア・アクセラレータ）
＞を搭載した。MPEG-4処理の大半をミドルウエアで対応していた従来の
＞「SH-Mobile」シリーズに比較し，CPU負荷を1/5に軽減したという。
＞これにより，MPEG-4の処理性能を2倍以上に向上させた。また，SXGAサイズの
＞カメラを直接接続できるインタフェースを内蔵した。高精細カメラの大容量
＞画像データを高速に取り込むことができるという。
　：
＞　動画・音声を同時記録するフォーマット「MP4」に対応した動画記録
＞ミドルウエアを用意した。アプリケーションからこのミドルウエアを
＞呼び出すだけで，動画と音声をMP4ファイル・フォーマットのデータとして
＞保存，および動画と音声の同期再生が可能。ビデオ・メール機能を容易に
＞開発できるとする。

アプリケーション・プロセサにビデオ・メール向けの機能拡張。
つまらないiアプリに金払うくらいなら、動画・静止画で遊んだ方が楽しい？

一方でiAppliのAPIにカメラ制御関連が追加される事になるんでしょうけど、
とりあえずは画像加工系のiアプリが無数に製作される事になりそうな…。
手軽に画像で遊べて、そのアプリを使うことで画像のやりとりが何倍も
楽しくなって、画像受信側にも同iアプリをインストールすると更に何倍も
楽しくなる！みたいなアプリを作れたら、伝染病的にヒットするかも。
...その為には対応端末が普及しなくちゃだめか。
画像受信だけなら従来の端末でも可能、に作れるし、工夫次第かな。

iアプリでゲーム。いや別にゲームに拘らなくても…いやそれじゃ板違い…

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

>>637
任天堂が許すかどうか冷静に考えてみろ。

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

それが売れるなら次のゲームボーイは携帯型だな

02/10/04 11:31

>>639
iアプリは他と比較してコピーが難しい
（通信先サーバが限定できる）ので
iアプリの本体さえ流出させなければ意外と実現可能かも

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

http://www.nttdocomo.co.jp/p_s/imode/java/tool_504i.html

↑のページから「DoJa2.0 API向けiαppli Development Kit」の
Downloadボタンを押しても、ダウンロードページに飛ばないんですけど…
漏れの環境だけですかヽ(`Д´)ﾉ

**642** · 02/10/07 11:19

あ、飛べた…　今まで全然ダメだったのに…
ということでお騒がせｽﾏｿ

02/10/07 14:02

↑オレもなったことある
ある日突然直った。なんでだろうね？

**名前は開発中のものです。** · 02/10/08 07:43

それはたぶんアクセスが集中してるからでは…？
httpsはサーバ負荷が大きいそうですし…。

02/10/15 12:18

ほしゅー

02/10/17 12:03

ハドソンの着信あぷりのサイトにあるｉアプリって
起動時に「読み込み中」って出てしばらくまたされるよね
（通信しているわけではない）

あれってなにやっているんだろう？
内部データの解凍でもしてるのかな？？

**名前は開発中のものです。** · 02/10/17 16:11

「読み込み中」って出てるんだから
読み込んでるんじゃないの？

02/10/18 11:59

スクラッチパッドから、なんか読んでるのかな？

**名前は開発中のものです。** · 02/10/18 13:19

そりゃもう。イメージの生成だけでめっちゃ遅いし。
ところで、そろそろ504isの季節ですがいかがお過ごしでしょうか。

**あぼーん** · NG

あぼーん

**あぼーん** · NG

あぼーん

02/10/21 11:54

おわらせんなよ

02/10/25 11:58

プログラム板のスレは盛り上がってるのに
こちらはぜんぜんだな。。。

**Javaの勉強** · 02/10/25 21:12

//２つ以上の数値をキーボードから入力する
import java.io.*;
class test11
{
public static void main(string args[]) thorws IOExseption
{
System,out.pritln("数値をキーボードから入力してください。")

BufferedReader =
new BufferedReader(new InputStreamReader(System.in));

String str1 =br.readLine();
String str2 =br.readLine();

int num1 = Integer.parseInt(str1);
int num2 = Integer.parseInt(str2);

?????????????????????????????????
?????????????????????????????????

}
}

**名前は開発中のものです。** · 02/10/26 11:07

iアプリと関係ないじゃんよ。

**名前は開発中のものです。** · 02/10/29 11:51

IApplication.getCurrentApp().terminate();

**AIR-real** · 02/10/31 16:47

エアリアル先生のサイトはどこですか？
エアリアル先生のサイトはどこですか？
エアリアル先生のサイトはどこですか？

**YASUDA** · 02/10/31 18:14

キャラクターとか動かす場合
------------------------------
int x[] = new int[20];
int y[] = new int[20];
------------------------------
という風にデータ保持する方法と

------------------------------
class hoge{
int x;
int y;
}

hoge chara[] = new hoge[20];
------------------------------
とクラス化する場合
jarファイルのサイズは気にしないとして

・速度的には前者のが早いと思うのですが、体感できるくらい変わりますでしょうか？
・ヒープメモリ使用量は、やはりクラス使用のほうが多いでしょうか？

上記二点がそこまで差が無いのであれば
クラス化して後々拡張しやすいようにしたいんですが･･･

助言お願いしまふ

**あぼーん** · NG

あぼーん

AK · 02/10/31 20:00

　>>659
　いくら携帯Javaでもその程度で速度差が出たりしないでしょう。
　使用頻度がものすごく多いのであれば話は別ですが……。
　KVMがどういうコードを読んでるのか覗いたことないですが、
　アセンブラで考えたら処理に違いは無いので(まぁ呼び出し方で変わるかもしれませんが)、
　気にするほどの問題ではありません。

　ヒープメモリに関してもクラス・インスタンスを管理する分、余計に食うでしょうね。
　ですがiアプリはユーザーのことを考えてjarは小さいに越した事はありません。
　クラスを使ってjarのサイズを肥大させるくらいなら、
　使わないでコーディングした方が良いです。
　なんならクラス構造を展開する最適化ツールを作ればコーディング中は問題ないでしょう。
　リリース時にソースを最適化すればよいわけですから。

**YASUDA** · 02/10/31 21:00

>>661
解答ありがとうございます。
体感そこまで変わらないのであれば、とりあえずクラス使って作って
最後に最適化するようにしてみます。
＞なんならクラス構造を展開する最適化ツールを作ればコーディング中は問題ないでしょう。
そんなツールもあるんですか！
検索してみます。

＃あぁ、機種毎の個性出すのはJAVA以外の部分でやってほしいなぁ

AK · 02/10/31 21:23

>>662
　そんなツールありました？
　あったら私も使いたいところです。

　504オプションAPIの各機種間対応表みると、まったくもって使えない機能が多すぎ。
　せめてSpriteくらい全機種対応して欲しい……。

**YASUDA** · 02/10/31 23:11

>>663
あ、「最適化ツールを作れば」か、あるもんかと勘違いして探してましたよ（´_｀
検索では見つからなかったです。
英語サイトは探してませんが、、、存在してれば既に広まってそうですよね。
がくり

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

データを送信するにはどんな感じすればいいのですか？
また、参考になったサイト・書籍を知りませんか。

経験値・レベル・クリアすると貰えるキーワードなどのデータを
鯖に送信、受信したデータをメールとして送信。

アプリ　→　鯖　→　指定したアドレスへ

※メアドはユーザーが自分で登録

メールを鯖から送信するからsendmailを使うんですよね？

**あぼーん** · NG

あぼーん

**haruka** · 02/11/01 08:44

>>659 >>661
実際には、それなりに速度差あります。
とはいえ、実際には配列アクセスとローカル変数のアクセスの間にも速度差があるので、
キャラクターの移動の場合、

int x = x[i], y = y[i]
　　 x と y を使って計算
x[i] = x; y[i] = y;

みたいなコードになります。そうするとアクセス回数自体が少なくなるので、
>>659の前者後者ではあんまり差がでないです。

ヒープの量は、だいたい1オブジェクトでフィールドに必要な量を以外に16バイトくらい
使うような気がするんで、それが誤差の範囲かどうかは作るモノによると思います。

**haruka** · 02/11/01 08:45

>>663
Sprite自体あんまり使い道のないAPIなので
全機種対応されててもされてなくてもあんまり関係ないと思うょ。

AK · 02/11/01 09:44

>>667
　>配列アクセスとローカル変数のアクセスの間にも速度差
　マジですか？！
　JVMってそんな処理してんですか……遅いわけだ。
　っていうか一体どういうメモリアクセスしてるんだ？

　単体インスタンスの方が速いって本当ですか？
　私は最後に変数を全て配列化してたので、それが本当ならものすごく遅くしてたということになりますな……。

>ヒープの量は、だいたい1オブジェクトでフィールドに必要な量を以外に16バイトくらい
　まったくJAVAのintなどのインスタンスにも、クラスIDだかサイズなどをくっつけてでかくするのはやめて欲しいですね。
　変数は4バイトまでにして欲しい。

>Sprite自体あんまり使い道のないAPIなので
　そうですね。Graphics2が全部対応してくれればいいんですけど……。
　拡大はできなくても仕方ないけど、反転などのラスタ系が使えないってどういうこと？　って思います。
　いっそのこと別にライブラリに付けなくてもいいから、
　画像などの内部データにアクセスさせてくれれば自前でラスタ処理するんでその方がいいですけどねぇ。
　画像処理あたりはアセンブリライクに組みたいですよね。

**haruka** · 02/11/01 10:27

>>669
配列は
NullPointerとか、ArrayIndexOutOfBoundsとかのチェックが入るので
どうしても遅くなっちゃうでしょ。

あと、intはインスタンスじゃないので、4バイトしか使わないです。

**YASUDA** · 02/11/01 11:05

>>667
その方法が速度的、ヒープ的にベストっぽいですね。
ただ、配列管理だと場合キャラクターのステータスが増えた場合管理が面倒くさそうですね
しかしActionゲームを作る上では避けて通れ無そうなのでその方法でがんばってみます。
ありがとうございます

AK · 02/11/01 12:06

>>670
　いやぁ、今までずっと勘違いしてました。
　私の頭の中のJVMと実際のJVMではだいぶ違ってたみたいです。
　ちょっと調べてみたら確かに配列使うと遅いですね。
　やり方によって体感するくらいの差が出るんじゃないですか？

　>クラスIDだかサイズなどをくっつけてでかくするのはやめて
　jarにする時、宣言一つで10数バイトほど余計に増えるので「なんだよ、intごとにlengthでもつけてんのか？」
　と思ってましたが、よくよく考えればバイトコードのサイズアップは実際のメモリ配置とは関係ないですもんね。
　それに調べたらlengthというフィールドがあるわけでもないようですし。
　
　私は最終的にソースコード上の単体変数を配列に置換するツール作ってjarの容量減らしてました。
　大体1kくらい軽くなるので、それでよしと思ってましたが、
　まさか遅くなっていたなんてね……。

　今までそんなバカなことやってないだろうと、調べずに無視してきましたが、
　Javaのあまりのお節介加減に気を失いそうになりました……。
　最近ハードいじりに疲れたんでJavaってましたが、
　なんかもうJava愛も冷めたって感じです……。
　やっぱ古巣へ帰ろう……。