Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

116 Neutral

About deveee

  • Rank

Personal Information

  • Interests
  1. That's why I said that it's not that important. I suppose that there are some performance improvements due to newer arm generation, but I don't see any real difference in frames per second.   I probably won't implement it until other things will be finished. We'll see later.
  2. Thanks!   I just thought that the arm64 is fully supported and there is a bug somewhere.   It's not critical for us, because the armv7 build works on both armv7 and aarch64 platforms. I also didn't notice any performance improvements. I will make some tests with the auto wrapper functions, but I will finish other things first.   Regards, Deve
  3. The issue is a bit old, but I'm currently working on the STK Android port and I finally have a possibility to test it.   The arm64 compilation indeed works fine, but I get some errors on a console and the angelscript is practically not working on this platform.   I get something like: W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'int getCompletedChallengesCount()' (Code: -7) W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'int getChallengeCount()' (Code: -7) W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'bool isChallengeUnlocked(string &in)' (Code: -7) W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'int getChallengeRequiredPoints(string &in)' (Code: -7) W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'void squash(int id, float time)' (Code: -7) and then W/SuperTuxKart(27724): (0, 0) : ERR : Invalid configuration. Verify the registered application interface. E/SuperTuxKart(27724): Build() failed And then it says that scripting function is not found and it can't execute it.   Note that it works fine on armv7 build (on both armv7 and aarch64 devices). Only aarch64 build doesn't really work.   Do you have some ideas what may be wrong?   I can provide more info, test some patches etc. if you need.
  4. Actually there were two lines that I removed. It was this commit: https://github.com/supertuxkart/stk-code/commit/f351c359fd9100910e7e5336086233e24f73abeb   In our case it is placed in build directory: stk-code\build\lib\angelscript\projects\cmake\libangelscript.a   The path seems to be a bit complicated because cmake file is in "projects\cmake". Otherwise it would be: stk-code\build\lib\angelscript\libangelscript.a   If you need something more simple, you can use ${CMAKE_BINARY_DIR} for the LIBRARY_OUTPUT_PATH variable, for example something like: set(LIBRARY_OUTPUT_PATH ${CMAKE_BINARY_DIR}/angelscript/lib) set(RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/angelscript/bin) Though I didn't check if it works ;)
  5. The compiled library is placed in a directory related to project sources dir:   set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/../../lib)   This causes issues when you have more than single build directory in the project. I personally have maybe 10 different build directories for different compilers/platforms ;) (linux compilation, mingw-32bit, mingw-64bit, 32-bit linux static package, 64-bit static package etc...). All these build directories use by default single library which is placed in "${PROJECT_SOURCE_DIR}/../../lib". This causes erros when linking final executable. For example the 32-bit executable tries to link previously compiled 64-bit library.   Here is original bug report: https://github.com/supertuxkart/stk-code/issues/2325   We fixed this by just removing this line. It would be nice to make this fix upstream, so that we won't need to apply this modification after every update.
  6. To be honest, I didn't check the lastest angelscript version, but it looks that nothing has changed related to this issue.   We have some problems with compilation on arm64, mips/mips64/mipsel, ppc64el, s390x architectures. This bug prevents us from migrating to Debian Testing repositories.   Here is a bit more info: https://github.com/supertuxkart/stk-code/issues/2569 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830748   Could you have a look?   Regards, Deve
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!