我的打飞机游戏的碰撞算法是不是很失败？

Civilian

简单,可以建立存在网格模型,处理物体时,将物体存在处网格置为true
处理子弹时直接看它在的网格是否为true就可以了

superdai

我看到日本的有些射击游戏有最大子弹上限的。

射击游戏没可能拼命的显示满屏幕的子弹。但是一旦多了确实会降低画面速度，记得街机也看到过这样的问题。（1945的一关）

免费打工仔

woodangel: Re:我的打飞机游戏的碰撞算法是不是很失败？

不用对象做子弹就如同用C而不是C++编写游戏一样，如果不用对象做子弹，日后对子弹做出更高的要求的时候比如子弹加上会追踪，会判断对方的距离，会根据不通的敌人作出不同的动作的功能的时候你怎么扩展啊？

很好办，在子弹上加一个int type 然后粒子系统根据不同的type处理不同的子弹移动方式，只要扩展粒子系统就好了，按你的想法如果子弹都继承一个类的话，可能要准备很多虚函数的，想象满屏幕的子弹会让系统雪崩吧。

如果可以继续按照你的思路想的话，两个子弹配合打击一个目标，人工智能子弹，还是粒子系统来协调比较好。

“不用对象做子弹就如同用C而不是C++编写游戏一样”这句话我不能认同，我不认为C++只能用类而不能用结构。当然C++是一种面向对象思想，这也不能说明必须所有的能看到的东西都是对象阿。其实我看到的绝大多数粒子系统的教程都使用结构来实现粒子的。对象和结构只是一个权衡而已，用最有利的就好了。

woodangel

是可以，不过用粒子系统面向对象的思想就没怎么深刻了，按你的思想再干脆点把敌人，玩家，建筑等都做成是粒子系统的一员，这样就等于是用C而不是C++来编写游戏的道理一样，如果子弹的运动规律在复杂点比如子弹具有人工智能等，你要扩展和维护不就更困难了把，要快不如用机器码来编写整个游戏算了

小陈00

晕，就算有一个屏幕有１００００颗子弹又怎地．．．
才多了4*10000 byte,又不是做街机，不缺这个，而且多这个指针是　用的空间换的速度！可以把Ｃ风格下的很多类型相关的 if 省掉，速度可能还快一点？（虚函数有一个必用的理由就是　程序中大量出现if的情况）
再说这种小对象大规模的构造都是要用内存池的，这一点可能无论用Ｃ和Ｃ＋＋来写，都是一样．

免费打工仔

您误会的想法，并没有思想那么深刻的说。

子弹是什么样子，策划应该早就说了吧，如果子弹有人工智能的话当然是类好了，如果子弹有3中飞行状态2种附加武器54种攻击模式，可以携带物品，可以和别的子弹对话，还可以隐身，变形。哦，这个子弹比你的飞机还好复杂得多。
别说用类了，用类的组合来实现这样的子弹都不过分。

我的想法是，最好用最适合的结构，我是一个比较笨的策划的话，可能我的子弹只要直线飞行就好了，我需要类么?可能我不需要。你的策划很伟大，当然需要为大的方式来开发了，这个不矛盾的。

如果敌人，玩家，建筑物更适合粒子系统我也会，我也会有个权衡。

但是明确一点，我们两个现在不是对一个游戏来讨论，我们脑中的游戏不一样。这样来说，我所认为一个纵向设计游戏大部分子弹是可以直线飞行，简单得不得了的。而敌人和玩家相对复杂，建筑物不会移动，只有被破坏和提供奖励。

你脑中的游戏呢，就目前看来，你的子弹系统的确复杂。我认为你的游戏子弹的确不适合粒子系统的说。

woodangel: Re:我的打飞机游戏的碰撞算法是不是很失败？

是可以，不过用粒子系统面向对象的思想就没怎么深刻了，按你的思想再干脆点把敌人，玩家，建筑等都做成是粒...

小陈00

晕死,谁给我解释一下,这个问题里面 用 对象 哪一点慢了????????
如果都是用内存池的话,C和C++在这个问题上会表现出的性能区别么?
class A{fuc();} 和 struct A{};fuc(A* p)有区别????????
如果子弹的种类多的话,C++的虚函数还会快一点.因为虚函数的前生正是C里面的一项高级技巧.

再说C++从不拒绝小对象!实际上的所有C++优秀的设计都是善用小对象组建而成的.

免费打工仔

大家要知道的是，函数调用是要使用系统的栈来保存数据的，如果编译器里有栈检查选项，一般在函数的头会嵌入一些汇编语句对当前栈进行检查；同时，CPU也要在函数调用时保存和恢复当前的现场，进行压栈和弹栈操作，所以，函数调用需要一些CPU时间。大量的小类，每个类分别调用函数，开销很大。inline函数是没有这个开销，可是虚函数又不能inline。
算法分析书上经典的八皇后问题大家都做过吧，我曾经自作聪明的用面向对象方法实现回溯，用对象实现每个棋子，然后棋子互相检查条件判断，并在棋盘移动，其他基本上和算法书上是一样的算法，也可能是我程序设计问题，效率无法接受，十几秒钟的过程竟然用了几分钟。如果大量调用类中无数个小函数可以和用一个函数处理结构效率一样的话，希望哪位大大实现一个好一点的八皇后看看。证明我的愚蠢。

小陈00

这两个问题不一样吧?
八皇后一般的算法都用 递归或跌代  解决 ,在这种只有一个函数(而且函数体十分简单)来判断的情况下, 跌代比递归快很多,是无可厚非的.
但如果不是八皇后? 而是 一皇后+1国王+1相+兵...什么的呢?
情况和子弹比较接近了吧?不同的是子弹函数的主体会比 一皇后+1国王+1相+兵...的运算量大一点...恩,复杂一点.
so ,多一个类型,跌代就多一个if,CALL的周期记不得了好象是3~5个?+栈的操作(编译器可以优化到寄存器里吧) 也不会比那10个8个的if(==)慢到那里去啊?
虚函数其实比较象以前C里的函数指针大法,在很多C的设计里也出现过用函数指针顶IF作用的.
这句话哈 （虚函数有一个必用的理由就是　程序中大量出现if的情况）

我刚开始可能误会你的意思了,你可能也误会我的意思了.
我是想说明 类型比较多时 虚函数比IF管用 ,
你是说明 类型较少时 函数调用的开销太大吧?

迪哈鲁特

......