盛り上がらないMPWスレ - 1063116069

1：ぷご★：2003/09/09(火) 23:01: 無料で提供されているにもかかわらず､ユーザ数の
少ないまま消え去ろうとしている。

でも、僕にとってはHyperCardよりも人生を変えた
そんな開発環境なんだ。

-- Macintosh Programmers Workshop --
2：ぷご★：2003/09/09(火) 23:03: XCMDを作るなら最強かも。
pugoGLはさすがにダメか。
いまさらMPWでゲーム作ってもねぇ。

役に立たないコード置き場
http://hp.vector.co.jp/authors/VA019519/CODE/
3：eagle：2003/09/13(土) 04:36: マラソンもどきでも作るとか。
今ならＡＤＳＬ回線使えば、ネットワーク対戦も可能ではないかと。
4：ぷご★：2003/09/15(月) 22:28: >>3
出来たらいいね。としか言えないです。
5：eagle：2003/09/16(火) 19:31: どうせマラソン２のソースコードは大切に所持しているんでしょ？
6：ぷご★：2003/09/16(火) 23:17: >>5
多分どこかにはあると思うが。
見ることはなさそう。

今探したら、VBLのコードだけ残ってた。
垂直同期合わせるつもりだったんだな。
PgColorXで。
7：smoke stack software：2003/09/29(月) 19:49: 「MPW & pugoGL」は僕にはとっても重要です。
これがないとC言語でプログラムできません....。
pugoGLが開発中止になってちょっと残念です。
線を引いたり、点を打ったりできるコマンドがあったらいいなぁと
思っていたんですが。
あと、Win(ygs2k)と互換性があるのがすごいと思います。

http://www.geocities.jp/terror_cage/index.html
8：ぷご：2003/09/30(火) 01:44: pugoGL使うより､いわゆるToolbox関数使うほうが便利だと思います。
資料も多いし。

個人的にはPgColorXは何かと便利なのでかなり使ってるのですが､
pugoGLは何かと面倒でして。

勝手なヤツですいません。
9：smoke stack software：2003/10/16(木) 22:16: >>PgColorXは何かと便利なので
MPWでPgColorXを使ってC言語のアプリケーションを作る
ということでしょうか？
PgColorXのソースコードを利用できるのかなと思って、見たんですが、
レベルが高すぎて（そもそもC言語が難しい..）理解できませんでした..

ゲームライブラリを使わないでC言語で作ると
ウィンドウをひとつ表示するのにもなかなか難しいものですねぇ。
彊良さんのホームページにある「MPWでプログラミング」をよみながら
基本的なところから勉強中です。
10：ぷご：2003/10/16(木) 23:02: >>9
PgColorX+HyperCardです。
速度が遅いこと以外は不満無いです。
C言語ではデータベース機能やインターフェースが厄介なんで。
PgColorXはXCMDだから、ソースコードを見ても価値無いですよ。

C言語を覚えるには他人のソースコードを改造するのが良いと思います。
自分でプログラムを書かないとプログラムは覚えられないですが、
はじめはどうやって書けばいいかも分からないわけで､実際のプログラムと
格闘することで覚えられるかなと。
11：ぷご：2003/10/16(木) 23:14: C言語って簡単に覚えられるものじゃないですね。
HyperCardでのスクリプトの組み方が上手い人で、やっと。

僕はHyperCardよりC暦のほうが長いけど､まだまだ修行中です。
12：smoke stack software：2003/10/17(金) 01:18: ポインタとか構造体とかハンドラとかさっぱり分かりません。
やっぱりpugoGLのようなライブラリを使うのが一番分かりやすいです。

