>みなつさん 　SFXVIをご存知でしたか^^;。インターネットも普及してなかった当時(20年ちょっと前!)でも盛り上がったので、今のプチコン3号なら行けるんじゃないかな、と思ってます。 　モニターは無いですが、一応まだX68000 CompactXVIが家にあります^^;。 　「こいつ＆あいつ」は当時私が作りましたが...偶然の指摘ですか？それとも、実は私のお知り合い？

　アップデート作業、お疲れ様です。 　今現在、格闘ゲームを作ってますので...それに関わる要望を書かせていただきます。 -GLOAD命令で、画像配列の開始オフセットを指定させてほしい 　大量の画像データを切り替えながら使う場合、現在は一度展開用配列にコピーする必要がありますので。 　このため、セル画方式の格闘ゲームは諦めました。 -BEEP命令で、ユーザ指定の音声データを再生させてほしい 　必殺技を喋らせたいですが、現状のMMLだと大変ですので... - LOAD命令で、読み出しファイルの開始位置、読み出しサイズを指定させて欲しい 　分割LOADを行いたいですので...

　まだ何も出来ないですけど、もし気になる方は公開キー「PKKKYPKP」でどうぞ。 　なんか、3D格闘ゲームのコマンドみたいなキーですが^^;。 　一応、プログラムスロット管理の雛形が実装されてます。 　ゲームシステム、キャラクタービルダー、API、各種実装実験（通信機能、プチコンBIGの高解像度対応等）を並行してやっていくんで、あんまり進みは早くないです。長い目で見てやってください。 　ではでは。

　こちらが、作成中のキャラクタービルダー。下側のスケールを触ると、モーションの再生タイミングを選べます。ってか、まだそれしか出来ません^^;。 　オレンジのマスが登録したモーションで、グレーは補完で作成するモーションです。 　これをある程度作らないと、立ちモーション以外を作るのが面倒で辛い...

　ちょっと、考えているコンセプトを。格闘ゲームシステム本体と、キャラ作成ツールをセットにした統合環境（という程立派では無いですが）を考えてます。 　キャラを自由に作れて、各自追加データとして公開出来るというものです。 　後々は、ステージも作れるようにしたいですね。 　キャラ、ステージにはプログラムスロットを割り当てます。つまり、キャラ作成にはある程度プログラムを作る必要があります。 　作成の難易度は上がりますが、自由度は広がります。 　「格闘ゲームのキャラを作ってたら、プログラムを覚えられた」なんて状況を作れれば、最高ですね!

　3軸回転の多関節格闘ゲームの進捗です。月一ぐらいで書こうと思ったら、早速1月に間に合いませんでした... 　ちょっとだけ、ゲームシステムに着手しました。相変わらず立ち状態だけで操作できませんが。それでも、背景付いて2キャラ出すとそれっぽい気もします。 　少し処理速度の最適化を行い、この状態でCPU負荷70%弱@旧3DS。もう少し最適化しないと、飛び道具なんかの追加オブジェクトを出すと処理落ちしてしまうかも。

　BGでキャラクター番号0を表示したくて、色々やったら出来たので書き込み。既出だったらスイマセン。 　普通に「BGPUT LAYER,X,Y,0」とすると、BGの仕様により透明パターンとなります。が、アトリビュートを付けてスクリーンデータが0以外になれば表示が有効になります。 　アトリビュートのうち、180度回転と横反転+縦反転は同じ動作となります。両方有効にすれば、元どおりのパターンで表示出来ます。 　ちなみに画像では、「BGPAGE 4」でスプライト用パターンをBGに割り振ってます。

　軽微な箇所ですが...バグ報告です。図の3箇所のボタンを順番通り押すところで、北側のボタンに辿り着いていない状況でも仕掛けを解除できてしまいます。 　方法は、青1のボタンを押す→もう一度青1に行き「しかし、すでに押してある」のメッセージを出す→青2のボタンを押す、で再現します。 　ざっとソースを見たところ、イベントフラグ319（押されたボタン数カウント）が「しかし、〜」のメッセージ表示でもインクリメントされているのが原因のようです（EVENT15の1360行、1381行、1402行の条件漏れ？）。 　ゲームの進行には支障が無いと思いますが、念のため報告まで... 　ではでは。

　るかかさん、どうもです。格闘ゲームが作りたくて、ひそかに検討してました。 　基礎検討を綿密にやってたら、ここまででもずいぶん時間がかかってしまいました。

　LまたはRで、ワイヤーフレームを重ねて描画します。15部位で、CPU使用率35〜40%（旧3DS）。もう少し高速化しないと、厳しいかな... プチコンBIGだと、5%ぐらい。余裕のパフォーマンスですね。

