Closed S-H-GAMELINKS closed 7 years ago
現状FileRead_gets
で読み込みをしていますが、この場合DXArchiveに対応しています。この対応を切ってもいいなら比較的ラクにできますが、DXA対応が必要な場合はFileRead周りをラップすることになり大変です。どうしますか?
いずれにしても動的確保にすることでメモリー使用量削減に寄与するかと思います。
あー、DXArchive周りの事まで考えが回ってなかったですね…。
DXArchive非対応となるのはユーザーからすると辛いでしょうし、かといってラップするというのも大変ですし。
やっぱり対応しないとあかんか・・・。結局 https://github.com/Nagarei/DxLibEx/pull/53#issuecomment-218428288 と同じ問題にぶち当たるのか・・・。
まあようはstd::streambuf
, std::istream
, std::ostream
をそれぞれ継承してやればいいんだけど、本当に設計が古臭くてだるい。
個人的には、DXA対応を切ってしまっても問題ないと思いますよ。
それに、現状ユーザーからの声はほとんどないですので(サークルメンバーからのみ……)、DXA非対応になったとしても大きな問題にはならないと考えます。
この際ですし、非対応の方向で行きましょうか。
ちなみに前にstd::wcin
/ std::wcout
をUTF-8としてバイパスする目的で書いたstreambufが
https://github.com/yumetodo/utf8_streambuf
です。まあこれよりは楽に書けるんじゃないかな・・・
非対応だと嬉しいです。
以下愚痴。
boost::iostreams
とかでzlibなりbzip2で圧縮すればいいんですよ。たまにDXAの暗号化が必要だからとか言っている輩がいますが、解除鍵がプログラム中にある時点でいくらでも逆アセンブルして割れますし、ネットワーク通信で手に入れる実装にしても通信がある事自体はオフライン環境で実行すればわかるし、通信内容はWireSharkでわかるし、結局無意味なんですよ。もちろんDRMの認証に使っているものくらい頑張ればそうそう破られないでしょうが、そんなコードかけるやつはDXAなんてつかいませんよ。そんなにリソースファイル隠したいならもうブラウザゲームにしろよっていう・・・。改ざん対策にDXA使うのも誤りで、そんなもんハッシュチェックしろよと申し上げたい。つまりDXAなんてゴミ箱に投げ捨てるべきなんですよ。ええ、あんなものがあるせいでboost::iostreams
をstatic linkしようとするとリンカーエラーになるし、まじでDXA考えたやつは頭が(ry
(DXAへの恨みのあまり錯乱したので隠しました)
よし、非対応にしましょう!
個人的にも、DXAでの暗号化は「見ようと思えばみれてしまうよな」という思いがありましたので、今回の件はいい区切りだと思います。
あと、それ以上いけない……
了解です。試しに実装してみています・・・
よろしくお願いします。m(__)m
こちらのスクリプト配列:String を
下記のコードで行数と文字数(バイト数)を返して、配列を動的確保できないでしょうか?