PgColorX+HyperCardは使ってみました。
>>速度が遅いこと以外は不満無いです
同感です。なれてしまえば非常に分かりやすいです。
スピードが重要でなければ必要な事は全てできますね。
13：ぷご：2003/10/18(土) 10:29: //矩形領域をネガポジ反転
void CPlane::FlushBlt(Rect r){
LockPlane();

CGrafPtr SaveGrafPort;
GDHandle SaveGDHandle;
GetGWorld(&SaveGrafPort, &SaveGDHandle);
SetGWorld(m_gpPlane, 0);

InvertRect(&r);//ネガポジ反転命令

SetGWorld(SaveGrafPort, SaveGDHandle);
}

void CPlane::FlushBlt(long PlaneID, Rect r){
if(m_PlaneChain[PlaneID] == NULL) return;
m_PlaneChain[PlaneID]->FlushBlt(r);
}
14：ぷご：2003/10/18(土) 10:33: pugoGLのpugoPlane.cppから取り出したものですが、
これを改造して線の描画命令にするくらいは簡単です。

InvertRect(&r); //ネガポジ反転命令
この行をLineTo,MoveToのQuickDraw命令を使用した線描画ルーチンにすれば
OKです。
15：ぷご：2003/10/18(土) 10:34: 描画命令はPgColorXから取り出してきます。

PenSize(theWidth,theWidth);
PenMode(mode);
GetForeColor(&saveColor);

ZeroToPas(paramPtr,*paramPtr->params[2],tmpStr);
theColor = myGetColor(paramPtr,tmpStr);
RGBForeColor(&theColor);
MoveTo(sPoint.h,sPoint.v);
LineTo(ePoint.h,ePoint.v);

RGBForeColor(&saveColor);
PenMode(patCopy);
SetGWorld(saveGrafPort, saveGDHandle);
16：ぷご：2003/10/18(土) 10:37: というわけでちょっと作ってみますかね
17：ぷご：2003/10/18(土) 12:19: 完成。pugoGLベータ1.1も初公開。

http://www012.upp.so-net.ne.jp/ToT/stack/pugogl_b11.lzh
18：ぷご：2003/10/18(土) 12:27: DrawLine命令
DrawLine(planeID, sx, sy, ex, ey, width, red, green, blue);
(sx,sy)から(ex,ey)に太さwidthで色red,green,blueの線を引きます。
red,green,blueは0から256までです。

セカンダリに直接描画はサンプルのようにSwapToSecondaryを使うとできます。
makeファイルはサンプルのものを改造して使って下さい。

DrawLine命令を作るには、pugoYGS2k.cやヘッダファイルにも
手を加えないといけなかった。結構手間かかりますね。
19：Smoke Stack Software：2003/10/20(月) 20:58: 描画命令が追加されてとても助かります。
PgColorXのソースを利用して自分でなんとか作れないか
模索していたんですが、掲示板を見たら完成してました...
いとも簡単に作ってしまうところがスゴイです。
この具体的な改造方法を参考に「点・円・多角形」などの
描画命令についても考えてみたいと思います。
どうもありがとうございます。
20：ＵＤＩ：2003/10/21(火) 01:36: 　こんちわですー。QTのエフェクトを使ったXを作りたいと、
ず～～～っとCompileIt!でトライしてるんですけど、どうもあかんようです。
で、MPWに逃げて来たんですが、68Kのコンパイルがうまく行きません。
雛形になりそうなmakeファイル分けて頂けないでしょうか（泣）
21：ぷご：2003/10/21(火) 22:31: コマンドラインでやると、こんな感じでコンパイルできます。
コンパイルはできますが、XCMDを実行するとエラーです。
OSX上で実行しているのでClassic環境が落ちました。

SC :UxPlayMIDI-TC2.0.c -o :UxPlayMIDI-TC2.0.c.o -b -proto strict
Link -w -m MAIN -rt XCMD=2100 -sg UxPlayMIDI-TC2.0 -o "TestStack" ｶ
:UxPlayMIDI-TC2.0.c.o "{Libraries}"HyperXLib.o "{Libraries}"Interface.o ｶ
"{CLibraries}"StdCLib.o "{Libraries}"MacRuntime.o "{Libraries}IntEnv.o" ｶ
"{Libraries}ToolLibs.o" "{Libraries}Interface.o"
22：ぷご：2003/10/22(水) 00:35: 上のコマンドでNtFillCharXではきちんと動作しています。
うーん、QuickTimeを使うためにはどうすれば？

