NintendoDS(NDS)非公� ..
547:名前は開発中のものです。
07/12/20 16:30:09 tLTzhhXD
>>542
>先頭だけしか速くないMicroSDの多さにびっくりしました。
その情報を逆手にとって悪魔城をSandisk 2GBの先頭において起動してみました。
位置はFATの直後あたりです。カーネル等よりも前に置きました。
結果。信じられない話ですが、このメモリカードでは絶対フリーズしていたポイントで
まったくフリーズしなくなりました。
高速に動かしたいゲームはフォーマット直後最初にコピーするよう意識することで
かなり快適に使えるようになることがわかりました。
microSD上で位置を自由に設定してファイルをコピーできるソフトがあるといいですね。
昔、ノートンにそんなソフトなかったかな？
548:名前は開発中のものです。
07/12/20 16:51:05 G9sHKr8Z
今思えばAceKardのAKFSがいかに優秀だったかがわかるもんだな。
断片化しないだけでなく、先頭からコピー元ファイルの空き場所を探すから
入れ替えが簡単にできる。書き込み専用ツールで中の状態もはっきりわかるしな。
昔と違って大容量記憶メディアが簡単に手に入るようになったのだから
ファイルシステムも使用効率より動作性能を重視してもらいたいもんだ。
まあMicrosoft社が遅れてるだけで。Mac OS X 10.2以降で使用されているHFS+や
Linuxのext3など参考にすべきだと思うんだが。
せっかくマジコンで採用してもFATにしろ！と潰されるのはAceKard+で実証済み。
Windowsの標準ファイルシステムにならないと受け入れられないだろうよ。
549:Moonlight
07/12/20 17:05:37 21+7rRsc
転記ありがとうございます。感謝です。
す、すいませんー。独り言をぼそぼそと書き散らしただけのつもりだったのですが、わざわざお手数かけてしまって申し訳ない＆感謝の限りです。
(ひとりごと～私はW-ZERO3とマジコンで使う以外のリムーバブルHDDやCF/SD等は全部NTFSで使ってます。NTFSラブ。デジカメとか持ってない)
550:名前は開発中のものです。
07/12/20 17:10:26 EvQ1qSv8
>>594
意外に勉強不足なんですね。
URLﾘﾝｸ(www.atmarkit.co.jp)
あるいはこれがSDの世界では問題ないとかいう理論で俺が恥をかく展開になるのか？ｗｗｗ
551:名前は開発中のものです。
07/12/20 17:23:10 G9sHKr8Z
>>550
俺も単純にNTFSはフラグメントしにくいと理解していた。どうも違うようだな。
マジコンで750バイト以下ってiniファイルくらいしかない罠。
それ以外はどこのクラスタに飛ばされるかわからへんわけやね？
そうなるとNTFSは思ったよりいいファイルシステムじゃないことになるね。
552:名前は開発中のものです。
07/12/20 19:26:52 800P5N4j
なるべく同じクラスタに収めようとするので、
FATよりはよっぽどフラグメント化しないよ。
553:名前は開発中のものです。
07/12/20 20:01:54 UZjuOACo
久しぶりにHDDを分析したら真っ赤だった
554:名前は開発中のものです。
07/12/20 20:52:56 G9sHKr8Z
>>552
同一クラスタを異なるファイルが共有するのかい？
読み取る時にどうやって区別するのかね？
クラスタごとにバイトポインタでも持ってシークするのだと？
負荷高そうなファイルシステムだねｗｗ
555:名前は開発中のものです。
07/12/20 21:08:11 fkgSddbS
ソフトウェア版のデフラグソフトのスレッドでたまに流れる話題だなぁ
556:名前は開発中のものです。
07/12/21 09:43:45 7ouPPK0Y
Check disk for NDS Ver0.3ですけど…
断片ファイルの検索がnds/savファイルになってますが
M3 RealはSaveファイルの拡張子が0,1,2なんですよねー
ずーっと断片化してないと思って安心してたけど
全検索してはじめて断片化に気付いた次第。
気付くのが遅かったらセーブが壊れるところだったかも知れない。
マジコンのトラブルは断片化に端を発しているものが多そうだから。
断片化があった場合、断片化ファイルだけをmicroSDの外へ移動し
USB接続を切ったあと再接続して戻してあげると空き領域に
断片化がない状態でコピーされるみたい。もちろん空き容量が
十分あればの話だけど。
Check disk for NDS Ver0.3は使っているうちにだんだん
手放せなくなってきたすごいツールだよ。
557:BlackMoon
07/12/21 16:38:50 jGmKHxn8
そんな拡張子に0とか2とか数字使うマジコンにわざわざ対応する必要ねーよ。
M3Realの方でツールの仕様にあわせろっつーの。
いちいちそんなのに付き合わされてたら開発者は身がもたねーつーの。
少しはこっちの身にもなってみろって。
558:BlackMoon
07/12/21 19:24:52 7ouPPK0Y
>>557
悪かったねぇ
そのツールが今一番必要としているマジコンで使いにくくなってたから
皮肉なもんだなーって感じたから言っただけだよ。
どの道お前の世話にはならんから安心汁。
559:BlackMoon
07/12/21 23:59:44 WfuwbDfL
外見を極限まで高めて厨房の大量取り込みに成功はしたが
技術力が無いから、M3チームは駄目だな
決め打ちパッチだからサポート放置されたら即死だぞ
560:名前は開発中のものです。
07/12/22 01:49:20 JbsPsov5
じゃあどれならいいんだ？
561:名前は開発中のものです。
07/12/22 13:43:58 Otmx5mfl
Moonlighit氏がCheck disk for NDS Ver0.3をアップデートしましたね。
URLﾘﾝｸ(mdxonlinemirror.dyndns.org)
戯言みたいな書き込みにこんなに真面目に対応してくれる人はなかなかいないよ。
技術者って一般的に視野の狭い人が多くてコミュニケーション能力に乏しい。
だから女性にもなかなかモテない。プログラミングで自分を表現するのは得意なのにね。
生の人間相手より見えないちゃんねらー相手にコミュニケーションをとる方が気は楽かも。
でも強度の煽り耐性がなければやってられないでしょう。本当に大したものです。
ある方はマジコンごとにリセット対応するのが面倒なのでマジコンから吸い出した
Romを直接起動しようと考えました。M3 Realなどの場合はこの方法でうまく行くそうです。
moonshellからndsが起動できなくなってかなり立ちますが、もしndsが起動できていたら
このような手法も使えたかも知れません。もちろん定かではありませんが。
まあ仲良くやってくださいよ。
562:名前は開発中のものです。
07/12/22 18:21:08 RDHqMR1H
んじゃ何万人を指して｢一般的｣というのか教えて
563:名前は開発中のものです。
07/12/22 19:27:35 Otmx5mfl
>>562
明確には提示できないけど、その中にお前が含まれるのは確実。
564:名前は開発中のものです。
07/12/23 01:23:38 aCvi7wW4
2007年12月19日 14:48
メモ。またアクセス規制…うちはOCNなのかなぁ。
後述。Check disk for NDS Ver0.3をアップデートしました。
ページ上部のリンクから辿ってください。
お手数かけますです。
細かい書き込みまで転記して頂いてしまって申し訳ないです。
動作テストなども含め、どなたか存じませんが
私は見ず知らずの人に助けてもらってばかりだなーと思います。（苦笑
checkdiskfornds031.zip
(他にもクリティカルな中身の拡張子があったら教えてください。
なさそうだったらこのままエントリ起こします。)
Version 0.31 2007/12/22
拡張子NDS/SAVに加えて、拡張子0/1/2/3/4/5/6/7/8/9も
断片化チェックをするようにしました。
どうせ過疎スレなのでプログラム関係じゃない話題でも
私は気にしないのですが、けんかしないで…。
565:名前は開発中のものです。
07/12/23 09:43:37 GQn87g8C
ううMoonLight様のRepairMoonShellが
消えていた・・・
もう少し早く気がついていれば。。。
(TДT)
566:名前は開発中のものです。
07/12/23 10:58:47 LaCNw6ob
スロット２起動すればいいんだよ
567:名前は開発中のものです。
07/12/23 13:44:52 vfS66XeO
3Dでタッチした座標にあるポリゴン(トライアングルふたつ)との交差判定をしたいです。
OpenGLでは、gluUnProjectを使って、タッチした座標と向き(マウスレイ)を取得するのですが、
libndsのvideoGLには、これがありません。
代わりになる方法はあるんでしょうか？
568:名前は開発中のものです。
07/12/23 14:32:04 JogT0J4D
>>567
URLﾘﾝｸ(devkitpro.cvs.sourceforge.net)
nds-examples-20071023\Graphics\3D\Misc\Picking\
569:名前は開発中のものです。
07/12/23 16:58:00 9lGG4dEa
wavからrawに変換したものが思ったように再生できません・・・
既に >>93 のサンプルは消えてしまっているようで
もしよければ再度サンプルを置いていただけませんでしょうか？
おねがいします。
570:名前は開発中のものです。
07/12/25 21:45:25 Bx4UTy/Y
>>561
＞一般的に視野の狭い人
その定義は如何に
＞だから女性にもなかなかモテない。
根拠は何処に
571:名前は開発中のものです。
07/12/25 22:26:19 pmHIaQhz
>>561は、
視野が狭くて、コミュニケーション能力も乏しく、
女性にもモテない、しかも技術力も無い
と、言うことが分かりました。
572:名前は開発中のものです。
07/12/25 22:34:52 QxVRW44c
身に覚えのないことならサラッとスルーした方がいいよ。
くだらんレスに粘着してると身に覚えがあるように見えるよ。
女にモテなくてもお袋さんはおまいを愛してる。
コミュニケーション能力がなくても２ちゃんねるなら弁慶にもなれる。
それで十分じゃね？日本の典型的な内向きの技術屋さんたち（爆）
573:名前は開発中のものです。
07/12/25 22:54:42 eieLjBGr
きょうも つりばりが いっぱいだ!
574:名前は開発中のものです。
07/12/28 20:40:16 y/ZeLQkU
Moonlightさんにお作りいただいたCheck disk for NDS Ver0.3、M3Realで使わせてもらってます。
その中で気が付いたことがあるのですが、0バイトのファイルが書き込まれた場合、
ディレクトリエントリとクラスタのサイズが違うというメッセージが出て致命的エラーになるようです。
なぜこれがわかったかというとM3Realのでチートの設定でチート項目を何もチェックせずに
戻るとゲームのIDのファイル名で0バイトのファイルを作るからです。
1バイトでも中にデータがある場合は問題ありません。
また、この0バイトのファイルを削除すると致命的エラーはなくなります。
あとこれは贅沢なのですが、M3RealでGBAのリアルタイムセーブを行うとis0という拡張子のセーブファイルができます。
もし今後マルチセーブが可能になるとis1、is2とかになるのかも知れません。
最近は書き込みをするファイルはすべて要注意と思うようになってきました。
M3Real用に拡張子0～9までセーブファイルと認識していただけたので便乗して対応いただけたらと思いましたが、全ファイルをチェックしても然程時間が掛からない秀逸なソフトですので、全ファイルチェックだけで良いのかも知れませんね。
すべてに対応していたらきりがありませんから。
あと、やはり8GBのmicroSDでライトアクセス時間のベンチマークを取ると再起不能な
状態で壊れてしまうものなのでしょうか？恐いので試してませんがもし可能性がある程度の
事でしたら自己責任でチャレンジしてみたいと思います。
575:Moonlight
07/12/28 21:31:12 r6XOZjDh
>>574
テストありがとうございます。IS0～IS9を追加したVer0.32をアップしました。
NDS（いわゆるgba_nds_fat）で作った0byteファイルと、Windowsで作った0byteファイルの挙動が違うなんてブービートラップですー（笑
NDSに限らずWindowsでも書き込みは危ないです。たとえば、ユーザが暇してる（画面見てるとかの）空き時間を使ってセーブしようとすると、セーブしている瞬間に電源切られたり、カードを抜かれたりします。ライトバックキャッシュは危険よねって話。
で、それはそれとして、SDHC対応は私が自信を持って大丈夫と確信していない（SDHCの仕様書を入手していない）ので未確定です。
いまのところ本気でフォーマット不能なまでに壊れたという報告は頂いていませんが、いまのところは、ってだけかもしれないので。（チキン（笑
576:名前は開発中のものです。
07/12/28 21:48:28 naoJX6xE
>>574
>>561さんこんばんは
577:名前は開発中のものです。
07/12/29 04:38:58 Z96Jd6yV
>>574
本当にエラーなのかも。
一応、PCでスキャンディスクかけてみて確かめるといい。
サイズが0バイトなのに、1クラスタ割り当てちゃってるとか。
もしもそうだとすると、ファイルシステム(libfat)の不具合ということになるね。
あと、マジコンユーザーにはメディアの消耗を気にしてデフラグしない人が多い。
それを考えると、ライトアクセスのベンチマークやる人は勇者です。
デフラグよりもっと消耗激しいかも。もちろん、ベンチマークの内容によるけどね。
578:名前は開発中のものです。
07/12/29 09:47:35 PDHcBllJ
Moonlightさん、早速のご対応いただきましてありがとうございました。
当該エラーは無事キャンセルされ致命的エラーを回避できました。
実はこの0バイトファイルができる過程でM3Real側に動作上のバグがあるようで
一度何かのチート項目を設定して戻ると、次回チート項目を全クリアできない。
即ち、最低一項目のチート項目を選択しなければ状態が保存されないようになっています。
つまり０バイトのファイルは作れないように意図されている感じです。
再度チートファイルを選択し直すとすべてのチート項目がクリアされた状態になります。
ところがこの状態からチート設定画面に行き何もしないで戻ってくると０バイト
ファイルができているという始末です。非常にバグ臭い感じがしています。
>>577
FATにエントリされている以上、他のファイル操作の際には使用されることもないので
問題はないと思います。そのエントリは0バイトファイルを削除すると消えますし。
もし消えていなければCheck disk for NDSでひっかかっているはずです。
実害はないと思いますよ。
書き込みのベンチマークはそれほど多くの場所に書き込みしているようでは
ありませんし8GBは恐いのでやっていませんでしたが、2GBまでのmicroSDでは
いくつか試してみました。テスト中に電源を切ったりしなければ大丈夫でしょう。
おそらく8GBの結果は6GBとあまり変わらないと思います。リードでのベンチを
やった結果では6GBとほとんど同じでした。
しかしM3RealのDLDIドライバの性能はすごいですね。他のマジコンでのベンチ
テスト結果が哀れに思います。DSTTに唯一負けてない領域でしょうか。
579:Moonlight
07/12/29 20:25:14 pw4v1uVO
>>578
どういたしましてですー。
0byteファイルの作り方については微妙なところですが、FATはMicroSoftが作ったのでDOS/Windowsの挙動が正しいんだと思います。
（あれ？MicroSoftが作ったのはLFNだけでしたっけ？）
といっても、重複するわけでもないですし、削除すればエントリとクラスタリンクはちゃんと消えるので、512byteくらいなら余分に使ったところで問題は無いと思います。
チート設定で云々はとてもバグっぽいですが、あまり致命的じゃなさそうなので直さないかもですね。
>DSTTに唯一負けてない領域でしょうか。
とか書くから煽りだと思われるんじゃないかなーと余計なことを心配してみたり。（苦笑
実際、ハードのポテンシャルは高くてもその性能を生かせているとはいえないと思う…けど私には関係ないからどうでもいいやー。（ゲームとか興味ないので…（酷い（苦笑
ライトベンチマークでは、128kbyte読み込んで32kbyte書き込んで1024kbyte書き込んで128kbyte書き込む処理を8回しますので、合計10MByte分くらいアクセスします。
MP3ファイル３つ分くらいなのでそんなに負担にはならないと思いますが、計測中に電源切られるととても困るのでめいっぱい脅してます。（笑
580:名前は開発中のものです。
07/12/30 00:56:55 5BJqZ1d6
wavからrawに変換したものがどうしても雑音がかったものになってしまいます。
Moonlightさん、申し訳ないのですが >>93 のサンプルを再度アップしていただけませんでしょうか？
よろしくおねがいいたします。
581:名前は開発中のものです。
07/12/30 02:29:09 /ePZFksH
エイリアスノイズが載ってるんだと思うので
変換後のサンプリング周波数*0.5以上の周波数を
事前にフィルタしておくと良いかも
582:ｔｍ
07/12/30 16:20:27 MsSLbwJq
遅ばせながら
file_2.bmpとfolder.bmpがこんなに問題になってたとは……
もうしわけないです
583:名前は開発中のものです。
07/12/31 01:13:00 rN7PTsQ5
まだやってんのかと言われそうだけど、TTAの再生できました。
>>93で、SOUND_ONE_SHOTが使われていることに気づいてMorningTimerのソースを見直してみました。
ダブルバッファリングのためにふたつのチャンネルを交互に鳴らしてるんですね。
SOUND_REPEATで鳴らしっぱなしにしてバッファの前半と後半を交互に書き換えればいいと思ってました。
# 実際に無圧縮の*.wavは、それでもノイズ無しで鳴っていたので
Moonshellさんありがとう。
そんなチラシ裏
584:名前は開発中のものです。
07/12/31 01:26:20 M5kyCS2V
はじめまして。
devkitProのexampleにある2D/BG_Rotationを変更しながら試行錯誤して
いるのですが、bmp2binを使って変換した画像ファイルを表示させようとすると
画像の下1/3くらいが真っ黒になって切れて表示されてしまいます。
元画像 foo.bmp 256x192 24bits (filesize: 144KB)
これをbmp2binの-dオプションをつけ、16bitsのbin形式に変換
変換後 foo.bin 16bits (filesize: 96KB)
以下ソースの一部です
videoSetMode(MODE_5_2D | DISPLAY_BG3_ACTIVE);
vramSetMainBanks( VRAM_A_MAIN_BG_0x06000000, VRAM_B_LCD,
VRAM_C_SUB_BG , VRAM_D_LCD);
BG3_CR = BG_BMP16_256x256;
BG3_XDX = 1 << 8;
BG3_XDY = 0;
BG3_YDX = 0;
BG3_YDY = 1 << 8;
//BG3_CX = 0;
//BG3_CY = 32 << 8;
dmaCopy(foo_bin, BG_GFX, 256*256);
BG3_XDXのあたりかなあと思い、値を変えてみたものの、
画像が引き伸ばされた感じになっただけでした・・
585:名前は開発中のものです。
07/12/31 01:52:33 rN7PTsQ5
>>584
libnds-20071023使ってるけど、BG_BMP16_256x256の値がこうなってました。
---
#define BG_BMP16_256x256 (BG_RS_32x32 | BG_256_COLOR | BIT(2))
---
BG_256_COLORが入ってます。
あと、16ビットカラーだったら、dmaCopyの3番目の引数は256x256x2になると思います。
586:584
07/12/31 01:54:38 M5kyCS2V
いちおう解決しました。
dmaCopy(foo_bin, BG_GFX, 512*256);
dmaCopyの3番目の引数はファイルサイズでしたorz
BG3_CR = BG_BMP16_256x256;
こっちの256x256は画像の解像度ということでよいのでしょうか？
また、画像を利用するに当たりbmpをbinにするのと、
png+gritを変換する方法がありますが、これに何か違いってありますか？
587:584
07/12/31 02:03:40 M5kyCS2V
>>585さん
すいません。上書き込んでるときにレスがあったみたいで
一部コメントの内容が重複してしまいました。
>256*256*2の部分、わかりました。ありがとうございますm(_ _)m
ところで、
>BG_256_COLORが入ってます。
はどういった意味があるんでしょうか？
#define BG_256_COLOR (bit(7))
となってますが、(BG_RS_32x32 | BG_256_COLOR | BIT(2)) が
16bitsの解像度が256x256の画像を使う宣言みたいなものと
覚えておけばよいでしょうか？
588:584
07/12/31 02:07:44 M5kyCS2V
すいません、ファイルサイズじゃなくて解像度256x256に1ドットあたり
2バイトなのでさらにx2したから256*256*2ですね
589:Moonlight
07/12/31 04:45:20 GrGVceoQ
>>580
sndtest.zipを再アップしました。
あ、これは例えば符号付き8bitリニアPCMと符号無し8bitリニアPCMを間違えてる人には役に立つかもしれませんが、エイリアスノイズ対策には役に立ちません。
符号あり/なしを間違えたときは音にならないくらいノイズが乗りますが、エイリアスノイズならチリチリとノイズが乗るって感じだと思います。
リアルタイムには（CPUパワー的に）フィルタかけられないので、事前にフィルタかけるか線形補間で誤魔化すかだと思います。
線形補間でエイリアスノイズを誤魔化すならMorningTimerのARM9のdllsound.cppのDLLSound_Update関数が…役に立たなそう。（笑
>>582
実は自分でテストしてないので実感がありません。
CheckDiskでは怖いので厳重にエラー検査しますが、実際はそんなに問題じゃないんじゃないかなーとか適当なこと書いてみたり。（不遜ですね（苦笑
>>583
strpcm.cppを書いた頃は、44.1kHzからの周波数変換をNDSのサウンドチップに任せていたので、クロックズレが発生していたのですが、32768Hzで直接再生できるようになったんだからもしかしたら今ならSOUND_REPEATでもいけるのかもです。
周波数にもよりますがクロックズレが原因の微少なプチノイズは50秒に一回くらい発生していると思います。
で、SOUND_REPEATだと発生したら（リピート間隔毎に）ずっと発生し続けますが、SOUND_ONE_SHOTなら次のズレが発生するまでノイズが乗りません。なのでSOUND_ONE_SHOTを使いました。
（1サンプル以下の累積誤差補正コードを自前で書くなら大丈夫だと思いますがめんどくさくてやってられなーい。（笑））
なにはともあれ、ソースが役に立ったみたいで本当に嬉しいです。
590:Moonlight
07/12/31 04:45:55 GrGVceoQ
>>587
私もあまり詳しくはないのですが、BG設定は同じビットでも他のビットの設定によって意味が変わってくることがありました。
GBAからむりやり拡張したって感じがします。
8bitカラーモードのときと15bitカラーモードのときでは、同じビットでも意味が違うという感じで。（BGサイズと拡張パレットの設定ビットとかめちゃくちゃだと思うんですけどどうなんでしょうか（苦笑
ちなみに、例えばビットマップBGに256x256画像を読み込んでも実際には256x192分しか見えませんが、縦オフセットを徐々に変えると手軽にスクロール効果を表現できたりします。ランダムに細かく変えると地震っぽいとか。
チラ裏というか余談失礼しましたです。
591:583
07/12/31 17:46:55 rN7PTsQ5
TTAに続いてoggに挑戦。
libogg+libvorbisが重い。
↓
tremorのことを思い出す。早速導入。
↓
再生の始めが早送りに聞こえる。後に期待した音が流れる。
↓
日暮れ。←いまここ
↓
そば食べる。
今まで、ぶちぶち言ってたのに困ってたんですが、今度は逆に早送り･･･。
誰か他にogg(tremor)いじってませんか？
592:Moonlight
07/12/31 23:51:45 kzjZELj8
>>591
もしかしたらソース見せてもらえたら横槍入れられるかもと思ってみたり…
593:583
08/01/01 10:45:53 NNk1mtua
>>592
URLﾘﾝｸ(www.uploda.org)
遅くなりました。よろしくお願いします。
594:名前は開発中のものです。
08/01/01 15:24:49 T3NYT7jt
あけましておめでとう。みなさん今年もよろしく！
DSのプログラムを初めて思ったのは、面白いことをするためには
どうしてもハードウェアの制作が必要になるんだな、ということです。
例えばGPSとかカメラとか、そういったのをDSに付けたくなってしまう。
俺はずっとソフトウェアしかやってこなかったので、
初心者の気分でハードウェアの勉強をしてみようかと思うんだけど
そういうときに最初に行くべきスレッドってどこでしょう？
今年、DSの自作プログラムの幅が広がれば嬉しいな
595:名前は開発中のものです。
08/01/01 21:24:21 +s8QW2Sx
電気・電子板のARMスレが良いんじゃなかろうか
ｽﾚﾘﾝｸ(denki板)
596:名前は開発中のものです。
08/01/01 22:38:14 Rbh21JyU
何かつけたいならCPLD覚えた方がいいんじゃなかろうか
597:Moonlight
08/01/01 23:06:37 Ftb+OQMO
>>593
割り込み内で直接デコードしちゃうのは危険ですー。
っていうほど危険じゃないのかも…。私が調べたときは、割り込み時にユーザスタックに切り替えてくれない割り込みハンドラだったので、スタックが極端に少なかったです。（今は大丈夫なのかも…）
とりあえずデコードはできているみたいなので大丈夫と仮定して次に。
16384Hzモノラル16bitの4096サンプル単位で再生しているようにみえました。
4096サンプルの演奏時間は0.25秒ですが、負荷計測してみたところ最初の4096サンプルのデコードが重くて処理落ちしているんじゃないかと思いました。
最初の4096サンプルのデコード（while(reedNeed>0)ループの所用時間）が209.268msで、次が22.791ms、37.251ms、22.740ms、37.393ms、という感じでした。
最初のフレームでも40ms残っているので間に合っているような気もしますが、とりあえず重いのは確かなのでリングバッファで8フレームくらい先読みすると（例えば今後他に重い処理を入れても平気になって）いいんじゃないかと思いました。
ov_read関数呼び出しの直後に
>volatile int i; for(i=0;i<0x10000;i++);
とか入れて、故意に重くしてみたときの音飛びと似ているように聞こえました。
最初の1フレームだけ極端に重いので、リングバッファじゃなくダブルバッファだけでも入れてみて様子を見たり…。（対処療法的なので誉められた対応ではないのですがテストで（笑））
598:名前は開発中のものです。
08/01/01 23:19:13 6ptbDBuA
あけおめです。
>>594
DSの場合、Wi-Fiが使えるので無線経由でPCに接続したカメラや
GPSの情報取得してもおもしろいかもね
599:593
08/01/02 00:19:35 xkC7Ea9V
>>597
添削ありがとうございます。
再生データの形式を書き忘れていたのですが、16384Hz/モノラル/16ビットで正解です。
割り込みと処理落ちというキーワードから見直しをしてみました。
FIFOハンドラのループで複数のコマンドがキューに乗ったときに連続して処理して、
間髪入れずに鳴らすコマンドを投げてしまいます(と、指差ししながら脳内検証)。
デコードの処理をハンドラから出してみたところ、現象は収まりました。
ただ、初回デコードが時間がかかってる感じが少しします。
対策として、
ダミーのデコード(鳴らさない)
↓
ov_*_seek系のAPIで先頭シークに戻す
↓
改めて再生
ってなことをしようと思ったんですが、ov_pcm_seek( &vf, 0 )が効いてる気がしない様子。
あしたもがんばるぞorz
600:名前は開発中のものです。
08/01/02 08:06:49 tTTSdt9O
みなさんいろいろとありがとう。
実は加古英児さんのサイトを見ていて触発されたんです。
URLﾘﾝｸ(www.kako.com)
このページを見て、小学生のころ電子工作（とは名ばかりのはんだ付けキット）を
やっていた記憶が鮮やかによみがえり、本格的にやりたくなりました。
だからARM系やCPLDだけじゃなくて、1から回路を作って楽しみたいんです。
そういうときの入門スレってどこだろう？？
（それはそれとしてWi-Fiは面白そう、ありがとう！）
601:名前は開発中のものです。
08/01/02 09:51:15 6mZ1FxBS
このスレの住人は、向上心があっていいなｗ
602:593
08/01/02 11:10:58 xkC7Ea9V
>>599の自己レスです。
libtremorのCFLAGSがおかしかった模様。
誤: $(INCLUDE) -DARM9 -DBYTE_ORDER=LITTLE_ENDIAN
正: $(INCLUDE) -DARM9 -DLITTLE_ENDIAN -DBYTE_ORDER=LITTLE_ENDIAN
正の状態でビルドしたライブラリをリンクしたら、ov_*_seek系APIが通るようになりました。
ov_*_seekが使えないと、ov_*_totalも使えないのでいろいろ困ってました。
oggはBGM途中でのリピートもできるので重宝できるはず。
てことで正月半分オワタorz
603:Moonlight
08/01/02 14:11:11 Af6IKbG3
支離滅裂な横槍失礼。
>>602
なんかスタック壊れてておかしいなーと思っていたら、シークのコールバック関数の引数が32bitだったみたいです。
extern int ovs_seek( void *datasource, size_t offset, int whence );
じゃなくて、
extern int ovs_seek( void *datasource, ogg_int64_t offset, int whence );
だと思います…こういうのはエラーが出ないのかなぁ。
ここを修正すれば動くかなーと思っていたのですが、まだなにかおかしくて原因探索…していました。
御自分で修正してシークできるようになっていたんですね。おめでとです。参考までにどこらへんを直したのか教えてくださいです。
ところで、ovstream.cのovs_seek関数、pStream->srcseekの値がころころ変わったり、呼び出されるたびに0になっていたりしていませんでしたか？
もう直っているとのことなので蛇足なのですがあっ64bitメモリから32bit変数をLittleEndianで読み込んだときにSigned/Unsigned不整合で0xffffffffと0x00000000が…。
独り言で長文書き込んですいませんです。ではまた。
604:593
08/01/02 15:49:48 xkC7Ea9V
>>603
時系列に書いていきます。
まず、>>602のCFLAGS(誤)でlibtremorを作ります。
union magicはLITTLE_ENDIAN側を無条件に使用するようにします。
このライブラリで>>599まで進みます。
次に、ovs_seekのoffsetの問題を直します。
ソースを追跡していて、size_t型で受け取ると値がおかしくなりました。
これが原因でseekableが許可されませんでした。
ogg_int64_t型にすると正しい値になりました。
すると今度はvorvisfile.cの_get_next_page関数のループで抜けません。
ここで、lowmem_branchがあることを知ります。
lowmem_branchをビルドする際に、CFLAGS(正)で通すことできました。
これを通常ブランチに適用して、自分のプログラムに組み込みました。
その結果が>>602です。
64ビット値がスタックに乗ると、どうなるんだっけ？とうっすら考えたんですが、
明確な答えを見つけられなかったんですよね。
結論、ovs_seek直しましたorz
605:名前は開発中のものです。
08/01/02 15:57:05 6ig8IlcH
NDS開発云々の前に凡ミスが多くね
606:名前は開発中のものです。
08/01/02 16:28:43 3kcyZQN4
なれない環境なんてそんなもんだよ
607:Moonlight
08/01/02 23:30:28 w4bCClKX
>>604
あーフラグの偽でしたか。私もoggライブラリ移植するときに引っかかりました。charのsigned/unsignedとか。
misc.hを直接書き換えて、LittleEndianしか通らないようにしました。（手抜き（笑
私はlowmem_branchをマージしたのですがtrunkしかないしメモリリークバグもあるしであまり好きじゃないです。
ovs_seekを直す。結局それが一番近道だと思います。（笑
わざわざ開発状況の報告をさせてしまってどうもでした。またなにか躓いたら（役に立てるかは別としてっ！（笑））訊いてくださいね。でわでは。
608:名前は開発中のものです。
08/01/05 00:43:36 /+yjt+NH
pngを読み込んでspriteで表示する簡易なサンプルとかありませんでしょうか。
めらまん氏のwikiは見たのですが何をやっているのか理解できず。
サンプルのspritebitmapを弄ってますがどうにも･･･
609:名前は開発中のものです。
08/01/05 00:50:22 9PNTe7K3
pngじゃ無いとダメなの？
610:608
08/01/05 00:58:17 /+yjt+NH
>>609
Tileでpng使ってたもので、そのまま使えるかなとか思っておりましたが
spriteってやっぱりbmpでやるものなんでしょうか？
611:608
08/01/05 01:26:12 9PNTe7K3
>>609
自分はbmpをCソースに書き出して使ってるのでどっちでもいいと思ってる。
pngは展開しないといけないので、特に理由が無い限り使わないです。面倒だし。
612:名前は開発中のものです。
08/01/05 11:34:13 c8GGWOxF
>>611=609
お前の番号ずれてないか
613:Moonlight
08/01/05 20:15:53 j7N7Qhly
>>608
もし私なら、
・画像ファイルからbinに変換した画像の扱いに慣れるまでビットマップでいじくってみる。スプライトのことはとりあえず忘れる。
・DLDIドライバを組み込んで、半角英数10行くらいのテキストファイルを表示してみる。
・色深度固定（例えば24bitとか）のbmpファイルをディスクから読み込んで、15bitに自前で変換して表示してみる。
・色深度自由な汎用bmpライブラリを組んでみる。
・libpngを組み込んで、色深度固定のpngファイルを読み込んで、15bitビットマップに変換して表示してみる。
・色深度自由な（アルファチャネルとかを含む）pngライブラリを組むかどうかはやる気と気分次第。
・この頃になるとビットマップの扱いに充分慣れていると思うので、スプライトで表示してみる。8bitパレットを扱うかはやる気次第。
という感じで、進んでいくと思います。あくまで、私ならですが参考になれば幸いです。
614:あ
08/01/08 20:56:16 m4lL5SxZ
>>1～1000
おｋ
615:名前は開発中のものです。
08/01/11 16:48:48 IDnFxZnm
背景画像の上にフォントを表示させる場合、
フォントの一部の色を透過させて背景画像が見えるようにしたいのですが
フォントの描画はスプライトで行うのが一般的でしょうか？
616:名前は開発中のものです。
08/01/11 17:00:08 lysu1ST4
Check disk for NDS EWIN2でタッチパネルが動作しません。(T_T)
対応していただけないでしょうか・・・
617:Moonlight
08/01/11 18:37:48 858Jtf0V
>>615
もちろんスプライトでもできますが、背景BGと文字BGを重ねるほうが楽だと思います。日本語フォントを扱うならスプライトでどうこうできる量ではないので。
色を透過させるだけならこれでできますが、影を半透明でとかアンチエイリアスフォントだとかになったら、ビットマップモードしかないと思います。
最近わたしはもうめんどくさいので、ビットマップモード＆自前合成ばっかりです。（Windowsと似た感覚で扱えるので）
>>616
EWIN2は…。ごめんなさい、古すぎてもういいやって感じがしています。（不遜でごめんなさいです。
特にこの機能だけ使いたいからメニューでAボタン押したらこれ、Bボタンはこれにしてほしい、というくらいなら対応できます。
618:名前は開発中のものです。
08/01/11 20:34:41 gV4ausxY
>>617
616です。
EWIN2の対応は諦めました。
カーソルキーで移動、Aボタンで選択というのは無理でしょうか？
R4でもそれなら、もう少し使い易くなると思います。
619:名前は開発中のものです。
08/01/11 22:43:18 gV4ausxY
ありゃ、表現が変ですね。
カーソルキーで移動・選択、Aボタンで実行です。
よろしくお願いします。m(__)m
620:615
08/01/14 14:36:28 gI9YVpPo
>>617
ありがとうございます。
とりあえずBGを2枚重ねて処理する方法を試してみます。
621:615
08/01/15 21:21:10 lG1M2LiD
背景をBG2にして、その上に表示させたいものをBG3に設定したつもりなのですが、やり方が間違ってるようで
BG3に書き込んだキャラクタの座標や、透過設定した色が反映されませんでした。
drawBackgroundは256*192のすべてに緑で塗りつぶしており、drawCharacterは16*16のビットマップデータを書き込んでいます。
キャラクタデータの背景は15ビット目を0にしているので透過させているつもりなので、緑色が表示されてほしかったのですが、黒色が表示されている
状態です。
BG_BMP_BASE()とBG_BMP_RAMの対応が間違っているんでしょうか？
------------
videoSetMode( MODE_5_2D | DISPLAY_BG2_ACTIVE | DISPLAY_BG3_ACTIVE );
vramSetBankA( VRAM_A_MAIN_BG_0x06000000 );
BG2_CR = BG_BMP16_256x256 | BG_BMP_BASE(0) | BG_PRIORITY(0);
BG2_YDX = 0;
BG2_XDX = 1 << 8;
BG2_XDY = 0;
BG2_YDY = 1 << 8;
BG2_CX = 0;
BG2_CY = 0;
BG3_CR = BG_BMP16_256x256 | BG_BMP_BASE(64) | BG_PRIORITY(1);
BG3_YDX = 0;
BG3_XDX = 1 << 8;
BG3_XDY = 0;
BG3_YDY = 1 << 8;
BG3_CX = 0;
BG3_CY = 0;
drawBackground( (u16*)BG_BMP_RAM(0) );
drawCharacter( (u16*)BG_BMP_RAM(1) );
622:615
08/01/15 22:24:27 lG1M2LiD
memcpyで描画していた部分を修正して1ドットずつ描きこんだらうまくいきました。
ただ、BG_BMP_BASE(n)とBG_BMP_RAM(n)の意味でよくわからないところがあります。
定義では
#define BG_BMP_BASE(base) ((base) << 8)
#define BG_BMP_RAM(base) (((base)*0x4000) + 0x06000000)
となっているのですが、BG_BMP_BASEは0x06000000を基準に(base)<<8した位置を
BGxで使用する、という意味なのでしょうか？
そうなると、BG_BMP_BASE(n)のnと、BG_BMP_RAM(n)のnを同じにするのではなく、
上記の定義からアドレスを計算して、二つのアドレスが一致するように設定すれば
よいということでしょうか？
今は同じnを使用してうまくいっているのですが、アドレスをあわせようと、
BG_BMP_BASE(64) = 64<<8 = 0x4000, BG_BMP_RAM(1) = 1*0x4000+0x06000000
にしたのですが、こうすると逆に背景が少し下にずれて描画されてしまいました。
623:615
08/01/15 22:31:45 lG1M2LiD
スレ汚しすいません・・・
baseは0..31あって、1が0x0600 4000に対応して、
以降そのまま番号ごとに対応しているのですね。
NDS/Tutorialsをもっと読んできます・・
624:Moonlight
08/01/15 23:29:54 r+7lzlIg
>>620
えーっと、よくわかりませんが16bit単位で書き込んだときにBG2/BG3両方に普通の画像を表示できましたか？
前景（人物とか）をBG2、背景をBG3に描いたとのことですが、コードを見ると優先順位の設定が逆のように見えました。
優先順位は0が最も前で、3が一番下です。よくあるADVに適当に割り当てると、BG_PRIORITY(3)に背景、BG_PRIORITY(2)に人物レイヤー、BG_PRIORITY(1)にテキストフレーム、BG_PRIORITY(0)にテキスト、という感じとか。ニュアンスが伝わればいいのですが。
ちなみに、同じBG_PRIORITY(n)のときは、BGよりもOBJ（スプライト）が前に来ます。
BG二枚両方に同じBG_PRIORITY(n)を設定したときの挙動は分かりません。BG0が前に来そうな気がします。
BASEとRAMの設定値の関係は、お察しの通りで合ってます。BG設定レジスタのBIT8～BIT12がアドレス指定フラグです。
256x192x16bitで96kbyte使うので、二枚使うときは背景がbase0(0～5)で、人物がbase6(6～11)、という風に割り当てる感じになると思います。
ちなみに二枚使うと192kbyteになるので、128kbyteバンクを二枚使うようにBank割り当てを変えたほうがって蛇足過ぎですね私。
ビデオ周りはほんとめんどくさくてわかりづらいのですが、めげずに頑張ってくださいませ。それでは。
625:Moonlight
08/01/15 23:36:50 LHI5s0tv
>>624
ごめんなさい書き間違えました。
>前景（人物とか）をBG2、背景をBG3に
を修正、
>背景をBG2、前景（人物とか）をBG3に
ですね。
で、ソースだとBG2の優先度が0でBG3が1なので、BG2を1でBG3を0にすると重ねる順番が直るかも直らないかも私が数字を勘違いしてるかも。
一度動いたらもうBG/OBJ周りは手を加えたくない…（苦笑
626:Moonlight
08/01/15 23:53:22 h1DkvG7e
私も質問したいです。
ARMアセンブラで、RNでエイリアスしたレジスタを解除するにはどうしたらいいでしょうか。
気持ちとしてはこんな風に書きたいです。
REG_tmp RN r1
ldr REG_tmp,[sp]
add REG_tmp,#1
str REG_tmp,[sp]
REG_tmp UNRN (とかundefRNとか…)
別にエイリアスしたままでも（プログラム的には）問題ないのですが、他のことに使ってるときに間違って使ってしまいそうなので解除したいです。
r15に再割り当てできれば、間違えて使う＝即異常動作なのでわかりやすいのですが、もう宣言されてるよばかーと言われてしまいました。
627:名前は開発中のものです。
08/01/16 07:04:48 zWJR+3di
>>622
memcpyは1バイトずつコピーするから奇数バイトのコピーでこけるんじゃないかな
自作の4バイトメモコピー関数作ればどう
int* p1 = (int*)src;
int* p2 = (int*)dst;
len>>=2;
for (i = 0; i < len; i++)
{
*p2++ = *p1++;
}
628:名前は開発中のものです。
08/01/16 11:06:38 zxUoql5e
>>626
確かに必要ないところでは使えなくしたいところですね
で、マニュアルのRNの項目を見てみたんですが、
「違う名前で同じレジスタを重複して使わないように注意してね」って書いてあるだけですね
これといって、RNの逆をしてくれる疑似命令はなさそうです
使いたくなければ、別ファイルに分けろってことでしょうかねぇ
629:615
08/01/16 16:18:34 Rxj1FtFA
>>624, 627
ありがとうございます。ビデオまわりの部分は検索しても情報が少なく
これまで馴染みがなかった概念があり手探り状態です。
ちょっとした情報でも大変参考になります。
630:615
08/01/17 01:37:04 Z+jfE4TA
実はセックスフレンドのコンバーターを作ってるのですが
なかなか上手く行かないものですね。
631:名前は開発中のものです。
08/01/17 19:42:19 CSwrgLBR
>>630
2点
632:Moonlight
08/01/17 21:47:28 daPJ8MZf
>>628
わざわざ調べてくださってありがとうございます。
注意してね、って書いてあって（危険性を認識していて）なおかつ対処法が書いてないということは、本当に無いんでしょうね。
同じレジスタを交差しながら使いまわして最適化しているので、簡単にはブロックごとに別ファイルにできなさそうです。
MACROだけだと不十分なので、プリプロセッサで#includeと#defineを使って、とも思ったのですが、コンパイル中に別のexe起動させるのもなんか面倒くさそうでやめました。
むー。全体的にほとんど十分なのですが、痒いところに手が届かない感じ…（苦笑
633:名前は開発中のものです。
08/01/18 21:10:46 uKjx+lCO
>>632
チェックプログラムを作って、それに通してチェックさせるしかないんじゃないでしょうかね。
DOSアプリでチェックプログラムを作ってみました。
UNRN xxxと書いた所から先に、xxxが見つかったら行番号と名前を表示します。
（UNRNは実際にはない命令なので、先頭に;を付けてコメントとしてください）
テストソースtest.sを同梱したので、通してみたら分かると思います。
まあ、面倒ですがｗ
URLﾘﾝｸ(ud.gs)
ちなみに、#defineはEQUのことでしょうか。レジスタにEQUは使えないんですよね。
REG_tmp EQU r1
とすると、見事にエラーになりました。
634:名前は開発中のものです。
08/01/19 15:00:00 lwFGyVi0
画像をテクスチャにするdevkitproの3Dのサンプルにあるような
pcxファイルはどのようにして変換すればいいですか？
635:名前は開発中のものです。
08/01/19 15:14:31 9w9pPM+Z
変換出来ませんか？
636:名前は開発中のものです。
08/01/19 15:34:28 lwFGyVi0
drunkenlogo.pcxをdrunkenlogo.pcx.oとdrunkenlogo_pcx.hに変換しているようで
そこで何を使っているのかがわかりません。
637:名前は開発中のものです。
08/01/19 16:13:09 PbX5b0Di
makefileを見たところbin2oをそのまま使ってますね
638:名前は開発中のものです。
08/01/19 18:21:37 Edl9lJvc
かみ合わなさすぎ笑った
けど俺は635と637を支持する
639:名前は開発中のものです。
08/01/20 05:31:33 Tm5/geYl
いやかみ合ってるでしょ？
ちゃんと636の意図を汲んで回答したつもりですよ
640:名前は開発中のものです。
08/01/21 06:25:28 V51tZRX6
>>639
氏ねよ低脳＾＾
641:名前は開発中のものです。
08/01/21 06:45:03 RQWaaLj1
Cloros!を使ってみて思ったんだけど、液晶タブレット化ソフトって作れないかな
液タブって一番安いのでも10万近くするし、実現できたら入門用としていいなと
642:名前は開発中のものです。
08/01/21 16:11:40 jSedK63m
ＧＢＡをＰＣにＵＳＢで繋いでジョイスティックにするドライバが
あったけど、ＰＣ側のドライバを作れれば、できそうな気はするが。
643:名前は開発中のものです。
08/01/21 19:46:01 DnoBdQO+
解像度がなぁ・・・
644:名前は開発中のものです。
08/01/21 21:01:50 O1DPMOZH
>>641
液タブじゃなくてタッチパネル液晶なら3万ぐらいからあるよ
違いはペン交換負荷、筆圧感知なし
もうちょい安くするなら、安いPDAって選択肢もあり？
QVGAならDSと同じぐらいの値段だし
645:名前は開発中のものです。
08/01/21 21:36:18 4X6pNulX
NDScripterってどこかにうｐしてないですか？
再うｐお願いしたいです。
646:名前は開発中のものです。
08/01/21 21:37:58 o5qLQIe2
>>645
探し方がほんの少し足りないんじゃないかな？
647:名前は開発中のものです。
08/01/21 23:19:03 ZIx41Zvj
探し方が足りないと言うより、脳みそが足りないと言った方が（ｒｙ
648:名前は開発中のものです。
08/01/22 00:11:48 UXR2naSd
ちょっと質問なんですが、ＢＧ１は1６色パレット、ＢＧ２は２５６色パレット、ＢＧ３は１６色パレット・・・
って感じに使う事は可能なんでしょうか？
649:名前は開発中のものです。
08/01/22 01:09:41 UKSk6OUY
コンパイルしたプログラムをmicroSDに書き込んでマジコンに入れて
実機で動かすまでの差し替えが面倒になってきたので、1:1タイプの
N-Cardを買いました。
で、プログラムを書き込んでみたのですが、音が出ません。
手持ちのソフトのイメージではきちんと音が出るのですが。
自作プログラムとROMイメージは同じ物ではないのでしょうか？
650:名前は開発中のものです。
08/01/22 01:58:57 PNF0vUM/
俺エスパーじゃないからスルーするー
651:名前は開発中のものです。
08/01/22 02:28:24 UKSk6OUY
>>650
やっぱスルーされますかorz
とりあえず自作プログラムがマジコンごとに動きが違うことって
いうのが起きうるのか。
また、違いがあるのであれば、おかしい方は一律おかしい結果で
あれば納得できるのですがROMイメージはおかしくないので、
情報をお持ちのエスパーがいれば、と思ったのですが･･･。
他にもサンプルを動かしてみました。
examples/nds/Graphics/3D/Misc/Picking ... タッチパネルでPickできない
examples/nds/sound/SimpleSound ... 音(ry フリーズしてる模様
652:名前は開発中のものです。
08/01/22 02:47:26 QDQndHhu
>>649
他のマジコンでは音は出るの？
あと、エミュで動かしたらどうなる？
エスパーな俺に言わせれば、単なるバグだと思うけど。
653:名前は開発中のものです。
08/01/22 04:46:34 FTu8bsB4
たとえば仕様だと0で初期化されるような部分があったとして
そのマジコンがROM起動前に勝手に違う値で初期化してたら場合によっては他とは違う動作するよな
違うってことはあるんじゃないか？・・・というかあるだろ
他のマジコンあるなら試してみるのがいいだろな
動いた場合どっちのマジコンがおかしいのか調べるの大変そうだけど
654:651
08/01/22 08:52:26 UKSk6OUY
>>652
今までEZ5使ってました。期待通りの動きをします。
エミュは、desmumeを使ってます。
音は出ない代わりにフリーズしません。
IPCを経由してARM7側で代入した値をARM9側で
表示するプログラムをおこしてみました。
ARM7側で指定した値になってない。
ARM7側が止まる/動いてないみたいな状態になってると憶測。
これが原因であれば、音も出ないしタッチパネルの座標も取れない。
こんなことってあるの？
655:名前は開発中のものです。
08/01/22 12:07:32 t/rMcNXw
ロクな知識もなしに口出しして悪いけど、DLDIの問題だったとかってオチじゃないよね？
656:名前は開発中のものです。
08/01/22 12:33:25 QDQndHhu
>>654
>こんなことってあるの？
もちろんある。
開発の経験少ないとわからないかもしれんが、単なるバグだろうな。
>>653 の言うように初期化漏れである可能性もかなりある。
不具合が再現する環境で調査するのがいいよ。
あと、バグと認識した上で調査すること。
657:名前は開発中のものです。
08/01/22 13:41:15 gUHlGxAr
対数（log）をとるのってどうすればいいかわかる？
devkitProにそういった関数がない以上、
自前でマクローリン展開をするか
対数テーブルでも作るしかないとは思うけど
だれか実践している人はいますか？
658:名前は開発中のものです。
08/01/22 14:02:36 Ji00TJph
つ#include <math.h>
はダメ？
659:名前は開発中のものです。
08/01/22 14:46:32 QDQndHhu
>>657
devkitPro/devkitARM/arm-eabi/include/math.h
660:名前は開発中のものです。
08/01/22 14:57:28 gUHlGxAr
>>659
なんと…
これを使うためにはどうすればいいの？
661:名前は開発中のものです。
08/01/22 15:04:49 PxbgiTbg
>>660
>>658
662:名前は開発中のものです。
08/01/22 15:07:46 gUHlGxAr
>>661
それだとlibndsのmathがインクルードされる。
インクルード自体は
#include "devkitPro/devkitARM/arm-eabi/include/math.h"
でいいんだけど、問題はリンクをどうすればいいのかということ。
663:名前は開発中のものです。
08/01/22 15:15:42 PxbgiTbg
>>662
> それだとlibndsのmathがインクルードされる。
パス通せばいいだけなのに。
> でいいんだけど、問題はリンクをどうすればいいのかということ。
同じ場所に lib があるだろ。
664:名前は開発中のものです。
08/01/22 15:33:50 yQKos8cm
>>663
よくわからんのだが、一部の関数は標準ライブラリの関数名とlibndsとで完全に被るんじゃない？
printfとか
665:名前は開発中のものです。
08/01/22 16:06:08 gUHlGxAr
>>663
やってみたけどリンクされなくて困った。
多分makefileが悪いんだろうから夜に調べてから報告する
666:名前は開発中のものです。
08/01/22 17:38:48 +KuWPN/o
>>662
mathのライブラリはlibm.a
LIBSに
-lm
を追加すればいいと思うよ。
667:名前は開発中のものです。
08/01/22 18:17:13 gUHlGxAr
>>666
ありがとう。lcやら色々ためして、lmでやっと上手く行きました。
結構速いし意外と容量食わないし、mathいいね
668:636
08/01/22 18:37:09 shPt/KFF
遅くなりましたが回答有難うございます。
oファイルを使っての描画はできたのですが、一々Makefileに書き足すのが面倒なので、
bmp2sprのようにデータをそのままcに書きだすツールはありませんか？
669:名前は開発中のものです。
08/01/22 19:24:11 Ji00TJph
>>668
Makefileにサフィックスルール書けばいいんじゃないの？
670:名前は開発中のものです。
08/01/22 21:40:43 shPt/KFF
自己解決しました。
24ビットbmpをAGBGFXConverterで65536colorで出力したものを
loadPCX、image8to16を使わずにglTexImage2Dの最後の引数に渡せばいいようですね。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4309日前に更新/236 KB
担当:undef