Porting OHRRPGCE to C / C++ / C#

Hello everyone. And since this is my first post on the forum, nice to meet you all I found OHR a week ago, and am very glad such a great RPG engine exists. I already learned how it works and plan to make my own games at some point.

Being an open-source gamer and occasional developer, I like to look at the technical side of things. I noticed that OHRRPGCE was first created in Qbasic, the latest version using Freebasic. I know some basic C#, but barely heard of Freebasic before. Although I don't know it well and can't judge, Freebasic doesn't feel like the most stable and advanced programming language to me at this day. Since I found OHRRPGCE, I've been wondering if it might ever get ported to C++ entirely.

Earlier on the wiki, I noticed that someone is already working on this, the project being called OHR++. Apart from the name and not being in the "abandoned projects" list however, I can't find any information on it, and some links appear to be broken.

Does anyone know if the OHR++ project is still alive? If not, is anyone else working (or planning to work) on porting the engine entirely to C / C++ / C#? I vote for this idea, since I believe it might improve (or allow improving) some limitations as well as stability, even if it wouldn't become the official OHR.

As far as I know, the OHR++ rewrite is long dead. I haven't heard anything new about it for years.

FreeBasic is still being actively developed, and the FreeBasic devs are working on a gcc backend. When this is finished, it should be possible to compile the OHRRPGCE for any platform that has a gcc port (which is more or less all of them)

We have also tossed around the idea of trying to create our own Freebasic->C++ source code translator. TMC has even done some experimental work on that, however, this approach doesn't have any obvious advantages as compared to waiting for the FreeBasic gcc backend.

The possibility of re-writing the engine in C++ or another language (python?) always exists, and whenever somebody steps forward to try I always give them all the encouragement I can, but it is a monstrously big project to be re-writing, so I understand why nobody has been able to do it.

I think that some languages are better than others, and that FreeBasic is not that great of a language, however, I also believe that making gradual incremental changes to a system that works is almost always better than scrapping a working system in favor of building a new system. No matter how conceptually better the new system might be planned to be, you cannot erase the fact that re-implementing a system requires a huge up-front investment of work to get past that long initial non-working stage.

I see. Sorry to hear OHR++ is dead. I heard that Freebasic will improve most limitations too, but I'm still unsure how up to date and compatible it would be able to stay compared to C. Not that I don't trust Freebasic is a good language, and will always stay updated too.

And I thought of a code converter, which would be nice idea. It would allow the normal code to keep being developed, and platform-specific versions to be automatically converted from latest SVN /GIT. Problem is, did anyone make a freebasic -> C++ converter yet? Not specifically for OHR, but an interpreter that can translate any file from one language to the other. I imagine it would be a difficult task, since it would have to read and know how to translate every detail. But maybe in the future such a thing will happen, since it would likely be helpful for tons of open-source projects, and OHR could use it too.

Hi, welcome.


Oh dear, if you search the wiki for "OHR++" you'll see that there's a page called "OHR++" but I can't find any way to actually view it! I would guess that some mediawiki update broke this.

The project's homepage is at http://ohr++.castleparadox.com/wiki/



Actually there would be a number of benefits, such as faster and more compact resultant machine code, the option of creating a new FB dialect rather than put up with pointless restrictions, and being able to easily extend FB with C++ features (have the FB devs have finally implemented virtual methods yet?). The drawback is that it's a lot more work than simply waiting for someone else to do everything.

A code converter/translator is a bad idea and here's why: The code it generates will not be properly optimized(unless the converter/translator is made right). A direct conversion from one language to another can lead to unstable code and other mishaps. I learned this the hard way when I attempted to manually convert one program in one language to another by hand, using similar functions in both languages. The code was badly unoptimized for the target language and contained lots of redundant code. The language I came from was a class-less language, and the one I was going to supported classes. The new didn't make use of this new facility, or any of the languages special functions and modules in place to optimize most of what I was doing in less lines of code...

Because of the differences between FreeBASIC and C/C++/especially C#, the converted code would be even more difficult to maintain, and on top of that, the new code won't be making proper use of new languages features for multimedia processing. Again these can be negated if the converter was thoroughly done(which can take maybe just as long as it can take to just port the thing over from scratch). I wish James knew Java when he first started, then we'd definitely have a portable engine. Time machine anyone?

To allay your fears: as it happens, almost nothing you said applies to fb2c++, for one reason or another. For example, FB does almost no optimisations (just some peep-hole optimisations), so even the most irreversible mangling by the translator will still produce a much faster and smaller binary. fb2c++ uses a C++ templated class library (already written) which wraps FB arrays and strings, meaning it is much more efficient than the C code produced by fbc -gen gcc. The output code is as close as possible to the input code, which is very close indeed.

But I'm getting pretty sick of talking about fb2c++, because I am likely to never work on it again because I have so much else to do.


!?!?