引用:

原帖由 sakerping 于 2020-3-26 14:18 发表

你还别说，论复杂程度，这游戏我觉得比旷野之息更复杂，单位面积的细节多很多。旷野之息那才真是内存不够，跑两步回来一看东西没了复位了。而且这游戏的细节是近乎不可控的，或者说很难量化吧，没什么家具东西的话 ...

联动不提，只说读盘。
旷野内存为了兼容萎哟只用了1GB，真正用尽的是巫师3（都没法录像了）。旷野里跑远了东西复位是游戏设计问题。举个例子有的东西比如树如果想每棵树都记录个状态（有没有砍倒，倒下的方向和距离、变成了几个打捆的木料、每个的位置朝向等），每棵树状态也就几BYTE，地图里所有树都记录也用不了多少内存。问题是游戏没这么设计。至于为什么不这么设计，一是没必要，二来道具这类东西都是消耗品数量无限，所以不能每个都记录状态。
真正设计成需要记录世界里一草一木状态的游戏，举个例子DQ建造者。游戏里每棵树每朵花每个土坯，拿掉就没了。但消耗内存多少？5个存档也就700多M，平均每个不到200M。
动森大概也属于这样的游戏，存档文件多大？几个档？

然后说单位面积的细节：楼上贴了个微博，但里面内容真看不出有多占内存。而且还是室内，场景这么小。进这种房间都需要读盘除了技术力差就没别的解释。

引用:

原帖由 fooltiger 于 2020-3-26 14:12 发表
posted by wap, platform: iPad
你玩了就知道了

https://m.weibo.cn/detail/4486362994994598

这是游戏里的最小的物件，占一格，一屏幕里轻松放几百个，你感受下这个建模和贴图的细致。荒野之息跟这个比简直算 ...

几百张图好了。假设每次进屋前都需要把这几百个图读进内存，而不是等到拿起来看时再读（这本身已经够技术力低下了）。每个图分辨率多少？颜色数多少？自己算需要多少容量（再假设没压缩）。

引用:

原帖由 Nigel 于 2020-3-26 17:54 发表


联动不提，只说读盘。
旷野内存为了兼容萎哟只用了1GB，真正用尽的是巫师3（都没法录像了）。旷野里跑远了东西复位是游戏设计问题。举个例子有的东西比如树如果想每棵树都记录个状态（有没有砍倒，倒下的方向和 ...

我们也没否认技术差。我觉得我们的意思是，在任天堂的游戏里，他这种机制是有原因的，而任天堂的游戏本身技术都算不上好的。
另外你注意过没有，动森这次每个物品都可以放大的，用拍照模式可以放大看的很清楚，只是常规模式的视角限制所以平时看不出来。我就觉得这游戏比我们想的内容和细节肯定多很多，这样规模的细节和内容对这种（落后的）技术来说就只能采取这样的机制，就是各种loading，所幸也没算破坏体验，因为其实这游戏人物动作各种都慢半拍，就不是个快节奏的机制。

posted by wap, platform: 小米NOTE

引用:

原帖由 @混血王子  于 2020-3-25 10:16 发表
单纯的码农技术力问题，从联机就看出来了

这作的开发时间是2012年，用了8年的时间完成，其实论技术力可能动森组比剑盾组还差点，但任天堂愿意打磨

并没有开发8年，本来是为wiiu开发的，但是wiiu失败才转到ns上，而且也没有一直开发，中间开发splatoon2了

posted by wap, platform: iPad

引用:

原帖由 @Nigel  于 2020-3-26 17:54 发表
联动不提，只说读盘。
旷野内存为了兼容萎哟只用了1GB，真正用尽的是巫师3（都没法录像了）。旷野里跑远了东西复位是游戏设计问题。举个例子有的东西比如树如果想每棵树都记录个状态（有没有砍倒，倒下的方向和距离、变成了几个打捆的木料、每个的位置朝向等），每棵树状态也就几BYTE，地图里所有树都记录也用不了多少内存。问题是游戏没这么设计。至于为什么不这么设计，一是没必要，二来道具这类东西都是消耗品数量无限，所以不能每个都记录状态。
真正设计成需要记录世界里一草一木状态的游戏，举个例子DQ建造者。游戏里每棵树每朵花每个土坯，拿掉就没了。但消耗内存多少？5个存档也就700多M，平均每个不到200M。
动森大概也属于这样的游戏，存档文件多大？几个档？

然后说单位面积的细节：楼上贴了个微博，但里面内容真看不出有多占内存。而且还是室内，场景这么小。进这种房间都需要读盘除了技术力差就没别的解释。

室内的家具是可以摆在室外的呀，室外把内存用满了，再进室内不就只能读盘吗。

室外堆这种东西是可以同屏几百个的。

