xampp と workbench

今年は気合入れてやるぜ！と元旦から、キーボードに向かってカタカタ入力しているラターシュです。

xamppとworkbenchのインストールをしら、まずは MySQLのデータベースを構築し、phpでアクセスするのが、一連の流れ。

以前は、週に３つのブログを立ち上げたこともあるくらい、データベースとかHTML触ってましたが、ここ数年はさっぱり。

まあ、仕事の一環で、会社PCに両方ともインストールしているので、特に問題はない。

…と思ったら大間違いである。

早速、トラブルに見舞われたので、ここに記録しておこう。

Failed to Connect to MySQL at 127.0.0.1:3306 with user root SSL connection error; SSL is required but the server doesn’t support it

まずはこのエラーである。
これは、workbenchがxamppへの接続にSSLが要求されているが、xamppがそもそもSSLに対応していない、というのが原因らしい。

設定を見ると、Use SSLの項目が、Require 一択になっている。

これでは、どうしようもないので、workbenchのバージョンが低いものをダウンロード。

同じようにSSLのところを見ると、

if available
が選択できたので、その設定にすると、無事にMySQLとworkbenchが接続できた。

なぜ、require 一択になってしまったのかは知らないが、もし同じエラーが出たら、バージョンを戻して試してみるといいかもしれない。

2022年 プログラム初め

もう2022年である。

前回の投稿が2019年なのはともかく。
去年2021年は、今までで一番高速に過ぎていった。

まるでそんな年はなかったかのように…。

歳を取ると時の流れが速くなるとは言うが、そんな生ぬるい速さではなかった。
今年は、そういうことにならないように、１月１日から、色々やることにした。

まずは、購入して、ほぼ放置していた、ゲーミングデスクトップ。
いくつかゲームをインストールして遊んだ程度である。

まずは、これをプログラム環境にすることから。
ちょうど、メインで使用していたノートPCの調子が悪くなったので、各種データの移行も併せて色々やろう。

…で、さくっとやったのが以下。

・いつものテキストエディタのインストール
・VisualStudioのインストール
・xamppのインストール
・mysql workbenchのインストール
・Android Studioインストール

インストール後は、ちゃんと色々起動して、ビルド・接続などができるところまでは完了。

今時、こういうブログで色々書いて公開できるのに、
わざわざ年会費払って独自ドメイン取得している個人はそんなにいないだろうな…。

放置状態だから、ページもボロボロだし、サーバー側のバージョンアップの関係で、データベースも初期化されてるから、動作もやばいだろうし。

次にするのは、このWebサイトの手入れか、Androidアプリの作成かな。

プログラムブログ更新は久しぶり

 毎日プログラムしてるけど、ほぼ更新してない！

HSPもcocos-2dxも全く触れて無いわ！

つか、ほぼ毎日、終電だゴルア！

まあ、楽しいのでいいんですがね。

不具合修正のプログラムが楽しい人ってそうそういないか。

で、不具合について。

Windows.forms.System.SplitContainerを使ってフォームを作る。

これは、左右２つのパネルをSplitterで分割するフォームパーツだ。

このSplitterはアプリ使用者が自由に動かすことができるが、

アプリを再起動すると、デフォルト位置に戻ってしまうので、位置をキープして欲しい、というもの。

実は、保存する際に、値はちゃんとシリアライズされている。

ではなぜ、ずれてしまうのか？

それは、いわゆる仕様バグである。

まず、SplitContainerを、幅200で初期化・作成する。

Splitterの位置は、100(ちょうど中央)とする。

※ちなみにSplitter自体の幅は4

ここまではちゃんと、再起動時にデシリアライズされている。

問題は…。

作成したこのSplitContainerを、Dockに収めていることだ。

その際、300とか400とか大きめのDockにはめ込んでいるため、

幅200で作ったSplitContainerが、引き伸ばされる。

全体が均等に引き伸ばされるため、spliterの位置が、右にずれるのだ。

そしてこれが保存され、次回再度引き伸ばされ…。

デフォルトに戻るどころか、どんどん右にずれていく、というのが現状だったようだ。

解決するのは簡単で、Splitter自体は自由に動かせるが、ウインドウサイズを変えても、

パネルサイズを変更しない、fixedPanelプロパティで、Panel1（左側）を固定にするだけでいい。

…のだが！

実は罠があるらしい。

今開発しているツールは、各種機能が複数のタブによって仕分けされており、

