トップページgamedev
990コメント372KB

NintendoDS(NDS)非公式開発 Part2

■ このスレッドは過去ログ倉庫に格納されています
0001名前は開発中のものです。2007/04/06(金) 07:28:10ID:0HAbZjic
NDSで何やら作ってみようという人の為のスレ。ライセンス不要。
初心者歓迎。質問歓迎。英語苦手な人歓迎。冷やかし歓迎。ネカマ歓迎。

資料、リンク等
http://nocash.emubase.de/gbatek.htm
http://www.bottledlight.com/ds/index.php/Main/HomePage
http://www.helloworld.jp/~duke/nintendo_ds/

開発環境
http://www.devkitpro.org/
http://sourceforge.net/project/showfiles.php?group_id=114505

関連スレ
ゲームボーイアドバンス(GBA)開発@ゲ製板(避難所)
http://bbs.gamdev.org/test/read.cgi/gamedev/1055111303/
ゲームボーイアドバンス(GBA)非公式開発 Part2
http://pc5.2ch.net/test/read.cgi/gamedev/1099119005/

前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1113780562/
0524名前は開発中のものです。2007/12/17(月) 23:50:53ID:eWYlxyJ0
>>523
なるほどそういう事でしたか。よくわかりました。
問題はJ14のdldi_ds.m3にあるのではなくJ14のhomebrew.jpにありそうですね。
J13のhomebrew.jpとJ14のdldi_ds.m3でJ14ファームで動くかも知れませんね。
もし動いたら最新版で超高速ということになるわけですが・・・
0525名前は開発中のものです。2007/12/17(月) 23:58:49ID:MhsFv35n
ありがとうございましたです
0526Moonlight2007/12/18(火) 00:07:16ID:F8gE+Mcp
>>524

