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?
Comments
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:Core Debug
Core Profile
Core Release
Debug
Profile
Release
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
Bounce
demo plugin.The
__orxPLUGIN__
is only defined inside the compile unit of a plugin (when they includeorxPluginAPI.h
actually), 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.
Not quite.
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 exposesorx_Execute
. Changing the platform to x64 for some reason causes__orxPLUGIN__
to no longer be set, and thereforeorx_Execute
to 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.h
,orx_Execute
is 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_Execute
isn'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 (
orxCrypt
andorxFontGen
), 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.