Hi guys,

I wanted to get some idea on how to deal with a problem I created for myself over the last few months.

I started building small games a few years ago, trying to make perfect functional copies of Pong, Space Invaders, Pacman, etc. With each new project I built on top of the same little engine, adding more stuff, and retooling it with each new game. The engine is in C++ and using DirectX.

Now, my current project, on which I've been working for nearly a year, is an RPG and I started testing stuff and building an editor for it, but this time to test a few things out quickly, I used Delphi (Pascal language) which I've been using since 1995, and I'm pretty good at it. It builds user interfaces in the blink of an eye.

But as weeks went by, I added so much stuff that I built a very feature-rich editor (map, dialogue, combat, etc), all in Pascal, complete with unit tests for game logic. I did not intend to do any serious coding in Pascal, but it was so easy that I let myself believe it was all going to work out fine. It ain't.

So now I'm stuck with wanting to expand the engine in C++, but all my game code is in Pascal, and works properly. I have a massive number of Pascal files, covering everything from AI to maps to anything else you can think of. Except the actual "run-time", the engine itself.

I have a few options I thought of, most of them are problematic, so this is where I would appreciate some insights.

I can bite the bullet and convert everything to C++, but since the game isn't complete yet, that would mean so much work...

I can use DLLs to have the engine access the game logic, but object oriented and DLLs don't play well together I think, so that's another nightmare.

I can rewrite the engine part in Pascal, and have all the code play well together. While I love Delphi and Pascal, the IDE is fickle and the rarity of Pascal code in the industry would lock me out of a lot of what's out there in term of open source, etc.

I am pretty depressed about the hole I put myself in, and if anyone of you guys have dealt with multiple languages like this, be it Pascal, or whatever else, I would appreciate some advice.

Thanks!

I think you pretty much covered the options of trying to merge two rocks into one; one of the rocks must move.

You can look for a more automagic solution; there are convertor programs that take a program in one language, and convert it to another language.
Don't know what exists for your situation though, but a lot of people have legacy Delphi stuff, so my guess is some people must have tried this.
At a simpler level, if you used a (mostly) consistent coding style, you might get pretty far with a simple text recognition and replacement program specifically written for your code.
It will likely require some pre-conversion editing, and definitely some post-conversion editing, but you should be able to convert the bodies of the functions at least, thus reducing the amount of work significantly.

The other direction is to keep both rocks; it's not fundamentally wrong to have two separate programs together forming one game. Especially an editor and "the game program" are sufficiently different functions that a player won't think twice about it.
You need to have an exchange of data, at least from the editor to the game program, eg by means of "save scenario / load scenario" through a file or so.
Further integration can be done here, launch one program from the other, or have both running at the same time. You can talk to the other program through an internal 'network' connection (pipe).

I don't know Windows at all, but perhaps write a gui front-end that uses both programs to display things?


If you do decide to bite one rock, and convert it into the other language, please keep in mind that a 1-to-1 rewrite is quite doable. It's a lot of work, but due to the 1-to-1 notion, it doesn't require deep design considerations.
You will likely find spots that you want to improve, but don't until you finished the conversion. (Just add a marker "// IMPROVE What was I thinking?!").

If the rewrite includes "change a few things" you very quickly get lost in the quicksand of trying to convert much code, but it doesn't quite work due to the changes.
In such a case, you may want to call the current thing "version 1", and then design version 2 in the other language, where of course you are allowed to peek at previous solution for inspiration ;)

One of the main reasons for you to rewrite the game code seems to be the Delphi IDE. Why dont you try using Lazarus/FreePascal before you start rewriting everything in C++, its free and I read its striving to be compatible with many older Pascal implementations?

Also, it seems you can do function calls from one language to the other, which means you could just keep it that way. Just try to move a few parts when it allows you do have a smaller cross-language API? Then if you want to move some part to the engine you could only reimplement that part in C++, not everything.

One out for you could be Oxygne, Pascal for .NET. I have worked on stuff where there is C++ and CLR code and C++.NET is used to bridge between.

Never looked at Oxygne so not sure how easy you could port your Delphi stuff though

Small correction: DLLs work fine for "Object oriented" code, they can even be used with C++ as long as the DLL is built with the exact same compiler as the code using the DLL.