この複数のタブそれぞれに、SplitContainerが使われている。

前半で述べた方法で、これらすべてのSplitterの位置は個別に保存されるようになったのだが、

どうやら、リセットするトリガーがあるらしい。

タブ３にある、Splitterの位置を動かしたら、なぜかタブ１とタブ２の位置がリセットされるのだ。

（現象はランダムで、変わらない場合もある）

現在、このリセットされるトリガーが何か？が調査対象である。

オリンピックのボランティア募集が盛り上がってますな！

というわけで、私も応募に挑戦です！

「Webデザインでやっちゃいけないことを全部やってる」
って言われたら、やらないわけいはいけないでしょ。
BAD UI、気になりますよねー。

ってことでサクッと行ってみましょう。
忘れるといけないので、入力しながら、リアルタイムでこっちに気づいた点を記載するぜ。

まず皆に言われているが、応募したら英語ページに行くという罠。
右上に切り替えボタンがあるってことだったが、国旗マークがあるだけだった。
切り替えかどうかすら説明がなく、自分で気づけだったとは。

次。ログインアカウント。
Facebook等のアカウントを要求するのはレベルが高いということだったが、
アカウントがなくても、新規登録画面はあった。
なので問題なし。

しかし。ここからは問題！
まず、そもそも。
ボランティアの応募のはずなのに、「マイページ開設」にすり替わってる罠。
なんや、マイページて。
さらにここに来る前に、６ページ分の入力があるって注意書きがあるが、
なんで「プライバシーポリシーへの同意」が最後やねん！
それ最初に確認させる奴や。
入力し終わった後に、同意できない内容だったらどうするんだっての。

とかいいつつ、マイページ新規登録の入力ページを開くと。
６つのテキストフォームがあるのだが、
　パスワード*
という風に全部に * マークがついている。
このマークの説明一切なし。
また、説明の補足のためか、i マークがついているのだが、
パスワードの項目についた iマークをクリックしてみると…。

「９文字以上、半角英小文字、半角英大文字、半角数字を含む」という説明が。
いや、それずっと出しておけや。
わざわざクリックしないと読めないってダメやろ。

いくつかワザと間違って登録ボタンを押してみたが、どこが間違っているのか、
明確に指摘してないとか、もう全然ダメ。
（大文字で入力してくださいだけ言われてもな！）

次に表示されたのは、個人情報保護方針。
大体テンプレのような内容だが…。第三者から本人の個人情報を取得する場合があるという。
まあ、facebookなどから情報を得る、等の想定だろうが…。
「銀行口座、宿泊先、予定」
うーん、何気に変な項目も交じってるぞ。
つか、他の団体から情報を得る場合、まずは本人（私）が、そっちにOK出す必要があるんじゃないのか？
このポリシーはボランティア専用ではなく、オリンピック全般のもののようなので、チケット・グッズ販売とか、広告表示用とかでも表示されるものと共有だから、まあ、こういう書き方になるんだろう。

ネットでは、情報漏洩までが１セットって言われてるし、この保護方針は念のため保存しておこう。

というわけで、テンプレのある文章はそこまでズレてはいないが、
Webデザインは、ちょっとダメなレベル。
まだアカウント登録しかやってないが、それでも疲れたんで、次回へ続く。

cocos2d-xを始めてみる。

HSPでプログラム作っていたんだが、ちょっと浮気して、
別の言語を試してみようと思い立つ。

Windowsでゲームが作れるものといえば、Unityとか思いつくが、
ライセンスであったり、ロゴ表示の問題もあるので、
フリーで使用できるという観点で、cocos2d-xに決定。

スマホアプリを作るイメージがあるが、当然、Windows用も作れる。
導入から解説しているページを見て、サクッと作るぜ！

…。
…。

と思い立ってから、サンプルを実行するまで、５時間もかかったわ！！

VisualStudioはインストールしていたものの、C++での開発環境入れてないとか、
他にもcocosをビルドするのに足りないパッケージがあるとか、
導入について解説している内容では全然足りないって！

という過程を経て、ビルド環境と実行環境を得る。
３０分でサンプルが動くHSPとはえらい違いだ。

まあ、その分、C++（っぽいもの）で開発できる、実行速度が速い、というメリットはあるが…。

そもそも、AndroidやiOSで動くものも作れるという時点で、
素のC++ではなく、覚える作法（APIとか）はいっぱいあるわけで、
その点については、HSPから乗り換えるメリットは薄い。

