ｉアプリでゲーム

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

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

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

まあ、Java向けに作られたVMだからねえ。
普通のアセンブリ言語よりも最適化の余地が少ないと思う。
プライム変数の割り当てとかチェックするくらいかな。

０からバイトコード書いたら何か面白いことできるのかも知れんけど。
スタック周りでどうにか。

02/01/26 20:13

JVMでもＫＶＭでも同じだよん。

02/01/26 20:13

ＶＭアセンブラではスタックなどいじれない。

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

? ほぼ全部のインストラクションがスタックがらみじゃろ。

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

>>141
本当にちゃんと見たか？
thisのフィールドにアクセスするとどえらく命令数食うとか、
コンパイラはそのへんを全然最適化してくれないとか、わからなかったか？
逆アセの結果を見てjavaのコードを最適化する。最後の仕上げだけ
アセンブラ。それでも10KBに収まらなかったらﾏｽﾞｰ

>>144
オペランドスタックのことと思われ。

**haruka** · 02/01/27 01:32

>>146
マルチスレッドで動かすことを考えているせいで、
フィールドアクセスは、
同じ意味のまま最適化するのが難しいんじゃないかと思う。

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

その辺の最適化の限界は、C++あたりと事情は同じかな。
まあ、504iが出たら半分どうでもよくなるかもしれんけどねー。
適当にobfuscator通すくらいか。

**148** · 02/01/27 06:07

って、たった30KBじゃまだそんなわけにもいかないのか。
嗚呼、なんかもう感覚が麻痺してるよ。

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

MoPee、SpicyDog Builderみたいな簡易制作ツールのマック版ってないですかね？？
わざわざ細かい事しないで作れるから楽そうだよ。でも俺Winじゃないし…

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

やっぱり、サムロマみたいな大作を初期の時期にリリースできた
shi3z氏に聞くのが一番早いと思う。JVMのコード作成にあたっては
彼が深く関与しているし。

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

>>150
あの手のFlash系（身も蓋もないが）ツール、
今のiアプリの性能では使い物にならんと思ー。
ベンダにとってみれば、早いうちにツバつけとこうって感じなのかな。
２～３世代性能上がらないと駄目かもね。

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

バイトコード解析の最新流行はやっぱりJad、これだね。
http://kpdus.tripod.com/jad.html
逆コンパイラとしては有名だけど、
-aオプションつけるとコメントでバイトコードも一緒に出力される。

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

152>>　でもちょっとしたものつくる時にはつかえそうだと思ったんだけど、それでもだめかな～

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

円をかくメソッドがないんだけど
どうすれがいいの？

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

鼻糞食って喜んでる小学生レベルの質問だな。

02/01/29 23:02

なかったっけ？

02/01/29 23:05

自分で書くか、imageで張り付けなされ。

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

でもなんで　円を書くメソッドないんだろう。
矩形ならあるのに。

javaのほうにもあるのに。

**haruka** · 02/01/30 01:16

円は矩形と違っていまいち使いでがないからだと思うよ。

02/01/30 02:26

容量食うからでない？

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

>>160
そうかなぁ
俺は使いたいけどつかえないってことが
結構あるんだけどなぁ・・

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

あげりんこ

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

あげまんこ

**haruka** · 02/01/31 00:57

それより
drawImage(Image,int dx. int dy, int sx, int sy, int w, int h)
がない方がおかしいよー。絶対欲しいよ。

02/01/31 01:51

ライブラリ作った奴はド素人なんでしょう。

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

ブレゼンハムなりなんなり使って自分で描きなさい＞円
APIがないだけで文句言うヤツ多すぎ。

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

ブレゼンハムってなに？

02/01/31 13:31

アルゴリズムヲタ用語だろ

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

俺は丸大ハムで円描いてるよ。

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

↑山下？

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

