关于自适应全屏

lufy

那个引擎并不是基于canvas的，他是通过div标签来实现的，里面所有对象都是div，你看一下代码就知道了，让div全屏那是html最基本的功能，所以比较容易，而让canvas全屏就没那么容易了，我也一直在寻找更好的方法，以后一旦有更好的全屏对策，会及时更新的

lufy

cailven 发表于 2013-6-20 18:08
我非常偏执，对这个问题我调研了其他好几个游戏引擎包括著名的EaselJs,国内的QuarkJS，以及melonjs都没有 ...

非常感谢兄弟一起帮忙。
其实，像这样动态的设置canvas的大小，lufylegend.js也是完全可以的，无非就是取得当前屏幕的大小，然后再设置canvas的大小和屏幕大小相等即可。
不过，这样一来，因为canvas的大小并不是比例缩放，而是大小改变了，那么你的游戏或应用也必须能够随这个canvas的大小变化而变化，比如原来你游戏的地图大小是800x400，当把canvas的大小改为1000x500的时候，如果你的地图不随着改变大小的话，就会出现空白区域了。
而真正想实现类似于flash那样的全屏效果，肯定要对整个canvas进行缩放，而并不是单纯的改变大小，所以才需要通过改变viewport标签的比例来实现全屏效果，这个缩放是整个canvas的缩放，你的游戏对象也会随之缩放。

lufy

cailven 发表于 2013-6-21 00:07
对的，没错，canvas标签根据window的大小自动缩放的同时，viewport的缩放应该就能计算出来。比如初始化的 ...

是啊，对于HTML5来说，全屏的处理相当麻烦，我现在也只是计算了一下viewport的值来完成全屏的，其实要修改的地方还有很多，目前我的精力又无法全都放到这里，所以只能慢慢来了，我本人的兴趣就是研究技术，所以引擎一般来说是夭折不了的，而且引擎开源，以后使用的人越来越多了，就算我不管了，也有其他高手来完善的，哈哈

lufy

cailven 发表于 2013-6-21 11:31
我昨晚想了一下，其实流程上可以这么做就方便很多了。在一开始建立项目的时候，先建立一个LSprite对象取 ...

这虽然算是一种方法，但是我个人不太提倡，一旦对底层的LSprite对象进行缩放，那么里面的坐标肯定会全都变成小数。对于canvas绘图来说，坐标是否取整直接影响绘图效率，在某些浏览器上可能会有8,9倍的差距，绘图效率对于HTML5来说本来就是硬伤，开发过程中应该尽量避免一些影响效率的算法等处理，滤镜等都要尽可能的用图片来代替。

lufy

cailven 发表于 2013-6-21 12:17
对的，还是要考虑性能优化。Js不像as3可以设置强类型，如果as3直接声明变量时候设置成int就好了。诶~~确 ...

兄弟可能没有明白我的意思，
比如有一个LSpriteA,然后在LSpriteA上面加一个LSpriteB，这个LSpriteB的坐标当然是个整数，当LSpriteA进行缩放之后，LSpriteB的坐标依然是整数，但是它相对于Canvas来说坐标就不一定是整数了，引擎在绘制这个LSpriteB对象的时候，需要按照相对于Canvas的坐标来绘制，我说的小数是指相对于Canvas的坐标，这个坐标是无论如何也没办法取整的，如果说硬要在引擎中取整，那么原来对象之间的相对位置就会发生变化了

lufy

cailven 发表于 2013-6-21 16:00
理解，但如果这样的话，只要任何物体缩放后，他的宽高就很有可能产生小数，如果这个物体里面嵌套其他物体 ...

其实效率只是相对来说的，绘制一个对象的时间是很短的，只要不是大量的对象都进行缩放，是不会太影响效率的，我的测试数据的循环次数是相当大的。
另外，单个canvas的效率也明显高于多个canvas

lufy

cailven 发表于 2013-6-21 23:16
那想请教兄弟，页面中像这种html4就有的标签缩放有小数会不会也有效率问题呢。有没有测评过？ ...

我所说的小数是指使用canvas的api来绘图时的坐标，并不是指html标签
因为在游戏中canvas是在不断进行刷新的，可能一秒钟要重绘几千几万个对象，甚至更多，所以才要考虑绘图的效率
像这些单纯的标签，一旦添加之后，跟静态没什么区别了，带给页面的影响完全可以忽略不计