2016年12月29日木曜日

■Android上で自作アプリからDPMファイル内のテキストデータを読み込んだ後で気を付けること

例えば以下のような文字列を比較するプログラム(*1)でS-JISのテキストファイル"test.txt"(*2)をDPMファイルに含ませてアプリをビルドし、Android上で実行させるとどうなるでしょうか?


(*1)
;--------------------------------------------
; 開始
;--------------------------------------------

#include "hsp3dish.as"

      setcls 1, $000000
      color 255, 255, 255

      dat = ""
      notesel dat
      noteload "test.txt"

*main
      redraw 0

      get_tx = ""
      noteget get_tx, 0
      pos 0, 0
      if get_tx == "A" {
            mes "[A]と同じです"
      } else {
            mes "[A]と違います"
      }

      get_tx = ""
      noteget get_tx, 1
      pos 0, 50
      if get_tx == "あ" {
            mes "[あ]と同じです"
      } else {
            mes "[あ]と違います"
      }

      redraw 1
      await 16
      goto *main

;--------------------------------------------
; 終わり
;--------------------------------------------


(*2) test.txt
-------
A
あ
-------


結果はこうなると思います。


[A]と同じです
[あ]と違います


なぜこうなるのでしょうか?

実は、Dish Helperでビルドされる際のソース内の文字列に関係があります。

通常のHSP(Windows上で動作する)は、文字コードはS-JISで処理されておりますが、Dish Helperでビルドされたアプリは内部の文字列の文字コードは全てUTF-8に変換されております。
また、DPMファイルにS-JISのテキストファイルを含めてもDPMファイル内のファイルは特に変換はされません。

感の良い方はここで気づいたと思います。

答えは、ソース内の「if get_tx == "あ"」の「あ」とテキストファイル内の「あ」は全くの別のものということです。
先ほども書きましたが、Dish Helperでソースをビルドするとソース内部の文字列は全てUTF-8の文字コードに変換されます。

もう少し具体的に書きますと、


S-JISの「あ」の文字コード = 1バイト( 130 ), 2バイト( 160 )
UTF-8の「あ」の文字コード = 1バイト( 227 ), 2バイト( 129 ), 3バイト( 130 )


というふうになります。

それでは、文字列をif文などで比較したい場合どうすればよいのか?

一番確実な方法としては、DPMファイルに含ませるテキストファイルをUTF-8で保存してからDish Helperでビルドをする方法です。
もう一つの方法としては、プログラム内で文字コードを書き換えて自前で文字を変換する方法です。

どちらの方法も利点と欠点がありますので自分のやりやすい方法で行うとよいでしょう。
ただし、「文字の変換ってどうやるの?」という人は、前者の方法(テキストエディターなどでUTF-8で保存したものをDPMファイルに含ませる)てビルドするようにしましょう。

2016年12月28日水曜日

■HSP3Dish上でのタッチ処理は「getkey」や「stick」ではなく「mtlist / mtinfo」を使うこと

例えば、以下のようなソースを組んだ場合、Windows上で動かしたときにどのような問題が出るでしょうか?


;--------------------------------------------
; 開始
;--------------------------------------------

#include "hsp3dish.as"

#const KEY_LEFT_CLICK 1

      setcls 1, $000000
      color 255, 255, 255

*main

      redraw 0

      tap = 0
      getkey tap, KEY_LEFT_CLICK
      pos 0, 0 : mes str(tap)

      redraw 1

      await 16
      goto *main

;--------------------------------------------
; 終わり
;--------------------------------------------



このソース内容は、ウィンドウ内をマウスで左クリックしている間ウィンドウの左上の位置に「1」が表示されるようになっています。

実際に実行してみると、確かにウィンドウ内を左クリックしている間は画面上に「1」が表示されます。
一見全く問題の無いようなソースですが、画面タッチが可能なWindowsタブレットPC等でこのソースを実行し、左クリックの代わりに画面をタッチすると何が問題なのかが分かります。

実は画面タッチ可能なWindowsタブレットPC等でこのソースを実行すると、画面をタッチしても画面上に「1」は表示されません。
もう少し詳しく書きますと、「getkey」命令の箇所で「1」ではなく「0」が返ってきます。

表示される答えとしては「画面をダブルタップ」すると画面上に「1」が表示されます。
つまり、ダブルタップをしないと「getkey」命令の箇所でクリックと判定されないのです。
これは「stick」命令についても同様です。

これがHSP3Dish上の仕様なのか不具合なのかはわかりませんが、Androidアプリを想定してプログラム作るのであれば、マルチタッチに対応している「mtlist / mtinfo」を使うように心がけましょう。

2016年12月27日火曜日

■作ったアプリのテストをなるべく簡単に行うために

HSP3Dishで作成したAndroidアプリをAndroid端末にインストールするには以下の方法があります。


  1. AndroidのファイラーからSDカードやネットワーク経由でビルドしたアプリをAndroid機にインストールする方法。
  2. USBデバックモードを利用してDish HelperからビルドしたアプリをAndroid機にインストールする方法。


1つ目の方法は、Android機のファイラーからWindows側のアプリが入った共有フォルダーにアクセスしてインストールする方法です。
欠点は、Dish Helperでアプリをビルド後にAndroid機側で毎回ファイラーを起動してインストール作業を行わなければならないことです。
インストール作業が1度か2度など少ない回数であればこの方法でも全く問題ありませんが、作成中のアプリを調整などで何度も動作確認したいのであれば手作業でのインストール作業は意外と面倒になります。


