いつもimgctlを便利に使わせて頂いております。

さて、ひとつ質問があるのですが、、、
クリップボードから

HANDLE hMem = GetClipboardData(CF_DIB);
void *lpMem = GlobalLock(hMem);

のような感じで取得した画像データ（lpMem）から、
imgctlのHDIB形式に変換する方法というのはあるでしょうか？

CreateDIB()を使った場合には、
HDIB hDIB = CreateDIB(pbmi, pvData);
のような引数ですが、

pbmiはlpMemをキャストするだけで済むと思うのですが、
pvDataの計算方法がよく分かりません。

何かよい方法がありましたら教えて頂けると助かります。

実際に試したわけではないですが、16ビット以上の非圧縮形式の場合であれば、
BITMAPINFO* headPtr = (BITMAPINFO*)lpMem;
としたとき、 headPtr->bmiHeader.biSize にヘッダのサイズが入っていますので、それを使って
BYTE* dataPtr = (BYTE*)lpMem + headPtr->bmiHeader.biSize;
とすればよろしいかと。

ただし、パレットカラー（8ビット以下）の場合や headPtr->bmiHeader.biCompression != BI_RGB の場合はヘッダと実データの間にパレットデータやらビットフィールドデータやらが入りますのでこれではうまくいかないと思います。

imgctlというよりBMPファイルフォーマットの話ですね。
当サイトの『BMPファイル仕様』を見たり、「BMPファイルのフォーマット」でググってみたりしてみてください。

レスありがとうございました。

つまり、パレットやビットフィールドがある場合には、自分でオフセットの値を計算する必要があるということですね。

> それを読んで、改めて考え直してみたんですが、つまりこういう処理なの
> でしょうか？
それで合っています。
再帰処理は使っていません。

> だとしたら結果、出来上がったパレットは
> ピクセル数の多い順に綺麗に並んでいる？！
パレットを作り終えた時点ではそうなるでしょうね。
各ピクセルでのパレット色の選定時に誤差拡散法を適用しているので、最終的な順序は前後する可能性がありますが。

> imgctlの「16bitカラー」とは
> RGB各、5bit,5bit,5bitの「32768色」でしょうか？
> それともWindowsのHighColorのように
> RGB各、5bit,6bit,5bitの「65,536色」でしょうか？
どちらも、というかそれ以外のビット数にも対応しています。

> dwBitFields を NULL にすると 5bit,5bit,5bit になります。
この部分について補足しておきます。
dwBitFields を NULL にするとビットフィールドは保持されません（Win32的に言うと、圧縮タイプが BI_RGB になる）。
そしてBMPの仕様により、16ビットBMPの場合は 5bit,5bit,5bit 、32ビットBMPの場合は 8bit,8bit,8bit であるものとして扱われます。
※当サイトの『BMPファイル仕様』内にも同様のことが書かれています。

回答ありがとうございます。返信が大変遅れてしまってすみません。
「dwBitFields」に「ビットフィールド」を指定するんですね。
imgctlの設定の柔軟さに改めて驚いています。
ヘルプを見直すと、しっかり書かれています。読みが甘く申し訳
ありませんでした。それでもレスを付けて頂いて感謝しています。
「ビットフィールド」については『BMPファイル仕様』を読ませて貰って
構造をきちんと分かっておきたいと思っています。
　それでは、返信の遅れを重ねて詫びつつ、取り急ぎのお礼までに。
ありがとうございました。

直方体と立方体、間違えてるよ

確かに。
立方体→直方体と読みかえてください。

こんなに詳しくありがとうございます！
ここまでネタバレしてくれると思いませんでした。
とりあえずもう１周して来ます。
わからなかったらまたよろしくお願いします。
それと続編は無いんですか？
このサイトから空想世界がDL出来ないのもびっくりしました・・・
ルーチェさんの中で無かった事になってるんでしょうか。
悲しいです。

>>19
> それと続編は無いんですか？
気のせいです。

> このサイトから空想世界がDL出来ないのもびっくりしました・・・
> ルーチェさんの中で無かった事になってるんでしょうか。
公開してからもうすぐ10年です。
そりゃあ心変わりもしますし、サイトも変わっていきます。
変わらないのはサイト名くらいでしょうか。

要するに、高校生の頃に作った黒歴史満載の自作RPGを嬉々として公開し続けるようなマゾではないということです。
自作RPGではイメージしにくいなら「高校生の頃に書いた自作小説」とかに置き換えて考えてみてください。
それでもイメージできないなら多分価値観が違うのだと思いますが。

ただ、ゲームを作ることに興味を失ったわけではないです。

空想世界で４つの本の入手方法と３つのメッセージを見るためにはどこでなにをすればいいのか、そのあとの混沌の心の入手方法を教えてください

いきなりすみません。自分は水月魅音と申します。初めまして。
しろくろねこっ！と言うサークルの部長をやっているものです。

