【发布时间】:2009-06-22 15:17:35
【问题描述】:
我有一个目前用 C/C++ 编写的中型项目(回合制游戏)。只有一个人正在研究它。它将符合 /clr,虽然我没有尝试过 /clr:pure。
我正在寻找有关将其转换为 C# 的整个过程的建议。
它主要是 C 语言,上面有一层薄薄的 C++(C 语言带有静态/单例类用于范围界定)。是的,这不是“真正的”OO,我一直计划先进行 C# 转换,以避免在转换时产生任何转换问题。
它在寻路模块中对 STL(队列类)的使用非常有限,而且因为它是一个游戏,它也不会在 DLL 中的第三方声音库之外进行任何内存分配,以及什么是必要的用于加载图形位图。
我想把它转换成惯用的 C#。我宁愿不讨论这是否是一个好主意,我知道不是,让我们放手吧。请假设我有最重要的原因。
我也完成了我的研究,并且有一个线程与使用反射器转换方法有些相关。当我有机会时,我计划更深入地研究它。
还有一个付费应用程序可以从 C++ 转换为 C#,如果它不能正常工作,我可以看看。
最困难的部分将是用 WPF/Silverlight 或 XNA(或两者兼有)重写界面。每种方法各有利弊,但由于字体支持,我现在倾向于 WPF,并且因为这样我就不必编写所有的小部件。我最终可能会同时做两个,一个 XNA 快速端口,一个 WPF。
对此有几种可能的方法,我想知道是否有人对这样的转换有任何经验,以及任何建议或陷阱。
1) 首先创建 UI,这包括将 Graphics 模块保持原样,从 GDI 转换为原始 GDI,如 XNA 中的调用,然后一次转换为 WPF 一个对话框。
2)先转换胆量,暂时将主UI留在C++/CLI中,胆量转换后,将界面一次一个对话框切换到WPF。
一个相关的问题是,是否值得一个模块一个模块地做这个,或者基本上一次做,以及粗略地转换成 C# 并清理所有东西,还是清理 C++ 中的所有东西然后转换成 C# 更好。
现在的想法是重写事件循环以使用像 MFC 这样的本地通用循环,然后尝试将所有内容立即转换为 C#。将图形留在 C++ 中,看看有什么问题。之后,移至 XNA 并稍后提供 WPF 层。最后两步是任意的,我认为XNA端口会更简单,但是使用WPF基本面板也可能很简单。
我愿意接受任何可能有帮助的建议。
谢谢, 拉尔夫
【问题讨论】:
-
我在考虑做同样的事情时发现了这篇文章,我很确定这与你七年前问的完全一样的回合制游戏。不过,我假设它无处可去。
-
我决定继续使用 C++。我编写了一个 UI 框架,而不是尝试将所有内容都更改为 C#。我应该在今年晚些时候发布。
-
我会期待的!