セグメントに関係ありそうな気もします。
ちょっとメモhttp://developer.apple.com/documentation/mac/runtimehtml/RTArch-121.html
23：ぷご：2003/10/22(水) 00:38: これでうまくいった。もう少しいらない部分を削ればOK.
WorkSheetのウィンドウにこれを貼付けて、ドラッグして選択し、
Enterキーで実行すればできます。
ソースコードも多少変更しましたが。

SC :UxPlayMIDI-TC2.0.c -o :UxPlayMIDI-TC2.0.c.o -model far -b -align mac68k -mc68020 -bigseg
ILink -w -m MAIN -rt XCMD=2100 -sg UxPlayMIDI -o "TestStack" ｶ
:UxPlayMIDI-TC2.0.c.o "{Libraries}"HyperXLib.o "{Libraries}"Interface.o ｶ
"{CLibraries}"StdCLib.o "{Libraries}"MacRuntime.o "{Libraries}IntEnv.o" ｶ
"{Libraries}ToolLibs.o" "{Libraries}Interface.o"
24：ぷご：2003/10/22(水) 00:42: -mc68020はいらないですね。LinkをILinkに変えたのが良かった。
上に貼ったAppleのページを見なければ分からなかった。
25：ＵＤＩ：2003/10/22(水) 02:27: 大感謝ーーーm(_ _)m
そうか、セグメントの問題だったのか。これから試してみます。
26：ＵＤＩ：2003/10/25(土) 00:31: 　ありがとうございました。うまく行ってるみたいです。

　Ｃは割と好きな言語なんですが、コンパイラは設定が面倒でいつも
泣かされます。ちゃんとした知識が無いのでオプションの意味がいまひとつ。
まぁCompileIt!も一筋縄でいかないツールなので、そのへんの面倒さは
同じなんですけどね・・・
27：ぷご：2004/01/17(土) 20:52: MPWにCarbonStdCLibを入れてみた。
Carbonなら、MPWでもコンパイル出来たという事を忘れていた。

さて、どうなるかな。
28：ぷご：2004/01/18(日) 01:18: MPWは無料とはいえ、インストールだけで手間がかかる・・・。
MPWでCarbonアプリを作る記事でも書こうかな。

まぁ、Carbonでコンパイル出来ずに悩んでるんだけど。
29：ぷご：2004/01/18(日) 04:11: MPWでのCarbonコンパイルに成功。
OS9でもOSXでも快適に動作するゲームが作れます。

よし、MacBeat作るか。
30：ぷご：2004/01/18(日) 06:25: MPWのインストール

まずMPWのページに行きます。
http://developer.apple.com/tools/mpw-tools/

QuickClicksと書かれた左の枠の「FTP Site」からMPW-GMのディレクトリ内を
全てダウンロードします。MPW-GM.imgでもOKです。

中身がStuffItアーカイブになっているので解凍します。
フォルダ丸ごとStuffItのアイコンにドラッグすると
フォルダ構造が分からなくなります。ファイルを複数
選択して解凍しましょう。フォルダ内のファイルも
アーカイブされてたりするので注意。

MPWフォルダの中のMPW Shellが、本体みたいなもの。
適当にいじりましょう。

Carbonアプリのコンパイル方法は、CreateMakeで作ればOK。
CarbonFrameworkLibをチェックする事。

古い情報を鵜呑みにすると引っかかります。
今の時点からはアップデートしないでしょうから、
僕の欠いている情報は割と正しいはず。
何も特別な事は書いてないけど。