J13はわかりませんが、J01とJ11の自動DLDIパッチには問題があるので、(たぶんJ13のでも)homebrew.jpを入れ替えても正常に自動DLDIパッチは機能しないと思います。
まぁそのうち直るんじゃないのー?くらいで私は傍観者な気分です。(笑
0527名前は開発中のものです。2007/12/18(火) 09:36:49ID:n9GS+972
>>526
Moonlightさんは開発者としてだけでなく預言者としても才能がおありのようですwww
昨日の今日でV2.8 J15で自動DLDIパッチが修正されました。

しかしこのdldi_ds.m3はすごい性能ですよ!dsm2onlyでエンコした256x192動画を
再生してみたら24fps、30fpsでも遅延発生せずに再生できるようになりました。
ImageViewerはサムネイルのスクロール速度が見えないくらいに速く動きますしw
使用しているメディアはSanのmicroSDHC 4GBです。6GBや8GBならもっと高速かも。

M3 Realとmoonshellの組み合わせで今までにないマルチメディアの世界が広がりました。
このマジコンは今は出来損ないですが、ものすごい可能性を秘めているかもしれませんなwww

とにかくMoonlightさん。ありがとうございました。
0528名前は開発中のものです。2007/12/18(火) 10:43:29ID:n9GS+972
>Moonlightさん

あつかましいお願いで恐縮なのですが…

以前にM3 REAL用タッチポインタ正常化moonshellを作成していただきましたが
今回J15でオートパッチャが正常化したことにより、DLDI対応ソフトとして
認識させたいと思います。

そのようなmoonshellをご用意していただくことは可能でしょうか?
J15におきましてもmoonshellのポインタズレは相変わらず直っておりません。
無理にとは申しません。もしご検討いただければ幸いです。
0529名前は開発中のものです。2007/12/18(火) 12:13:55ID:5oi3NSno
>>528

おお〜それおいらもお願いしたいです。土下座でもなんでもします。お願いします。
0530Moonlight2007/12/18(火) 13:38:54ID:F8gE+Mcp
>>528

homebrewが正しく起動できるM3REAL/J15(V2.7eX)以降専用です。
http://mdxonlinemirror.dyndns.org/RepairMoonShell.zip

タッチパネルを含むBIOS情報再取得コードと、MoonShellVer1.71+1のM3REAL用DLDIパッチ済みNDSROM本体と、内蔵バイナリリブートツールをまとめたNDSROMファイルです。
普通にMoonShellVer1.71+1をインストールしたSDのルートに'RepairMoonShell.nds'をコピーしてから起動してみて下さい。
前回との違いは、自動DLDI無効化パッチを適用しないように変更したことと、メモリマップを見直して512kbyteで済むようにしただけです。
セットアップで作成される'MoonShell_????_ほにゃらら.nds'ファイルは不要です。全部消しちゃってOKです。
ファイルサーバがごちゃごちゃしてきたので、2,3日で削除すると思います。 使い道がありそうでしたら、早めにDLしておいてくださいませ。
コピペで適当に済ませようとする手抜きさがアリアリと。(苦笑
0531Moonlight2007/12/18(火) 13:46:43ID:F8gE+Mcp
>>530 補足

自動DLDIパッチが正常に働くようになったのにM3REAL用DLDIパッチ済みで公開したのは、過去ログを見てdldi_ds.m3を削除してから起動した人がいても正常にアクセスできるようにと思ってこのようにしました。(蛇足
J14付属dldi_ds.m3とJ15付属dldi_ds.m3は、バイナリレベルで一致したので同じものです。たぶんJ15はhomebrew.jpの修正をしたんですね。
0532名前は開発中のものです。2007/12/18(火) 15:03:07ID:7T5JBS+s
有り難く使わせて貰います
0533名前は開発中のものです。2007/12/18(火) 18:19:32ID:n9GS+972
Moonlight様

早速のご対応ありがとうございました。
Sanの2GB microSDであるにもかかわらず
新DLDIドライバによりmoonshellがとてつもなく高速に動いています。

感謝感激デス!本当にありがとうございました。
0534名前は開発中のものです。2007/12/19(水) 10:15:09ID:vSX8Z0Q6
Moonlight氏のHomebrewをM3Realでプレイしてみました。
M3Real V2.8だとMoonshell、ImageViewerともに素晴らしい動きをしますね。

しかしCooking TimerやMorning TimerはFAT32で使うとディスクチェックで
エラー停止しますねぇ。FAT16なら大丈夫だけど。
ImageViewerのようにiniファイルでバイパスできるといいのに。
自分がその方法を知らないだけかも知れませんがw

あとM3Real用のリセットプラグインがあるといいですね。
Moonshellの動きが抜群にいいだけに、リセットできないのが非常に気になってしまいます。

M3 Realに対するMoonlight氏のサポート、ユーザー一同感謝しています。
ありがとうございます。
0535名前は開発中のものです。2007/12/19(水) 13:01:41ID:9Fgoq2AJ
こちらのカキコを見てM3 REALを買ってみました。
v2.8 J15からのスタートになります。

moonshellの動画再生能力が半端じゃありません罠このマジコンは!
平凡なSanの2GB MicroSDなのに、dsm2onlyでエンコした256x192動画を再生してみたら
24fps、30fpsでも遅延発生せずに再生できるようになりました。
今まで苦労していたのが何だったのか…

あと、やっぱりmoonshellでリセットしたいですね。
これだけ性能がズバ抜けているだけに。

ありがたや〜 あ〜ありがたや〜〜〜〜
0536名前は開発中のものです。2007/12/19(水) 16:06:35ID:eAmT+TQX
2007年12月19日 14:48
メモ。またアクセス規制…うちはOCNなのかなぁ。

転記したら消します。FAT32は壊れやすいので使いたくないんだけど、SDHCでも採用されたんだから今時FAT32警告ってのもアレなのかなっ。(苦笑

名前: Moonlight
E-mail: sage
内容:
>>534

基本的にディスクはいつ壊れ始めるかわからないので、ディスクチェックは有効のままにして欲しいのですが、FAT32警告が鬱陶しいとのことなら、ディスクチェックをスキップする方法はあります。
http://mdxonline.dyndns.org/skipdiskchk.png
左下の赤丸で示したチェックボックスを外すとOFFになります。(なるはずです。確かそう作ったような気がします(笑




これって起動できないからiniファイル上でどう記述すべきかを教えてあげた方が親切かも。
あ。Moonlight氏のような親切杉るくらい親切な人にこんな事言ったら失礼だと今気付いた。

すんません。

P.S.
moonshellのM3リアル用リセットプラグインは私も欲しいと思う一人なのであります!
0537名前は開発中のものです。2007/12/19(水) 16:44:15ID:x85E9Gaq
2007年12月19日 14:48
メモ。またアクセス規制…うちはOCNなのかなぁ。

あれ?私、勘違いしてる?
全然確認しないで記憶で書いたから、FAT32警告が出るんならそうなんでしょくらいで思っていたのですが、いま確認したらMorningTimerVer1.1はFAT32警告を外してあるみたいです。
お手持ちのファイル名を確認してみてください。MorningTimer11.ndsなら警告が出ないと思います。
ちなみに、FAT32警告はエラーでなく警告なので、何かキーを押せば次に進めるはずです。(そんな風に作ったような記憶が…(曖昧(笑



M3 REALではFAT32でそいつらを起動するとFAT32警告ではなく致命的エラーで死ぬ事実www
0538名前は開発中のものです。2007/12/19(水) 16:56:51ID:WOXs0V0+
なんか話が噛みあわないと思ったらMoonlightさんはFAT32警告が出ると思っていたんだな。

M3Realでディスクチェックが入ると致命的エラーが出て再起動しか方法がなくなる。
ImageViewerでも同様だがこれはINIファイルで切ってるから無問題。

一旦、FAT16で動かしてライセンス表示させない設定ファイルをセーブっといて
FAT32で使うときにコピーすればいいと思うよ。
0539名前は開発中のものです。2007/12/20(木) 09:44:49ID:G9sHKr8Z
M3R使ってMoonlight氏のHomeBrewの簡易ディスクチェックで致命的エラーになってる人。
たぶんtmとかいう奴のスキンを使っていたんじゃないかな?
http://ameblo.jp/t-t-tr/entry-10056864796.html

このスキン、今は修正されてるがチート設定時にフリーズしてしまう問題があった。
書き込み時のフリーズなので100%ディスクが壊れる。しかし再起動すると動いてしまう。
だから壊れたことに気付かないでそのまま使ってしまう。
tmのスキンに限らず海外で公開されているスキンでもまともに動くものはほとんどない。
悪いことにチートをはじめ設定の書き込み中にフリーズするパターンが多い。

実は自分もその事に気付かずにずっとM3Rを使ってきて、Moonlight氏のチェックディスクで
はじめて気付いた次第だ。
最新のカーネルであればHomeBrewの問題は皆無と言っていい。FAT32だろうがFAT16だろうが
DLDIの自動パッチは正常に動く。
ただ、なぜかクッキングタイマーだけは何をやっても起動時DLDIのメッセージのまま動かない。
まあT料理しないからいいけどさwww
0540名前は開発中のものです。2007/12/20(木) 10:12:58ID:TXV/829e
>>539
以前にtmさんのスキンを使っていました。
それとチートでフリーズしたのをおぼえています。
そして…やはりmicroSDが壊れていました(笑)
フォーマット後全ファイルコピーで修復しました。
Check disk for NDSの最新版 Ver0.3が今日リリースされています。
http://mdxonlinemirror.dyndns.org/resources/20071220_checkdiskfornds03.zip

ちょっとこのチェックツールまじで凄いんですけど。
断片化をビジュアルで表示したりどのファイルが断片化してるかとか全部わかるし。
凄いツールなのに知名度低杉。もっと話題になってもいいと思う。
自分のmicroSDの構造がメタメタだと知らずに○○マジコンは糞とか言ってる人って
きっといるよね。
何かを評価するときにはCheck disk for NDSちぇっく済みの一言を書き加えるべき。
そんな気がしました。

Moonlightさん、また一つ勉強になりました。ありがとう!
0541名前は開発中のものです。2007/12/20(木) 14:36:55ID:G9sHKr8Z
つ、スキンの不具合でディスク書き込み中にフリーズって仕様でいいのM3R?

スキン変えてるM3RユーザーはCheck disk for NDSは必携ツールだな。

チート設定から戻るときにフリーズしたら今のところ100%壊れてる。
0542Moonlight2007/12/20(木) 15:22:11ID:MAA+wn7E
>>539 >>540

なにするんだM3REALばかやろーって感じですね。(笑
最も注意して作らなきゃいけないディスク書き込みを伴う処理を、安全に作らない開発者ってなんなんだーばかやろー。
(マジコンの品質なんてソンナモノって話は却下です却下(笑))
J15でもまだチェック機構が甘いのかは(自分で確認してないので)さておき、それだけ致命的なバグならそのうちなおるでしょと思います。
ちなみに、ベンチマークで大事なのは最大値ではなく全体の均一さです。先頭だけしか速くないMicroSDの多さにびっくりしました。
SanDiskのSDHCが汎用的に優秀かは知りませんが、M3REALと相性が良いのだけは確かみたいですね。
0543名前は開発中のものです。2007/12/20(木) 15:22:29ID:1Z+yttvt
その程度でmicroSDを確実に壊してしまうM3Rは糞ですね
0544名前は開発中のものです。2007/12/20(木) 15:31:28ID:G9sHKr8Z
おっ!Moonlightさんの久しぶりのカキコやないか!BTW

M3Rのreset.mseはやっぱり却下ですか…

M3Rでクッキングタイマーが起動しないのは俺だけ…?

>>543
俺も先日までは糞だと思っていた。あの超高速dldiドライバが提供されるまではな。
あの速度をゲームに転用できたらすごいだろうな…

と思うとM3Rの将来に思いを馳せたくなるんだぜ。
0545Moonlight2007/12/20(木) 16:02:48ID:rwOvvo+K
後述。Check disk for NDS Ver0.3をアップデートしました。ページ上部のリンクから辿ってください。

転記ありがとうございます。感謝です。
(CookingTimerで使っているFATライブラリが古いので、特定のファイル名でディスクチェックに失敗することがあります。需要少なそうなのでほっといてもいいかなとか無精癖が(苦笑) reset.mseは私のできる範囲じゃないので関わりません。ごめんなさいです。)
0546名前は開発中のものです。2007/12/20(木) 16:19:19ID:G9sHKr8Z
なんや転記だったん?書き込めへんのか。

リセットはM3Rから吸い出したROMを起動してみる。だめっぽい?

クッキングタイマーは諦めた。料理やんないしとか言ったから怒ってるんやろな。
使うのはモーニングタイマーの方だからいいっすよ。

ま、M3Rはだんだん可愛くなってきた。でもTTDSに浮気したい気分が抑えきれないけど(爆
0547名前は開発中のものです。2007/12/20(木) 16:30:09ID:tLTzhhXD
>>542
>先頭だけしか速くないMicroSDの多さにびっくりしました。

その情報を逆手にとって悪魔城をSandisk 2GBの先頭において起動してみました。
位置はFATの直後あたりです。カーネル等よりも前に置きました。
結果。信じられない話ですが、このメモリカードでは絶対フリーズしていたポイントで
まったくフリーズしなくなりました。

高速に動かしたいゲームはフォーマット直後最初にコピーするよう意識することで
かなり快適に使えるようになることがわかりました。
microSD上で位置を自由に設定してファイルをコピーできるソフトがあるといいですね。
昔、ノートンにそんなソフトなかったかな?
0548名前は開発中のものです。2007/12/20(木) 16:51:05ID:G9sHKr8Z
今思えばAceKardのAKFSがいかに優秀だったかがわかるもんだな。
断片化しないだけでなく、先頭からコピー元ファイルの空き場所を探すから
入れ替えが簡単にできる。書き込み専用ツールで中の状態もはっきりわかるしな。

昔と違って大容量記憶メディアが簡単に手に入るようになったのだから
ファイルシステムも使用効率より動作性能を重視してもらいたいもんだ。
まあMicrosoft社が遅れてるだけで。Mac OS X 10.2以降で使用されているHFS+や
Linuxのext3など参考にすべきだと思うんだが。
せっかくマジコンで採用してもFATにしろ!と潰されるのはAceKard+で実証済み。
Windowsの標準ファイルシステムにならないと受け入れられないだろうよ。
0549Moonlight2007/12/20(木) 17:05:37ID:21+7rRsc
転記ありがとうございます。感謝です。
す、すいませんー。独り言をぼそぼそと書き散らしただけのつもりだったのですが、わざわざお手数かけてしまって申し訳ない&感謝の限りです。
(ひとりごと〜私はW-ZERO3とマジコンで使う以外のリムーバブルHDDやCF/SD等は全部NTFSで使ってます。NTFSラブ。デジカメとか持ってない)
0550名前は開発中のものです。2007/12/20(木) 17:10:26ID:EvQ1qSv8
>>594
意外に勉強不足なんですね。
http://www.atmarkit.co.jp/fwin2k/experiments/defragment/defragment_column.html

あるいはこれがSDの世界では問題ないとかいう理論で俺が恥をかく展開になるのか?www
0551名前は開発中のものです。2007/12/20(木) 17:23:10ID:G9sHKr8Z
>>550
俺も単純にNTFSはフラグメントしにくいと理解していた。どうも違うようだな。
マジコンで750バイト以下ってiniファイルくらいしかない罠。
それ以外はどこのクラスタに飛ばされるかわからへんわけやね?

そうなるとNTFSは思ったよりいいファイルシステムじゃないことになるね。
0552名前は開発中のものです。2007/12/20(木) 19:26:52ID:800P5N4j
なるべく同じクラスタに収めようとするので、
FATよりはよっぽどフラグメント化しないよ。
0553名前は開発中のものです。2007/12/20(木) 20:01:54ID:UZjuOACo
久しぶりにHDDを分析したら真っ赤だった
0554名前は開発中のものです。2007/12/20(木) 20:52:56ID:G9sHKr8Z
>>552
同一クラスタを異なるファイルが共有するのかい?
読み取る時にどうやって区別するのかね?
クラスタごとにバイトポインタでも持ってシークするのだと?
負荷高そうなファイルシステムだねww
0555名前は開発中のものです。2007/12/20(木) 21:08:11ID:fkgSddbS
ソフトウェア版のデフラグソフトのスレッドでたまに流れる話題だなぁ
0556名前は開発中のものです。2007/12/21(金) 09:43:45ID:7ouPPK0Y
Check disk for NDS Ver0.3ですけど…
断片ファイルの検索がnds/savファイルになってますが
M3 RealはSaveファイルの拡張子が0,1,2なんですよねー
ずーっと断片化してないと思って安心してたけど
全検索してはじめて断片化に気付いた次第。
気付くのが遅かったらセーブが壊れるところだったかも知れない。
マジコンのトラブルは断片化に端を発しているものが多そうだから。

断片化があった場合、断片化ファイルだけをmicroSDの外へ移動し
USB接続を切ったあと再接続して戻してあげると空き領域に
断片化がない状態でコピーされるみたい。もちろん空き容量が
十分あればの話だけど。

Check disk for NDS Ver0.3は使っているうちにだんだん
手放せなくなってきたすごいツールだよ。
0557BlackMoon2007/12/21(金) 16:38:50ID:jGmKHxn8
そんな拡張子に0とか2とか数字使うマジコンにわざわざ対応する必要ねーよ。
M3Realの方でツールの仕様にあわせろっつーの。
いちいちそんなのに付き合わされてたら開発者は身がもたねーつーの。

少しはこっちの身にもなってみろって。
0558BlackMoon2007/12/21(金) 19:24:52ID:7ouPPK0Y
>>557
悪かったねぇ

そのツールが今一番必要としているマジコンで使いにくくなってたから
皮肉なもんだなーって感じたから言っただけだよ。

どの道お前の世話にはならんから安心汁。
0559BlackMoon2007/12/21(金) 23:59:44ID:WfuwbDfL
外見を極限まで高めて厨房の大量取り込みに成功はしたが
技術力が無いから、M3チームは駄目だな
決め打ちパッチだからサポート放置されたら即死だぞ
0560名前は開発中のものです。2007/12/22(土) 01:49:20ID:JbsPsov5
じゃあどれならいいんだ?
0561名前は開発中のものです。2007/12/22(土) 13:43:58ID:Otmx5mfl
Moonlighit氏がCheck disk for NDS Ver0.3をアップデートしましたね。
http://mdxonlinemirror.dyndns.org/resources/20071222_checkdiskfornds031.zip

戯言みたいな書き込みにこんなに真面目に対応してくれる人はなかなかいないよ。

技術者って一般的に視野の狭い人が多くてコミュニケーション能力に乏しい。
だから女性にもなかなかモテない。プログラミングで自分を表現するのは得意なのにね。

生の人間相手より見えないちゃんねらー相手にコミュニケーションをとる方が気は楽かも。
でも強度の煽り耐性がなければやってられないでしょう。本当に大したものです。

ある方はマジコンごとにリセット対応するのが面倒なのでマジコンから吸い出した
Romを直接起動しようと考えました。M3 Realなどの場合はこの方法でうまく行くそうです。
moonshellからndsが起動できなくなってかなり立ちますが、もしndsが起動できていたら
このような手法も使えたかも知れません。もちろん定かではありませんが。

まあ仲良くやってくださいよ。
0562名前は開発中のものです。2007/12/22(土) 18:21:08ID:RDHqMR1H
んじゃ何万人を指して「一般的」というのか教えて
0563名前は開発中のものです。2007/12/22(土) 19:27:35ID:Otmx5mfl
>>562
明確には提示できないけど、その中にお前が含まれるのは確実。
0564名前は開発中のものです。2007/12/23(日) 01:23:38ID: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も
断片化チェックをするようにしました。

どうせ過疎スレなのでプログラム関係じゃない話題でも
私は気にしないのですが、けんかしないで…。
0565名前は開発中のものです。2007/12/23(日) 09:43:37ID:GQn87g8C
ううMoonLight様のRepairMoonShellが
消えていた・・・
もう少し早く気がついていれば。。。
(TДT)
0566名前は開発中のものです。2007/12/23(日) 10:58:47ID:LaCNw6ob
スロット2起動すればいいんだよ
0567名前は開発中のものです。2007/12/23(日) 13:44:52ID:vfS66XeO
3Dでタッチした座標にあるポリゴン(トライアングルふたつ)との交差判定をしたいです。
OpenGLでは、gluUnProjectを使って、タッチした座標と向き(マウスレイ)を取得するのですが、
libndsのvideoGLには、これがありません。
代わりになる方法はあるんでしょうか?
0568名前は開発中のものです。2007/12/23(日) 14:32:04ID:JogT0J4D
>>567
ttp://devkitpro.cvs.sourceforge.net/devkitpro/libnds/include/nds/arm9/postest.h?view=markup
nds-examples-20071023\Graphics\3D\Misc\Picking\
0569名前は開発中のものです。2007/12/23(日) 16:58:00ID:9lGG4dEa
wavからrawに変換したものが思ったように再生できません・・・

既に >>93 のサンプルは消えてしまっているようで
もしよければ再度サンプルを置いていただけませんでしょうか?
おねがいします。
0570名前は開発中のものです。2007/12/25(火) 21:45:25ID:Bx4UTy/Y
>>561
>一般的に視野の狭い人
その定義は如何に

>だから女性にもなかなかモテない。
根拠は何処に
0571名前は開発中のものです。2007/12/25(火) 22:26:19ID:pmHIaQhz
>>561は、
視野が狭くて、コミュニケーション能力も乏しく、
女性にもモテない、しかも技術力も無い

と、言うことが分かりました。
0572名前は開発中のものです。2007/12/25(火) 22:34:52ID:QxVRW44c
身に覚えのないことならサラッとスルーした方がいいよ。
くだらんレスに粘着してると身に覚えがあるように見えるよ。

女にモテなくてもお袋さんはおまいを愛してる。
コミュニケーション能力がなくても2ちゃんねるなら弁慶にもなれる。

それで十分じゃね?日本の典型的な内向きの技術屋さんたち(爆)
0573名前は開発中のものです。2007/12/25(火) 22:54:42ID:eieLjBGr
きょうも つりばりが いっぱいだ!
0574名前は開発中のものです。2007/12/28(金) 20:40:16ID: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でライトアクセス時間のベンチマークを取ると再起不能な
状態で壊れてしまうものなのでしょうか?恐いので試してませんがもし可能性がある程度の
事でしたら自己責任でチャレンジしてみたいと思います。
0575Moonlight2007/12/28(金) 21:31:12ID:r6XOZjDh
>>574

テストありがとうございます。IS0〜IS9を追加したVer0.32をアップしました。
NDS(いわゆるgba_nds_fat)で作った0byteファイルと、Windowsで作った0byteファイルの挙動が違うなんてブービートラップですー(笑
NDSに限らずWindowsでも書き込みは危ないです。たとえば、ユーザが暇してる(画面見てるとかの)空き時間を使ってセーブしようとすると、セーブしている瞬間に電源切られたり、カードを抜かれたりします。ライトバックキャッシュは危険よねって話。
で、それはそれとして、SDHC対応は私が自信を持って大丈夫と確信していない(SDHCの仕様書を入手していない)ので未確定です。
いまのところ本気でフォーマット不能なまでに壊れたという報告は頂いていませんが、いまのところは、ってだけかもしれないので。(チキン(笑
0576名前は開発中のものです。2007/12/28(金) 21:48:28ID:naoJX6xE
>>574
>>561さんこんばんは
0577名前は開発中のものです。2007/12/29(土) 04:38:58ID:Z96Jd6yV
>>574
本当にエラーなのかも。
一応、PCでスキャンディスクかけてみて確かめるといい。

サイズが0バイトなのに、1クラスタ割り当てちゃってるとか。
もしもそうだとすると、ファイルシステム(libfat)の不具合ということになるね。


あと、マジコンユーザーにはメディアの消耗を気にしてデフラグしない人が多い。
それを考えると、ライトアクセスのベンチマークやる人は勇者です。
デフラグよりもっと消耗激しいかも。もちろん、ベンチマークの内容によるけどね。
0578名前は開発中のものです。2007/12/29(土) 09:47:35ID:PDHcBllJ
Moonlightさん、早速のご対応いただきましてありがとうございました。
当該エラーは無事キャンセルされ致命的エラーを回避できました。
実はこの0バイトファイルができる過程でM3Real側に動作上のバグがあるようで
一度何かのチート項目を設定して戻ると、次回チート項目を全クリアできない。
即ち、最低一項目のチート項目を選択しなければ状態が保存されないようになっています。
つまり0バイトのファイルは作れないように意図されている感じです。
再度チートファイルを選択し直すとすべてのチート項目がクリアされた状態になります。
ところがこの状態からチート設定画面に行き何もしないで戻ってくると0バイト
ファイルができているという始末です。非常にバグ臭い感じがしています。

>>577
FATにエントリされている以上、他のファイル操作の際には使用されることもないので
問題はないと思います。そのエントリは0バイトファイルを削除すると消えますし。
もし消えていなければCheck disk for NDSでひっかかっているはずです。
実害はないと思いますよ。

書き込みのベンチマークはそれほど多くの場所に書き込みしているようでは
ありませんし8GBは恐いのでやっていませんでしたが、2GBまでのmicroSDでは
いくつか試してみました。テスト中に電源を切ったりしなければ大丈夫でしょう。

おそらく8GBの結果は6GBとあまり変わらないと思います。リードでのベンチを
やった結果では6GBとほとんど同じでした。
しかしM3RealのDLDIドライバの性能はすごいですね。他のマジコンでのベンチ
テスト結果が哀れに思います。DSTTに唯一負けてない領域でしょうか。
0579Moonlight2007/12/29(土) 20:25:14ID:pw4v1uVO
>>578

どういたしましてですー。
0byteファイルの作り方については微妙なところですが、FATはMicroSoftが作ったのでDOS/Windowsの挙動が正しいんだと思います。
(あれ?MicroSoftが作ったのはLFNだけでしたっけ?)
といっても、重複するわけでもないですし、削除すればエントリとクラスタリンクはちゃんと消えるので、512byteくらいなら余分に使ったところで問題は無いと思います。
チート設定で云々はとてもバグっぽいですが、あまり致命的じゃなさそうなので直さないかもですね。

>DSTTに唯一負けてない領域でしょうか。
とか書くから煽りだと思われるんじゃないかなーと余計なことを心配してみたり。(苦笑
実際、ハードのポテンシャルは高くてもその性能を生かせているとはいえないと思う…けど私には関係ないからどうでもいいやー。(ゲームとか興味ないので…(酷い(苦笑

ライトベンチマークでは、128kbyte読み込んで32kbyte書き込んで1024kbyte書き込んで128kbyte書き込む処理を8回しますので、合計10MByte分くらいアクセスします。
MP3ファイル3つ分くらいなのでそんなに負担にはならないと思いますが、計測中に電源切られるととても困るのでめいっぱい脅してます。(笑
0580名前は開発中のものです。2007/12/30(日) 00:56:55ID:5BJqZ1d6
wavからrawに変換したものがどうしても雑音がかったものになってしまいます。
Moonlightさん、申し訳ないのですが >>93 のサンプルを再度アップしていただけませんでしょうか?
よろしくおねがいいたします。
0581名前は開発中のものです。2007/12/30(日) 02:29:09ID:/ePZFksH
エイリアスノイズが載ってるんだと思うので
変換後のサンプリング周波数*0.5以上の周波数を
事前にフィルタしておくと良いかも
0582tm2007/12/30(日) 16:20:27ID:MsSLbwJq
遅ばせながら

file_2.bmpとfolder.bmpがこんなに問題になってたとは……
もうしわけないです

0583名前は開発中のものです。2007/12/31(月) 01:13:00ID:rN7PTsQ5
まだやってんのかと言われそうだけど、TTAの再生できました。
>>93で、SOUND_ONE_SHOTが使われていることに気づいてMorningTimerのソースを見直してみました。
ダブルバッファリングのためにふたつのチャンネルを交互に鳴らしてるんですね。
SOUND_REPEATで鳴らしっぱなしにしてバッファの前半と後半を交互に書き換えればいいと思ってました。
# 実際に無圧縮の*.wavは、それでもノイズ無しで鳴っていたので
Moonshellさんありがとう。

そんなチラシ裏
0584名前は開発中のものです。2007/12/31(月) 01:26:20ID: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のあたりかなあと思い、値を変えてみたものの、
画像が引き伸ばされた感じになっただけでした・・

0585名前は開発中のものです。2007/12/31(月) 01:52:33ID: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になると思います。
05865842007/12/31(月) 01:54:38ID:M5kyCS2V
いちおう解決しました。
dmaCopy(foo_bin, BG_GFX, 512*256);
dmaCopyの3番目の引数はファイルサイズでしたorz

BG3_CR = BG_BMP16_256x256;
こっちの256x256は画像の解像度ということでよいのでしょうか?

また、画像を利用するに当たりbmpをbinにするのと、
png+gritを変換する方法がありますが、これに何か違いってありますか?
05875842007/12/31(月) 02:03:40ID: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の画像を使う宣言みたいなものと
覚えておけばよいでしょうか?
05885842007/12/31(月) 02:07:44ID:M5kyCS2V
すいません、ファイルサイズじゃなくて解像度256x256に1ドットあたり
2バイトなのでさらにx2したから256*256*2ですね
0589Moonlight2007/12/31(月) 04:45:20ID: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サンプル以下の累積誤差補正コードを自前で書くなら大丈夫だと思いますがめんどくさくてやってられなーい。(笑))
なにはともあれ、ソースが役に立ったみたいで本当に嬉しいです。
0590Moonlight2007/12/31(月) 04:45:55ID:GrGVceoQ
>>587

私もあまり詳しくはないのですが、BG設定は同じビットでも他のビットの設定によって意味が変わってくることがありました。
GBAからむりやり拡張したって感じがします。
8bitカラーモードのときと15bitカラーモードのときでは、同じビットでも意味が違うという感じで。(BGサイズと拡張パレットの設定ビットとかめちゃくちゃだと思うんですけどどうなんでしょうか(苦笑
ちなみに、例えばビットマップBGに256x256画像を読み込んでも実際には256x192分しか見えませんが、縦オフセットを徐々に変えると手軽にスクロール効果を表現できたりします。ランダムに細かく変えると地震っぽいとか。
チラ裏というか余談失礼しましたです。
05915832007/12/31(月) 17:46:55ID:rN7PTsQ5
TTAに続いてoggに挑戦。

libogg+libvorbisが重い。

tremorのことを思い出す。早速導入。

再生の始めが早送りに聞こえる。後に期待した音が流れる。

日暮れ。←いまここ

そば食べる。

今まで、ぶちぶち言ってたのに困ってたんですが、今度は逆に早送り・・・。
誰か他にogg(tremor)いじってませんか?
0592Moonlight2007/12/31(月) 23:51:45ID:kzjZELj8
>>591

もしかしたらソース見せてもらえたら横槍入れられるかもと思ってみたり…
05935832008/01/01(火) 10:45:53ID:NNk1mtua
>>592
ttp://www.uploda.org/uporg1183384.zip.html
遅くなりました。よろしくお願いします。
0594名前は開発中のものです。2008/01/01(火) 15:24:49ID:T3NYT7jt
あけましておめでとう。みなさん今年もよろしく!

DSのプログラムを初めて思ったのは、面白いことをするためには
どうしてもハードウェアの制作が必要になるんだな、ということです。
例えばGPSとかカメラとか、そういったのをDSに付けたくなってしまう。

俺はずっとソフトウェアしかやってこなかったので、
初心者の気分でハードウェアの勉強をしてみようかと思うんだけど
そういうときに最初に行くべきスレッドってどこでしょう?

今年、DSの自作プログラムの幅が広がれば嬉しいな
0595名前は開発中のものです。2008/01/01(火) 21:24:21ID:+s8QW2Sx
電気・電子板のARMスレが良いんじゃなかろうか

http://science6.2ch.net/test/read.cgi/denki/1072102432/
0596名前は開発中のものです。2008/01/01(火) 22:38:14ID:Rbh21JyU
何かつけたいならCPLD覚えた方がいいんじゃなかろうか
0597Moonlight2008/01/01(火) 23:06:37ID: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フレームだけ極端に重いので、リングバッファじゃなくダブルバッファだけでも入れてみて様子を見たり…。(対処療法的なので誉められた対応ではないのですがテストで(笑))
0598名前は開発中のものです。2008/01/01(火) 23:19:13ID:6ptbDBuA
あけおめです。

>>594
DSの場合、Wi-Fiが使えるので無線経由でPCに接続したカメラや
GPSの情報取得してもおもしろいかもね
05995932008/01/02(水) 00:19:35ID:xkC7Ea9V
>>597
添削ありがとうございます。
再生データの形式を書き忘れていたのですが、16384Hz/モノラル/16ビットで正解です。

割り込みと処理落ちというキーワードから見直しをしてみました。
FIFOハンドラのループで複数のコマンドがキューに乗ったときに連続して処理して、
間髪入れずに鳴らすコマンドを投げてしまいます(と、指差ししながら脳内検証)。

デコードの処理をハンドラから出してみたところ、現象は収まりました。
ただ、初回デコードが時間がかかってる感じが少しします。
対策として、
ダミーのデコード(鳴らさない)

ov_*_seek系のAPIで先頭シークに戻す

改めて再生
ってなことをしようと思ったんですが、ov_pcm_seek( &vf, 0 )が効いてる気がしない様子。
あしたもがんばるぞorz
0600名前は開発中のものです。2008/01/02(水) 08:06:49ID:tTTSdt9O
みなさんいろいろとありがとう。
実は加古英児さんのサイトを見ていて触発されたんです。
http://www.kako.com/neta/
このページを見て、小学生のころ電子工作(とは名ばかりのはんだ付けキット)を
やっていた記憶が鮮やかによみがえり、本格的にやりたくなりました。

だからARM系やCPLDだけじゃなくて、1から回路を作って楽しみたいんです。
そういうときの入門スレってどこだろう??
(それはそれとしてWi-Fiは面白そう、ありがとう!)
0601名前は開発中のものです。2008/01/02(水) 09:51:15ID:6mZ1FxBS
このスレの住人は、向上心があっていいなw
06025932008/01/02(水) 11:10:58ID: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
0603Moonlight2008/01/02(水) 14:11:11ID: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が…。
独り言で長文書き込んですいませんです。ではまた。
06045932008/01/02(水) 15:49:48ID: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
0605名前は開発中のものです。2008/01/02(水) 15:57:05ID:6ig8IlcH
NDS開発云々の前に凡ミスが多くね
0606名前は開発中のものです。2008/01/02(水) 16:28:43ID:3kcyZQN4
なれない環境なんてそんなもんだよ
0607Moonlight2008/01/02(水) 23:30:28ID:w4bCClKX
>>604

あーフラグの偽でしたか。私もoggライブラリ移植するときに引っかかりました。charのsigned/unsignedとか。
misc.hを直接書き換えて、LittleEndianしか通らないようにしました。(手抜き(笑
私はlowmem_branchをマージしたのですがtrunkしかないしメモリリークバグもあるしであまり好きじゃないです。
ovs_seekを直す。結局それが一番近道だと思います。(笑
わざわざ開発状況の報告をさせてしまってどうもでした。またなにか躓いたら(役に立てるかは別としてっ!(笑))訊いてくださいね。でわでは。
0608名前は開発中のものです。2008/01/05(土) 00:43:36ID:/+yjt+NH
pngを読み込んでspriteで表示する簡易なサンプルとかありませんでしょうか。
めらまん氏のwikiは見たのですが何をやっているのか理解できず。
サンプルのspritebitmapを弄ってますがどうにも・・・
0609名前は開発中のものです。2008/01/05(土) 00:50:22ID:9PNTe7K3
pngじゃ無いとダメなの?
06106082008/01/05(土) 00:58:17ID:/+yjt+NH
>>609
Tileでpng使ってたもので、そのまま使えるかなとか思っておりましたが
spriteってやっぱりbmpでやるものなんでしょうか?
06116082008/01/05(土) 01:26:12ID:9PNTe7K3
>>609
自分はbmpをCソースに書き出して使ってるのでどっちでもいいと思ってる。
pngは展開しないといけないので、特に理由が無い限り使わないです。面倒だし。
0612名前は開発中のものです。2008/01/05(土) 11:34:13ID:c8GGWOxF
>>611=609
お前の番号ずれてないか
0613Moonlight2008/01/05(土) 20:15:53ID:j7N7Qhly
>>608

もし私なら、
・画像ファイルからbinに変換した画像の扱いに慣れるまでビットマップでいじくってみる。スプライトのことはとりあえず忘れる。
・DLDIドライバを組み込んで、半角英数10行くらいのテキストファイルを表示してみる。
・色深度固定(例えば24bitとか)のbmpファイルをディスクから読み込んで、15bitに自前で変換して表示してみる。
・色深度自由な汎用bmpライブラリを組んでみる。
・libpngを組み込んで、色深度固定のpngファイルを読み込んで、15bitビットマップに変換して表示してみる。
・色深度自由な(アルファチャネルとかを含む)pngライブラリを組むかどうかはやる気と気分次第。
・この頃になるとビットマップの扱いに充分慣れていると思うので、スプライトで表示してみる。8bitパレットを扱うかはやる気次第。
という感じで、進んでいくと思います。あくまで、私ならですが参考になれば幸いです。
06142008/01/08(火) 20:56:16ID:m4lL5SxZ
>>1〜1000
おk
0615名前は開発中のものです。2008/01/11(金) 16:48:48ID:IDnFxZnm
背景画像の上にフォントを表示させる場合、
フォントの一部の色を透過させて背景画像が見えるようにしたいのですが
フォントの描画はスプライトで行うのが一般的でしょうか?

0616名前は開発中のものです。2008/01/11(金) 17:00:08ID:lysu1ST4
Check disk for NDS EWIN2でタッチパネルが動作しません。(T_T)
対応していただけないでしょうか・・・
0617Moonlight2008/01/11(金) 18:37:48ID:858Jtf0V
>>615

もちろんスプライトでもできますが、背景BGと文字BGを重ねるほうが楽だと思います。日本語フォントを扱うならスプライトでどうこうできる量ではないので。
色を透過させるだけならこれでできますが、影を半透明でとかアンチエイリアスフォントだとかになったら、ビットマップモードしかないと思います。
最近わたしはもうめんどくさいので、ビットマップモード&自前合成ばっかりです。(Windowsと似た感覚で扱えるので)

>>616

EWIN2は…。ごめんなさい、古すぎてもういいやって感じがしています。(不遜でごめんなさいです。
特にこの機能だけ使いたいからメニューでAボタン押したらこれ、Bボタンはこれにしてほしい、というくらいなら対応できます。
0618名前は開発中のものです。2008/01/11(金) 20:34:41ID:gV4ausxY
>>617

616です。
EWIN2の対応は諦めました。
カーソルキーで移動、Aボタンで選択というのは無理でしょうか?
R4でもそれなら、もう少し使い易くなると思います。


0619名前は開発中のものです。2008/01/11(金) 22:43:18ID:gV4ausxY
ありゃ、表現が変ですね。
カーソルキーで移動・選択、Aボタンで実行です。
よろしくお願いします。m(__)m
06206152008/01/14(月) 14:36:28ID:gI9YVpPo
>>617

ありがとうございます。
とりあえずBGを2枚重ねて処理する方法を試してみます。
06216152008/01/15(火) 21:21:10ID: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) );
06226152008/01/15(火) 22:24:27ID: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

にしたのですが、こうすると逆に背景が少し下にずれて描画されてしまいました。
06236152008/01/15(火) 22:31:45ID:lG1M2LiD
スレ汚しすいません・・・
baseは0..31あって、1が0x0600 4000に対応して、
以降そのまま番号ごとに対応しているのですね。
NDS/Tutorialsをもっと読んできます・・
■ このスレッドは過去ログ倉庫に格納されています