C# 进程间通信<--> C++用于游戏调试引擎

发布于 2024-08-28 08:53:03 字数 158 浏览 2 评论 0 原文

我正在开发游戏脚本引擎的调试器项目。我希望用 C# 编写调试器的 GUI。然而,实际的调试引擎嵌入在游戏本身中,并以 C、C++ 和汇编补丁的混合形式编写。

处理调试器 GUI 和调试引擎之间通信的最佳方法是什么?两者将在不同的进程中运行。

谢谢!

安迪

I am working on a debugger project for a game's scripting engine. I'm hoping to write the debugger's GUI in C#. The actual debugging engine, however, is embedded in the game itself and is written in a mixture of C, C++, and assembly patches.

What's the best way to handle communication between the debugger GUI and the debugging engine? The two will be running in separate processes.

Thanks!

Andy

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

顾北清歌寒 2024-09-04 08:53:03

如果您需要 Windows Vista 或更高版本以及 .Net 3.5 或更高版本,命名管道可以提供简单、高性能的 IPC。查看这篇文章

If you can require Windows Vista or later, and .Net 3.5 or later, Named Pipes provide simple, high-performance IPC. Check out this article.

随波逐流 2024-09-04 08:53:03

几年前我就这么做了。脚本调试器用C#编写,在PC上运行;脚本运行时是用 C++ 编写的,可以在我们当时支持的所有设备上运行 - PC、PS3、Xbox360、Wii、DS、PSP 和 PS2。

无论您的目标是什么,我都建议放入某种层,以便调试器和运行时与底层协议隔离。将 API 调用放在您可以监视的地方!这//让你的选择保持开放,并且(如果做得正确)简化了两端的代码。某种基于数据包的系统(数据包大小为 1K 或更少)可以很好地映射到任何内容。 (仅使用公共 API,可以在更高级别完成 >1K 的传输。)

如果您仅针对 PC,我建议使用 TCP/IP。它是网络透明的,每个人都熟悉它的 IP 地址和端口,使用 API 并不比命名管道难。

对于下一代游戏,如果您想在跨平台兼容性和易于编码之间取得良好的平衡,TCP/IP 仍然是最佳选择。适用于 PC、Xbox360 和 PS3。

(关于命名管道,据我记得,SN的目标管理器将为您提供对PS3和PS2的命名管道支持,并且它通过开发LAN端口而不是游戏LAN端口,但Xbox360根本不支持它。所以它可能值得支持它——如果我没记错的话,这是你在 PSP 中的唯一选择——但就我

个人而言,我在实现 TCP/IP 支持后就停止了,我很高兴我这么做了!总而言之,Wii 和 DS 都很糟糕,但方式不同,而且 PSP 只支持命名管道,原因不明。 PS3 和 PS2 支持 TCP/IP,但只能通过游戏 LAN 端口。 (开发 LAN 端口的工作方式不同。不要使用它。向您的制作人索取更多网络电缆并保持理智。)Xbox360 支持 TCP/IP,但前提是您使用调试库,并且仅通过游戏IP。(调试 IP 的工作方式不同。不要使用它。)

简而言之,无论您做什么,都需要该绝缘层。

I did this a couple of years ago. Script debugger was written in C#, and ran on PC; script runtime was written in C++, and ran on everything we supported at the time -- PC, PS3, Xbox360, Wii, DS, PSP and PS2.

Whatever you're targetting, I'd recommend putting in some kind of layer so that the debugger and runtime are insulated from the underlying protocol. Keep the API calls where you can keep an eye on them! This //leaves your options open, and (if done right) simplifies the code at both ends. Some kind of packet-based system, with packets of 1K or less, maps tolerably to just about anything. (Transmission of >1K can be accomplished at a higher level, using only the public API.)

If you're only targetting PC, I recommend TCP/IP. It's network-transparent, everybody is familiar with its IP addresses and ports, it's no harder to use API-wise than named pipes.

For a next gen title, if you want to strike a good balance between cross platform compatibility and ease of coding, TCP/IP is still the way to go. Works on PC, Xbox360, and PS3.

(Regarding named pipes, SN's Target Manager will give you named pipe support for PS3 and PS2, as I recall, and it goes via the dev LAN port rather than the game LAN port, but Xbox360 doesn't support it at all. So it might be worth supporting it -- and it's your only option in PSP, if I remember rightly! -- but it's not a universal panacea.

Personally, I stopped after implementing TCP/IP support, and I'm quite glad I did! As a summary, the Wii and DS are both horrid, but in different ways, and unlike anything else. The PSP only supports named pipes, for some unknown reason. The PS3 and PS2 support TCP/IP, but only via the game LAN port. (The dev LAN port works differently. Don't use it. Ask your producer for more network cables and save your sanity.) The Xbox360 supports TCP/IP, but only if you're using the debug libraries, and only via the game IP. (The debug IP works differently. Don't use it.)

In short -- whatever you do, you'll need that insulating layer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文