It looks like you're new here. If you want to get involved, click one of these buttons!
I'm not sure if this is intended behavior or not, but
__orxPLUGIN__ is not being defined in the x64 platform in the dynamic debug configuration. Is this normal? Can it be changed? Should it be changed? As it stands right now, no
__orxPLUGIN__ means no
orx_Execute entry point. Has it been deprecated or something?
Hi @sonicbhoc nice to see you here!
So, assuming you've synced the repository (either git or hg, doesn't matter), and ran
setup.bat, you should have a VS2017 solution with the following configurations:
You should be building any of the non-core configuration, which should lead to the compiling of all the plugins in embedded mode as well as the
__orxPLUGIN__is only defined inside the compile unit of a plugin (when they include
orxPluginAPI.hactually), and should be transparent to the end user.
Does this match what you're seeing?
Hey, @iarwain! I missed working with this engine, so I kinda want to toy around with it again.
So, I sync the repository and run
setup.bat. Without making any further changes, compiling in the Debug configuration on the x86 platform generates a dynamic library that exposes
orx_Execute. Changing the platform to x64 for some reason causes
__orxPLUGIN__to no longer be set, and therefore
orx_Executeto no longer be exposed (or compiled in at all, since it's a compiler conditional). I need that function for C# Interop (yeah, I'm still doing that, but I'm actually going about it in a way that actually makes sense now). Is it safe to simply define
__orxPLUGIN__in the global preprocessor definitions or are there other considerations I should make?
That's the thing though,
__orxPLUGIN__is never defined outside plugins, neither in 32bit nor in 64bit.
If you check
orx_Executeis only defined iff
__orxPLUGIN__is not defined:
So does that mean I should be compiling Orx as a static library?
EDIT: Nope, it has to be a DLL. But, the standalone tutorial says I can write my own. I think I can handle that.
I have to admit I'm not very knowledgeable with the C# interop part, however writing your own version of
orx_Executeisn't complicated, it's mostly a convenience function for the most common case and offers a ready to use game loop.
If you look at the tools (
orxFontGen), they both have their own version as well, as they don't have the same requirements.
Cool! The only thing I was looking for was a proper entry point, so knowing that I can make one tailored to my use case is much better. I can think of a few killer features I can implement regarding logging, too.