MPW CarbonのMacBeatのソースコードと
MacBeat.makeを眺めればそれなりにできるかな。

Xcodeとソースレベルでの互換性は高いです。
OS9ではダブルバッファされず、OSXではダブルバッファ
されるなど動作が違うのが困ったところ。
OSXではAquaインターフェイスになるし。
無視してるけど。

こんな明け方までプログラムするのも久しぶりだなぁ。
31：ぷご：2004/01/18(日) 22:54: OSXでメニューが文字化けする場合。
アプリ本体にversリソースを入れてJapaneseにするとOK。
32：（　´ω｀）y-~：2004/04/18(日) 23:34: http://www.signaltalk.com/company.html

なんていうものを見つけた。

同一人物じゃないよね？
33：（　´ω｀）y-~：2004/04/18(日) 23:35: なんでもスレッドにかこうと思って誤爆してしまった・・・
34：ぷご：2004/04/19(月) 21:24: もっと調べてみれば分かると思うよ。
35：ぷご：2004/04/21(水) 23:07: yokomizo.comじゃなかったかな、、、
ああ、ハイフンがいるのな。
36：ぷご：2004/09/03(金) 00:38: 最近のMPWの用途はPgColorXをコンパイルするだけだな。

68KでInstallコマンドが使えるようになったのは、
-nearモデルにするだけだった。

昔は-bigsegオプション付けてなかったから、気づかなかったよ。
37：ぷご：2004/11/23(火) 18:02: やっとSeedCFillが使えなかった理由が分かった。
3年くらい掛かった…。

SetGWorldでdstBitMapを指定していたのがよくなかった。
srcBitMap(あるいはPixMap)を指定する必要があった。
38：ぷご：2004/11/23(火) 22:30: (int)0xFFFFFFFFは非常に小さい数だと思っていたのね。
2の補数表現を思い出してみた。
これは-1じゃないかー！
エラーとしてあり得ない数字を出そうと思っていたのに，
よりにもよって，ありそうな数字をー！

・・・ごめんなさい。
39：ぷご：2004/11/27(土) 23:53: リージョン付きPICTはPaintRgnやEraseRgnで
実現できるのかぁッ！

長年の疑問が氷解していく・・・。
40：ぷご：2004/11/28(日) 01:16: SetClip(region)を使う手もあるのか。
さらに、他にもPICTの領域指定方法はあるようだ。
拡張性があると言うか、統一感が無いと言うか。
41：ぷご：2004/11/29(月) 00:37: PackBits,UnpackBitsでPICTを圧縮/解凍しないと
PICTの領域指定は扱えないのかな。

これが使えると、透過PNG出力が出来るかな。
42：ぷご：2004/12/01(水) 22:27: PICTの圧縮では8bit単位で圧縮するため、
32000色以上の画像に対しての圧縮効果は
とても少ない。

なんて事が分かってもあまり嬉しくない。
43：通りすがりの名無しさん：2004/12/04(土) 17:26: copybitsでrgnを指定した場合もリージョン付きPICTになったはずです。
ところで、長年の心残りの質問なのですが、
PICTからリージョンを得る方法をご存知ですか？
白黒背景にDrawPictしたのを合成やパレット利用などあると思いますが、
PICTから直接取り出す方を探してました。

OS Xではtiffが標準になってPICTの出番もめっきり減りました。
44：ぷご：2004/12/04(土) 18:36: CopyBitsでリージョンを付けても無視されます。
それで長年悩んでいます。
仕方が無いので、自前でやってます。

>リージョンを得る方法
透過部分付きのPICTはいろいろなやり方があるので、
僕自身は白黒背景にDrawPictしたのを合成でやるのが
良いかなと思っています。

