Today we’ll continue the series by addressing a nagging problem: how do we build the C++ plugin? With C# we inherit, for better or worse, Unity’s build system where we just edit .cs files and press the play button. This doesn’t work with C++, so we’ll need to build something similar that’s just as easy to use.
Posts Tagged plugin
Last week in the series we took a step back to verify that the C++ plugin’s performance was acceptable. With that confirmed, we’ll continue this week by making our programming lives easier. One pain point so far has been with exposing new Unity APIs to C++. It’s not that it’s difficult to do this, but there’s a lot of boilerplate required. That boilerplate takes time to write and it’s easy to make mistakes copying and pasting existing functions. So this week’s article introduces a code generator that will write the boilerplate for us! We’ll also reorganize the project a little so the code that supports C++ scripting is separated away from our game code. That’ll make it easy to add support for C++ scripting to any Unity project.
In the first three parts of this series, we focused on setting up a development environment that makes it easy and safe to write our game code in C++. Today’s article takes a step back to assess where we are in terms of performance. Is what we’ve built so far viable, or are the calls between C# and C++ too expensive? To find out we’ll use the existing framework to write some simple performance tests.
Last week’s article continued the series by eliminating the need to reboot the editor for every change to the C++ plugin. The idea is to make a more productive environment for us, the programmers, to work in. This week we’ll continue that theme by mimicking the object-oriented Unity API in C++. So instead of int transformHandle = GameObjectGetTransform(goHandle) we’ll write a more familiar Transform transform = go.GetTransform(). Also, we’ll build a simple system to automatically clean up object handles so we don’t have to do that manually.
Last week we began the series by establishing two-way communication between C# and C++. We used object handles to pass class instances between the two languages. Everything was going great, but then there was a major productivity problem: we had to restart the Unity editor every time we changed the C++ plugin. Today’s article is all about how to overcome that obstacle so you can iterate on your code just like with C#.
For all of the nice things about C#, writing code with it also comes with a lot of downsides. We spend so much time working around the garbage collector, working around IL2CPP, and worrying about what’ll happen if we use a foreach loop. Today’s article starts a series that explores what would happen if we escaped .NET and wrote our code as a C++ plugin instead of using C#.
Sizable applications are often in need of externalizing code from the main application. Often times this is done via a library or framework and it is well understood in the Flash community how to use these in our applications. What is less-understood is how we can go about delegating some parts of our applications to plugins. Read on for a simple technique to get plugins into your Flash application.