逆に、ゲームを作るのに覚える量は変わらないので、乗り換えによるデメリットもないとも言える。
とりあえず１週間ほど触ってみて、無理ゲーだったら、HSPでがんばろう。

HSPを少しずつ進める。

何事も放置すると、忘れたり、鈍ったりするわけで。
少しずつでもHSPのプロジェクトを完成に近づけなければ。

そもそも、何を作るかすら決まっていないけどな！

さて、今日の目標は、１０年前には無かった（はず）module機能についてだ。
追記：過去のソースコードに、#module が記述されていた。ただ、それだけで、modfuncなどは使ってなかった模様。

とりあえず、インスタンスを作り、モジュール関数をコールし、
いわゆる、セッターやゲッターの動作も確認できた。

一通りやった(つもり）なので、早速実践。
ゲームには必須である、画面のフェードイン/アウトアウト機能をmoduleで作ってみる。

基本は、過去に deffunc で作ったものをコピペ…する予定だったが、
目に余るコードだったため（笑）、１から作り直す。

とはいえ、ゲームプログラマなら、
簡単なフェードシステムのコード書くのに30分も掛からないはずだ。

というわけで、出来たものを実行っと。

　う　ご　か　な　い　！

いや、そんなはずは。
ちまちまとミスはあったが、そんなレベルではない、何かが違う。

試しに module外のメインループに移すと、きちんとフェードしている。
ということは、moduleが独立空間であるがゆえに、何かしらの障害が発生しているということだ。

さて、なんだろうか？
もしかして、module内では、gsel や gcopy などが使えない？
ありえそうだが、マニュアルには、そういうことは、一切書いてない。
さらに、付属のサンプルでは、思いっきり、moduleの中で、gcopyしてる。

まったくわからん！

が、独立空間という観点で見たときの問題が、もう１つあるじゃないか！

ゲーム作りの鉄則として、後から変更がありそうな部分は、define で一括で変更できるようにする。
Windowsのゲームだと、画面サイズなどが真っ先に定義される。
今回も、
#define screenW = 1280
#define screenH = 720
と定義している。
が、定義している箇所は、当然、#globalだ。

module内の gcopyは、

gcopy 1,0,0,screenW,screenH
になっている。

全くエラーは出てないが、これが悪いんじゃね？
というわけで、変更。

gcopy 1,0,0,screenW@,screenH@

ビンゴ！うまく表示されたわ。
うーむ、module内で全く定義せずに使用している変数は、
エラーを出さず、0として使われてるようだな。

マニュアルでは、module内から globalを参照するのは推奨しないとされている。
スクリーンのサイズを取得する変数や関数があるだろうか？

…あった。

画面の描画エリアXサイズ
ginfo_winx
画面の描画エリアYサイズ
ginfo_winy

定数をこちらに置き換えて、動作することを確認。
ま、なければ、セッターで画面サイズ渡せば良いだけか。

こういうのが、やってて面白いところだな。

追記：
#define の後に、global をつけることで、全module対象になるんだと！

#define global screenW 1280

これが正解の書き方ということだな。

再びHSPを始めたんだが。

過去に、HSPを使って商品を２つ作ってリリースしたことがある。
2006年頃、もう１０年以上前だから、HSP1.0だろうか？
もっともメインじゃなくて付録的な位置づけの作品だったが。

一応そのソースを持ってきたが、現在の HSP3.5では、互換性が無かった。
当たり前だが。

まあ、色々便利になっているし、サンプルやドキュメントが格段に整備されているので、過去に触れていたということもあるが、１０分程度で画面は表示できた。

module 辺りを中心にいじってみる。
うまく使えば、オブジェクトっぽいものが表現できると思われるが…。

module内に作成した関数、modfunc にアクセスする方法が
module関連のドキュメントで全く触れられてないのが残念すぎる。

モジュール変数とかコンストラクタとか、
だいたい一定のルールの記述方法なのだが、なぜモジュール関数(modfunc)だけ、

val = funcname(modVal)

という方式にしたんだ…。
ルールに従ったら、

val = funcname@modVal
val = funcname modVal

辺りが妥当なところじゃないか？
せっかく module関連をまとめたドキュメントが用意されてるのに、
これ説明しないでどうするよ…。

結局、moduleのサンプルコード見て探し出したが、
初見殺し過ぎる…。