1001コメント349KB

iモード携帯電話用Java(iアプリ) Part10

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2005/11/10(木) 15:11:53

0075デフォルトの名無しさん

2005/11/22(火) 10:30:15

>>74
近所で氷上釣りが始まる人？(´・ω・｀)

0076デフォルトの名無しさん

2005/11/22(火) 15:50:48

>>75
兄さんMIDPスレ見ているなっ
でもハズレ

0077ﾋｬｯﾊｰ ◆N0JnmCMoD2

2005/11/23(水) 00:58:18

とりあえずアパッチとかいうの入れてみた！ﾋｬｯﾊｰ
DoCoMoの開発キット入れようとしたらＣドライブがないと言われた！ﾋｬｯﾊｰ
http://www.774.cc:8000/upload-micro/src/up0835.png
とりあえずパソコン直す…。

0078デフォルトの名無しさん

2005/11/23(水) 04:31:32

ここはお前のチラシの裏じゃないんだよ
分かるな？

0079ﾋｬｯﾊｰ ◆N0JnmCMoD2

2005/11/23(水) 06:11:03

>>78
ごめんなさい。もうしませんﾋｬｯﾊｰ
パソコン直ったら、次からチラシの裏に書きます…

0080デフォルトの名無しさん

2005/11/23(水) 08:27:49

>79
ブログでも立ち上げたらどうか。

0081デフォルトの名無しさん

2005/11/23(水) 15:43:40

描画関係の処理をpaint()の外に書くと落ちたりってしますか？
g.setColor()とかg.fillRect()とかしか書いてないのに実機で落ちます．
エミュレータでは普通に動きます．
無理矢理全てpaint()の中に押し込めたら落ちなくなったんですが・・・
エミュレータで動くのに実機で落ちるという状況だとパケット代がかかって大変です．

0082デフォルトの名無しさん

2005/11/23(水) 16:24:40

とりあえずgc()でも入れてみようか

0083デフォルトの名無しさん

2005/11/23(水) 17:13:18

テスツﾋｬｯﾊｰ
ttp://222.225.75.194/~Owner/

0084デフォルトの名無しさん

2005/11/23(水) 19:11:59

>>82
gc()ですか．後で試してみます．

0085デフォルトの名無しさん

2005/11/23(水) 22:01:12

ど素人な客じゃないんだから、エラー内容くらい見ようぜ。

0086デフォルトの名無しさん

2005/11/24(木) 01:29:58

>>81
まさかpaint()の引数に渡ってくるGraphics gを外で使ってるとかじゃないよね？
paint()の外で使うなら、getGraphics()しなきゃだめだよ。

0087デフォルトの名無しさん

2005/11/24(木) 20:22:17

ｉアプリからプログラムに入ると、
基本と応用の違いが理解できなくて
糞プログラマになっていくような気がしてしょうがない。

0088デフォルトの名無しさん

2005/11/24(木) 23:18:04

N88BASICでgotoを乱用することから始めた人が
プロとしてバリバリにやっているのをみると
あまり関係ない気がする

0089デフォルトの名無しさん

2005/11/25(金) 00:30:14

DoCoMoのエミュレータ…
どっかの素人が趣味で作ったのか？
あんなくそソフトが基準だとやりづらくてしょうがねぇ。

0090デフォルトの名無しさん

2005/11/25(金) 05:16:11

>>89 Vodaのより何倍もマシ

0091デフォルトの名無しさん

2005/11/25(金) 06:14:13

>>89
じゃあお前はもっといいものを作れるわけだな？
うｐ

009289

2005/11/25(金) 06:50:48

>>90
そうなんだ…ボーダApp開発者かわいそす。

>>91
そうだな、いずれは作らなきゃアカンか…。
あのエミュは使用感が精神衛生上よろしくない。

0093デフォルトの名無しさん

2005/11/25(金) 07:40:40