PICTのフォーマットから調べれば、直接rgnを得られますが、
そこまでやるのは面倒です。データの種類を示すopcodeと、
可変長のデータが並んだ作りになっていますので、リージョンを
取り出す位置を求めるのは大変です。
（参考）
http://www.openspc2.org/format/MacPICT/
45：ぷご：2004/12/04(土) 20:14: >>42で書いた、「32000色以上の画像に対しての圧縮効果は
とても少ない。」は正しくありません。

32000色の場合は2バイト単位で圧縮するようになっているため、
問題なく圧縮できます。なるほど。
とすると、PackBitsを自前で実装しないと。
46：ぷご：2004/12/05(日) 01:44: 32000色以上にしか対応していないけど、
Region+PixMapなPICTを生成できるようになった。

この画像をQuickTime変換かけてみたが、透過PNGは出来なかった。
そんなもんか。透過PNGへの道は遠い……。

クラリスワークスの出力するフォーマットに合わせたので、
クラリスワークスに貼付けたらマスク付きで貼付けられるだろう、
と思ったら、ならなかった。クリップボードにコピーする時に
PICT以外の情報もクリップボードに入れているらしい。

ちきしょー、頑張って作ったのに役に立たないや。
透過PNGはぜひやりたいんだけどなぁ。
47：ぷご：2004/12/05(日) 12:55: 32000色未満に対応しても実用にならないので、
自前PICT保存はやめる事にする。
ソースはPgExportXに含めて公開します。

気を取り直して、次はcicnリソースで保存できるようにしてみよう。
PICTの解析をしたので、cicnくらいならどうにでもなるはずだ。
48：ぷご：2004/12/05(日) 13:13: 透過させる場合は32bitにする？意味深な記述があるなぁ。
http://developer.apple.com/ja/qa/qa2001/qa1183.html

じゃ、32bitで保存させて変換……。
だめだ、バグがあってフリーズするよ。
49：通りすがりの名無しさん：2004/12/05(日) 23:04: 情報ありがとうございました。

＞CopyBitsでリージョンを付けても無視されます。
OS Xのcarbonで試してみたんですけど、
DrawPictureでちゃんとマスクされてますよ。

＞透過PNG
PixMapからPNGへの変換はどうでしょう？
alphaこみのPixMapを使えばうまくいきそうな気がします。
やりかたはこちらのサイトが参考にしてください。
http://homepage.mac.com/mkino2/cocoaProg/Carbon/CarbonGraphics/CarbonGraphics.html#gworldToNSImage
50：ぷご：2004/12/06(月) 00:53: こちらはClassicがターゲットなもんで。
しかもHyperCardのXCMDで68Kまでサポート必要です。

流氷通信を参考にしてPicture(PICT)から変換させようとしていましたが、
PixMapは32bitだとalpha含められるようですし、PixMapからだと
いけそうな感じですね。ありがとうございます。
51：（　´ω｀）y-~ （G5PVvZZ2）：2004/12/06(月) 14:18: 高速化を目的としたMPWで簡単XCMD講座キボンヌ
52：ぷご：2004/12/06(月) 22:48: >51
XCMDは面倒なわりに効果は薄いです。
XCMDをコールすること自体が重い感じがします。

・オールC言語
・HCなのに、XCMD中ですべて処理してしまう
のどちらかが良いでしょう。
とすると、オールC言語のほうがよほど魅力的ですね。

お手軽な方法として、CompileIt!のデモ版で
10行までのスクリプトをXCMDに出来るので
それを使うのも良いんじゃないかと。
53：ぷご：2004/12/06(月) 22:51: あまり効果がないXCMDの一例

//xCheckOverlap XCMD
//(C)PugoStation 2004
//2004/11/28

//make方法：次の２行をMPWコンソールでEnterで実行すればOK
/*
SC xCheckOverlap.c -o xCheckOverlap.c.o -model near -b -proto strict -align mac68k
Link -w -m MAIN -rt XFCN=13904 -sg xCheckOverlap -o "xCheckOverlap" "xCheckOverlap.c.o" "{Libraries}HyperXLib.o" "{Libraries}MathLib.o" "{CLibraries}StdCLib.o" "{Libraries}MacRuntime.o" "{Libraries}IntEnv.o" "{Libraries}ToolLibs.o" "{Libraries}Interface.o"
*/

