HSPTV!掲示板

スレッド一覧 | 新規書き込み | 新着一覧 | 使い方 | 過去ログ

未解決

解決

停止

削除要請


	2011 0520	夢見がち	HSPに期待すること。	53

夢見がち

2011/5/20(Fri) 13:07:34|NO.39275

HSP3.4とHSP5に期待することをぶちまけましょう。

この記事に返信する

ORZ

2011/5/20(Fri) 16:32:39|NO.39277

先のことを考えるより、夢を見てないで基本事項を勉強した方がいいと思うな俺は。

晩御飯

2011/5/20(Fri) 16:59:52|NO.39278

それはぶちまけないであげて下さい

wass

2011/5/20(Fri) 18:25:38|NO.39280

命令と関数の統合がほしい
statなんて使ってられない

whoさん

2011/5/20(Fri) 18:40:53|NO.39281

>>wassさん
APIですか？　それなら#cfuncで自分で定義すればいいと思います。
(意図が違かったらすいません)

HK2

2011/5/20(Fri) 19:26:25|NO.39282

配列の最初の要素に異なる型を代入したときにエラーになるようにしてほしい

晩御飯

2011/5/20(Fri) 20:39:13|NO.39284

本来関数の返り値で結果を受け取るところを命令＋statで取るのは嫌だってことじゃないかと

ひらまる

2011/5/20(Fri) 21:28:34|NO.39287

statでステータスを取得する命令に"objsel -1"などがありますが、こんな風に書くのはだめですか？



#defcfunc getSelObj
	objsel -1
return stat

2011/5/21(Sat) 03:45:28|NO.39291

var宣言によるローカルスコープの有効化と簡単なクラスの実装

f3d

2011/5/21(Sat) 07:57:40|NO.39292

モジュール機能がいまいち使いづらい

HK2

2011/5/21(Sat) 09:16:26|NO.39293



	#undef objsel
	#defcfunc objsel int p1
	objsel@hsp -1
	return stat

このようにするのはどうでしょうか。

mom

2011/5/21(Sat) 14:39:35|NO.39299

モジュール機能は確かに使いにくいですねえ

skyblue

2011/5/21(Sat) 19:00:53|NO.39320

上級者向けに構造体の定義を可能にしてほしい。
そして、モジュールをもっとわかりやすいように

whoさん

2011/5/21(Sat) 20:03:45|NO.39323

>>skyblueさん
>>上級者向けに構造体の定義を可能にしてほしい。

同感です。上級者(自分で言うのも変ですけど)C言語とかやってると、HSPにもこんなのがあったらいいな～って思う時があります。

2011/5/21(Sat) 23:09:39|NO.39325

少なくとも、この雑談は「ＨＳＰの将来に期待すること」です。

雑談なので「下ってくる」内容でも良いかもしれませんが、「上っていく」
内容のほうが合っているような気がします。

期待することといえば、内部マクロ等の命令・関数が、実際には単純な関数
に置き換えられていることを明確にし、基本命令・関数の数を減らすことを
望みます。

初期のコンセプトから、逸脱を始めているように感じます。

ひらまる

2011/5/22(Sun) 00:13:53|NO.39332

>内部マクロ等の命令・関数が、実際には単純な関数
に置き換えられていることを明確にし、基本命令・関数の数を減らすこと

foreach A → repeat length( A )
のようなことですか？
まぁforeachはモジュール型変数に対して有効なのでこれは良い例ではないかもしれませんが…

たしかHSPはいつからか、アプリケーション内で使わない関数や命令はコンパイル時に無視されて、
実行ファイルには含まれなくなったと思います。
だからこそ命令や関数の肥大化が起きているのではないでしょうか。違ったらごめんなさい；

あもしかしてcelloadとかそういう命令のことでしょうか。
この辺は確かに、bufferやgselなどを理解していれば、
自分でさらにカスタマイズした関数などを作れると思いますが、
やはり初心者にはcelloadの方がやさしいのでしょうか…う～ん？

しかし、初期のコンセプトから逸脱してきているというのはなんとなくわかります。
というより、celload系の命令が追加されたとき私も、「HSPらしくない命令だなぁ」と思いました。

なんか今日はテンションが高くて余計なことをつらつら書いてしまいますね　ごめんなさい；

