现在的很多游戏开发，完全反过来了

polarboy

instemast: Re: 现在的很多游戏开发，完全反过来了

所谓“理想的方式”是怎样的？看一个例子：
[code]
// 规律:
using system::time
with class Ball
   ...

我怎么觉得这和switch没多大区别啊

我想说一下,就算是verilog,一个硬件描述语言
也需要用parameter定义一系列的常量(当然,都是以1,0构成的),如

parameter state1 = 3'b000, state2 = 3'b001, state3 = 3'b010

然后我们有一个always块
always (posedge clock, reg_q)
   case (reg_q):
     state1:
         reg_d = state2;
     state2:
        reg_d = state3;
     state3:
       reg_d = state1;
end

然后再有一个
always (posedge clock,reg_d)
  register (clock, reg_d, reg_q); 把reg_d的状态写入reg_q
end

我觉得这和switch根本就没多大区别

bbvs

写脚本最方便了 [em21]

instemast

polarboy: Re: Re: 现在的很多游戏开发，完全反过来了



我怎么觉得这和switch没多大区别啊

我想说一下,就算是verilog,一个硬件描述语言
也需要用parameter...

当初还在编BASIC的时候，比如：

10 请输入姓名
20 如果错误 GOTO 10
30 请输入密码
40 如果错误 GOTO 30
...

在C++中，假如有同时两个并行的模块都要像上面那样，那么在软件开发中一般会选择win32 multi-thread。但游戏开发在这里通常不用多线程，那也就要写成：
（方便起见不用状态极类而直接用switch）

switch(m_State)
{
case 1:
  请输入姓名; m_State++; break; // "break":把CPU交给下一个并行的模块,下同
case 2:
  如果错误 m_State=1; break; else m_State++; break;
case 3:
.........
case 4:
.........
};

这样累不累？（改为state machine CLASS也是一样的道理）

instemast

1. 
   
2. 10 请输入姓名
   
3. 20 如果错误 GOTO 10
   
4. 30 请输入密码
   
5. 40 如果错误 GOTO 30
   

复制代码

在这种方法中，m_State（状态变量）由 CPU 的 EIP 寄存器充当。也就是说直接利用了CPU的现成功能。

但是后一种方法，等于是手工实现 EIP 寄存器

crazii

instemast: Re:现在的很多游戏开发，完全反过来了
状态机用 if ... then ... else ... 写， 而不是 interface IStateMachine, 或 switch(m_State)

[em7]这个不明白啊.
怎么感觉状态机用ifelse和switch是差不多的呢.状态多的时候,就会有很多ifelse或者switch.所以扩展修改起来很乱很不爽.
而用state machine就会有很多state class,但是貌似结构很清晰,扩展的时候就添加一个newstate class,对上层的机制:statemachine不需要做修改.
这是设计模式里面说的状态模式讲的,我感觉也是这样.呵呵

instemast

crazii: Re: Re:现在的很多游戏开发，完全反过来了


[em7]这个不明白啊.
怎么感觉状态机用ifelse和switch是差不多的呢.状态多的时候,就会有很多ifelse或者sw...

ifelse 和 switch 这两个是差不多。就像我说“电脑”和说“计算机”都是指同一个事物，而不是发个帖子讨论，电脑和计算机有什么不同，这没有必要，因为谁都知道说电脑和说计算机一般都是指同样的东西。

但是 ifelse / switch 和
if m_State=... else... / switch(m_State) / 状态机类
这两个差的就远了.

loserwang

其实这种思想从早期的消息封装就有了，更好的做法当然是“适配器 + 映射表查找”，行为类只是套用类的外壳，其核心是需要把异质的行为和相关事件配接并放置到同质容器中并完成转发，这样，通过派生新的适配器，可以满足各种类型的事件数据解析机制，通过配接，用户可以简便地将一些函式的地址作为行为放置到映射表以便于事件发生时可以正确转发。

现提供一个适配器实现：

1. 
   
2. template<typename ClsTy> class invoke_ui_ii
   
3.         :public invoke_root
   
4. {
   
5. public:
   
6.         InheritClass(invoke_ui_ii);
   
7.         typedef uint arg_type_1;
   
8.         typedef int arg_type_2;
   
9.         typedef int arg_type_3;
   
10. 
    
11.         typedef LRESULT(ClsTy::*method_type)(arg_type_1, arg_type_2, arg_type_3);
    
12. 
    
13.         Type(method_type Met_, class_type* This_)
    
14.                 :Base(This_), Method(Met_)
    
15.         {}
    
16. 
    
17.         virtual LRESULT operator()(WPARAM wparam, LPARAM lparam)
    
18.         {
    
19.                 arg_type_1 arg1 = arg_type_1(wparam);
    
20.                 arg_type_2 arg2 = arg_type_2(LOWORD(lparam));
    
21.                 arg_type_3 arg3 = arg_type_3(HIWORD(lparam));
    
22.                 return (reinterpret_cast<ClsTy*>(_This)->*Method)(arg1, arg2, arg3);
    
23.         }
    
24. private:
    
25.         method_type Method;
    
26. };
    

复制代码

但是这有一个前提条件，适配器种类应当是相对稳定的，并且面向系统行为，对于一开始便打算由用户提供的状态机机制，是否需要这么严格地进行设计，本人认为大可不必，因为此类状态机应用是属于“逻辑脚本”的一种，重用性基本为零。

snhun

polarboy: Re:现在的很多游戏开发，完全反过来了

状态机用 if ... then ... else ... 写和 switch(m_State)的区别在于...?

switch永远只做1次判定.
if在运气最好的时候才做1次判定, 不然要做n次判定, 所以时间消耗也不一样.

怎么样?

神秘的猫

枚举+函数指针才素王道

instemast

snhun: Re: Re:现在的很多游戏开发，完全反过来了


switch永远只做1次判定.
if在运气最好的时候才做1次判定, 不然要做n次判定, 所以时间消耗也不一样.

怎么样?

ifelse 和 switch 这两个是差不多。就像我说“电脑”和说“计算机”都是指同一个事物，而不是发个帖子讨论，电脑和计算机有什么不同，这没有必要，因为谁都知道说电脑和说计算机一般都是指同样的东西。

但是 << A >> ifelse / switch 和
  << B >> if m_State=... else... / switch(m_State) / 状态机类
这两个差的就远了.
-----------------------------------------
说下速度：
<<A>> 由于状态机是透明的(由CPU中的EIP寄存器充当状态变量), 所以不会浪费时间.
<<B>> 由于手工实现了状态机，所以要浪费时间. 浪费多少时间，取决如如何编码。
如果用 switch(m_State) 则很慢而用多态(函数指针)则很快。
-----------------------------------------
但是注意：执行速度快，不代表书写就方便。