シェアウェア作者の愚痴 27
場違いかもしれませんが、質問です。たぶんニコニコ動画のことだと思うのですが、
＞ここって右上のアマゾンアフィだけで絶対元とれないだろうなと思って
＞C:\Document and Settings\user\Cookies
＞チェックしたら黒だった。
＞でも一回消してリロードしたら食わなくなってた
＞しばらくして「痛いニュース」のランキングから入ったらgyaoのクッキー食ってた
＞恐らくIPとかリファラとかで巧妙に仕組んでる。悪質。
＞楽天社員さんもたまには他のIPからチェックしてみるといいですよー。
＞そういう商材も出回ってきたし、早めに手を打たないと大事になるでしょう。
こういうコピペが流行ってるみたいなんですが、こういう系統の事って、
Ｆｌａｓｈとかを使用してる見た目、普通のサイトとかでもやってるんですか？
＞ここって右上のアマゾンアフィだけで絶対元とれないだろうなと思って
＞C:\Document and Settings\user\Cookies
＞チェックしたら黒だった。
＞でも一回消してリロードしたら食わなくなってた
＞しばらくして「痛いニュース」のランキングから入ったらgyaoのクッキー食ってた
＞恐らくIPとかリファラとかで巧妙に仕組んでる。悪質。
＞楽天社員さんもたまには他のIPからチェックしてみるといいですよー。
＞そういう商材も出回ってきたし、早めに手を打たないと大事になるでしょう。
こういうコピペが流行ってるみたいなんですが、こういう系統の事って、
Ｆｌａｓｈとかを使用してる見た目、普通のサイトとかでもやってるんですか？
は？
>>938
＞住所すら公開しない個人の小遣い稼ぎと
シェアウェアとは限らないが住所を晒しても詐欺会社はある。
信頼度の印象が違うと言う指摘には否定できないけどね。
＞絶対に妙なことをするわけがないからな
世間知らずだな。昨年の賞味期限偽装、今年の餃子事件。
製品なら安心と言う訳でもあるまい。
故意に欠陥を仕込む訳ではないけれど、「こんな会社辞めてやる」
と思ってるときはバグを発見しても指摘はしないかも知れない。
コードを他に転用すると不具合が発生する可能性を残して
作り込むことがあるかもしれない。
ライブラリにする必要がない部分をライブラリにして手直し時に
気づきにくくしたりしてることもある。
販売するのは会社でも作っているのは生身の人間だからね。
>>939
文章上手いし代弁してくれてるようだ。
＞中身が綺麗で安定してるときさえある。
あぁ、アルゴリズムや実装が気に入らなければ書き直すことがあるしね。
返って利益を追求する企業だと作り直しはしない。
＞リバースエンジニアリングが趣味の俺は思う。
すごいね、とてもじゃないが技術も根性もマネできないよ。
＞住所すら公開しない個人の小遣い稼ぎと
シェアウェアとは限らないが住所を晒しても詐欺会社はある。
信頼度の印象が違うと言う指摘には否定できないけどね。
＞絶対に妙なことをするわけがないからな
世間知らずだな。昨年の賞味期限偽装、今年の餃子事件。
製品なら安心と言う訳でもあるまい。
故意に欠陥を仕込む訳ではないけれど、「こんな会社辞めてやる」
と思ってるときはバグを発見しても指摘はしないかも知れない。
コードを他に転用すると不具合が発生する可能性を残して
作り込むことがあるかもしれない。
ライブラリにする必要がない部分をライブラリにして手直し時に
気づきにくくしたりしてることもある。
販売するのは会社でも作っているのは生身の人間だからね。
>>939
文章上手いし代弁してくれてるようだ。
＞中身が綺麗で安定してるときさえある。
あぁ、アルゴリズムや実装が気に入らなければ書き直すことがあるしね。
返って利益を追求する企業だと作り直しはしない。
＞リバースエンジニアリングが趣味の俺は思う。
すごいね、とてもじゃないが技術も根性もマネできないよ。
売れまくりは嬉しいが、初心者サポートがうざくなってきた。ドライバくらい最新の物にしておけよ。
paintgraphicなんかのソースネクストのソフトは、
簡単なバグつぶしでメジャーバージョンアップですよ。
それに比べれば良心的なシェアウェアの方がマシだったり。
ただ、ソース臭いシェアウェアもたくさんあるから困る。
簡単なバグつぶしでメジャーバージョンアップですよ。
それに比べれば良心的なシェアウェアの方がマシだったり。
ただ、ソース臭いシェアウェアもたくさんあるから困る。
バグは消しましぇん！！！！！！！！
最近って、CDやDVDなんかも、シェアウェアみたいになってきてるよな。
動画サイトで見て、気に入ったらDVDやCDを購入するみたいな感じで。
もっとも、こっちは制作側の意図とは別なんだろうけど。
動画サイトで見て、気に入ったらDVDやCDを購入するみたいな感じで。
もっとも、こっちは制作側の意図とは別なんだろうけど。
＞もっとも、こっちは制作側の意図とは別なんだろうけど。
シェアウェアとDVDとの制作側の意図の違いって何？
シェアウェアの制作側の意図？→
DVDの制作側の意図？→
シェアウェアとDVDとの制作側の意図の違いって何？
シェアウェアの制作側の意図？→
DVDの制作側の意図？→
動画サイトって、ニコニコとかようつべのことだと思うのだが。
ちょうど、今しがたNHKでニコニコの話してたな
角川が英語字幕で無許可動画がアップされているのが人気なので
正式に英語字幕版DVDを出したら6万枚売れてうほうほだったとか
ニコニコには関連動画のときは広告出すようにしてるとか
角川が英語字幕で無許可動画がアップされているのが人気なので
正式に英語字幕版DVDを出したら6万枚売れてうほうほだったとか
ニコニコには関連動画のときは広告出すようにしてるとか
>>944
普通サポートは別料金だろ、寝ぼけてんのか
普通サポートは別料金だろ、寝ぼけてんのか
>>944
「多少」の基準が人それぞれなんだよ・・・
>>953
そっち系の人の本読むとどうしてもそう思えねーよ。
実写は知らん（てか日本実写を海外で売れたの聞いたこと無い）ので
アニメ限定の話だが、海外の日本アニメ専門アニメ会社にとっては
youtube他の動画サイトは「売り上げを落とす理由」にしかならないらしいぞ。
翻訳までされちゃあ宣伝にすらならんし、そりゃそうだろって思うが。
「多少」の基準が人それぞれなんだよ・・・
>>953
そっち系の人の本読むとどうしてもそう思えねーよ。
実写は知らん（てか日本実写を海外で売れたの聞いたこと無い）ので
アニメ限定の話だが、海外の日本アニメ専門アニメ会社にとっては
youtube他の動画サイトは「売り上げを落とす理由」にしかならないらしいぞ。
翻訳までされちゃあ宣伝にすらならんし、そりゃそうだろって思うが。
>>953
現地の変な会社通さずに直に売って普通に儲かっただけじゃね。
昔から外国人の作った日本アニメのホームページとかいっぱいあったし、
それらを今まで無視してきただけで、特にニコ動とか関係ないようなきがす。
ちなみに直に商売したらしたで、
日本のアニメは暴力的だとかバッシングが始まるだろうから、
市場としては無視しておくのも悪くはない選択だとは思うが。
現地の変な会社通さずに直に売って普通に儲かっただけじゃね。
昔から外国人の作った日本アニメのホームページとかいっぱいあったし、
それらを今まで無視してきただけで、特にニコ動とか関係ないようなきがす。
ちなみに直に商売したらしたで、
日本のアニメは暴力的だとかバッシングが始まるだろうから、
市場としては無視しておくのも悪くはない選択だとは思うが。
>>954
シェアウェアにそんな常識はないだろ。
シェアウェアにそんな常識はないだろ。
>>958
丁寧なサポートなら別料金は頷ける。
もっとも売れた以上はFAQを無料で掲載するくらいは仕方ないとも思う。
シェアウェアにしても使って気に入ったら対価を払って下さいだし
使い方が解らないなら送金は控えて下さいが基本。
でもまぁ、間違って送金された場合の返金はご容赦下さいで
今後の開発のためにありがたく使わせて頂きますが基本方針かと。
この基本方針が提供する側もされる側も曖昧なのでグチになるのかな。
丁寧なサポートなら別料金は頷ける。
もっとも売れた以上はFAQを無料で掲載するくらいは仕方ないとも思う。
シェアウェアにしても使って気に入ったら対価を払って下さいだし
使い方が解らないなら送金は控えて下さいが基本。
でもまぁ、間違って送金された場合の返金はご容赦下さいで
今後の開発のためにありがたく使わせて頂きますが基本方針かと。
この基本方針が提供する側もされる側も曖昧なのでグチになるのかな。
シェアウェアｗｗｗｗ
操作法⇒無料
活用法⇒有料
活用法⇒有料
vectorでこんなんおきてるけど、
http://internet.watch.impress.co.jp/cda/news/2008/03/18/18858.html
http://internet.watch.impress.co.jp/cda/news/2008/03/18/18858.html
シェア作家ってうんこだな
木を見て森を見ずってやつか
売り上げ80万円超えたお〜
シェアウェアを作ってお小遣いを稼ごうと思っているのですがそれに関して質問があります。
1.どのようなソフトが求められているか
2.収入はどれぐらいか
よろしくお願い致します。
1.どのようなソフトが求められているか
2.収入はどれぐらいか
よろしくお願い致します。
∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
マルチコアCPUマシンを高速化するツールってよくね？
WinAPIで並列処理化すると高速化しそうなものをフックして色々速くなるとか。
作りたくてたまらないけど、他のもの作っている余裕がないぜ。
存在していたらorz だけど、注目は浴びると思う。
WinAPIで並列処理化すると高速化しそうなものをフックして色々速くなるとか。
作りたくてたまらないけど、他のもの作っている余裕がないぜ。
存在していたらorz だけど、注目は浴びると思う。
マルチコアを生かしきるほど高速化できるAPIってそうそうあるか？
マルチスレッド化してなくてレスポンスもっさりとか、描画系だけど過剰更新なのを遅延するとかは可能かもしれんが、
大抵のAPIだと基本的に呼んだ時点で処理完了を前提に構成されちゃうからなぁ…。
普通に出来そうな範囲だと
勝手にダブルバッファ化して、ロックしていても再描画することで「固まっている」感覚を軽減する
→描画だけ抜き出すのがメドー。アプリじゃなくてWindows側に干渉する必要がありそう。ってかそれぐらいならレイヤードウィンドウにするだけで済む
描画を自前でキャッシュするなどで制御して過剰描画を抑制して高速化を図る
→描画がネックなら効果的だが、それ以外の効果が薄い。
投げっぱなしAPIを別スレッドに自動分離
→レジストリ書き出し・ファイルIO(CopyFileとかその辺限定)辺りだけで、それがネックの物にしか効果が無いが、それがネックになることはあんまり…
メッセージをコマンド発行系と描画その他システム系で分離してそれぞれ別スレッドに分ける
→API描画系とコマンド発行系で同じスレッド前提だとアウアウ
投げっぱなしAPIは大抵が最初から投げてるからなー…。
APIじゃなく通常のロジック部分こそマルチコア向けに変更すべき箇所だが、これを自動認識するのは骨だ。…上手くいけば効果的だろうが…
マルチスレッド化してなくてレスポンスもっさりとか、描画系だけど過剰更新なのを遅延するとかは可能かもしれんが、
大抵のAPIだと基本的に呼んだ時点で処理完了を前提に構成されちゃうからなぁ…。
普通に出来そうな範囲だと
勝手にダブルバッファ化して、ロックしていても再描画することで「固まっている」感覚を軽減する
→描画だけ抜き出すのがメドー。アプリじゃなくてWindows側に干渉する必要がありそう。ってかそれぐらいならレイヤードウィンドウにするだけで済む
描画を自前でキャッシュするなどで制御して過剰描画を抑制して高速化を図る
→描画がネックなら効果的だが、それ以外の効果が薄い。
投げっぱなしAPIを別スレッドに自動分離
→レジストリ書き出し・ファイルIO(CopyFileとかその辺限定)辺りだけで、それがネックの物にしか効果が無いが、それがネックになることはあんまり…
メッセージをコマンド発行系と描画その他システム系で分離してそれぞれ別スレッドに分ける
→API描画系とコマンド発行系で同じスレッド前提だとアウアウ
投げっぱなしAPIは大抵が最初から投げてるからなー…。
APIじゃなく通常のロジック部分こそマルチコア向けに変更すべき箇所だが、これを自動認識するのは骨だ。…上手くいけば効果的だろうが…
>>974
描画系のキャッシュってのは途中経過表示で100000オーダのエディットボックスを1増加毎にSetTextするような奴や、
そういう方法で描画してるGDIのことのつもりで書いた。
DirectXやOpenGLが絡む高負荷処理はルーチンワークでは手の付けようが無いと思う。
>>971の具体的な案が気になるな…。
描画系のキャッシュってのは途中経過表示で100000オーダのエディットボックスを1増加毎にSetTextするような奴や、
そういう方法で描画してるGDIのことのつもりで書いた。
DirectXやOpenGLが絡む高負荷処理はルーチンワークでは手の付けようが無いと思う。
>>971の具体的な案が気になるな…。
議論に付き合っちゃうけど
描画系は結果的にビデオメモリとシステムメモリのやりとりになるっしょ。
それがマルチになってないビデオカードが多いってこと。
もちろんおまいがあげたのも最終的にそれ依存だよ。
大体ビデオメモリとシステムメモリのやりとりが
複数本無いとマルチコアなんて（ビデオ系限定じゃ）意味ねーんだから。
ビデオカード複数挿しなんて一般的じゃないし
やったとしてもマルチスレッド的になるのかも分からん。やったことねーし。
それ全部考慮して「意味なさげ」。な。
描画系は結果的にビデオメモリとシステムメモリのやりとりになるっしょ。
それがマルチになってないビデオカードが多いってこと。
もちろんおまいがあげたのも最終的にそれ依存だよ。
大体ビデオメモリとシステムメモリのやりとりが
複数本無いとマルチコアなんて（ビデオ系限定じゃ）意味ねーんだから。
ビデオカード複数挿しなんて一般的じゃないし
やったとしてもマルチスレッド的になるのかも分からん。やったことねーし。
それ全部考慮して「意味なさげ」。な。
>>976
そこは理解してる。
そうじゃなくて人間が見えないくらいの速度で画面更新するソフトに対して、描画を何割か端折るって事なんだが…。
「キャッシュするなどで」「過剰描画を抑制」するわけだから。
それ以前に、単純に描画API呼び出しだけ別スレッドに流し込むって手法だけでも、描画結果待ちのブロッキングは解消されると思うけど。
モデルとしては「描画スレッド」「内部処理スレッド」に分割するイメージで。
書き忘れたが>>973ではAPIフックする高速化全般について考えてたからマルチコア関係ないチューニングも混ざってる。
混乱させてすまん。
以下話の行き違いがあったどうでも良い話題。
BitBltとかは上手くアクセラレーションが効けばビデオメモリ→ビデオメモリにはなるらしいから、システムメモリと競合はしないケースも有る。
メインメモリがコアごとに独立して無い以上、メモリ他IOが多い処理同士は並列化しても衝突する…が、逆に言えば「CPUキャッシュに収まる処理」とそれ以外(「ビデオメモリ⇔システムメモリな処理」とか)の組み合わせであれば問題無い。
筈。
そこは理解してる。
そうじゃなくて人間が見えないくらいの速度で画面更新するソフトに対して、描画を何割か端折るって事なんだが…。
「キャッシュするなどで」「過剰描画を抑制」するわけだから。
それ以前に、単純に描画API呼び出しだけ別スレッドに流し込むって手法だけでも、描画結果待ちのブロッキングは解消されると思うけど。
モデルとしては「描画スレッド」「内部処理スレッド」に分割するイメージで。
書き忘れたが>>973ではAPIフックする高速化全般について考えてたからマルチコア関係ないチューニングも混ざってる。
混乱させてすまん。
以下話の行き違いがあったどうでも良い話題。
BitBltとかは上手くアクセラレーションが効けばビデオメモリ→ビデオメモリにはなるらしいから、システムメモリと競合はしないケースも有る。
メインメモリがコアごとに独立して無い以上、メモリ他IOが多い処理同士は並列化しても衝突する…が、逆に言えば「CPUキャッシュに収まる処理」とそれ以外(「ビデオメモリ⇔システムメモリな処理」とか)の組み合わせであれば問題無い。
筈。
Su
>>977
＞モデルとしては「描画スレッド」「内部処理スレッド」に分割するイメージで。
このモデルの概念なら「メインスレッド」と「作業スレッド」と言うことで
マルチスレッド機能が搭載されたwin95の時に既に確立していた。
最近はSMP以前に書かれたコードがマルチコアが当り前になってタイミング的な
バグが顕在化してるようだけど。
ともあれ>>971の具体的な案を聞きたいと言うのには共感。
＞モデルとしては「描画スレッド」「内部処理スレッド」に分割するイメージで。
このモデルの概念なら「メインスレッド」と「作業スレッド」と言うことで
マルチスレッド機能が搭載されたwin95の時に既に確立していた。
最近はSMP以前に書かれたコードがマルチコアが当り前になってタイミング的な
バグが顕在化してるようだけど。
ともあれ>>971の具体的な案を聞きたいと言うのには共感。
そこをバラしてしまったら何食わぬ顔でパクるやつがいるからなあ。
実際マルチコアで様々高速化のプログラミングしていれば、
どういった事が高速化可能かがわかるよ。
ちなみに、DirectXやOpenGLなどはマルチスレッドレンダリングという方法で
コマンドを効率よく送り込むことでパフォーマンスを上げることができる。
色々なゲームで既に行われている。
実際マルチコアで様々高速化のプログラミングしていれば、
どういった事が高速化可能かがわかるよ。
ちなみに、DirectXやOpenGLなどはマルチスレッドレンダリングという方法で
コマンドを効率よく送り込むことでパフォーマンスを上げることができる。
色々なゲームで既に行われている。
>>979 >win95の時に既に確立していた。
確立してる割には実践して無い例も多いのが嫌なところだ。
自動でマルチコア向けに最適化しなおすってのは相当面白そうだが…
>>980
楽にパクれる簡単な方法ならばらそうがばらすまいが結局パクられるかと。
この手の最適化はやたらと面倒な手順でやらないと出来ないと思うが(100%解析しきる事は無理なんで)、
そうするとよりベターな結果を出せるエンジンを目指して同種のソフトで削りあいになるだろうさ。
確立してる割には実践して無い例も多いのが嫌なところだ。
自動でマルチコア向けに最適化しなおすってのは相当面白そうだが…
>>980
楽にパクれる簡単な方法ならばらそうがばらすまいが結局パクられるかと。
この手の最適化はやたらと面倒な手順でやらないと出来ないと思うが(100%解析しきる事は無理なんで)、
そうするとよりベターな結果を出せるエンジンを目指して同種のソフトで削りあいになるだろうさ。
同種のソフトに対してイヤガラセしてんだろ？ おまえらｷﾓｯ
>>982
＞確立してる割には実践して無い例も多いのが嫌なところだ。
必要性がなかったのでないか。まぁ子プロセスの返り値を使うこともないのに
ヒマなので子プロセス起動時にマルチスレッド化したこともあった。
もちろん子プロセスの返り値を使う場合もあったけど。
マルチスレッドの最適化ならアプリ毎に対応するのが何と言っても最善と思う。
各アプリで対応すべきことをしてないのであれば、それだけの値のアプリで話はお終い。
＞確立してる割には実践して無い例も多いのが嫌なところだ。
必要性がなかったのでないか。まぁ子プロセスの返り値を使うこともないのに
ヒマなので子プロセス起動時にマルチスレッド化したこともあった。
もちろん子プロセスの返り値を使う場合もあったけど。
マルチスレッドの最適化ならアプリ毎に対応するのが何と言っても最善と思う。
各アプリで対応すべきことをしてないのであれば、それだけの値のアプリで話はお終い。
常識で考えてばかりだと独創的な物を作り出せないよ？
と非常識なヤツが言う
そう，常識を知った上で非常識な事を考えないと
それが難しいぜ
何て言うか、せいぜいがオリジナルを参考にした手直しか工夫・改善で
つくづくオレって日本人だ〜な、と自覚することは結構あるな。
独創的なことができて儲かりそうなら特許取るぜ。
つくづくオレって日本人だ〜な、と自覚することは結構あるな。
独創的なことができて儲かりそうなら特許取るぜ。