本帖最后由 fooltiger 于 2020-3-26 21:18 通过手机版编辑

posted by wap, platform: iPad
我简单算一算，一个物体，贴图一个面256x256是有的吧

256x256x6x24bitx500，物体贴图就五百多MB了，还有模型数据，还有程序数据，室外部分用光内存很正常啊。

以ns的机能，内存肯定都是预先划好块而不是随着使用量增多动态申请，动态申请平时执行时肯定会卡顿，现在至少读完盘后整个过程是顺畅的。

假设ns游戏可用内存3g，室外最坏状况2.5g，室内最坏状况1g，那在室外时就会一次性分配2.5g内存给室外，进室内时把室外部分的一段500m的数据放入ns内置存储的交换区，再读入1g的室内部分。出门时又交换回来。

cpu更强的情况下可以选择动态分配内存，室内和室外数据加起来不到3g的时候就都读入内存，进出不用读盘，但这种方式，cpu不强的情况下后期数据爆炸时平时的运行就会非常卡顿，因为需要频繁的把碎片化的内存数据换出换入缓冲区。

本帖最后由 fooltiger 于 2020-3-26 21:35 通过手机版编辑

我又归纳一下看法，就是，说任天堂技术差是可以的，但动森读盘的这个机制并不是因为技术差所以傻慢，也确实有游戏实际情况的因素。我是那种稀里糊涂的老人儿，最近看大乱斗体积10多G那么大才意识到任天堂这公司还是很喜欢在一般人看不到的地方堆料的，说是细节但平时注意不到啊，但也确实是下了很大功夫。

引用:

原帖由 fooltiger 于 2020-3-26 21:23 发表
posted by wap, platform: iPad
我简单算一算，一个物体，贴图一个面256x256是有的吧

256x256x6x24bitx500，物体贴图就五百多MB了，还有模型数据，还有程序数据，室外部分用光内存很正常啊。

以ns的机能，内存 ...

你这算法……还乘以6……
普通物体DXTN格式，每个像素4bit。
那个微博里的场景，如果500多张纸都是玩家自己画的，倒是可以勉强按24bit算（其实256色足够了）。更大的问题是纸那样摞起来，进屋读盘只需要读最上面一张图（其它全压下面看不见），500多全读简直蠢不可及。
总之真正需要的数据量撑死也不会有多少

posted by wap, platform: iPad

引用:

原帖由 @Nigel  于 2020-3-27 09:16 发表
你这算法……还乘以6……
普通物体DXTN格式，每个像素4bit。
那个微博里的场景，如果500多张纸都是玩家自己画的，倒是可以勉强按24bit算（其实256色足够了）。更大的问题是纸那样摞起来，进屋读盘只需要读最上面一张图（其它全压下面看不见），500多全读简直蠢不可及。
总之真正需要的数据量撑死也不会有多少

蠢不可及的是你，你对这个游戏引擎的运行方式没有最基本的了解，纯靠脑补想象，举的例子都很可笑。

dxtn压缩贴图是用来减少存储空间和载入时间的，渲染时解压到显存里原来是多少就要占多少。不渲的物体可能占的空间很小，渲了多少物体显存就要不压缩的占多少。

不显示的物体就不载入？这游戏里所有的物体都是可以随时添加删除的，把东西从包里拿出来就去读一下低速设备？把上层的东西移走就去读一下低速设备？直接卡到不想玩。

我现在物品还不够，没法做压力测试，但是从目前的运行状况判断，如果把整个岛都堆满两层不一样的东西，然后移动时不拖慢的话，这游戏应该是一次性把整个岛上所有的东西都读入了内存的。

本帖最后由 fooltiger 于 2020-3-27 10:02 通过手机版编辑

技术大神能不能解释一下进了房间后再换个房间也要加载是怎么回事

posted by wap, platform: iPad

引用:

原帖由 @第七个男孩  于 2020-3-27 09:50 发表
技术大神能不能解释一下进了房间后再换个房间也要加载是怎么回事

这个加载速度明显就快得多

他一个房间分配了一整段内存，这个大小是按最坏情况考虑，动态墙纸动态壁纸加堆满两层不重样的物品，加墙上挂满，一两百件东西？占的内存不小的。

其实室内占的内存应该也不小，收纳箱里几百件东西，浏览和放出来时都是秒出，都是预先读进内存了的。所以剩下的进出房间也只能分段交换不用的房间到硬盘交换区了。但是总的来讲这一段内存不是很大，所以读取速度快很多。

本帖最后由 fooltiger 于 2020-3-27 10:00 通过手机版编辑

posted by wap, platform: 小米
印象里各种游戏里读盘最狠的一类游戏就是街霸和拳皇，2D的那些作品。

Posted by Xiaomi MI 8 Lite
索尼SSD真是独步天下啊！    TGFC·NG