|
Ｑ．問い
|
Ａ．答え
|
|---|
|
V3.00で遅くなった気がします。
|
確かに遅くなりました。特に64ビット環境で遅さが困りものです。
プログラムでウエイトを入れている場合、減らす必要があるかもしれません。
原因は色々考えられますが、64ビット対応でメモリアクセスに更に高い負荷がかかるようになったことと、
iOS自体も遅くなったから、と思われます。
現状、解決策がありません。
スプライトが遅いのは単純に技量不足であり、別問題ですm(_ _)m
|
|
スプライトが遅い
|
これはもう技量不足としか言いようがありませんm(_ _)m。
追加費用なしにしたのでご勘弁いただきたいと。
現在のスプライトは100％自作で、純然にソフトウエア的に実現しています。
X68000のスプライトの仕様は簡単そうで実は結構難しく、特に各スプライトごとに
BGとの重ね合わせの優先順位が設定できる部分が難関でした。
でも、BGなしにしてもすごく遅いので、どこかに速度ネックがあると思われますが、解っていません。
iOSのスプライトを使えば速くなるでしょう。しかしそれを行うための時間と何よりも気力が足りません。
|
|
どのくらいのサイズまでのプログラムが作成可能ですか
|
ソースは64ＫＢまでです。配列のサイズは32ビットで管理しています(64ビット版でも)。
変数や配列は、グローバル・ローカル別に32K-1個まで登録できます(事実上無制限のはず)。
行数は(理論上)65533行までいけます。
|
|
iPhone/iPod touchの横画面で検索時にスクロール領域がほとんど取れないのですが。
|
これはデバイスの制約なので仕方ないです。
|
|
ヘルプ内の検索をエディター内のそれと同じに出来ませんか。
|
ヘルプ内検索は実はJavaScriptで実装されており、使える機能が全く違うため同じに出来ませんでした。
特に、検索で見つかった最初の位置にスクロールさせることは実現したかったのですが、
その命令を発行しているはずなのになぜかうまく動かないので今回は見送りました。
|
|
モーション系関数のサンプリングレートはどのくらいですか？
|
100ms固定です。
なお、方位取得は変更時即時なので、サンプリングレート設定はありません。
|
|
「最終行へ」を押したとき、最終行からちょっとずれている気がするのですが。
|
その通りです。が、iOSのバグのような気がしてます。現在のところ対策方法が見つかってません。
|
input/linput/inputWithPlaceholder()/selectMenu()/SelectMenu2()実行中に を押しても
プログラムが止まりません。
|
これは仕様です。
input系は、iOSの仕様により、入力待ちから強制的に抜けると異常になるため、止めることができません。
それらの実行中にを押した場合、入力後にプログラムが停止します。
selectMenu()中はそもそもが押せません。
selectMenu2()ではキャンセル扱いになり、リターン値として帰ってきます。
|
|
selectMenu系の表示位置を変更できませんか？
|
iOSで自動設定されるので、変更できないです。
|
|
正常に表示されないPICファイルがある。
|
いろいろなPICファイルを調べていると、どうも、Oh!X 1990年2月号に載っていたCで書かれたPICのサンプルソースの
仕様に合致していないデータを持つファイルが存在するようです(色数ではなく、データの格納され方がおかしい)。
たとえば、電脳倶楽部146号に掲載された、HIOTOKO.PICという画像がそれにあたります。
これはAPICG.rでは表示できますが、PIC.Rでは一応表示はできますがエラーが発生します。
原因を調べて対応しようかとも思いましたが、よくわからなかったのと、本来出力側の問題なので、止めました。
HIOTOKO.PICも、表示した後PIC.R /s または APICG.r /sで出力し直せば、正常に表示されるファイルになります。
IKPICなどで出力されたファイルなのだろうか・・・。
|
|
256色PICを表示できないか
|
256色PICは、ヘッダー情報はわかっても手元に実データが見つからず、APICGなどで無理矢理作ってまでサポートするのも面倒なので、
技術的の可不可はともかく、「時間をかけて実装するに値しない」と判断しました。
よほど要望が強ければ考えます。そのときはデータもくださいm(__)m。
でも、MAGで256色対応したので勘弁していただけるとありがたいかと。
|
|
MAKIファイル、200ライン画像、および16/256色アナログ以外のMAGファイルが表示できないのはなぜですか？
|
「データがない」が主な理由です。
MAG/MAKIファイルはかつて大量に持ってましたが、それを入れたMOやHDDがもう読めないので、
手元にかろうじて残っていた16色/256色アナログのMAGファイルのみサポートしました。
処理はフォーマット開発者Woody RINNさんの書いた「まぐろーだー仕様書・非売品」を基に一から起こしました(256色に関しては資料が記述不足で、どえらくデバッグに時間がかかりましたが)。
データをいただければ、MAKIや200ライン画像には対応するかもしれません。
これでPIC/MAG共に表示できるようになりましたが、残念ながら画面サイズを超える画像をスクロールや縮小して全体表示することは現状出来ません。
ビットマップ上には全体が格納されているので、表示処理だけ作れば良いのですが、
時間＆気力不足です。
|
|
circleX68()/circle16X68()の扁平率の挙動が違う
|
横方向の扁平率は同じですが、縦方向は同じにしきれませんでした。
graph.fncをdisったりLIB-Cのソースも見ましたが、
処理の実態がIOCS内にあるのでフローがわかりません。
実行結果から推測した処理を実装していますが、すべての値範囲(256～65535)では同じに出来ませんでした。
特にiOSの楕円処理への変換処理の精度の問題もあり、おおよそ4096以上では一致しません。
フローをご存知のかた、お教え下さい。
|
|
なぜBASICプログラムのインポート機能がない、もしくは廃止されたのですか?
|
アップルの審査で拒絶されたからです。
アップルは、BASICのソースも含め、いかなる形式の実行ファイルもインポートを許さない方針のようです(データは可能)。
BASICソースなんて、アプリの上でしか動かないスクリプトのようなものなのになぁ。
「何とかならないか」ということに対する答えは、サポートブログ(更新終了)の中にあります。
アップルにバレたら困るのでここでは詳しく書きません。
|