But if you're going to talk between languages you need a well defined binary interface. The most common one is C (not C++). But you'll sometimes see other things layered on top, like COM, which provide "object oriented" interfaces. .NET is also another option, as the MASM is well-defined and multiple languages all can compile down to it (C#, VB, and other third party compilers for other languages).

So you can do what you're asking, but you're going to at least need some kind of translation layer, which may have performance and memory costs.

In my personal experience, I would write the game and core code in C++, and then write the editor as a separate program, pulling in the C++ code (via some translation layer, usually C++/CLI to get it to talk to .NET) into the editor, which is written in a language better suited for UI programming (in my case, usually C# with WPF). The reasoning being that I can afford the memory and performance issues in the editor, but I want to avoid those costs in my game.

I have a few options I thought of, most of them are problematic, so this is where I would appreciate some insights.

What are the problems? Does the current Pascal codebase have any problem? If not, why do you insist on porting it to C++?

A game does not have to be built in C++.

Thanks a lot for all the replies!

@Alberth, Thanks for the extensive post. I made my decision and will continue on my current path of doign the engine in VS C++ and the editor in Delphi. I do have Rad Studio, so I can use C++ Builder in time to start the conversion.

@ryan20fun, I'm using the unmanaged version of Delphi, so AFAIK, pinvoke is out of the question. But hey, I know very little about it and I need to look into it. Thanks.

@WozNZ, huh, I havent heard about Oxygen in years! I'll take a peek and see where they're at. Thanks!

@SmkViper, I always tried to stay away from .NET and WPF, but it is so widely used that I should take a look at that since I have Vs. Thanks mate!

@alnite, My problem with Delphi/Rad Studio does not stem from the codebase in general, but rather the way Embarcadero is taking the product as well as the quality of the IDE itself. I have the IDE crash on me at least once a day. I end up chasing quirks deep in the VCL source, or rattling my brain trying to understand their Direct2D implementation since the docs are not that amazing. And frankly, as someone that has decades of programming experience but just trying to finish my first big game project, Pascal is not the way to go.

Please dont get me wrong. I love Delphi, but it will never match VS in term of power. I just watched a video on the new DirectX debugging features of VS2015 and I was blown away with how powerful it is and how deep you can investigate. Yet, interface-wise, nothing matches the speed at which you can pump out native Win32/64 apps.

Embarcadero isn't the same since Nick Hodges left...

And alnite, you're totally right, a game doesn't have to be written in C++. But I believe that using Delphi will make things more complicated. The first time around anyways!

Thanks all!

In the short term, writing your game in delphi is fine. However, you are right that the industry does not use delphi anymore.. And you will not likely get open source collaboration in delphi.

Eventually, I strongly recommend you experiment with C# and VS IDE to replace your delphi fast GUI prototyping. In fact the lead desigber of C# is Anders Hejlsberg, the same person who designed delphi.

You might even find you prefer coding in c# vs c++.. Totally acceptable for simpler games, and also the language used by unity.

My main concern is that developers should start treating their code as assets. People always get opinionated about programming languages. X is better. Y is faster. Z is easier. Whatever your preferred language of choice is, it doesn't really matter because you still have to put in the code, and that's where it takes the most of your development time, not your language being slower (or whatever). You have done the hard work, but now you are thinking of scrapping all that, and I hope it's not just because of some arbitrary reason like "C++ is better".

@alnite, My problem with Delphi/Rad Studio does not stem from the codebase in general, but rather the way Embarcadero is taking the product as well as the quality of the IDE itself. I have the IDE crash on me at least once a day. I end up chasing quirks deep in the VCL source, or rattling my brain trying to understand their Direct2D implementation since the docs are not that amazing. And frankly, as someone that has decades of programming experience but just trying to finish my first big game project, Pascal is not the way to go.

Please dont get me wrong. I love Delphi, but it will never match VS in term of power. I just watched a video on the new DirectX debugging features of VS2015 and I was blown away with how powerful it is and how deep you can investigate. Yet, interface-wise, nothing matches the speed at which you can pump out native Win32/64 apps.

Embarcadero isn't the same since Nick Hodges left...

And alnite, you're totally right, a game doesn't have to be written in C++. But I believe that using Delphi will make things more complicated. The first time around anyways!

From what I get reading your posts, it seems that you used Pascal for the editor, not for the game itself. I don't see much wrong with it. If you are inches away from completing the game, just hammer through it, finish it in Pascal, despite the IDE challenges. Even if the game is written in Pascal, if you are *that* close in finishing the game, just finish it. This happens all the time in studios, and that's because it makes sense financially and time-wise.

Future shiny version can be written in C++ if you prefer.