[讨论]又犯了个错误
原来一直以为在为游戏引擎的render模块提供被渲染物件列表的时候，用链表可能会在内存分配上更自由一点，不会有频繁的数组移动操作。突然想起来，游戏在切换关卡或地图的时候，要载入处理各种资源，如果在这个时候简单的创建一个连续分布的array，一样可以解决问题，而且写起来更简单一点。最后还是发现，用了array，在为多个物体进行排序分层等操作的，还是要不断移动为数不小的内存，还是链表好。迷茫了，不知道大家都是怎么处理这个问题的。 那用数组分配池，用索引当链表………………
其实不是很理解－ 你的办法很好啊，回头我试试。
感激不尽～ 简单说，就是先分析自己要的是什么，
1. 游戏在切换关卡或地图的时候，要载入处理各种资源, 写起来更简单一点
2. 为多个物体进行排序分层等操作的，还是要不断移动为数不小的内存
实际上不如先用list实现，因为所谓的数组分配池，在不考虑很大分配量的时候就是malloc（或者new这类等），对于1.直接就是内存分配了，而2. 从对节点的操作力度上来看基本上就是用list，或许目前来看std::list应该足够你的需求了。。。
不知道有没有赞同或者反对……
其实绝大多数游戏用list就应该够了，主要就是担心如果是弹幕的话，可能要显示的对像会特别多。因为我不是专业的，没有钻得很深，不太清楚list的具体性能怎么样。如果能做到10w个左右的元素创建加入删除什么的操作能是1xx ms级的，list应该就足够我用了。 弹幕也不会有10W对象吧……一个弹幕估计就10/s左右的生成、消灭频率。
如果是粒子系统，可以独立出来，把“粒子系统”而不是“粒子”作为一个对象，对象数也就减少了很多，而且这样对3D渲染Batch也有好处。如果真的要做比东方BT N倍的弹幕，也许把它作为粒子系统处理会比较好……
我觉得一般用std::list足已，快一点的可以是std::vector保存指针然后动态malloc，或者干脆重用已alloc的内存，感觉上频繁malloc也会影响性能……
以上在下愚见 2D渲染瓶颈肯定在渲染上啊，所以结构可以先不要太在意XD
偶渲染的方法对了，比优化LIST或者ARRAY更加重要……
10W，是把背景什么都算上去的，因为我是想只用一个列表就可以渲染所有的东西。
弹幕游戏只是临时拿来打个比方用，如果采用john_he所说的办法，list也绝对是够用的。
其实我在写的这个引擎，计划要做游戏只有两个SLG。说是在写通用引擎，其实主要就为这两个游戏量身定制。一个就是牧场物语式经营游戏的，这个没有有多少对像，list绝对够用。
而另一个是三国志式的战略游戏。我是希望能做出来容纳100W人的战场，且最少同屏显示1000vs1000的战斗画面。这里面就没有多少子弹，可对象的数量依然很多。所以......
是野心太大了吧，典型的眼高手低。唉～ 对象其实不是太大的问题，直接对应到内存
不过一个对象100字节 10W个就10M…… ||| 不过有体会过300M内存的数个GAME……基本偶机器直接就无法启动……一个就是東方弹幕风做得梦剧终－ －
另外……
1000 VS 1000 其实就应该做得像曹操一样号称百万，重在气势哦，没有人会去数究竟100还是200罢，还有人家 英雄无敌III里面的九头怪不也只有三个头（终极的是五个）嘛。。。 LW大说得有理，100W个对象无疑需要以100M计的内存，把所有要显示的对象都用一个“对象”表示不是很现实。1000vs1000倒是很容易，估计所有对象加起来绝不超过1W（前提是不把粒子系统的每个粒子都算一个……），用list或指针vector都可以。
另，营造气势应该把N个人归为一小队营造假象，像家园2那样的小队系统不错（抱歉俺基本没玩过“气势游戏”，只能用这个作例了），小队攻击力等数值直接基本值*人数算出来就行。100W对象不要说渲染，光游戏逻辑的处理就吃不消了，而且应该不会有玩家会数着杀了多少个……
因为我是想只用一个列表就可以渲染所有的东西
你应该提供一个“渲染对象”的抽象类，供自定义渲染使用，就像N多其他引擎一样，这样扩展性大大增加，又可以利用渲染列表的便利。
页:
[1]
2