Is there any possible to port a C++ game project to use Unity?

Hello everyone,

I have some C++ game projects with resources (image, data...), I want to port these projects to DLL or whatever which can import to Unity and call it to run as mini games in my Unity project.
But as far as I know, create DLL for Unity only contains game logic, no resources.
Is there any possible to port a C++ game project with resources to use Unity? Is my goal achievable?
I would appreciate any advice.

Thank you very much.

 

Not quite....

If you have raw data stored as code using something like xbm format , you can make a loader for that.

As for making the whole C++ game run under unity, that will be difficult and probbaly not even worth it. The easiest route is to reimplement every game in Unity/C#. If your game uses software rendering, then it could be made to run as a dll from under unity (because you can write a C++ function to fill texture data), but if it is hardware accelerated, it is, frankly, not worth the hassle.

See documentation on native plugins for more info:
https://docs.unity3d.com/Manual/NativePlugins.html

One issue while interfacing with C++ is that you're required to write plenty of glue code, and should be careful to ensure that all data is being marshalled properly. It is very tedious.

 

Thank you very much for your quick reply. I really appreciate the information you provide.

I also thought about rewriting the entire game with Unity, but doing so might change the experience of these games.
So it's not possible to port C++ games that run on Unity? Because I'm going in this direction but haven't found a suitable solution yet. If it's not possible or it takes a lot more work than rewriting games with Unity, I will find another way to achieve goal.

 

Choice of language isn't going to affect the experience. Choice of engine can have an effect depending on the engine but that's going to happen regardless of whether you choose to use the original C++ or rewrite it in the language of the engine.

 

Thank you for your advise. But I want to confirm that is it possible to port complete C++ game project to call from Unity as DLL or plugins?
I would be very grateful to hear from you.

 

Like I said, it is pretty much only reasonably possible to do if your game is using software rendering.

In this case you'll declare some sort of

Code (csharp):

1.  
2. extern "C"{
3.     void getCurrentaFrame(RGBA *pixelData, int screenWidth, int screenHeight);
4. }
5.  

And use that to fill texture on unity side.

Native plugin API also allow interaction with raw graphics:
https://docs.unity3d.com/Manual/NativePluginInterface.html

But in this scenario you'll be fighting unity, because unity has its own event loop and its own functions for managing graphical resources.

Finally, there are things like this:
https://docs.microsoft.com/en-us/do...te?redirectedfrom=MSDN&view=net-6.0#overloads
https://forum.unity.com/threads/communicating-c-with-c.89930/
Which in theory allow you to call C# parts of unity code from C++, meaning you could attempt to create intricate system of callbacks and juggle monobehaviors and unity objects from C++, but it will require so much glue code that I don't see the point.

So, you technically may be able, but practically it is not worth it.

The main point of using the engine is extremely fast prototyping speed and ease of using the resources, plus supporting multiple platforms. By trying to stuff a C++ codebase into engine you're kinda fighting the good parts of the engine, at which point the question is do you even gain anything from using unity.

 

Yes, and it's a real headache for all the reasons mentioned by @neginfinity.

Speaking of headaches I'm assuming there is a security headache involved too, right?

 

Honestly, I can't think of a security headache off the top of my head.

C++ dll can't compile new code of any sort, it is static and remains unchanged. A virus could infect a dll, but it can infect ANY dll, and given that right now windows OS works in restricted mode by default, C++ dll isn't any different or especially dangerous.

A MUCH bigger security threat would be a project that has embedded interpreted language with an eval() or repl loop. A program that uses python or javascript is a potential security problem. C++ by default is not exactly unsafe.

Now, maybe you're referring to sprintf/sscanf functions that had issues and potentially could lead to buffer overrun. However, those are kind of an ancient dialect, and come from C. C++ way would be using sstream, boost and so on.

 

I was thinking along these lines though not necessarily a virus but you're right anyone or thing could just modify the .NET DLLs too.

 

What game engine do those use? XNA?

Why would this be software rendering? If you have for example an OpenGL based game, you can also let it render to a texture and then display that texture in Unity via the low level API. That would keep hardware acceleration in tact.

Btw. DLL-replacing is indeed a viable attack vector. However that requires arbitrary code execution on your machine, so that's not directly an additional security risk as long as you don't allow users to somehow share their own mini game DLLs and let other people run them.

 

Except when you're on Mac, use metal API and there's no OpenGL?

Software rendering is easier because it is agnostic to your graphic API, and only requires a buffer to write into.and nothing else. And that buffer can be provided by anything. Hardware accelerated game is dependent on specific graphic API and will fight unity trying to be exclusive. So you're losing all unity advantages and fight the engine in a roundabout way.

Your suggestion reminds me of skyrim spellglyph mod (MageVR) in VR. That mod allowed you to draw glyphs in air in VR, and it was done by running unity engine in background and rendering glyphs there, because they couldn't hijack skyrim rendering properly. The performance wasn't exactly good.

 

Hence why I ask the thread starter about the engine they used. They started with "I have some C++ game projects with resources (image, data...)", so I strongly assume they already have a running game including its own hardware accelerate rendering and just want to bring that rendered end-result into Unity.
Of course if they want to rewrite it all to actually use Unity's rendering, it's most likely better if they redo it in C#.

Performance can be okay. I do this with the radar-style minimap of a game I'm working on because the whole procedural terrain generation lives in a DLL.

 

In this scenario I would assume that there's no engine and it is naked libsdl or something similar. But. I might be putting too much faith into people.

Regarding conversion, it sort of reminds me of Fable remake. They had their own engine in the original game, but switched to a stock engine in the remake.

 

Yes, there is no engine, it's c++ project with some libraries such as SFML, sorry for the lack of information.

It's great. Can you recommend some techniques you've used? My goal is to render the game to unity, if possible I can call the event to Unity at the end of the game for example.

 

It's a bit complex to explain, but basically I started with this example which contains the basics. Even in a platform-independent way: https://github.com/Unity-Technologies/NativeRenderingPlugin

However I would not recommend rendering a whole game like that. It probably will be more hassle than rewriting the game in Unity directly..

 

*sigh*
Start reading here:
https://docs.unity3d.com/Manual/NativePluginInterface.html

You need to use native plugin interface, then you'll need to hijack graphic events to create and release resources. Resources would be created normall, they you'd do that without SFML.

The rest is like DragonCoder said. You need to modify C++ part so it renders onto native texture.

And as it was said, this approach is not recommended.

 

I will review all solutions and their feasibility.
Thank you so much for your support @neginfinity, @Ryiah and @DragonCoder.