http://www.google.co.jp/search?sourceid=navclient&ie=utf8&oe=utf8&q=%E3%83%96%E3%83%AC%E3%82%BC%E3%83%B3%E3%83%8F%E3%83%A0
検索しなさい。ていうか、Graphics.drawOval()あたりが
どうやって円を描いてるのか一度でも疑問に思わないようでは
プログラマとして駄目だぞ。

**haruka** · 02/02/04 00:01

普通はブレゼンハムだろうけど、iアプリだったらそんなの使わずに
drawPolylineで書く方がきっと速いと思う。

int _cosTable[] = new int[]{
256, 251, 237, 213, 181, 142, 98, 50,
0, -50, -98, -142, -181, -213, -237, -251,
-256, -251, -237, -213, -181, -142, -98, -50,
0, 50, 98, 142, 181, 213, 237, 251, 256,
251, 237, 213, 181, 142, 97, 49, 0
};
static int _xTable[] = new int[33];
static int _yTable[] = new int[33];

public void drawCircle(Graphics g, int x, int y, int r) {
for (int i = 0; i < 33; i ++) {
_xTable[i] = x + (_cosTable[i] * r >> 8);
_yTable[i] = y + (_cosTable[i + 8] * r >> 8);
}
g.drawPolyline(_xTable, _yTable, 33);
}
こんな感じ。
小さい円でよければもっと頂点を減らしてもいいと思うけど。

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

↑ありがとう。
そうなるよね～　ゲーム中に頻繁につかえないなぁ
forがないぶんましかー

**名無しさん** · 02/02/04 17:51

質問ですけど、皆さん、bmpをgifに変換するためにどんなツールを使ってますか。
僕はDPixedを使ってます。もっと一気に変換できるツールって無いんですかね。

**haruka** · 02/02/05 01:42

netppm使ってる…

**haruka** · 02/02/05 01:45

Netpbmだった。かなり鬱ぅ

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

すいません、質問なんですが、ディスプレイの左上原点座標って
どうやって求めるんでしょうか？

(0,0)だとディスプレイ最上部のステータス欄で隠されて
しまうんですが。

いろんなサンプル見たんですが、どれもこれも
(0,10)みたいに適当に左上位置を決め打ちして
お茶を濁して参考になりません。

そのくせ Canvas#getHeight() で得られる
値はディスプレイからステータス欄を除いた
ものなんで、わけわかりません。

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

↑そこまでわかってれば、後はある計算ででますよね・・・

**178** · 02/02/08 02:59

>>179
すみません、わからないです....。

**haruka** · 02/02/08 10:15

>>178
drawStringで描画しようとしてる?

もしそうなら、、
ちゃんとAPIリファレンス読んでよ…

**178** · 02/02/08 15:01

>>181

そうです。
「描画位置は、ベースラインの座標を指定します」
という一文がキーなのでしょうか？
さっぱり意味が分からないのですが....。

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

JavaのFontの扱いについて調べてみるよろし。
説明が面倒くさいのでページ探してきた。
http://homepage1.nifty.com/runrun/java/back/04/0063.html

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

>>182
本よめよ
文字のしただろ

**名無しさん** · 02/02/10 02:35

ゲーム中にフラグを使って１回だけダイアログを表示させようとしてるんですけど、
なぜかダイアログが表示されないんですね。

背景の下にダイアログが隠れてるのかなと思って背景を消して見たんですけど、
やっぱり表示されてないんです。でも機能は生きてるみたい。
一回決定を押すとまたゲームが動き出すので…。

これってどうしたら表示されるようになるんでしょうか？
誰か教えてください。

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

携帯が死んで全てのデータが失われてしまいました。

そこで質問

何か「これはやってみれ！」というアプリはありませんか？

機種はＤ５０３です。

スレ違いかもしれませんがおながいします

02/02/10 10:33

全て？
iアプリだけじゃなくて？
ああ、そりゃだめだ。
ドコモショップに相談してみたら？
多分駄目だろうけど。

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

↑だせー煽りだ。

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

>>186
スレ違いどころか板違いやんけ。携帯・PHS板のここらへんにゴー。

