唔,有种莫名想笑的感觉。 就一个描绘文字的矩形宽度而已,说得太多反而会让提问者觉得云里雾里。 简单粗暴直接,是最有效的办法。 看到这怎么莫名的想到了 大话西游 里的 唐僧 ?! |
本帖最后由 Vortur 于 2018-1-12 23:56 编辑 ⑨姐姐 发表于 2018-1-12 04:34 1. 退一步讲,叫失误。因为当时回复中的代码在下后来又测试了一下,确实不能解决问题。但是附件里的已经更新。而且在下自己都在用这个方法,又怎么能叫误导? 2. 到底是失误还是误导,现在是一个有争论的点,阁下直接跳过争论而把误导作为前提,不免有拉偏架的嫌疑 3. 请阁下仔细阅读阅读贵方能人的回复,连专有名词都用上了,什么时候论坛的版规里还有学术论文的要求了? 4. 请阁下自己读读RaidenInfinity近来的回复,他这么能,怎么不在回复里好好写?把无聊的精力都花费在打击仇人的事情上,对份内职责玩忽职守,天下将亡矣 欲加之罪,何患无辞。就算贵方硬要就地修改版规,处理在下,那在下也要申诉 RaidenInfinity 这个人的品质问题 |
本帖最后由 Vortur 于 2018-1-12 23:42 编辑 RaidenInfinity 发表于 2018-1-12 04:01 1. 删除线里的东西怎么了?你公然抗拒管理层处理结果的事跟我比算什么? 2. “【】”里的东西又不是专业论文,我什么时候说这是专业名词了?那你口中的【误导】我还说是你自己臆想的词语呢;请拿出你自己的参考文献,说说误导是个什么意思 3. 就算跟图片没关系,但这个方法是不是解决了【字体被压缩】的问题?你只用说是还是否 4. 你这么有本事,怎么不在贴里说明,也好让不明白的人知道知道哪里有所谓的错误。回答问题的时候怎么不见你这么用心? 在下帖子里其他的东西,你都没提,那是不是你就承认了?如果你非要抠字眼,好呀,在下去开新帖,处理你 |
本帖最后由 ⑨姐姐 于 2018-1-12 22:35 编辑 我觉得误导确实是不能忍的一件事情,就算动机是好的,也满足了自己的参与感,但结果非但帮不上忙,反而还会给人错误的知识。 矛盾在于很多时候回答问题的时候,缺乏一些“自知之明”也是很自然的吧。我觉得作为回答者来说,最好的方法可能是尽量分享自己的经验,如果要分享理论需要慎之又慎,最好是有官方文档出处的。所谓“分享经验”,就是自己尝试过的和看过的可靠来源加起来如果有10分,在回答的时候不要超出这10分;如果了解10分的内容,却试图总结出50分的经验,最好以一种“我认为”的态度来分享自己的猜想,并且不要当做是绝对正确的。充满自信地写回答,但内容却不是来源于可信的资料,甚至是自己的脑补,虽然很有快感,但在给新人解答疑难的时候不是个好做法,而且损害自己的可信度…… |
本帖最后由 RaidenInfinity 于 2018-1-12 22:23 编辑 来,终于考完期末也回到家了有时间来清算了啊。 首先,来上图。这是后台的回收站里存放的已删除回帖。 熟悉RGSS3脚本应用的各位是不是眉头已经开始皱了呢? 是的,当时我的眉头皱得都快可以夹死蚊子了,虽然我这儿雨季天气稍冷并没怎么有蚊子。 我们就不计较一开始删除线里包含的这个。 【fonts_view != bitmap】 fonts_view是什么东西?这凭空捏造出来的专有名词,是我第一时间就判定为误导,而且还是恶意误导的重大依据。 字体相当于一张图片 来,请拿出参考文献。是哪儿记载的这个说法呢? 什么叫字体?维基百科记载着:字体在书法和印刷领域是指文字的式样。 一些游戏引擎,如libGDX和MonoGame的确是用已经列印好在一张或数张图片上的字符用于文字的绘制(这叫BitmapFont)。 但是,RGSS3基于ttf或者otf格式的,矢量电脑字体文档来进行文字的绘制,是直接在位图上生成文字的。 和图片有什么关系?有 什 么 关 系? 图片有自己的宽高度。这个宽高度与字体实际显示的宽高是不同的。(可以想象一张透明的大纸,纸面只有一小部分被写了字;纸面的宽高是图片宽高,而人眼见到的字是实际宽高) 来,这位老兄,不懂就不要装懂。来装懂你这就是误导。 上面提到的“直接在位图上生成文字”,想当然也就可以附上各种参数。 Bitmap(位图)的参数font(字体),包含的是一个Font(字体)类。 这个类的用途只有一个:就是装载下一次在这个位图执行绘制文字的操作时所使用的字体数据(字体名称,大小,是否粗体,是否斜体,是否描边,描边颜色,是否加影子,文字颜色)。 Bitmap类关系到文字绘制的方法有三个(实际上是两个)。 第一个是 draw_text(x, y, width, height, str[, align]) (中文翻译:绘制文字(X坐标, Y坐标, 宽度, 高度, 文字, 靠边) *靠边是指左中右,默认左,是选择性参数。) 第二个是 draw_text(rect, str[, align]) (中文翻译:绘制文字(矩形, 文字, 靠边)),和第一个的差距只是用一个Rect(矩形)类来表示坐标和宽高。 第三个是 text_size(str) (中文翻译:文字大小(文字)),主要用途是获取以这个字体在这个位图上绘制这段文字的时候生成的宽度和高度。 那么我们来看,draw_text这个方法的前面四个参数。X坐标和Y坐标,这很正常,是决定这文字要在位图的哪个部分绘制。 宽度和高度,就是我们要知道的重点了。在调用draw_text参数的时候,如果实际需要的宽度少于参数内附上的宽度,会发生什么事情呢? 那么RGSS3会尝试不会让文字只显示在框内的部分。它会干啥呢?它会强制压缩文字的宽度,到原本的大约一半。 该帖楼主的提问是:(链接:https://rpg.blue/forum.php?mod=viewthread&tid=405018) RT,两种字体都是相同字号,相同空隙,但一种就能完全显示,另一种被压得面目全非。 因为楼主所提供的截图内的的文字看似是一个技能的,而且也很明显背景是窗口皮肤,所以这是Window(窗口)相关类里面执行的绘制。 RGSS3中,窗口内所绘制的任何事物都是直接画在contents(内容)这个位图上的。想当然,文字就要调用draw_text来执行绘制。 因此,会导致上述问题的,就是宽度参数设定不足。 好,不知不觉就成讲课了。希望各位看官有学到一点知识啊。 那么这家伙发的是什么鬼呢? 本来该绘制在窗口的东西,搞什么精灵啦src_rect啦… 然后! RM有专门的方法来显示文字,叫做“contents”,只要在“Window”类的子类中显示的文字全部都归它管;但它是用C写成的(貌似) > 有专门的方法来显示文字 > 叫做“contents” > 只要在“Window”类的子类中显示的文字全部都归它管 > 但它是用C写成的(貌似) 好哦。来我们看看这张图。 我还需要说什么吗? 大概…已经不需要了。 然后我再看了一次主楼,哦,我看到了什么? 2. 我贴的方法是不是解决了【文字大小与显示】的问题 哦,不止没解决,添加了问题呢! Bitmap的clear_rect方法是用于清空位图内的一部分,避免需要完全重绘位图(一般是窗口的)内的事物。 当窗口的,contents(内容位图)的大小大于窗口所显示的范围而无法一次过完全显示时,就会需要滚动(由ox和oy参数操纵滚动幅度),而且也会显示表示可滚动的箭头。 那么试想想,如果把字体用精灵的方式来显示的话… 大!爆!炸! 所以结论是啥?误导。 明显恶意的误导。别用什么花言巧语来掩饰你那撒旦般的行为。 就像一个“医生”发明了什么“特效药”其实特么是洗涤剂掺绿油精掺红花油然后拿出来想给人治病… 然后被抓个正着被关了。这有趣吗?一点也不有趣。 以上。 |
本帖最后由 赤炎 于 2018-1-12 17:57 编辑 这不算是恶意删帖,是操作失误吧。 第3楼扯得特别远了 版主有哪里操作不合理,好好一起讨论就可以了,不要生气。 |
Vortur 发表于 2018-1-12 13:54 由于提到的版主并没有出来回复。@RaidenInfinity 我也仅能对操作理由“误导”稍作解释。 已通知出面给说法。 |
站长信箱:[email protected]|手机版|小黑屋|无图版|Project1游戏制作
GMT+8, 2024-11-21 23:09
Powered by Discuz! X3.1
© 2001-2013 Comsenz Inc.