//includes
#include <HyperXCmd.h>

//protoTypes
static void DoMain(XCmdPtr paramPtr);
static char *lineStrOfHandle(Handle str,short line);

//main codes
pascal void main(XCmdPtr paramPtr)
{
DoMain(paramPtr);
}

//2つの文字列の重なりを判定
static void DoMain(XCmdPtr paramPtr)
{
Str255tmpStr;
char*c1, *c2;
Handlestr1, str2;
Pointpt;
intx1, y1;
intx2, y2;
intflag;

//大きいフィールド
str1 = paramPtr->params[0];
if(**str1 == 0)
{
paramPtr->returnValue=PasToZero(paramPtr,"?pError: no string1");
return;
}

//小さいフィールド
str2 = paramPtr->params[1];
if(**str2 == 0)
{
paramPtr->returnValue=PasToZero(paramPtr,"?pError: no string2");
return;
}

//小さいフィールドのオフセット
if(**(paramPtr->params[2]) > 0)
{
ZeroToPas(paramPtr,*paramPtr->params[2],tmpStr);
StrToPoint(paramPtr,tmpStr,&pt);
}
else
{
pt.h = 0; pt.v = 0;
}

//オフセット
y1 = pt.v;
x2 = pt.h;
y2 = 0;

//lock
HLock(str1);
HLock(str2);

//判定ルーチン
flag = false;
while(1)
{
//一行取り出す
c1 = lineStrOfHandle(str1, y1);
c2 = lineStrOfHandle(str2, y2);
if( *c1 == 0 || *c2 == 0 )
break;
//オフセット分移動
x1 = 0;
while(x1 < x2)
{
if( *c1 == 0 || *c1 == '?n' )
break;
c1++;
x1++;
}
//逆オフセット
while(x1 > x2)
{
if( *c2 == 0 || *c2 == '?n' )
break;
if( *c2 != '0' )
flag = true;// *c1の外にはみだした場合はtrue
c2++;
x1--;
}
//文字比較ループ
while(1)
{
//文字列終了
//if( *c1 == 0 || *c1 == '?n' )// *c1の外にはみだした場合
//break;
if( *c2 == 0 || *c2 == '?n' )
break;
//判定比較
if(*c1 != '0' && *c2 != '0')
{
flag = true;
break;
}
//次の文字
if( *c1 != 0 && *c1 != '?n' )
c1++;
c2++;
}
if(flag)
break;
//次の行
y1++;
y2++;
}

//unlock
HUnlock(str1);
HUnlock(str2);

if(flag)
paramPtr->returnValue=PasToZero(paramPtr,"?ptrue");
else
paramPtr->returnValue=PasToZero(paramPtr,"?pfalse");
}

//line行目の文字列を取り出す（0行目から始まる！）
static char *lineStrOfHandle(Handle str,short line)
{
short returnCnt;
char *c;

c = *str;

returnCnt = 0;
while(returnCnt < line && *c)
{
if(*c == '?n') returnCnt++;
c++;
}

return c;
}
54：（　´ω｀）y-~ （G5PVvZZ2）：2004/12/08(水) 03:07: ・・・ある種の幻滅を・・・

・・・なんか元のＣより２倍近く肥大化してないか？（汗
55：ぷご：2004/12/08(水) 23:04: XCMDだとどんな引数渡されるか分からないから
エラー処理はいるし、文字列しか扱えないから
データのやり取りは面倒だし、C言語の標準関数が
68Kだとリンクエラーになって使えないし、
やってられません。