ααα良きiアプリααα
http://cheese.2ch.net/test/read.cgi/phs/1007725265/

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

zip圧縮しなおすのは有効なんですか?
動かないんですが、教えていただけるとうれしいです。

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

数値の文字列かってどうやるんですか？
うまくいかないんですが、
void pain(Graphics g){
int a = 3;
g.drwaString(""+a, 20,20);
}

**191** · 02/02/18 04:29

くだらんこと聞いてスマン、Java初めてなもんで
a.toString()でよかったのか。

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

age

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

zip再圧縮は上のほうに書いてある７ｚｉｐってソフトで成功できたよ。
１０５１０バイト位のが１０２００くらいまで減った。
ｓｏとｎでは実行できたと思う。

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

出る前は大騒ぎされたのにiアプリって盛り上がってないね。

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

>>195
100kbになったらもう少し状況も変わってくると思ふ。
いわゆるプログラマーの人がもちっと参入してさ。
もちろんCPUとかを携帯端末に期待するのはアレなので、
シュミレーションとかＲＰＧ、アドベンチャーになると。
ツール類はドコモがも少し携帯の方いじらせてくれれば。。。

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

皆はどのエミュレータを使ってるんでしょか?
私は西村誠一さんのを使っています、はみ出してしまったりします。
何かいいエミュレータはないでしょうか?

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

>>197
デフォルトでええンじゃないの。
ドコモので。
他のもつかったけど、結局これでやってるわ。
devices落ちてるの使えば、ってゆーか自分で書けば
はみ出さないよ。

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

D503iが売れ残ってて買いやすい値段なんですが、
これってテスト用にどうでしょう？

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

200

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

age

**エアリエル** · 02/04/06 21:39

>>199
Nがシェア50％以上だからNをオススメするよ。

iアプリ遅いかな～。遅い事は遅いけど
努力すればカバー出来るレベルのものだと思うが…
参考例にならんかも知れないけど、私の作ったアプリなんかは
結構高速に動くと言われてるんですが…
http://homepage.mac.com/airriel/i/i.htm

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

F50i4は503iと比べてアプリの速度が約10倍になるんだそうで。

**ワイデス2001** · 02/04/10 07:30

N504iの解像度160x198やて？
他の機種もバラバラみたいやね。正直もう頭が遺体DEATH
容量があればロジックと描画きちんと切り分けて対処するんだけどねえ。
まだたった30KBではねえ。

**ワイデス2001** · 02/04/14 13:58

176x220という説も登場。まいったねこりゃどうも。

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

俺が聞いたのは160*180だす
うーん

**エアリエル** · 02/04/18 16:34

現行のiアプリそのまま動くのかな～？　＞　504

私の作ってるアプリは120*130以外でも大丈夫なように設計してるつもりだが
180～200はちょっと、、ねぇ～。想定外も甚だしいというべきか…
それに画面が大きくなった分、保存すべき情報量も増えるだろうし、、
現行サイズでも特別画面が狭いとは思えないが…

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

たしかに画面サイズだけ先走られてもね
ハード制作側はゲーム作ることはあまり考えてない設計してるって言うし、
つうか考慮してくらさい

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

まあ、解像度が高くなること自体は歓迎できるんだけどね。
http://www.zdnet.co.jp/mobile/0204/16/n_reso.html
176x220という中途半端なサイズにはそれなりに理由があるらしい。

**ビッダーズ向上委員長** · 02/04/19 14:16

ヤフーは、どこをどうとっても最悪。
ビッダーズが一番！！！↓
http://www.bidders.co.jp/bpu/1072049

皆、左上の会員登録をクリックして、
入会しよう。

**エアリエル** · 02/04/23 11:15

176*220…ホント、、中途半端な…

http://www.zdnet.co.jp/mobile/0204/22/n_504.html
504はこんな感じになるらしい

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