以前、白魔道士縛りでの動画を拝見させて頂き、とても楽しませていただきました。
白魔道士縛りが完結した今ですが、誠に勝手ながら自分のサークルで白魔道士縛りのノベルゲームの作成を開始しました。事後報告ですみません。
もう少し完成すれば体験版を配布する所まで来ているのですが、キャラクター創作者様にご連絡をしていないという事で慌てて探しました所、このホームページに辿り着きました。
勝手にキャラクターをお借りして、あげくゲームを制作している事を連絡せずに大変申し訳ございません。
つきましてのご相談なのですが、このままゲームの製作を続けてもよいでしょうか？もし、やめてほしいという事であれば、連絡を頂いた後に制作を中止致しますが、いかがでしょうか？

ご参考までに、当サークルの活動ブログを記載させて頂きます。お返事を頂ければ幸いです。
http://suigetumion.blog65.fc2.com/
それでは、用件だけで申し訳ございませんが失礼いたします。

>>22
大丈夫だ、問題ない。
一番いい白魔道士を頼む。

Pixivでちょくちょく白魔縛り絵をブックマークしたりしているので、ゲーム作ってる事もブログも知ってました。
どんなシナリオでもどんなキャラ付けでもご自由にどうぞ。
製作頑張ってください。

BMP RLE 圧縮の Sample Program は大変参考になりました。ありがとうございました。
ところで、行 Data の Encode の Program に 2 ヶ所不具合があるようです。ちょっと残念なので Feedback させていただきます。

1. 99 行目の後に追加
---
// 今までの連続データがあればエンコードデータ書き出し
pdest += store_encoded(pdest, prev, cont, bitcount);
cont = 1;
abso = 0;
/*
これを入れておかないと "連続1", "連続2", "絶対" と来た時に
"絶対" の先頭 Address [pabs] が "連続2" の先頭 Address を
指してしまう。
*/
---
2. 117〜124 の条件分岐を入れ替え
---
// 残りのデータを書き出し
if (cont >= 2)
{
pdest += store_encoded(pdest, prev, cont, bitcount);
}
else if (abso >= 0)
{
pdest += store_absolute(pdest, pabs, abso + 1, bitcount);
}
/*
この条件分岐をひっくり返さないと最後が "連続1", "連続2" と来た時に
"連続2" が "絶対" として誤認識されてしまう。
*/
---

後、連続 Mode は 2byte 以上ではなく 3byte 以上にした方が圧縮後の Size が小さくなる確率が高くなるようです。
ちなみに、PhotoShop は 4byte 以上に設定されているようです。
この設定 Prameter を minbyte として可変にした Version の Program も組んでみましたが、120行の投稿になってしまいます。
ルーチェさんのお許しが出たら投稿させていただきますので、ご検討ください。

不具合報告ありがとうございます。

頂いた指摘を元に該当コードを書き換えてみました。
不具合の根本原因は「絶対モードのカウンタ（abso）が初期化されないパスがある」ということのようでしたので、
if (cur == prev) の場合には必ず abso = -1; によるカウンタ初期化を行うようにしました。
これで指摘1にも2にも対処できたはずです。

> 連続 Mode は 2byte 以上ではなく 3byte 以上にした方が圧縮後の Size が小さくなる確率が高くなるようです。
確かにちょっと考えてみると、
AABCDDEF
というデータに対しては
2A1B1C2D1E1F
とエンコードするより、すべて絶対モードにまとめて
08AABCDDEF
とエンコードしてしまった方がサイズは小さくなりますね…。

ルーチェさんの許可も出ましたので、以下に修正 Version のご提案をさせていただきます。

1. Encode 時の連続 Mode の最小長さを可変にする。(とりあえず Photoshop の設定 4 で Coding)
2. Decode 時の Error Check を強化する。(Decode 時にしか Check できないもののみ)

ちなみに、ルーチェさんの Simple な Code 形態は私好みです。別にケチをつけているわけではありませんので、念のため。
本文に反映するかどうかはこだわりません。一応、情報提供ということでご理解ください。

1. 連続 Mode 可変
---
...略...

// 行データのバイト幅及び最大連続バイト数設定
long bytelen, maxbyte, minbyte;
switch (bitcount)

> if ((abso >= 1) && (minbyte == cont))
掲示板プラグインの修正ミスで、この部分がPukiWikiの注釈と誤認されて「abso >= 1) && (minbyt...」のように置換されてしまっていました。
minbyt... 以降のコードが亜空間に葬り去られていたので、多分 (minbyte == cont) だろうと思って修正しましたが、間違っていたらご指摘ください。

コード提供ありがとうございます。
すぐにとはまいりませんが、反映できそうな部分は反映を検討します。

一応 "(minbyte <= cont)" のつもりでしたが、cont が 2 以上になるのは "cont++" は一ヶ所のみですので "(minbyte == cont)" でも問題ないかと思います。