f3d

2011/5/22(Sun) 07:59:03|NO.39340

使いやすけりゃ命令数が増えても、サイズが大きくなってもかまわない。

2011/5/24(Tue) 14:25:54|NO.39367

ＶＢみたいに変数の定義の強制化オプション希望。
変数のタイプミスでバグるのはもうイヤｗ

2011/5/24(Tue) 14:25:54|NO.39368

ＶＢみたいに変数の定義の強制化オプション希望。
変数のタイプミスでバグるのはもうイヤｗ

ORZ

2011/5/24(Tue) 15:01:13|NO.39369

よほど大事なことだったんだな。分からなくもないけど。



	unitposx+=speedx:unitposy+=speedy
	
	pos unitosx,unitposy

うー

2011/5/27(Fri) 22:47:04|NO.39402

主に今後対応して欲しい事項は二つ

ファイルのセーブ・ロード命令強化

特に文字列型配列変数の保存を直接ひとつの命令で出来るようにして欲しい。
2次元の文字列型配列変数を保存するとき厄介な手順踏まなきゃいかんし、出来ればbsave(あるいは別の新しい命令)で一発保存出来るようにしてくれ。

べき算の演算子

なんだかんだ言ってべき算は結構使うから関数じゃなくて演算子として利用出来るようにして欲しい。
どうして^をべき算の演算子として使わなかったのだろうか……。

check

2011/5/28(Sat) 11:04:56|NO.39406

HSP本体に対しての要望

・モジュール機能は正直使いづらい。
クラスを実現させようとするのなら、それっぽい独自のものを実装させるのではなく、
C++やJavaなど有名な既存の言語にあわせてくれ。

そして、標準命令のなかでモジュール機能で代替できるものはなるべくそうして、
ランタイムの大きさをできるだけ小さくしてほしい。
（標準命令を組み込んでいるものと、モジュールで実装しているものの
２つのランタイムに分けてもいいかもな。）

・デフォルトでアイコン書き換えツールがほしい。

・標準で(picload)でpngファイルを読み込めるようにしてほしい。
というか、なんでメジャーフォーマットの中でpngファイルだけ対応してないのだろうか。
gifファイルよりも読み込む機会は絶対に多いはずだろうに。

エディタに対しての要望

・最近開いたファイルの履歴をたどれるようにしてほしい。

・欲を言えばRADタイピングを可能にしてほしい。
簡単なツールをHSPで作成することも多いからな。
C#はどうにも馴れないし……

f3d

2011/5/28(Sat) 11:37:16|NO.39407

実行サイズにこだわって使いづらくなるのはやめて欲しい。
png読み込みもさらに増えそうなんで個人的にいらない、必要ないです。

panda

2011/5/28(Sat) 14:49:54|NO.39408

JITコンパイラの搭載

・・・なんちゃって。

あり

2011/6/2(Thu) 10:29:32|NO.39506

＞＞Ｍさん
>調べ物をしようと「OBAQ」で検索すると、オバＱばっかでてきて、お話にならない。
検索キーワードを『HSP OBAQ』とすればほぼOBAQ.dllの情報だけになりますよ。

ポチ

2011/6/11(Sat) 03:08:53|NO.39618

1.HSPのバッファに透明色情報を追加して標準でPNGファイル対応にして欲しい。