他のどの携帯エミュよりも、DOCOMOのが優れているんだが…。
VisualStudioでWin32プログラムしか組んだこと無いのか？

0094デフォルトの名無しさん

2005/11/25(金) 08:07:20

そこはJava GUIだろう

0095デフォルトの名無しさん

2005/11/25(金) 08:58:17

仕様を考えると、シロウトが趣味で作れるようなシロモノじゃないのは確かだ。
そこらへん理解できない>>89がシロウト。

0096デフォルトの名無しさん

2005/11/25(金) 11:05:26

DoJa1.5登場・・・何故に今更・・・・・。

あとP851iは4.0leだがどうなんだろうな。今日だっけ？発売日

0097デフォルトの名無しさん

2005/11/25(金) 13:26:31

質問失礼します。

iｱﾌﾟﾘ上から、jarのみの更新（バージョンアップ）って可能なのでしょうか？
DoJa-3.0以降だったら可能とチラッと聞いたのですが、具体的な命令等が分かりません。
初心者の質問で申し訳ないのですが、よろしくお願いします。

0098デフォルトの名無しさん

2005/11/25(金) 13:57:35

>>97
IApplication.launch()メソッド
第1 引数にIApplication.LAUNCH_VERSIONUP
第2 引数にnull を指定

後は頑張れ。

0099デフォルトの名無しさん

2005/11/25(金) 14:43:25

>>92
> あのエミュは使用感が精神衛生上よろしくない。

具体的に

0100デフォルトの名無しさん

2005/11/25(金) 14:43:38

>>98
解決しました。
ありがとうございます。

0101デフォルトの名無しさん

2005/11/25(金) 15:06:33

>>99
学生が作ったかのようなインターフェイス。
妙に粘り気のあるレスポンス。
あと処理が遅い気がする。

0102デフォルトの名無しさん

2005/11/25(金) 15:30:25

手前が斬新なエミュをうｐしてから文句言えばいいじゃないか。
ただのアレに見える

0103デフォルトの名無しさん

2005/11/25(金) 15:36:41

この規模のツールは仕事の人が作るほど素人っぽく見える気がする。
フリーの作者なら手間を惜しまず修正するかもしれないが、
仕事であれば、納期内に規定の動作を組み込む必要があるし、
そもそも、Doja2.0の頃からのUIをほとんど変えずにやってるんだから、
なかなか苦労してそう。

レスポンスはウチのマシンはPentium4の3Gで
メモリは1Gしか乗ってないけどそんなに重くないよ？
余計なソフト立ち上げてるんじゃね？

0104デフォルトの名無しさん

2005/11/25(金) 16:46:34

BREWエミュレータに比べれば恐ろしく快適なんだが。
あ、でもDoja-4.0エミュはもっさり動作だな。

0105デフォルトの名無しさん

2005/11/25(金) 16:51:07

>>96
海外キャリア向け

010681

2005/11/26(土) 00:06:29

>>85
エラーってどこかに出るんですか？
N901iSを使ってるんですが，落ちたことしかわからない気が．

>>86
ありがとうございます．たぶんそれですね．
どこかのサイトで見たソースを真似してしまったので・・・

0107デフォルトの名無しさん

2005/11/26(土) 01:59:32

iアプリで、
外部からファイルを読み込むって不可能ですか？
扱うクラスが全く見当たらないのです…

ゲームを作っていて、数十種類ある武器や鎧（及びそれぞれの設定値）を外部ファイルにして
起動時に読み込んで変数に格納したいのですが、、。

どうしても本体に長々と書くのが嫌なので
別のファイルに　武器鎧を全て変数に入れたものを　用意して
returnで返そうかな？なんて思っています

外部のファイルに武器鎧を保存したい場合、適切な手段はどのような手段でしょうか？
自分は↑しか思いつきませんでした…

0108デフォルトの名無しさん

2005/11/26(土) 02:32:10

>>107
ScrachPad

0109デフォルトの名無しさん