あう、今回もボタン配置まるまる一緒かい＞NEC
N503iのはとても最善とは呼べない（むしろクソ）シロモノなのに……。
なんかPC-9801化ってカンジ。シェアにあぐらかいとるんとちゃうか。

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

>>212

旧来のユーザが使い慣れてる配置から
変更する方がよっぽどどうかとも思うが。

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

変えるなら早いほうがいいね。
使い難い配置に慣らされる被害者が増えすぎないうちに。
って、俺は携帯持ってないんで使い勝手について全然知らないんだけど。

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

３０００円ぐらいでパケット数無制限とかあればＭＭＲＰＧとかできんだけどナー
まんまでシステム組むと上方向に一歩歩いただけで、１パケット送っちゃうし。
（システム工夫すりゃいいんだが、直感的でないしー）

**haruka** · 02/04/27 01:49

ゲームやるときは方向キーの真ん中に決定キーがないほうがいいから
私はN503iのキーは結構好きなんですが…
最善とはいえないけど503の中では一番いいよ。

**名前は開発中のものです。** · 02/04/27 18:01

デザインだけではＦが好きなんだが、あれでアクションはできんよな～。（Ｓ５０４も）

**名前は開発中のものです。** · 02/04/27 18:03

P503is反応速度遅すぎ！
ついてくるゲームもまともに動かん…

**親切な人** · 02/04/27 18:18

ヤフーオークションで、凄い人気商品、発見！！！

「高性能ビデオスタビライザー」↓
http://user.auctions.yahoo.co.jp/jp/user/NEO_UURONNTYA

ヤフーオークション内では、現在、このオークション
の話題で、持ちきりです。

**名前は開発中のものです。** · 02/04/27 18:53

目指すはケータイ制覇，日立製作所が動き出す
http://ne.nikkeibp.co.jp/mobile/2002/04/1000012001.html

＞今回のSH-Mobileでは，Javaの実行はソフトウエアで処理する。
＞「Javaアクセラレータがなくても，Javaの実行速度はかなり向上
＞するはず。ちょっとオーバースペックかもしれないほどだ。
＞各メーカーから端末が発表される際，SH-Mobileが搭載されてい
＞ることに言及するかどうかはメーカー次第だが，Javaプログラム
＞の実行速度が今までの機種に比べて圧倒的に速いので，一目瞭然
＞だろう」という。

日立は「アプリケーション・プロセサ」シェアを争ううちの１社に過ぎないわけですが、
今後、Java実行能力に優れた新機種がどんどん供給される・・・予定なんですよね。
それが付加価値として市場で認められなければ、高性能化の速度は鈍るでしょうけど。

コンテンツを作る人は本当に大変ですね。少なくとも向こう数年は、PC向けなどと比べて遥かに広いハード性能分布に対応し、それぞれのユーザーが満足するコンテンツを製作しなくてはならない。
最低位のスペックは恐ろしく狭苦しい訳だし。直ぐに切り捨てられるほど急速にユーザー移行が進めば良いけど、その為には高性能機ならではのサービス・コンテンツが提供されなければならないし、不景気だし。

**haruka** · 02/04/28 01:19

J-PhoneとかDoCoMoのセンスの無いAPIたちを見て、
それでも携帯Javaに将来があると思う人はどれだけいるだろうか。

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

ま、大元を辿ればSunが悪いんだけどね。
Javaしか選択肢がなかったのもまた事実だしﾆﾝﾄﾓｶﾝﾄﾓ

>>220
>NTTドコモ向けの複数の端末メーカーなど

むう、どこなんだろう。
504i手元にある人はこっそりベンチマーク実行しる！
http://www.seckey.net/iappli/KVMMark.html

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

>>221
最も問題なのはどのあたりでしょうか
改善の見込みは無いでしょうか

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

最も問題なのはJavaを使っていること…って突っ込みはダメかい？

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

>>224
それがどう問題なのか具体的に指摘できるならダメでは無いけど

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

Javaはゲームつくる言語としては
シンプルでいいと思う．

高速性を求められると
駄目だけど．

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

