具体是哪段代码? 因为我这图里面也用了很多循环代码, 而循环代码很多就是基于00:10:865开始的这段的, 实际上对应的时间点并不一定就刚好是这个时间点emergist wrote:
Breeze wrote:
还有，C,0,10865,11781,$red,$white这段代码不太明白，在图中光线的颜色并没有从红色变为原本的颜色，而是直接变成了蓝色，那么这段代码起什么作用呢？
forum
【翻译】故事版脚本指南(Storyboarding by Scripting)
posted
Total Posts
39
Topic Starter
第一段（不好意思，我是新手，请多指教）。Breeze wrote:
具体是哪段代码? 因为我这图里面也用了很多循环代码, 而循环代码很多就是基于00:10:865开始的这段的, 实际上对应的时间点并不一定就刚好是这个时间点
Topic Starter
麻烦复制这段代码给我看看
Breeze wrote:
麻烦复制这段代码给我看看
我把我不懂的地方一起贴出来吧：
1.
L,0,4在游戏里，光线的颜色并没有从红色变为原本的颜色，而是直接变成了蓝色，我不太明白为什么。
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不知道为什么会不一样……
__event, [...]
__event, [...]
4.
.osu里的SB该怎么写？是直接加到[Events]里吗？
5.
C,0,12697,13613,0,0,$white,255这句貌似是运用了shorthand，但是我不太理解这个概念，能否说得更详细一些？非常感谢。
顺便说一下我对于你文章翻译里的几个小点的看法：
1.
这里的“时间跨度”我觉得翻译成“时间间隔”或者“时间段”更好一些；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
Topic Starter
emergist wrote:
Breeze wrote:
麻烦复制这段代码给我看看
我把我不懂的地方一起贴出来吧：
1.L,0,4在游戏里，光线的颜色并没有从红色变为原本的颜色，而是直接变成了蓝色，我不太明白为什么。
C,0,9949,10865,$white,$red
C,0,10865,11781,$red,$white
C,0,11781,12697,$white,$blue红色变到原本颜色的时间点是00:11:781, 这里确实是变回了原本颜色的, 请再仔细看看
2.这里的“动画”是否指的是sprite和animation?Breeze wrote:
用以下的简写参数也是可行的,应用的参数只在动画持续期间生效
3.原文里的Standard Loop的代码是：_L,starttime,loopcount而你的是：
__event, [...]
__event, [...]_L,time difference,loopcount不知道为什么会不一样……
__event, [...]
__event, [...]
4.
.osu里的SB该怎么写？是直接加到[Events]里吗？
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.这里的“时间跨度”我觉得翻译成“时间间隔”或者“时间段”更好一些；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等等。
這裡的話，是當開始時間和結束時間一樣，後面的結束時間可以省略。
补充说明下循环的部分：两种用法皆可
用法A——例子
L,0,5 <---- Loop,每次循环额外延迟为0 (time difference), 循环5次。
这个0是从哪里开始计算的呢？答案是：
从物件生效的第一个时间点开始计算，也就是(363)
那么363开始，循环开始第一次，持续到13400结束，然后第2次....，总共5次。
于是这里就又引出了循环的用法B（我觉得更直观）
例子
看这段代码：
time difference = 49090, 物件的第一动作时间点是0，那么实际整个循环是从49090+0=49090开始，运行到49090+1820为止是一个完整的循环，然后再继续，总共循环15次。
这么写应该足够清晰了……
用法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次。
这么写应该足够清晰了……
这样的话微风和原文的意思应该是一样的，因为原文说的是：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次。
这么写应该足够清晰了……
Note that events inside a loop should be timed with a zero-base. This means that you should start from 0ms for the inner event's timing and work up from there. The loop event's start time will be added to this value at game runtime
这样的starttime其实也就是time difference。
还有一个小问题：sprite和animation中的origin（TopLeft/TopCenter...）指的是什么地方的位置？
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【右下】
Topic Starter
这并不是一个确切的点, 而是动画效果所参考的一个"基准点"
比如说放大缩小以及长宽比例改变, 如果是Centre的话那么就是默认以中心点为基准来进行放大缩小以及长宽比例改变
如果是TopLeft则是以这个元件的最左上的像素点为基准点
这样应该可以理解了吧
比如说放大缩小以及长宽比例改变, 如果是Centre的话那么就是默认以中心点为基准来进行放大缩小以及长宽比例改变
如果是TopLeft则是以这个元件的最左上的像素点为基准点
这样应该可以理解了吧
每張圖都是長方形，center就是指的幾何中心，topleft是最左上角的那一個像素，如此類推，我是這樣理解的
那么对于不同的基准进行的改变有什么不同呢？Breeze wrote:
这并不是一个确切的点, 而是动画效果所参考的一个"基准点"
比如说放大缩小以及长宽比例改变, 如果是Centre的话那么就是默认以中心点为基准来进行放大缩小以及长宽比例改变
如果是TopLeft则是以这个元件的最左上的像素点为基准点
这样应该可以理解了吧
Topic Starter
就是改变的基准点不同啊...解释地应该很清楚了...
自己试试效果应该就可以理解的
自己试试效果应该就可以理解的
Breeze wrote:
就是改变的基准点不同啊...解释地应该很清楚了...
自己试试效果应该就可以理解的
刚才做了一下实验，先发布一下实验结果：
1.
SPOILER
Sprite,Foreground,Centre,"eminem_nz6d1wc2.jpg",0,0
2.
SPOILER
Sprite,Foreground,TopLeft,"eminem_nz6d1wc2.jpg",0,0
3.
SPOILER
Sprite,Foreground,Centre,"eminem_nz6d1wc2,jpg",320,240
结论：
经过比较，我得出的结论是：origin指的是图片的左上、右下等位置在屏幕中的坐标（左上角是(0,0),右下角是(640,480)），但是我并没有发现origin对于scale或者vector scale有什么影响，所以我更同意abalee的看法。
虽然明白了origin的意思，但是关于这篇文章第二条技巧中的第二点我还是不太明白，为什么不同的origin可以导致不同的SB Load呢？
Topic Starter
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呢？
origin是指参照点吧 用来决定素材位置的x,y坐标的东西 如果设置为bottomcentre的话为定义在素材的底边中间 这样的话 上端的一些空白部分就可以用各种软件删去而不用担心需要调整对齐的问题