libGDX
-
一、Off-Screen Rendering 一些画面效果经常需要离屏渲染，离屏渲染需要创建一个独立的FBO来绘制，在绘制处理完成后再把绘制内容提取出来绘制到游戏显示的FBO里。 这个过程因为涉及到FBO的切换，所以需要跟OpenGL底层打交道。虽说用gdx-vfx库里的VfxFrameBuffer应该是可以自动处理OpenGL的嵌套FrameBuffer的问题的，但gdx-vfx的FrameBuffer限制了只能用TextureAttach的，如果想要使用MSAA之类的特性就不支持了，那只好自己写一个。 主要处理FBO绑定、Viewport和裁剪开关的备份和恢复，需要给裁减开关是因为通常在布局UI中会有一些布局裁剪会设置裁剪区间，如果不临时禁用裁剪的话在离屏FBO上也会被裁剪。 public class GLStateMaintainer { private final IntBuffer viewport = BufferUtils.newIntBuffer(16); private final IntBuffer previousFboId = BufferUtils.newIntBuffer(1); private int vpx, vpy, vpWidth, vpHeight, previousFbo; private boolean scissorEnabled; private void backup() { Gdx.gl.glGetIntegerv(GL20.GL_VIEWPORT, viewport); vpx = viewport.get(0); vpy = viewport.get(1); vpWidth = viewport.get(2); vpHeight = viewport.get(3); Gdx.gl.glGetIntegerv(GL20.GL_FRAMEBUFFER_BINDING, previousFboId); previousFbo = previousFboId.get(0); scissorEnabled…
-
随手写的，有空再整理。 一、Stage、ViewPort、Camera、FrameBuffer、Batch Stage就是实在的游戏世界，Stage与显示逻辑毫无关系，Stage只是在客观的描述游戏世界的内容。 ViewPort代表Stage到Screen的缩放方式（平铺、缩放、拉伸、延展等）。 Camera包含两部分，观察世界的位置与方向，以及如何投射到FrameBuffer。 FrameBuffer就是画布。 Batch是连接Camera投射和FrameBuffer工具，Batch在事务过程中不能修改Camera投影，也不能改变画布大小。 任何时候必须保证Camera大小与FrameBuffer大小相同。 二、布局坑minWidth, minHeight, prefWidth, prefHeight, maxWidth, maxHeight的处理逻辑非常恶心，和width还有height的关系很迷惑。 恶心的根本原因在于框架的布局逻辑里没有专门为测量做设计。通常布局的逻辑有两个阶段： 测量阶段：布局控件要先测量所有孩子控件的大小，来计算自己需要的总大小。此时控件没有真实大小。 布局阶段：然后根据自己的可用大小和孩子的预期大小权衡后进行布局。此时父级（包括当前）布局都已拥有真实大小。 这两个阶段本都是相对比较独立的递归过程，单独写都很好写，但框架实际只有一个layout函数要处理完整个逻辑时就很容易出错。测量阶段被用prefWidth和prefHeight简化了。 但框架里prefWidth和prefHeight都是接口，而且只有WidgetGroup会提供这个接口，这意味着用户不能在布局文件中预设控件的大小——因为prefWidth和prefHeight不是所有控件都有，甚至也不是个能写的数值。如果使用width和hegiht来填写这个期望值，那么当父布局因为某些原因无法按照预期大小对控件进行布局时，原来的width和height属性就会被覆盖，这个原始的“期望”大小就会消失。 总结下来注意的就两点： 测量阶段的函数不要使用任何需要控件实际大小的依赖，某些处理空余空间分配的逻辑不要尝试写进测量阶段。 对于用户的期望大小，尽量使用控件外的逻辑来赋予，而不要使用width和height，否则会丢失原始数据。 三、布局默认会把transform设置为true，导致孩子的draw方法会使用父布局的坐标 他妈逼的煞笔默认逻辑，查了我半天为什么会出现偏移错误，关键是layout出来的位置都是对的。 先这样吧，
-
本文非面向libGDX入门用户，仅为个人日常记录。 相关关键词：Skin-Composer, gdx-vfx 绕不开的控件Skin-Composer 虽然我用着gdx-lml很舒服，但是想要深度定制自己的界面终究还是绕不开使用Skin-Composer。这玩意真的太折磨了，但是又不能不用，gdx-lml基本上都是从skin里取样式的。 一堆的Bug，真是被恶心的不要不要的，包括但不限于： Skin的定制还是应该从0开始 其实从0开始最大的好处就是我其实根本用不到所有的控件，所以如果上来给我贴全部皮肤的样式我会直接懵逼的。我甚至不知道那些控件的属性要放什么，反而加大了我配置皮肤的难度。所以，个人认为自制libGDX皮肤最好的方法是，首先写使用默认的样式写好你自己的应用的基本UI界面，之后把读取的skin换成一个空的skin，启动游戏，报错里面缺哪个Style就加哪个Style，就从默认的样式里把这个样式加进来。经过一次一次的报错，就可以把所有需要定制的样式全部写完。 Skin的TTF支持 虽然这libGDX官网有介绍怎么在gwt下使用TTF，但是Skin文件里是不带TTF字体配置支持的，而Skin-Composer倒是在导入TTF文件的界面有个指引，算是个加分项吧。这里把类贴一下吧，避免下次自己什么时候忘了。 gdx-vfx屏幕特效踩坑 这个项目gdx-vfx其实看着还挺帅的，所以拿来试了一下，效果是杠杠滴。不过内置的这些特效都太夸张了，只能用来预览效果，实际使用还是要自己做修改。 于是在试玩的过程中就有一些小发现： 最近的就这些吧。 这几天（主要界面的）UI基本上画好了，接下来可以狠狠地写代码实现了。真是个奇怪的习惯，应该是从安卓开发时期落下的，只当有了完整的设计图我才有开发动力，希望这周能实现个最最最粗略能跑的DEMO.