2つ目の方法は、Android機の「USBデバックモード」を利用し、Dish HelperからAndroid機へ自動インストールを行う方法です。
こちらの方法はビルド後のアプリをDish Helperの「転送」ボタンを1クリックすることでAndroid機へのインストールを勝手に行ってくれます。
利点はビルド後のアプリをAndroid機へインストールする手順と時間が大幅に短縮されることです。
とても便利な反面、USBデバックモードを利用するにはまず最初にWindows側に「ADBドライバ」を入れておく必要があります。
「ADBドライバ」はWindows機とUSBケーブルで接続しているAndroid機の専用ドライバになり、ドライバは端末のメーカーWebサイトなどでダウンロードできます。

また、USBデバックモードを利用する場合にはAndroid機側でもUSBデバックモードを使用するための設定を行っておく必要があります。


慣れないうちは1つ目の方法でアプリをインストールするし、インストール作業に慣れたら2つ目の方法でインストールしてもよいかと思います。

■HSP3Dishでアプリを作るときの基本ソース

通常のHSPはWindows上で動作するアプリケーションを作る場合、「redraw 0」で画面の更新を停止させても現在の描画先の表示状態はそのままになりますが、HSP3Dishの場合「redraw 0」で画面がクリアされます。
そのため、HSP3Dishでアプリを作る際は通常のHSPと勝手が異なるため注意が必要です。

HSP3Dishの基本となるソースを以下に記載したいと思います。


;--------------------------------------------
; HSP3Dish基本ソース(開始)
;--------------------------------------------
#include "hsp3dish.as"
 
      ; setcls [mode], [color]
      ;
      ; [mode]  = 「redraw 0」での画面クリア設定(0:画面クリアしない, 1:画面クリアする)
      ; [color] = 「1:画面クリアする」の場合、画面クリア色24bitRGBコード($rrggbb)
      ; 
      ;(注意)
      ;     スクリプト内で画面のクリアを行なっている場合は、
      ;     「setcls 0」の方が処理速度の向上につながります。
      setcls 1, $000000
 
*main
      redraw 0
      ; ====================================================
      ; 画像表示などの処理はこの場所に記載していく形にする
      ; ====================================================
      redraw 1
      wait 1                ; await でもOK
      goto *main
 
;--------------------------------------------
; HSP3Dish基本ソース(終わり)
;--------------------------------------------


以上がHSP3Dishの基本となるソースとなります。
これはあくまで一例なので人によっては作り方が異なることがあるかと思いますのでそこはご了承ください。

■HSP3Dishで作ったAndroidアプリが突然落ちてしまう場合

HSP3Dishで作ったアプリをAndroidで動作させてプログラムに不具合があったりDishの仕様を守っていないとアプリが突然落ちます。
エラー情報が画面に表示されず急に落ちるために、「だいたい『コレ』で落ちてるんだろう」とある程度想像できる場合はよいのですが、「Windows上ではちゃんと動いていたのになんで!?」という場合だと不具合個所を特定するのは容易ではありません。

そこでアプリが突然落ちてしまったときに落ちてしまう個所を見つける方法です。

  • Dish Helperの「Logcat」ボタンをクリックしコマンドプロンプトが起動している状態でAndroidにインストールした自作アプリを起動する方法。
    この方法はAndroidのUSBデバックモードを使用してWindowsのコマンドプロンプトの画面にアプリ実行中の状態を表示します。もしアプリが突然落ちてしまう場合にはコマンドプロンプト画面にHSPのエラーコードが表示されます。
    ただしエラーコードが分かってもどの場所で落ちているのかまではわかりません。
  • プログラムソース内に怪しいと思われる個所に文字表示命令やDialog命令などを入れておいて視覚的に落ちている個所を少しづつ探し出していく方法。
    この方法は少し手間がかかりますが、手当たり次第にソースをいじくり回すよりも安全です。
落ちてしまう個所を見つけるのが困難な場合上記の2つを組み合わせて行うことで特定しやすくなるかと思います。

■HSP3Dishで作ったAndroidアプリでエラーを出さないために

HSP3Dishで作成したアプリをAndroid上で動作させる場合の注意点です。

  • Dishの仕様を守っていない場合、Windows上で正常に動作しているプログラムでもAndroid上はで突然落ちることがあることを頭の片隅に覚えていく。
  • 作成中のアプリのプログラムが、「doclib\support_cmds.txt」内のHSP3Dishサポート済み(コマンド, システム変数・関数, プリプロセッサ命令, マクロ)に沿ったものだけをちゃんと使用しているか?
  • データファイル(DPMファイル)内のファイルのファイル名の文字数が15文字を超えていないか?

その他の詳しい情報は「HSP3Dish android(NDK)版プログラミングガイド」を読んでみましょう。

2016年12月26日月曜日

■Dish Helperでエラーなくビルドを通すために

HSPソースをAndroidへエラー無くビルドする心構えは

  • はじめてHSP3Dishを使う人であれば、最小限のプログラム(文字だけ表示など)をビルド対象にする。
  • プログラム内で使用している命令や関数がAndroid上でも動作するものなのかを確認する。
  • 慣れないうちこまめにビルドしてAndroidで動作確認をする。

これらを意識して作るとそこそこ大きなプログラムでも一発でエラー無くビルドが通るかと思います。

ただし、ビルドが通ったからと言ってAndroid上で動作するかどうかは別問題なので、慣れないうちはこまめにビルドをしてAndroid上で動作確認をするように心がけましょう。
いきなり大きなものを作ってもAndroid上で動作しなかった場合どこに原因があるのかの判別が難しくなります。
なのでこまめに確認していきましょう。

macOSのシステムデータを減らす方法

  Time Machine ローカルスナップショットの消去 バックアップ待ちのデータ(スナップショット)がシステムデータを肥大化させていることがよくあります。 方法 :  ターミナル  を開き、以下のコマンドを入力して実行すると、古いスナップショットが強制的に削除され、数 GB...