2005/11/26(土) 02:32:31

リソースにぶっこむなり
サーバに置いてスクラッチパッドにぶっこむなり
お好きな方で。

0110デフォルトの名無しさん

2005/11/26(土) 06:00:03

余裕あるなら本体に長々と書いたほうが

0111107

2005/11/26(土) 06:21:18

スクラッチパッドを使ってのは出来たけど、うーん、、
リソースにぶち込むってのは、分かりませんでした
イメージと、音声のはあったのですが、
ファイル読み込みのってあります？

>>110
余裕があるなら、という事は、
やはり本体に長々と書いたほうが、動作が軽いのでしょうか！？

iアプリ作ってる割にvodafoneで、実機での動作はまだ行っておりません…

0112デフォルトの名無しさん

2005/11/26(土) 09:59:17

resフォルダにファイル入れてスクラッチパッドと同じ方法で読むだけ

0113107

2005/11/26(土) 11:01:00

>>112
愛してます
武器に「>>112」っての作りました

ありがとうございまｓ…愛してます

0114デフォルトの名無しさん

2005/11/27(日) 12:44:01

Doja3.5でButtonを

　B
B　B
　B

のような形に配置したくて、HTMLLayoutのLEFTとRIGHTを使って配置したら
　B
B
　　B
　B
のようになってしまったんですが何か解決方法とかありますか？

0115KoRoN@Vim%Chalice ◆8XALICEsdk

2005/11/27(日) 13:45:33

>>114 ボタンの幅

0116115@Vim%Chalice ◆8XALICEsdk

2005/11/27(日) 13:46:07

>>114
ボタンの幅を設定してみたらどうですか?

0117デフォルトの名無しさん

2005/11/27(日) 14:07:10

>116
ああ、幅のこと考えてませんでした；
やってみます、レスありがとうございました。

0118107

2005/11/27(日) 15:24:52

なんどもすいません、
resフォルダにテキストを突っ込み、読み込もうとするも、出来ません

先ず、112さんの指摘通りにやってみたのですが、
loadエラーになります
DataInputStream dis = Connector.openDataInputStream("resource:///buki.txt");
そこで、とあるサイトにあったのをコピペすると、
loadエラーが解決しました　ファイルの読み込みは成功です　が
実際にString型の変数に内容をいれる、readUTFが使えません

　コネクションを作成　接続先はリソースのbuki.txt
↓パラメーターは…？buki.txtを読みますよ　　って事ですか？
Connection connection=Connector.open("resource:///buki.txt",Connector.READ);

↓入力コネクションの作成
InputConnection inputConnection=(InputConnection)(connection);
↓入力ストリーム　オープン
InputStream in=inputConnection.openInputStream();

「↓」の右側に記したのが、自分なりの解釈です
この場合、
String hako = in.read();
で出来ると思ったのですが、、互換性の無い型とエラーが出て、出来ませんでした…
in.read();で　入力ストリームを通しインタフェースを通って　リソースの
buki.txtからデータを読み込むと思ったのですが、
解釈、間違っていますか？

時間をかけて調べて　上記に行き着いたのですが、
論外な程間違っていたら、本当申し訳ないです

0119107

2005/11/27(日) 15:34:30

上記の件ですがAPIは
http://orto.accelart.jp/docs/client/java/io/InputStream.html
を見ました

0120デフォルトの名無しさん

2005/11/27(日) 16:00:16

>>119
DataInputのreadUTF()を見ればわかると思いますが、
readUTFは特別なフォーマットのUTF-8しか読むことができません。
普通のテキストファイルを読みたければ、InputStream.readで1バイトずつ読込み、
改行記号のところで読み切るようなことをする必要がありますよ。

Vector vec = new Vector();
ByteArrayInputStream buf = new ByteArrayInputStream();
while (true) {
int d = in.read();
if (d < 0 || d == '\n') {
vec.addElement(new String(buf.toByteArray()));
if (d < 0)
break;
buf = new ByteArrayInputStream();
} else if (d == '\r') {
continue;
} else {
buf.write(d);
}
}
String[] array = new String[vec.size()];
vec.copyInto(array);