>>226
あたりまえだろ。
Javaは言語の理想形を追い求める余り実用性に欠ける設計なんだから。

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

>>227
実用性とは高速性のこと？

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

そういやJavaCPUやJavaOSってどうなったんだ？

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

JavaCPUはあるけど動作速度が問題にならないくらい遅いので主流にはならない。

主流になるくらいの動作速度を持つCPUを開発するのには金が掛かり過ぎて
永久に無理。

JavaOSは知らない。

**haruka** · 02/04/30 01:31

>>223
今の携帯電話の形やサービスに特化したAPIが多くないですか?
今後2年間で消えてしまいそうなサービスのためのAPIと
プリミティブなAPIとの区別が全くついていないように見えます。

>>222
KVMMarkってほとんどのベンチが1秒かからずに終わってるんで、
ベンチマークとしての精度が極めて低いんですよ。

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

次世代マイクロアーキテクチャ「ARM11」発表
http://www.zdnet.co.jp/news/0204/30/b_0429_01.html

＞ARM11が実装するARMv6命令セットアーキテクチャには，Thumb拡張命令，
＞Java高速化のためのJazelle技術，ARM DSP拡張命令，SIMDメディア処理
＞拡張命令が含まれる。
　：
＞0.3μm（0.13の誤り？）製造プロセスの場合で最低350MHz～500MHz以上，
＞次世代0.1μmプロセスの場合で1GHz以上を実現するという。
　：
＞ARMでは，同マイクロアーキテクチャの採用が見込めるデバイスとして，
＞2.5G/3G携帯端末，PDA，マルチメディアワイヤレス機器のほか，
＞イメージング／デジタルカメラなどの家庭アプリケーションを挙げている。

ARM® Jazelleテクノロジ
http://www.arm.com/jp/uk/uk_jazelle.html

＞Jazelleは、ソフトウェアJVMやJITコンパイラを使った方法に比べ大幅な
＞性能向上（最大8倍）を実現します。しかも、それに伴ってコンパイラや
＞コンパイルされたコードのメモリ・コストが増加しません。
　：
＞Jazelleは、コプロセッサやJava専用プロセッサに比べ、最大90%
＞の性能向上を実現するほか、ハードウェア・コストが最小限で済み、
＞複雑なハードウェアやソフトウェア統合の必要がありません。

どーなんでしょうか。

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

drawRectでピクセル打っていって
リアルタイムでソフトウェアレンダリングできるくらいのスピードきぼん

**エアリエル** · 02/05/06 17:36

私は各機種ほぼ同じ速度希望。
503、、SO速すぎ。

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

>>234
激しく同意！

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

つまり、一番遅い機種に合わせろって事？

**エアリエル** · 02/05/08 00:49

遅くは出来るが速くは出来ない。
だから遅いのに合わせて作っておくと後々何かと融通が効く。
とはいえ503、、P遅すぎ。

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

古い機種を使いつづける人はいるから、永遠に初期の最も遅い機種に合わせて行くつもりなのかな？
そんな非現実的な事・・・・

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

そろそろ504iが出る頃合ですが、
個人でやってる人、機種変するわけっすか？ 2機種持つ強者とかいる？

**エアリエル** · 02/05/10 00:19

>>238
えーとね、遅い方にある程度合わせて必要最低限ってレベルで作っていけば、
ある程度仕上がって追加したくなったときに、いくつか追加して多少重くなっても
耐えられるカンジに仕上がる、、可能性が高いというだけの話さ。
永遠に合わせる必要はない。
、、と、偉そうに御託を述べた本人が言うのもなんですが、
今自分のとこで作ったアプリP503iじゃ遅すぎてゲームになりません(爆）

**エアリエル** · 02/05/10 00:33

KVMMarkに504がいくつか登場してる…。
ややっ！？ImageやGraphicが思ったより速くない気がする…
もしかして画面サイズが広がった分描画に時間がかかってる？
実際問題どうなんでしょ？