关于2d平面游戏元素碰撞的一些想法

1，使用一个二维数组来表示游戏的静态元素，形如：

其中0表示空气，1表示泥土
这样玩家移动时碰撞检测，则只需要获取自己在二维数组中的位置，在判断该位置四周几个格子是否存在实体元素，并进行碰撞检测就行了，这样大大简化了碰撞检测的次数。

但如果存在动态元素我又该怎么判断呢？遍历所有动态元素并一一进行碰撞检测？这样对性能影响太大了，看起来也很蠢。实际游戏中的碰撞检测到底是怎样实现的？

你觉得遍历全部消耗性能，那你可以只让这个对象的周围8个元素参与遍历呀，每移动一步将上一步的八个元素清除，再加八个元素

实际游戏开发中一般会有物理引擎，说白了就是一套框架，后台已经写好了各种函数，直接调用就行了。
那么一般来说，面向对象的编程中，每一帧都会自动的调用每个物体的脚本，如果给物体放上了支持物理的脚本，每一帧都会调用一次进行判断。
性能开销大是必然的，所以跑3d对配置要求很高啊
你这种平面像素游戏计算开销大也耗费不了多少cpu的
-=-=-=-=-=
另，我自己用c#GDI+实现的生命游戏，像素800*600，每秒能跑20个生命周期，对于像素游戏来说足够足够了。
何况你这像素少的可怜

呃，LZ是在手搓2D游戏引擎吗？这真是各古老的问题.....你所说的动态变化的贴图是子弹一类的精灵吧？你在把显存里某一帧的内容绘制到显示器的时候应该有个矩阵对应每个最小拼图单位对应的title的编号。这个矩阵就是你问题中的哪个矩阵。你可以用它来做碰撞检测。根据你的所有可动title的速度，判断下帧是不是碰撞。