こんな感じにすると、arrayに読み込めると思われます。

0121デフォルトの名無しさん

2005/11/27(日) 22:28:13

>>118
> String hako = in.read();
そりゃInputStream#read()の戻り値の型がintなのにStringに代入しようとしてるからだろw

0122デフォルトの名無しさん

2005/11/27(日) 23:34:33

String hako = "" + in.read();
で通る・・かな？

0123o

2005/11/27(日) 23:47:02

>>122
そりゃ通るけど、意図しない結果になるよ。
InputStreamで流れてくるのは何？
シフトJISの文字列なら、素直にInputStreamReader使え。

0124デフォルトの名無しさん

2005/11/28(月) 00:36:24

>>122
119で解決すんのに何か問題でも有るのか？
データ型意識できない程度のレベルなら、
素直に人のソース真似とくべきかと。

UTF形式でやりたいなら、
テキストの先頭2バイトだか3バイトだかに
バッファ長入れとけば読めたはず。

0125デフォルトの名無しさん

2005/11/28(月) 01:39:39

アプリでゲームを作ろうと思ってるんだけど
当たり判定とかどうすればいいか分からないから教えてくれると助かります
ドットを拾う事はやったんだけど・・・
ご教授お願いします・・・orz
AとBが接触したらゲームオーバーみたいな奴なんだけど・・・

0126デフォルトの名無しさん

2005/11/28(月) 01:53:52

>ドットを拾う事はやったんだけど・・・
どのゲームもそんな馬鹿げた処理は使わない。

絵とは別に当たり判定用のrectを用意するのみ。
この程度基礎はゲーム板なりWebなりで勉強汁

0127デフォルトの名無しさん

2005/11/28(月) 02:11:21

>>125
わりとゲームプログラミングの基礎中の基礎と思われ。
最近は初心者向けのゲームプログラムの本もたくさん出ていて
当たり判定はどの本でも扱っているはず。

0128デフォルトの名無しさん

2005/11/28(月) 02:14:02

布留川英一の「iアプリゲーム開発テキストブック」本買ったーよ。
901iまで対応している本は貴重ですね。

0129デフォルトの名無しさん

2005/11/28(月) 02:32:36

>>126-127
無知でスマソ、出直してきます

0130デフォルトの名無しさん

2005/11/28(月) 06:10:20

>>128
漏れも去年買った
表紙はともかく、
中身は良書だと思う

0131デフォルトの名無しさん

2005/11/28(月) 11:33:21

>>105
try()～catch()でまずエラーを拾うところからはじめれ。
ADFにはAppTraceをonに設定して、必要な内容をプリントアウトすれば良い。
内容の確認は端末のトレース情報に出てくる。

例：
try{
//何かの処理
}
catch(Exception e){
//必要に応じてエラー情報を吐き出す。
System.out.println(e.toString());
}

0132デフォルトの名無しさん

2005/11/28(月) 11:33:57

>>131
レス場所間違えたｗ
>>106で・・・すまん。

0133デフォルトの名無しさん

2005/11/28(月) 16:31:57

iアプリでGPSと連動した機能を付けたいのですが、そのようなことは出来ますか？

0134デフォルトの名無しさん

2005/11/28(月) 16:55:30

できますん

0135デフォルトの名無しさん

2005/11/28(月) 23:08:28

>>131
ありがとうございます．
AppTraceですか，初めて知りました．

0136デフォルトの名無しさん

2005/11/30(水) 10:51:56