最近はHyperTalk書くよりはC言語のほうが慣れたので、
これくらいはどうってこと無いんだけどね。
むしろ、仕事でプログラム触らなくなってきたので
もっとC言語使いたかったり。
56：ぷご：2004/12/22(水) 01:58: PgColorXでWACOMタブレット筆圧感知に対応できました。
本格的にペイントソフトが作れそうです。

もうわけわからんな、このXCMDは。
57：ぷご：2004/12/23(木) 14:34: PgExportXがあれば、当然PgImportXも無いといけませんね。
というわけで作成中。QuickTime様々です。
58：ぷご：2004/12/23(木) 16:21: HyperCardのブラシくらいなら力技でもできるけど、
Painterのブラシなんかは難しいだろうなと思いつつ、
タブレットの筆圧を考慮したブラシの作成を悩み中。

「フルスクラッチによるグラフィックスプログラミング入門」
http://d.hatena.ne.jp/asin/479800958X
タブレットの筆圧を考慮したブラシストロークについて書いてあるらしい。
よし、買いに行ってくる。
59：ぷご：2004/12/23(木) 19:25: 本を読む。なるほど円を連続で描くのか・・・って力技じゃないか！！
僕の場合は円以外も使えるように考えているので、スタンプを
連続で行うような感じになるのかな。ま、それでええかな。

この本はPgColorXを作るような場合にとても役に立つなぁ。
なんとも素晴らしくマイナーだ。
60：ぷご：2004/12/25(土) 22:30: 検索していると、いいむらさんのページがよく引っかかる。
IconPartyを追っかけているかのような感じ。

単なるアイコン作成ツールかと思っていたけど、
IconPartyは意外と高機能だったんだ。
61：ぷご：2004/12/27(月) 01:56: とすると、次はネットワーク系XCMDですかね・・・。
62：（　´ω｀）y-~ （G5PVvZZ2）：2005/01/11(火) 02:09: http://www.h5.dion.ne.jp/~putora/jb.html
こいつにソースが付属してあるので改良してください。
63：ぷご：2005/01/12(水) 00:20: だから、そんなことにはきょうみがないといっておろう。
64：ぷご：2005/01/12(水) 00:24: 面白い／面白くないというのは一切関係ない。
自分の役に立つか／そうでないか、が基準です。
興味があることは、とりあえず情報だけは拾っておきます。
行動するかどうかは、役に立つとか得をするとか、そういったこと。
65：ぷご：2005/01/28(金) 08:01:15: ソースごとに最適化オプションを切り替えることで
コードサイズとスピードの両方の最適化を良くできる。
pugoGLで作っていた時はそんなことをしていた。
下手に最適化しようとするよりも効果があった。
66：ぷご：2005/01/31(月) 01:20:03: ClearTypeは横方向の解像度だけしか上がらないが、
それでも文字の読みやすさがかなり良くなる。

で、カラー画像にClearTypeの技術を適用することは可能か考えてみる。
RGBで1Pixelと考えるのではなく、RのPixel,GのPixel,BのPixelが
並んでいるだけと考えられるので、もちろん可能。
ただし、モアレ現象が発生する可能性があるのでその辺りの考慮が
欲しいところ。

そう難しくはなさそうなのでやってみたい。
67：ぷご：2005/01/31(月) 02:34:41: 画像のグレー要素をとりだし高解像度にする。
（RGB=#666633ならGの部分のグレー値は(66+66+33)/3=55）
差のカラー要素(66-55=11)は低解像度にする。

こんな感じでできるかな？
68：ぷご：2005/02/01(火) 01:00:14: >67は寝ぼけて書いてるのか意味不明だな。
うまくいくんだろうか。
69：ぷご：2005/02/01(火) 02:37:45: なんだかそれっぽい画像ができたが、IBookの液晶では分からない。
でも、試しにBGRの順で並べると線がギザギザになったので、
これで合ってると思うんだけどなぁ。
70：ぷご：2005/05/13(金) 21:37:39: いや、バグだらけだった。