辛苦了~推文
0-不可见,1-完全可见_F,[...],startopacity,endopacity
startopacity: 动画的初始不透明度
endopacity: 动画的结束不透明度
0 - 透明, 1 - 完全透明
Editor里只能实现最基础的四种功能:lcclarke wrote:
那你说的这些脚本,在Design里面都能实现么?~
坐标的自定变量应该是可以的,只要不是太简单的变量(即有可能出现在其他地方但其实又不是这个用处的相同变量)都是可以自定义的Darkrai7 wrote:
就这么多了?~
循环中可以给图片的坐标自定义变量吗?~或随机坐标...
比如说~
我要在一段地方设定一个循环~而这个循环的步骤是:
淡出淡入~放大/缩小~淡出淡入~缩小/放大~移动到随机位置~淡出淡入...循环~
一共8次~每次有4X4张图片要执行这个动作...
像这样的动作怎么通过简短的操作去完成呢?~
尤其是当要处理的图片数量过多时...
AKB48 - Flying Get里面基本都是类似于 C,0,9949,10865,$white,$red 的东西,C后面不是应该有6个参数吗?Breeze wrote:
(255,255,255)的静态图片将会呈现他们原本的颜色,(0,0,0)上网图片将完全是黑色.这两者之间的任何数值都将形成减色(subtractive colour)【其实就是三原色的数值,(红色,绿色,蓝色),用过photoshop等图像处理软件的应该很熟悉这个,关于这个的使用可以参照我的AKB48 - Flying Get中灯光的使用】
如果你是指$white和$red的话, 那是我赋值的一个代码, 其实本身他所对应的是颜色的rgb值代码emergist wrote:
AKB48 - Flying Get里面基本都是类似于 C,0,9949,10865,$white,$red 的东西,C后面不是应该有6个参数吗?
Thx.Breeze wrote:
如果你是指$white和$red的话, 那是我赋值的一个代码, 其实本身他所对应的是颜色的rgb值代码emergist wrote:
AKB48 - Flying Get里面基本都是类似于 C,0,9949,10865,$white,$red 的东西,C后面不是应该有6个参数吗?
Breeze wrote:
如果你是指$white和$red的话, 那是我赋值的一个代码, 其实本身他所对应的是颜色的rgb值代码emergist wrote:
AKB48 - Flying Get里面基本都是类似于 C,0,9949,10865,$white,$red 的东西,C后面不是应该有6个参数吗?
C,0,10865,11781,$red,$white这段代码不太明白,在图中光线的颜色并没有从红色变为原本的颜色,而是直接变成了蓝色,那么这段代码起什么作用呢?
具体是哪段代码? 因为我这图里面也用了很多循环代码, 而循环代码很多就是基于00:10:865开始的这段的, 实际上对应的时间点并不一定就刚好是这个时间点emergist wrote:
Breeze wrote:
还有,C,0,10865,11781,$red,$white这段代码不太明白,在图中光线的颜色并没有从红色变为原本的颜色,而是直接变成了蓝色,那么这段代码起什么作用呢?
第一段(不好意思,我是新手,请多指教)。Breeze wrote:
具体是哪段代码? 因为我这图里面也用了很多循环代码, 而循环代码很多就是基于00:10:865开始的这段的, 实际上对应的时间点并不一定就刚好是这个时间点
Breeze wrote:
麻烦复制这段代码给我看看
L,0,4在游戏里,光线的颜色并没有从红色变为原本的颜色,而是直接变成了蓝色,我不太明白为什么。
C,0,9949,10865,$white,$red
C,0,10865,11781,$red,$white
C,0,11781,12697,$white,$blue
这里的“动画”是否指的是sprite和animation?Breeze wrote:
用以下的简写参数也是可行的,应用的参数只在动画持续期间生效
_L,starttime,loopcount而你的是:
__event, [...]
__event, [...]
_L,time difference,loopcount不知道为什么会不一样……
__event, [...]
__event, [...]
C,0,12697,13613,0,0,$white,255这句貌似是运用了shorthand,但是我不太理解这个概念,能否说得更详细一些?非常感谢。
这里的“时间跨度”我觉得翻译成“时间间隔”或者“时间段”更好一些;Breeze wrote:
这个符号可以用来快速的把同一时间跨度的大量事件改写为脚本code
我觉得这个应该是XNA游戏框架里处理光影效果的一些方法,请见:Breeze wrote:
A - additive-blend colour (as opposed to alpha-blend)【理解不能...貌似是杂色效果?】
emergist wrote:
Breeze wrote:
麻烦复制这段代码给我看看
我把我不懂的地方一起贴出来吧:
1.L,0,4在游戏里,光线的颜色并没有从红色变为原本的颜色,而是直接变成了蓝色,我不太明白为什么。 红色变到原本颜色的时间点是00:11:781, 这里确实是变回了原本颜色的, 请再仔细看看
C,0,9949,10865,$white,$red
C,0,10865,11781,$red,$white
C,0,11781,12697,$white,$blue
2.这里的“动画”是否指的是sprite和animation? 简写代码因为我没用过所以也不太清楚, 这里只是照原文翻译, 不过应该说静态画面和动画都可以应用才是Breeze wrote:
用以下的简写参数也是可行的,应用的参数只在动画持续期间生效
3.原文里的Standard Loop的代码是:_L,starttime,loopcount而你的是:
__event, [...]
__event, [...]_L,time difference,loopcount不知道为什么会不一样…… 原文的英文解释地不是很清楚, 循环代码的那个starttime就应该是循环开始的时间点和事件发生的时间点之间时间差, 这个是经过验证的所以可以放心使用
__event, [...]
__event, [...]
4.
.osu里的SB该怎么写?是直接加到[Events]里吗? 对, 在event下直接编写就可以了, 但是要注意格式要正确, 格式不正确的时候读取时osu会报错, 会告诉你哪段代码有问题
5.C,0,12697,13613,0,0,$white,255这句貌似是运用了shorthand,但是我不太理解这个概念,能否说得更详细一些?非常感谢。 这里本身的代码是C,0,12697,13613,0,0,255,255,255,255然后我赋值了$white=255,255,255, 所以保存的时候系统会自动把255,255,255替换成$white, 这里实际上是把颜色从0,0,255换到255,255,255
顺便说一下我对于你文章翻译里的几个小点的看法:
1.这里的“时间跨度”我觉得翻译成“时间间隔”或者“时间段”更好一些; ok, 谢谢提出Breeze wrote:
这个符号可以用来快速的把同一时间跨度的大量事件改写为脚本code
2.我觉得这个应该是XNA游戏框架里处理光影效果的一些方法,请见:Breeze wrote:
A - additive-blend colour (as opposed to alpha-blend)【理解不能...貌似是杂色效果?】
http://shiba.hpe.sh.cn/jiaoyanzu/wuli/s ... &classId=4
http://dev.gameres.com/Program/Visual/2D/alpha.htm 因为没使用过这个效果所以我并不是太清楚, 加上你的链接了, 谢谢
F,0,774,,0
M,0,10244,,320,240
M,0,28269,,320,240等等。
L,0,5
_C,0,363,6881,240,120,240,240,0,0
_C,0,6881,13400,240,0,0,240,120,240
L,49090,15
_C,0,0,455,120,90,60,90,120,90
_C,0,455,910,90,120,90,60,90,120
_C,0,910,1365,60,90,120,90,60,90
_C,0,1365,1820,90,60,90,120,90,60
这样的话微风和原文的意思应该是一样的,因为原文说的是:Scorpiour wrote:
补充说明下循环的部分:两种用法皆可
用法A——例子L,0,5
_C,0,363,6881,240,120,240,240,0,0
_C,0,6881,13400,240,0,0,240,120,240
L,0,5 <---- Loop,每次循环额外延迟为0 (time difference), 循环5次。
这个0是从哪里开始计算的呢?答案是:
从物件生效的第一个时间点开始计算,也就是(363)
那么363开始,循环开始第一次,持续到13400结束,然后第2次....,总共5次。
于是这里就又引出了循环的用法B(我觉得更直观)
例子L,49090,15
_C,0,0,455,120,90,60,90,120,90
_C,0,455,910,90,120,90,60,90,120
_C,0,910,1365,60,90,120,90,60,90
_C,0,1365,1820,90,60,90,120,90,60
看这段代码:
time difference = 49090, 物件的第一动作时间点是0,那么实际整个循环是从49090+0=49090开始,运行到49090+1820为止是一个完整的循环,然后再继续,总共循环15次。
这么写应该足够清晰了……
Breeze wrote:
origin: 【初始点】
TopLeft【左上】
TopCenter【上方正中】
TopRight【右上】
CentreLeft【中左】
Centre【中央】
CentreRight【中右】
BottomLeft【左下】
BottomCentre【下方正中】
BottomRight【右下】
我的意思是,这些位置指的是sprite或者animation中哪个点的位置?abalee wrote:
Breeze wrote:
origin: 【初始点】
TopLeft【左上】
TopCenter【上方正中】
TopRight【右上】
CentreLeft【中左】
Centre【中央】
CentreRight【中右】
BottomLeft【左下】
BottomCentre【下方正中】
BottomRight【右下】
那么对于不同的基准进行的改变有什么不同呢?Breeze wrote:
这并不是一个确切的点, 而是动画效果所参考的一个"基准点"
比如说放大缩小以及长宽比例改变, 如果是Centre的话那么就是默认以中心点为基准来进行放大缩小以及长宽比例改变
如果是TopLeft则是以这个元件的最左上的像素点为基准点
这样应该可以理解了吧
Breeze wrote:
就是改变的基准点不同啊...解释地应该很清楚了...
自己试试效果应该就可以理解的
Sprite,Foreground,Centre,"eminem_nz6d1wc2.jpg",0,0
Sprite,Foreground,TopLeft,"eminem_nz6d1wc2.jpg",0,0
Sprite,Foreground,Centre,"eminem_nz6d1wc2,jpg",320,240
http://osu.ppy.sh/wiki/SB_Loademergist wrote:
为什么不同的origin可以导致不同的SB Load呢?
刚才看完了,大概意思明白了,但是里面说“if you set the origin to BottomCentre, then it won't matter how tall the sprite is, it will always be aligned from the bottom. So you can eliminate the empty space at the top. ” 既然图片是在bottom的,为什么会“eliminate the empty space at the top”呢?Breeze wrote:
http://osu.ppy.sh/wiki/SB_Loademergist wrote:
为什么不同的origin可以导致不同的SB Load呢?