2.不定形リージョン(出来れば最速で）を扱うコマンドを追加して欲しい。

3.デバックウインドウの変数のソート、検索を可能にして欲しい。

　　・・・希望です。

win5126

2011/6/11(Sat) 09:46:36|NO.39620

インクルードした命令でも色が変わるようにしてほしいなｗ

hexa.hemi

2011/6/11(Sat) 10:39:06|NO.39621

#deffuncや#defcfuncや#funcや#cfuncや#defineで定義したものも色が変わってほしい

info

2011/6/12(Sun) 13:11:46|NO.39648

callback関数の標準実装がほしいです。

skyblue

2011/6/12(Sun) 14:22:17|NO.39649

>3.デバックウインドウの変数のソート、検索を可能にして欲しい。
ソートだけならすでにあった気がします。

2011/6/12(Sun) 21:17:43|NO.39656

デバッグウィンドウでの変数一覧表示時、モジュール別の検索。（userdefのがですぎる。）

COMのとき、いちいちひとつずつたどらずに、一気にアクセスできるように。←無理？

構造体はぜひとも扱えるようにしてほしいですね。

関数と命令を区別せずに使えるように。
#defineとか#defcfuncを使えばできなくもないですが。。正直面倒。

ついでに（ちょっとはずれてる気もするが、）
様々なWindowsAPIやウィンドウメッセージ定数の定義ファイル。

木村

2011/6/13(Mon) 01:32:12|NO.39661

>>win5126さん
>インクルードした命令でも色が変わるようにしてほしいなｗ

>>hexa.hemiさん
>#deffuncや#defcfuncや#funcや#cfuncや#defineで定義したものも色が変わってほしい

　Footy2を用いた最新版のエディタの強調処理はFooty2のfooty2addemphasis命令とfooty2flushemphasis命令によって実装されていると思われます。(実際、コメントや文字列の強調処理はfooty2addemphasisで定義されていると思われる部分が有り。命令等の強調処理はhspcmp.dllを参照しているらしくて良く分からない)

　このfooty2flushemphasis命令はソースファイル『classify.cpp』に定義されるsetclassify命令にのみ使われているので、このfooty2flushemphasis命令のすぐ手前に各種命令の強調処理内容をfooty2addemphasis命令で書き込んだものをコンパイルすれば、強調処理がカスタマイズされたエディタが完成すると思われます。

　……しかし、MicrosoftVisualC++2010Expressを使っているのですが、どうやればコンパイルできるのでしょうか……
　MicrosoftVisualC++2010Expressは統合開発環境ですから、メニューのどこかにコンパイル機能がある気がするんですが、いまだに見つかりません……

skyblue

2011/6/13(Mon) 07:30:38|NO.39662

>……しかし、MicrosoftVisualC++2010Expressを使っているのですが、どうやればコンパイルできるのでしょうか……
>　MicrosoftVisualC++2010Expressは統合開発環境ですから、メニューのどこかにコンパイル機能がある気がするんですが、いまだに見つかりません……
ビルドする＝コンパイル＋リンク

ひらまる

2011/6/13(Mon) 12:17:19|NO.39663

うーん…
ＨＳＰはコンパイラが誰でも使えるように提供されているので、
標準のＨＳＰスクリプトエディタ以外のエディタでも使いやすくなっていると思います。
ＨＳＰはスクリプト言語であり、多機能エディタではないので、
私はスクリプトエディタにはあまり機能を求めていません。

とはいえ、ダウンロードすればすぐにでもプログラミングを始められる。
開発環境を揃える必要はなく、ＨＳＰ１つで開発が始められる。
という点は、ＨＳＰならではの非常に強い点だと思うので、
初心者がそのまま便利に使えるようなエディタは大切だと思います。
しかし、玄人がさらなる機能を望むのであれば、
使いやすい市販のエディタを使うという選択肢もあると思います。

個人的にはエディタの改良よりも、処理の高速化や機能の追加をして欲しいなー
なんて思います；　この流れでごめんなさい；

pony

2011/6/13(Mon) 18:18:17|NO.39666

>>Cookiesさん
>関数と命令を区別せずに使えるように。
大昔にここで提言したんですが受け入れられないようです。
http://hsp.tv/play/pforum.php?mode=pastwch&num=19952
仕方ないのでモジュール作って代替してるんですが良かったらどうぞ。



#module
#deffunc kansuninare
#define STRUCTDAT_OT_STATEMENT 2
#define STRUCTDAT_OT_FUNCTION 4
#define STRUCTPRM_SUBID_DLL (-3)
#define STRUCTPRM_SUBID_DLLINIT (-4)
mref hspctx,68
dupptr hsphed,hspctx,96
if hsphed.15>0{
	dupptr structdat,hspctx.210,hsphed.15
	repeat hsphed.15/28
		subid=structdat(7*cnt)>>16
		if (subid==STRUCTPRM_SUBID_DLL | subid==STRUCTPRM_SUBID_DLLINIT) & (structdat(7*cnt+5)==STRUCTDAT_OT_STATEMENT){
			structdat(7*cnt+5)|=STRUCTDAT_OT_FUNCTION
		}
	loop
}	
return
#global
kansuninare

#include "user32.as"
MessageBox hwnd,"","命令でも",0
ret=MessageBox(hwnd,"","関数でも使えます",0)

あとついでに
>デバッグウィンドウでの変数一覧表示時、モジュール別の検索。（userdefのがですぎる。）
ddwTree.dllというのがあるので使ってみては
http://hspdev-wiki.net/?HspPlugin%2FddwTree
>様々なWindowsAPIやウィンドウメッセージ定数の定義ファイル
WIN32API定数というそのものずばりのものがあります。
http://hp.vector.co.jp/authors/VA034288/index.html

2011/6/13(Mon) 18:53:40|NO.39667

>>ponyさん
　おおおおおお。すごい！！
　一気に三つ解決されてしまった。
　
　青い葉っぱさんは何度か行ったことありましたが、これは盲点でした。
　
　せっかく次期HSPに向けて要望したのにもう解決する方法があったなんて…
　本当にありがとうございます。

さっそくモジュールをuserdefへっと。。

2011/6/13(Mon) 19:02:24|NO.39668

と思いましたが、ddwTree.dllは入手できないようです。
kz3さんのブリーフケースが…
残念…

chiko

2011/6/15(Wed) 20:52:04|NO.39677

エディタのウィンドウを上下とか左右とかに分割できるようにしてほしいです。
プログラムが長くなってくると探すのが面倒です。
ラベルも助かりますが、以前入力した部分を見ながら新しく作成するときは画面分割して
作業したいです。

上大

2011/6/16(Thu) 00:19:27|NO.39684

僕は型を混在させられる連想配列 (JavaScript みたいな) が欲しいですね。高望みか。

> ddwTree
似たようなツールに、knowbug というのもありますよ (宣伝)
環境によっては動かないかもしれませんが……。
→ http://prograpark.ninja-web.net/CollectField/#knowbug

木村

2011/6/16(Thu) 06:42:23|NO.39691

>>skyblue様
>ビルドする＝コンパイル＋リンク
　成程。ご指導ありがとうございます。これでエディタのアレンジへの道筋が開けました。

　ところで、他の方で既にOpenHSPのソースを利用して改造エディタを使っている方はいらっしゃいますでしょうか？　いらっしゃるのでしたら、強調語句の追加以外にどんな改造をなされているのかお聞きしたいです。

（´ω｀）

2011/6/23(Thu) 11:15:03|NO.39819

コンパイル時に変数の宣言が必要/不必要なのを、オプションで設定できるようにしてほしいですね。
デフォルトでは不必要（今までどおり）、望むなら必要にできる、て感じに。

ほんとに、変数名のタイプミスによるバグが一番しんどいです。（；ω；）

aoisensi

2011/6/26(Sun) 04:57:51|NO.39838

とりあえずアドイン機能を付けてほしい

kos

2011/6/26(Sun) 15:55:28|NO.39839

BasicっぽいところやCっぽいところなど混沌とした記述を統一してもらえるといいですね

wak

2011/6/27(Mon) 00:23:52|NO.39848

言語仕様的な事は全然分からないのですが
エディタを気軽に開けて、高機能なのが良いかも。
ヘルプもパッパッと出て問題箇所を見つけ易い様な。

一番身近な所で、ＤＬＬの命令が変色せず
白いままなのを解決して欲しいと思います。
標準命令がブルーなら、ＤＬＬ命令はアクア等。

#includeの文字列の次に色指定出来る部分があって
色を指定すると、そのＤＬＬの命令は全て
その色で表示される、って言うの考えました。



#include"hspogg.as",$00FF00
～ほにゃららほにゃらら～
・
・
・

こんな感じで。

Ssri

2011/6/29(Wed) 22:13:03|NO.39870

マルチスレッド化希望
擬似マルチスレッドとかAPIでHD上に仮想共有メモリ作るのでは限界
俺だけかもしれんが

荒河軒持

2011/7/2(Sat) 04:14:12|NO.39904

現在分かれてるエディタとワンキーヘルプを統合して
*.hsファイルを元に色分け表示したり、
Visualなんたらみたいにマウスカーソルあてると一行ヘルプ的なのが出てきたり、
命令や関数の候補が表示されたりするエディタ。

そういえば世の中64bitに移行しつつあるけど、
未来のHSPは64bit化するのかな？それとも.NET Frameworkで動くようになるのかな？

skyblue

2011/7/2(Sat) 11:13:30|NO.39907

>未来のHSPは64bit化するのかな？それとも.NET Frameworkで動くようになるのかな？
64bit化のほうがいいです。64bit化希望！

snuke

2011/7/2(Sat) 14:47:53|NO.39911

サブルーチンのネストの深さの上限をもっと大きくしてもらいたい。。

荒河軒持

2011/7/2(Sat) 19:16:34|NO.39917

>サブルーチンのネストの深さの上限をもっと大きくしてもらいたい。。
そんなにネストして何を・・・

>>未来のHSPは64bit化するのかな？それとも.NET Frameworkで動くようになるのかな？
>64bit化のほうがいいです。64bit化希望！
.netならARM版Windowsが実現した時に同一のバイナリで動くんじゃないかなって。
（LinuxのMonoでも動くことを期待している）
まぁ、移植は確実64bitの方がやりやすいんじゃないかとは思うけど。

skyblue

2011/7/3(Sun) 08:35:28|NO.39922

>まぁ、移植は確実64bitの方がやりやすいんじゃないかとは思うけど。
自分はやったことないので断定はしませんけど、
.net化よりも64bit化のほうがやりやすいと思います。
64bit化の場合、変数などの型やポインタなどを64bitに変更したりするだけだし、
本当はもっと難しいのだろうけど。
それに対して.net化の場合、名前空間や文法の変更などをしないといけないだろうし。

2011/7/6(Wed) 02:48:13|NO.39933

>サブルーチンのネストの深さの上限をもっと大きくしてもらいたい。。
再帰処理でちょっと困った経験があるので、自分も希望します。
具体的にはぷ○ぷよですね。でかい塊を作るとネスト上限に引っかかる。

勿論再帰を使わない方法というのもあるにはあるんですが、
再帰を使った方がずっと処理速度が速かったので・・・。

木村

2011/7/6(Wed) 23:14:59|NO.39940

>>snukeさん
>>iiさん
>サブルーチンのネストの深さの上限をもっと大きくしてもらいたい。。
　再帰処理で『サブルーチンやループのネストが深すぎます(Error9)』のエラーが出るのでしたら、その原因はサブルーチンネストではなく“ループネスト”である可能性もあります。
　何故なら、サブルーチンネスト（sublevに相当、gosub命令やユーザー定義命令によるジャンプで増える）は最大511段まで潜る事が可能ですが、ループネスト（looplevに相当、repeatを経過すると増える）は最大31段までしか潜れないからです。
　再帰処理の中にrepeat～loop構文があるようでしたら、for～next構文に変えてやる事でネスト不足が解消されるかもしれません。解消しなかったらごめんなさい。

　……しかし、結構処理が面倒臭そうなサブルーチンネストの方が、cnt値と繰り返し元だけ記憶しておけば十分そうなループネストよりも深く潜れるという仕様は意外です。ループネストって、実は相当面倒臭い処理なのでしょうか？

zakki

2011/7/7(Thu) 23:18:06|NO.39950

> サブルーチンとループのネスト
サブルーチンの制限はメモリの消費量が増えることを気にしなければ、stack.hでの定義の変更で問題なさそうです。
サブルーチンのほうがループにくらべ引数やローカル変数の退避等で複雑ですし、ループ情報を保存しているLOOPDATがサブルーチンに使われて言うHSPROUTINE と比べて大きいということもありませんが、ループ情報はHSPCTXが保持しているので32段制限から変更するとプラグインのバイナリ互換性が無くなりそうです。

> JITコンパイラ
完全にはまだまだ遠くはありますがOpenHSP側ではllvm対応をやってます。

> 64bit化
.net化は作り直しに近いことになるような気がします。
x64対応の場合でも本体に加えてプラグインの64bit対応も必要になりますね。

skyblue

2011/7/8(Fri) 19:42:20|NO.39955

>.net化は作り直しに近いことになるような気がします。
作り直しに近いとはいえ、ある程度は再利用できるだろうけど大変そう。

>プラグインの64bit対応も必要になりますね。
プラグインのほうもやりやすさとしては本体とあまり変わらないんじゃ？