　ちなみに1軸はスプライトの回転で行い、残り2軸は手書きの力技です。全ての回転角度は書ききれないんで、背中などの余り表示されないパターンは割愛する方向で。 　2キャラでスプライト折半なんで、512x256（からシステム分が更に減る）で結構ギリギリです。 　そして、某デュラルっぽいキャラでも、ドット絵不慣れなんで殆ど書いてない状態。動きを見るためには、もう少し頑張って書かないと...

　今年の作業記録。３軸回転の多関節格闘ゲームシステムなんてものを検討してまいた。やっと基本構造が形になってきた...立ち姿だけですが、公開キー「RBWX52AV」でサンプルを置いておきました。 　自由にキャラを作れて、追加できるシステムを検討中...完成は、いつのことやら。 　ではでは。

開発＆デバッグ、本当にお疲れ様です。 この問題は、「初めにプチコン3号でファイル作成を行った場合」には発生しないのですよね？ 既に何度か3号<->BIGでファイルの移動、上書きを行っていますが...特に問題無いようですので。

るかかさん、まじっくすと〜り〜完成おめでとうございます＆お疲れ様でした。既に「魔導〜」を上回ってますね(^^)。 折角なんで、私も初めからプレイしています。 ストーリーのあるゲームを一本作り切るのは、本当に根気の要る作業です。本当に、脱帽です。 最近あんまり公開できてないんで、私も頑張らないと...

思いつく短いコードは既に皆さん書かれてますので...スーさん同様、ゴルフ度外視で作ってみました。SORTコマンドを使う方法です。 ではでは。

　「バージョンが異なれば適用されない」という件ですが…恐らくは、「異なる著作物と認識できるぐらい機能が異なるバージョンアップ」の場合は前バージョンと異なる契約になると思います。 　逆に言えば、軽微な変更では前バージョンの契約内容を引き継ぐ(=二次公開許可)事になると推測します。 　

> MIKIさん 　なるほど、シュリンクラップ契約の有効性に絡めてのお話ですね…文科省の専門家でも良くわからないものなので、かじった程度の私では歯が立ちそうにありません(^^;。 　ただ、個人的には…契約を締結しないと対価を払ったのに全くサービスを提供されないシュリンクラップ契約と、プチコン3号の一機能である公開キーの二次利用許可契約は対等ではない気がします。 　特に経産省のレポートは、「契約を不服とする場合返品できるか」という趣旨の様ですし… 　二次利用許可契約が有効かどうかは、「その時の裁判所の解釈次第」と鳴るように思えます。 　著作権法は結構な頻度で更新されているようですが、それでもソフトウェアの変化には追いつけて無いようですので...

> うえこうさん 　プリセットのフォント、SPはおろか、EDITモードの画面レイアウトですら「スマイルブームの著作物」だと考えられます。ホームページを見る限り、二次利用、公開、展示その他は認めていないようです。 http://smileboom.com/requirement.php 　というわけで、厳密に言えばNGとなってしまいます。 　あくまで楽観的な意見ですが…YouTubeにアップすることが著作権侵害よりも広告効果の方が高い件、損害賠償請求を行っても殆ど請求できない件(下記参照)を考えると、訴訟に発展する可能性は低いのではないかと思います。 http://www.meti.go.jp/policy/ipr/infringe/remedy/remedy03-4.html

　二次利用の用途は、著作権法の規定は無い(二次的著作物とは言え、別の著作物であるため)です。このため、基本的にはなんでもOKとなると思います(さすがに原作者を偽る事はNG=氏名表示権は行使できますが)。 　代わりと言っては何ですが...原作者は、なんと「二次著作物の作者と同じ権利」を持つことができます(二次的著作物の利用に関する原著作者の権利)。二次的著作物の作者は、単独で著作権の行使ができなくなる(原作者が「待った」をかけられる)のですから…やっぱり原作者は強いです。 　ではでは。

　著作権を持つことによって得られる権利の中に、二次利用を禁止する権利(同一性保持権や翻訳権、翻案権等)があります。つまり、二次利用を認める/禁止する権利は、いろんな権利が集まった「著作権」に含まれるものです。 　公開キー取得の際の条件である「二次利用許可」は、プログラムを公開した時点で「私は二次利用を許可しました」=「著作権のうち、二次利用を禁止する権利を行使しません」という意思表示になります。つまり公開キーを取得した時点で、二度と二次利用を禁止する事は出来なくなります。 　二次利用許可(契約)と著作権どちらが有効かというと、(両方とも有効ですが、強いて言えば)「二次利用許可の契約」となります。