64-bit Visual Studio 2017 project is not set to compile in plugin mode by default

edited February 2019 in Help request

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 include orxPluginAPI.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.

    @iarwain said:
    Does this match what you're seeing?

    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 exposes orx_Execute. Changing the platform to x64 for some reason causes __orxPLUGIN__ to no longer be set, and therefore orx_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?

  • edited February 2019

    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:

    #ifndef __orxPLUGIN__
    
  • edited February 2019

    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 and 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.

Sign In or Register to comment.