Orx/Scroll Tutorial - Binding Objects Error

Hey guys, I'm busy going through the tutorials for Orx/Scroll and, during the Object Binding stage, I've encountered difficulty binding the EnemyBug class to the "O-EnemyBug" game object defined in the config file provided by the tutorial. Specifically, the program fails to compile when I add the call to "ScrollBindObject" and I get a "vtable not found for EnemyBug" linking error, which perhaps means that the problem lies with the way I'm implementing the inherited ScrollObject's virtual methods. I was wondering if anyone could offer some insight as to what I'm doing wrong? I'm using MinGW to build the project for Windows, the skeleton of which I generated using the init script supplied with the main Orx library.

I've attached a .zip of the project files if anyone wants to have a look. The structure is mostly identical to that of the tutorial's, with the main difference being the files generated by the init script.

Comments

  • edited July 2019

    Hi @LudiG, I should be able to have a look either tonight or over this weekend and I'll let you know what I find.

  • edited July 2019

    Hi again,

    I was able to do a quick test on my side. I didn't see any issues with your code, however I had to make two changes in order to get it working with the archive you posted:

    • I copied the latest Scroll from https://github.com/orx/scroll to your src/include folder
    • I replaced the content of src/TestOrxScroll.cpp with the one of src/OrxScroll.cpp, deleted src/OrxScroll.cpp and re-ran premake4 to regenerate the build files (they both had a main function)

    After that I was able to successfully compile/link with both MinGW (GCC 6.3.0) and VS 2015. I had nice ladybugs walking around as a result, with both executables. :)

  • Hi @LudiG let me know how you get on. I fixed some of the orx/scroll tutorials so I'm keen to make sure they work properly for new comers.

  • @sausage Will do. I'm still having trouble, but now I'm sure that it's my build environment at least.

  • @iarwain When you ran premake4 to generate the gmake makefiles, what parameters did you pass?

  • edited July 2019

    To generate the makefile I called premake4 gmake.

    Are you using MinGW with gcc 6.3.0? That was the version used until last night.

    If you sync the bitbucket repository (hg), I upgraded orx to MinGW-w64 last night, with gcc 8.1.0, so it's also an option, this time with both 32bit and 64bit supported.

    Another thing to note is that using some custom terminal replacement, such as cmder, for example, seems to introduce compile time issues, but I have not yet pinpointed the exact reason.

    Lastly, visual studio, community edition, tends to be less error prone as well, so it might be a more robust solution, especially during a learning phase, as it's free even for commercial uses with a maximum of 5 users per company. We currently support 2015 and 2017 editions.

  • @iarwain The version of MinGW I'm using was last updated in April. I'm not sure what you mean by using gcc 6.3.0? I do have that binary in my MinGW directory, although the tutorial naturally gets compiled using the g++ binary, as specified by the Makefile. I am using the 32-bit version of MinGW, however it's possible that the problem lies with my specific version. There seems to be many different sources from which I can grab it. It has worked so far for me, though.

    I have tried building the tut through the regular Windows command prompt, if that answers the second part.

    Giving Visual Studio a try is also an option.

  • @iarwain @sausage I just got it working. Turns out I needed to update orx to 1.10 (I was working on 1.9), so it was my build environment that was the problem. Pretty dumb of me to only check that now, but oh well. Thanks for your help though, I very much appreciate it.

  • Thanks @LudiG good to hear it's working. Now onto the rest of those tutorials. Let me know if I can help at all.

  • Glad you got it working.
    The issue with MinGW is that C++ ABI isn't standardized and MinGW/GCC tend to break backward compatibility regularly.

    I'd also recommend not using any binary release of orx. 1.9 is 1.5 years old and 1.10 is already 6 months old. The source repository is kept in a rather stable state and will contain latest bug fixes and features as well. Orx also compiles out of the box effortlessly. I believe we do have a tutorial for this as well, starting at http://orx-project.org/wiki/#getting_orx

  • @iarwain I do have a local copy of that repository that I build with MinGW, I just forgot to keep it synced.

  • The other advantage of using the repository is that updating it will keep the ORX environment variable up to date, which means any project created with init will automatically find that version of orx, without the need of copying anything manually.

Sign In or Register to comment.