公式で発表されてない気がするからあえてぼかして書くけど
702シリーズってDojaのバージョン統一されてない？('A`)

0137デフォルトの名無しさん

2005/11/30(水) 11:17:41

>>136
ぼかしてない、ぼかしてないｗｗｗ

とりあえず（ここ重要）はそうみたいだな。
が、実機見てみないことにはなんとも言えないんじゃね？ｗ

0138デフォルトの名無しさん

2005/12/01(木) 01:46:19

本見たら、900以降はjarファイルが100k以内って書いてあるけど、
それを超えたらダウンロードできないんですか？それとも、
スクラッチパッドに画像とかいれる命令をしなくてはいけないんですか？
教えてください

0139デフォルトの名無しさん

2005/12/01(木) 03:36:38

＞それを超えたらダウンロードできないんですか？
はい。
＞スクラッチパッドに画像とかいれる命令をしなくてはいけないんですか？
100kBにおさまならければ。

0140デフォルトの名無しさん

2005/12/01(木) 18:31:14

すっごい今更なんだが…。
「何故スクラッチパッドにJarを落としてそれを軌道」ということができないんだろう…。
アプリ間移動つらい。

できない…よな？

0141デフォルトの名無しさん

2005/12/01(木) 18:34:35

思いのたけを書き込んだもんで、誤字脱字が酷いな…。

何故「スクラッチパッドにDLしたJarを、アプリJarのごとく起動実行する」ことができないのだろう。
これができれば、ポータル的なアプリだけつくり、動的にプログラムをサーバーからDLして実行できるのになぁ。

0142デフォルトの名無しさん

2005/12/01(木) 18:34:58

>>138
java以前に日本語の勉強からしっかりやっていただきたい。

0143デフォルトの名無しさん

2005/12/01(木) 18:38:43

>>141
アプリからアプリコードを直接実行できるようにしたらセキュリティうざいから

0144デフォルトの名無しさん

2005/12/01(木) 18:48:49

>>143
でも、preverifyとか、実際アプリを起動する前のチェック処理とかを使いまわせば問題なくね？
いや、問題があるからこそできないようになってるんだろうが…。

仮想マシン作るかー…。
あほくせええええ

0145デフォルトの名無しさん

2005/12/01(木) 19:01:27

落としたアプリはどこのスクラッチパッド使うんだよ（ﾟ∀ﾟ）
携帯本体のアプリケーションマネージャが知らないアプリを
作るのは駄目ポ。

0146デフォルトの名無しさん

2005/12/01(木) 19:07:35

>>144
ヒント：Jiglet
廃れつつあるが…

0147デフォルトの名無しさん

2005/12/02(金) 00:28:35

サーバにあるテキストファイルを取得するアプリを作ってます。
DoJa4.0ではBufferedReaderクラスのreadLineメソッドを使って
以下のような感じで１行ずつ読み込んでいました。

　InputStream in = con.openInputStream();
　InputStreamReader ir = new InputStreamReader(in);
　br = new BufferedReader(ir);
　String s;
　while ((s = br.readLine()) != null) {
　 // sは１行分のストリング
　 // sを配列に入れていく
　}

ところが、DoJa2.xだとBufferedReaderクラスがサポートされていなくて
このソースではビルドできません。
BufferedReaderクラスのreadLineメソッドを使用しないで1行ずつデータを
取得するにはどんな方法で行えばいいんでしょうか？

0148デフォルトの名無しさん

2005/12/02(金) 00:36:46

１文字ずつ読んで改行記号で区切るのは問題あるのかい

0149デフォルトの名無しさん

2005/12/02(金) 00:58:40

>>147 >>120

0150デフォルトの名無しさん

2005/12/02(金) 01:10:46

携帯Java上で動作するインタプリタ作ればいい

0151デフォルトの名無しさん

2005/12/02(金) 05:39:31

ゲームで扱う数字って、int型より、Byte型の方がメモリ食わないですか？

0152デフォルトの名無しさん

2005/12/02(金) 06:43:59

Java VMはint型の操作がメイン。余程のことでもなければ素直にintをつかうべき。
byte型を使ってコードが膨らんだり遅くなったりするのを確認されたし。

0153デフォルトの名無しさん

2005/12/02(金) 07:03:15

>>148

１文字ずつ読むって、具体的にどうすればよいですか？
実はjavaって今回が初めてであまりわかってないんです・・・

0154デフォルトの名無しさん

2005/12/02(金) 08:59:24

>>151
実はJAVAにはBYTE型なんていう型はなく、内部的にintに変換されている。
だから最初からintを使ったほうが(-127～128への)丸め込みの処理が無くなる分だけ高速

>>158
readByteで読んで保存していき、'\n'にぶちあたったらそこが改行ポイントということでよいのでは？

0155151

2005/12/02(金) 09:27:07

>>152　>>154
凄いタメになりました…
何故悩んだかというと、

武器を装備できるかどうかのフラグを立てたく、

int型の多次元配列で　フラグ，攻撃力，命中補正
って感じでやりたい、という話しをしたら、大学の講師さんが
「フラグは1か0でいいわけだから、int型を宣言するより、
BYTE型で1bitだけ使って後のbitを攻撃力とかに回した方が効率がいい」
と言ったためです

私が無知な事ももちろんありますが、152、154さんは本当凄いですね
このスレのレベルの高さを改めて実感しました
本当に感謝しています　有難う御座いました

0156デフォルトの名無しさん

2005/12/02(金) 09:37:38

フラグは1か0でいいわけだから、int型を宣言するより、
BYTE型で1bitだけ使って後のbitを攻撃力とかに回した方が効率がいい

0157151

2005/12/02(金) 09:44:16

>>156

!!?　(゜ д゜ )　　　( ゜д゜ )

0158デフォルトの名無しさん

2005/12/02(金) 09:52:28

「メモリ食わないか？」

っつー質問に

「こっちの方が高速」

っていう回答して
そっちを薦めるのは変じゃないか？

0159151

2005/12/02(金) 10:01:33

確かにそう言われてみれば…

メモリがいっぱいいっぱい　処理はもう少し余裕がある
→処理を犠牲にしてでも　メモリ効率を気にする

メモリが余裕　　処理がキチキチ
→メモリを気にするより　処理に余裕を持たせる

という解釈は間違っていますか？

0160デフォルトの名無しさん

2005/12/02(金) 10:19:09

int型でも1bitだけ使って後のbitを（ｒｙ

0161デフォルトの名無しさん

2005/12/02(金) 10:33:26

フラグ，攻撃力，命中補正

それぞれに必要なbit数を数える。

8bit以内ならbyteでもいいと思う。

0162デフォルトの名無しさん

2005/12/02(金) 10:35:21

ｷﾞﾘｷﾞﾘまで性能を使うってのも悪くは無いと思うんだけど、
携帯ｱﾌﾟﾘの新端末が出るたびに保守対応をしていく状況と、
開発者が次々に辞めたり手が空いてる人がいなくて
他人のｿｰｽを見る必要がある現状だと
ｿｰｽの保守性の方を優先して欲しいと思う(´・ω・｀)

0163デフォルトの名無しさん

2005/12/02(金) 10:45:45

>>159
そもそも、intとbyteの容量差ごときを気にしなければならないほどメモリの使用状況がシビアなの？

>>155
> int型の多次元配列で　フラグ，攻撃力，命中補正って感じでやりたい

これを見る限りそのような話にはとても見えないが。

> 大学の講師さんが「フラグは1か0でいいわけだから、int型を宣言するより、
> BYTE型で1bitだけ使って後のbitを攻撃力とかに回した方が効率がいい」

また時代錯誤な。象牙の塔の人間にありがちだなm9（^Д^）ﾌﾟｷﾞｬーとか言ってみるテスト。

「効率がいい」って、いったい何がどのように効率がいいのですか。
そうした面倒な工夫をすることで、実際のプログラムは高速になってますか。
また、そもそもメモリを節約する必要はあるのですか。
そうした工夫は、単に汚くて保守困難なバグの多いコードを生み出すだけではありませんか。

その講師に超おすすめのページ↓
http://pitecan.com/articles/Bit/Fugo/fugo.html

効率を云々する前に、まず「そんなこと気にせんでも動くんちゃうの？」と考えよう。
パフォーマンスが出ないなり、実際にメモリ不足で止まるなり、問題が起きてから対処すればよい。

0164デフォルトの名無しさん

2005/12/02(金) 10:54:53

うるせーよ
フラグなら素直にboolean使っとけや

0165デフォルトの名無しさん

2005/12/02(金) 11:46:46

>>155
そもそもビットで管理する事とintとbyteの容量差を混ぜて語ってるのが間違いなんだよね。

さらにいうなら、フラグはビットでいいが攻撃力はビットじゃ足りないだろ。
昔のTRPGみたいにサイコロの範囲内で決着が付くなら問題ないけど、攻撃力300
とか行くなら9bit必要でしょ？byteにどうやっていれるのさ？
よしんばintの32bitで管理したとして、フラグと、攻撃力と、補正値を出し入れするのに
いちいちビット演算する気？ & マスクとビットシフトするくらいなら素直に配列
使った方がマシだと思う。
試しに、32bitにその３つの情報を出し入れするコードを書いてみればいい。

1bitで済む情報だけを、１つのintに複数個入れるならいいけど、数値を扱うなら
ビット演算なんて検討するのは無駄。

0166デフォルトの名無しさん

2005/12/02(金) 11:53:32

FFばりにステを255までにすれば問題ない

0167デフォルトの名無しさん

2005/12/02(金) 11:56:13

>>165
>>155の内容は
「フラグ」の管理の離しだけだと思うのだが？

0168デフォルトの名無しさん

2005/12/02(金) 12:12:16

なぜに荒れてるのか判らんが・・・・>>159の解釈でおおかた間違ってないよ。
ただ最近の携帯ならメモリや速度でんでんより、ビット圧縮解凍処理を入れる事によって
アプリ本体の容量が増えてしまってり、バグ発生時の対処が大変だったり、
仕様変更に耐えれなかったり、面倒な種になることが多いｗ

知識として持っておくには良い事だろうと思うよ。やるかどうかは別で。
プログラマとしてはビット演算によるデータの保持は基本とも言えるし、
知識がないと後から考察しろと言われても出来ないor苦労するわけだし。

余談：
メモリ効率どうこうとは話変わるが携帯でビットでフラグを所持するのは
外部ファイルとして持つ場合有効とも言える。セーブデータなんかも。
が・・・最近は外部JAR（ZIP)解凍が出来るようになったので
下手にビット演算して小さくすると逆効果になったりもするｗｗｗ
ケースバイケースだなｗ

0169デフォルトの名無しさん

2005/12/02(金) 13:23:04

でふぉの攻撃力が離散的な値しかとらず

0 : 0
1 : 20
2 : 50
3 : 100
4 : 200
5 : 300

とかならbit数少なくても問題なし

0170デフォルトの名無しさん

2005/12/02(金) 13:47:05

とりあえず完成させてから悩め

0171デフォルトの名無しさん

2005/12/02(金) 13:58:31

で、定数をfinal intで定義して余計にソースが膨れ上がるとｗ

0172デフォルトの名無しさん

2005/12/02(金) 14:13:36

>>158
メモリ食わないか？という疑問に関しては、JAVAにBYTE型なんて存在しないという返事で一蹴している。
結論的には「メモリ食う量は同じ」だからね。

その上で、より高速なintを薦めた。

0173デフォルトの名無しさん

2005/12/02(金) 14:42:45

配列が前提なら、パケットしてくれた・・・よね？

0174デフォルトの名無しさん

2005/12/02(金) 15:20:58

うるせーよ
素直にバイト配列使っとけや

■ このスレッドは過去ログ倉庫に格納されています